From jwboyer at jdub.homelinux.org Sun Jul 1 01:03:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 30 Jun 2007 20:03:37 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630231540.GK15787@puariko.nirvana> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <20070630231540.GK15787@puariko.nirvana> Message-ID: <1183251817.10368.4.camel@vader.jdub.homelinux.org> On Sun, 2007-07-01 at 01:15 +0200, Axel Thimm wrote: > On Sat, Jun 30, 2007 at 07:07:29PM -0400, Alan Cox wrote: > > > And even though ppc is not expected to be a frontline arch, only 378 > > > boxes? Makes me feel like having a big share of ppc boxes. > > > > Most users won't be reporting anything > > Yes, that's the issue with these kind of statistics. > > At least for ppc one can get some comparative statistics by checking > the ratio of ppc to i386/x86_64 iso downloads. The correcting factor > would show how different the black numbers behind the smolt stats are > from i386/x86_64 to ppc and use that as a weighing factor for getting > improved estimators for ppc. Not really. Considering that: 1) iso downloads don't take yum upgrades into account, and 2) download statistics in general don't take local mirrors into account Smolt numbers show the people that voluntarily submit profiles. Download statistics show the number of downloads that hit the main servers. Neither can be used to derive estimators from the other. josh From sundaram at fedoraproject.org Sun Jul 1 02:55:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 08:25:42 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <20070630233910.GN15787@puariko.nirvana> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> <20070630233910.GN15787@puariko.nirvana> Message-ID: <468717AE.4050402@fedoraproject.org> Axel Thimm wrote: > On Sun, Jul 01, 2007 at 05:02:41AM +0530, Rahul Sundaram wrote: >> Axel Thimm wrote: >> >>> Whether it's "incorrectly" or not is up to the eye of the beholder, >>> and FWIW README.distribution is serving neither side of the >>> grammar. Or is this package really going to be used in a >>> "distribution"? I'm quite sure it will be. >> Distribution is just a off hand suggestion. Feel free to come up with a >> better name like others have suggested. > > How about README.Fedora? Axel, Don't waste everyone's time. Rahul From kagesenshi.87 at gmail.com Sun Jul 1 05:20:08 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sun, 1 Jul 2007 13:20:08 +0800 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> Message-ID: On 7/1/07, dragoran wrote: > [snip] > > I think ccp would be better, it also have a gconf-backend. > about desktop-effects: > there is not much that need to be changed there... > if we decide on what to use I can provide patches if needed ;) after I applied some of the patches from previous compiz package (with some modification in it) , and a little one-line patch in desktop-effects.c to load gconf plugin properly , desktop-effects is now back working .. but gnome-wm need some modfication to make compiz start on login I didnt apply the patches before because they was being rejected .. Like dragoran said, I also agree that ccp is a better choice .. because if we insist in using gconf, desktop-effects and gnome-wm need to do checking whether to load ccp or to load gconf plugin .. plus, the compizconfig-settings-manager requires user to use ccp plugin and it doesnt work with gconf plugin (compizconfig-backend-gconf != gconf plugin) .. for ccp, desktop-effects surely requires patching because the current desktop-effects is using gconf and not libcompizconfig .. > > > - the default installation provides several plugins that might pull > > more dependencies eg: fuse. to_split or not to_split > > do you have a list of this deps? > we could split it into compiz-fusion-plugins and > compiz-fusion-plugins-extras after some checking, I noticed fuse-libs is now standard in installations .. erm .. guess we dont need to split them then .. but I havent tested to yum it from a clean system .. so I might miss something > > > I just built today git checkout and they are available here > > > > > http://devel.foss.org.my/~kagesenshi/repo/private/testing/ > > > > feel free to play around with them .. > > thx, will look at them > > > about desktop-effects .. for systems with AIGLX, an environment var > > need to be exported before launching it to make it work > > > > export LIBGL_ALWAYS_INDIRECT=1 > > this should then be added to gnome-wm to because on login desktop-effects is > not inolved. > after the patch, the env var no longer requires exporting .. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From seg at haxxed.com Sun Jul 1 05:21:06 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 01 Jul 2007 00:21:06 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630230729.GB15010@devserv.devel.redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> Message-ID: <1183267266.22027.14.camel@localhost> On Sat, 2007-06-30 at 19:07 -0400, Alan Cox wrote: > On Sun, Jul 01, 2007 at 12:14:20AM +0200, Axel Thimm wrote: > > I also wonder what the 2.1% i386 are. These can't be true i386, or if > > they are they can't be 30x as many as i586. > > I'd been wondering if those are qemu/vmware/xen or something similar ? Generally those will report what the host CPU really is, as they're "virtualized" but they're still running on the host CPU. Though qemu's software mode may be different. I always run with kqemu, and Windows XP detects the Athlon 64 I'm running on. -------------- next part -------------- A non-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 Sun Jul 1 05:57:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jul 2007 07:57:25 +0200 Subject: OpenSceneGraph In-Reply-To: <468665FD.4080407@cs.nmsu.edu> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> <468665FD.4080407@cs.nmsu.edu> Message-ID: <1183269446.23976.13.camel@mccallum.corsepiu.local> On Sat, 2007-06-30 at 08:17 -0600, Rick L Vinyard Jr wrote: > Ralf Corsepius wrote: > > Hi, > > > > I've several times been asked to upgrade OpenSceneGraph to > > OpenSceneGraph-2.0 (on rawhide and may-be FC7) > > > > So far, there remain a couple of details unclear to me, I'd like to see > > clarified: > > > > * OpenSceneGraph-2.0 is completely incompatible to OpenSceneGraph-1.x! > > * Packaging, features and all SONAME have changed! > > > > Questions: > > > > * Is there anybody out there who is actively using (esp. developing for) > > OpenSceneGraph-1? > > > > Yes. In fact I was getting ready to submit packages for the VTP from > http://vterrain.org (initially including the libraries, VTBuilder and > Enviro). I've contacted the author to find out what the plans for > OSG-2.0 support are, and will follow up when I know more. OK. > In addition to that, I have vtgtkmm which is a library of VTP widgets > for Gtkmm (similar to the WX widgets included in libvtui from VTP). > > > * Is there anybody out there who is actively using Producer or who has a > > package which depends on (OSG-1's) Producer > > (OpenSceneGraph-2 has dropped Producer). > > > > I also have osgtkmm which is dependent upon Producer. However, a move to > OSG-2.0 wouldn't bother me at all. I'd much rather target OSG-2.0 anyway. OK. > > Should you answer to any of the questions above with "yes", please speak > > up ASAP. The background behind all this: Do people consider it worth to have OSG-1 and OSG-2 packages in parallel? The run-time environments/packages could rather easily be made installable in parallel (e.g. by introducing a set of OSG-2 packages), but implementing this for the devel packages would be non-trivial. For the moment, I've upgraded OpenSceneGraph to 2.0 on rawhide (replacing OSG-1), ... but I could revert this. > Just another side note on OSG examples... I noticed that none of the > data files are included so they run without textures, etc. Could you bugzilla this issue? Which data files are you referring to? OSG's sample data sets unfortunately can't be shipped with Fedora, due to licensing issues. Ralf From rc040203 at freenet.de Sun Jul 1 06:02:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jul 2007 08:02:38 +0200 Subject: RFE: Use generic names in packages In-Reply-To: <468717AE.4050402@fedoraproject.org> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> <20070630233910.GN15787@puariko.nirvana> <468717AE.4050402@fedoraproject.org> Message-ID: <1183269759.23976.17.camel@mccallum.corsepiu.local> On Sun, 2007-07-01 at 08:25 +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > > On Sun, Jul 01, 2007 at 05:02:41AM +0530, Rahul Sundaram wrote: > >> Axel Thimm wrote: > >> > >>> Whether it's "incorrectly" or not is up to the eye of the beholder, > >>> and FWIW README.distribution is serving neither side of the > >>> grammar. Or is this package really going to be used in a > >>> "distribution"? I'm quite sure it will be. > >> Distribution is just a off hand suggestion. Feel free to come up with a > >> better name like others have suggested. > > > > How about README.Fedora? +1 > Axel, Don't waste everyone's time. Rahul, you are wasting our time, by having made an issue from a non-issue. Users aren't as dumb as you seem to think. Ralf From jeevanullas at gmail.com Sun Jul 1 07:41:28 2007 From: jeevanullas at gmail.com (Deependra Singh Shekhawat) Date: Sun, 01 Jul 2007 13:11:28 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <1183269759.23976.17.camel@mccallum.corsepiu.local> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> <20070630233910.GN15787@puariko.nirvana> <468717AE.4050402@fedoraproject.org> <1183269759.23976.17.camel@mccallum.corsepiu.local> Message-ID: <1183275688.10005.0.camel@localhost.localdomain> On Sun, 2007-07-01 at 08:02 +0200, Ralf Corsepius wrote: > On Sun, 2007-07-01 at 08:25 +0530, Rahul Sundaram wrote: > > Axel Thimm wrote: > > > On Sun, Jul 01, 2007 at 05:02:41AM +0530, Rahul Sundaram wrote: > > >> Axel Thimm wrote: > > >> > > >>> Whether it's "incorrectly" or not is up to the eye of the beholder, > > >>> and FWIW README.distribution is serving neither side of the > > >>> grammar. Or is this package really going to be used in a > > >>> "distribution"? I'm quite sure it will be. > > >> Distribution is just a off hand suggestion. Feel free to come up with a > > >> better name like others have suggested. > > > > > > How about README.Fedora? > +1 +2 > > > Axel, Don't waste everyone's time. > Rahul, you are wasting our time, by having made an issue from a > non-issue. Users aren't as dumb as you seem to think. I completely agree. Users aren't dumb. > > Ralf > > > -- http://freeshells.ch/~source/ From drago01 at gmail.com Sun Jul 1 07:57:12 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 01 Jul 2007 09:57:12 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> Message-ID: <46875E58.3030106@gmail.com> Hikaru Amano wrote: > On 7/1/07, dragoran wrote: >> > [snip] >> >> I think ccp would be better, it also have a gconf-backend. >> about desktop-effects: >> there is not much that need to be changed there... >> if we decide on what to use I can provide patches if needed ;) > > after I applied some of the patches from previous compiz package (with > some modification in it) , and a little one-line patch in > desktop-effects.c to load gconf plugin properly , desktop-effects is > now back working .. but gnome-wm need some modfication to make compiz > start on login > yes you only have to load the glib plugin before loading gconf ... attached patch fixes this for gnome-wm > I didnt apply the patches before because they was being rejected .. > > Like dragoran said, I also agree that ccp is a better choice .. > because if we insist in using gconf, desktop-effects and gnome-wm need > to do checking whether to load ccp or to load gconf plugin .. plus, > the compizconfig-settings-manager requires user to use ccp plugin and > it doesnt work with gconf plugin (compizconfig-backend-gconf != gconf > plugin) .. > +1 also using ccp allows us to use the compiz-settings tools and not require user to use gconf-editor. > for ccp, desktop-effects surely requires patching because the current > desktop-effects is using gconf and not libcompizconfig .. > yes I now.. but what is the compiz maintainers opinion on this? krh? >> >> > - the default installation provides several plugins that might pull >> > more dependencies eg: fuse. to_split or not to_split >> >> do you have a list of this deps? >> we could split it into compiz-fusion-plugins and >> compiz-fusion-plugins-extras > > after some checking, I noticed fuse-libs is now standard in > installations .. erm .. guess we dont need to split them then .. but I > havent tested to yum it from a clean system .. so I might miss > something > ok, then leave it like upstream does. >> >> > I just built today git checkout and they are available here >> > >> > >> http://devel.foss.org.my/~kagesenshi/repo/private/testing/ >> > >> > feel free to play around with them .. >> >> thx, will look at them >> >> > about desktop-effects .. for systems with AIGLX, an environment var >> > need to be exported before launching it to make it work >> > >> > export LIBGL_ALWAYS_INDIRECT=1 >> >> this should then be added to gnome-wm to because on login >> desktop-effects is >> not inolved. >> > > after the patch, the env var no longer requires exporting .. it doesn't have to be exported. just call setenv() in desktop-effects.c and in gnome-wm start compiz with LIBGL_ALWAYS_INDIRECT=1 compiz ... btw. I would suggest to use --ignore-desktop-hints by default. because else compiz uses viewports *and* workspaces at the same time when started via desktop-effects ...which is just weird. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome-wm-compiz-fusion.patch Type: text/x-patch Size: 571 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Jul 1 08:01:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 13:31:45 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <1183269759.23976.17.camel@mccallum.corsepiu.local> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> <20070630233910.GN15787@puariko.nirvana> <468717AE.4050402@fedoraproject.org> <1183269759.23976.17.camel@mccallum.corsepiu.local> Message-ID: <46875F69.6000605@fedoraproject.org> Ralf Corsepius wrote: > Rahul, you are wasting our time, by having made an issue from a > non-issue. Users aren't as dumb as you seem to think. You got to stop assuming what I think of users. If you consider merely asking for comments wasting time you are free to ignore this thread and let people who have constructive suggestions participate. Thanks. Rahul From nigel.metheringham at dev.intechnology.co.uk Sun Jul 1 08:18:38 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Sun, 01 Jul 2007 09:18:38 +0100 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <1183251817.10368.4.camel@vader.jdub.homelinux.org> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <20070630231540.GK15787@puariko.nirvana> <1183251817.10368.4.camel@vader.jdub.homelinux.org> Message-ID: <4687635E.4060601@dev.intechnology.co.uk> Josh Boyer wrote: > Smolt numbers show the people that voluntarily submit profiles. > Download statistics show the number of downloads that hit the main > servers. Neither can be used to derive estimators from the other. > One of the question is can the figures be used to derive proportionate information from the data set - ie approximately what proportion of people have (say) i586 systems from the rpm point of view. Even if we can get that information out of smolt for the systems reporting to smolt (and by the looks of things the question is rather more complex than uname -m), are i586 boxes equally likely to have enabled smolt reporting as current generation boxes.... Nigel. From drago01 at gmail.com Sun Jul 1 08:32:25 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 01 Jul 2007 10:32:25 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <46868B83.5030006@redhat.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> Message-ID: <46876699.90801@gmail.com> Mike McGrath wrote: > Nigel Metheringham wrote: >> Having watched from the sidelines I updated my VIA mini-ITX system >> yesterday. Its an original 800 MHz model. >> >> Fedora installs for an i586 on it - 586 kernel etc. However, at least >> post F7 upgrade (meaning I didn't check beforehand) uname -m and arch >> report i686. Smolt also sees this as an i686 - in fact the complete >> profile is at > Whats the right way to determine the arch of the box? > you could try rpm -q --queryformat %{ARCH} kernel From Lam at Lam.pl Sun Jul 1 08:37:12 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 01 Jul 2007 10:37:12 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <46876699.90801@gmail.com> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> <46876699.90801@gmail.com> Message-ID: <1183279032.3772.0.camel@pensja.lam.pl> Dnia 01-07-2007, nie o godzinie 10:32 +0200, dragoran napisa?(a): > you could try > rpm -q --queryformat %{ARCH} kernel Especially on 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 rc040203 at freenet.de Sun Jul 1 08:43:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jul 2007 10:43:23 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <4687635E.4060601@dev.intechnology.co.uk> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <20070630231540.GK15787@puariko.nirvana> <1183251817.10368.4.camel@vader.jdub.homelinux.org> <4687635E.4060601@dev.intechnology.co.uk> Message-ID: <1183279404.23976.33.camel@mccallum.corsepiu.local> On Sun, 2007-07-01 at 09:18 +0100, Nigel Metheringham wrote: > Josh Boyer wrote: > > Smolt numbers show the people that voluntarily submit profiles. > > Download statistics show the number of downloads that hit the main > > servers. Neither can be used to derive estimators from the other. > > > One of the question is can the figures be used to derive proportionate > information from the data set - ie approximately what proportion of > people have (say) i586 systems from the rpm point of view. Even if we > can get that information out of smolt for the systems reporting to smolt > (and by the looks of things the question is rather more complex than > uname -m), are i586 boxes equally likely to have enabled smolt reporting > as current generation boxes.... IMO, probably not, because i586 boxes tend to be small boxes, with scarce resources, which tend to be administrated, installed and used differently from "big boxes". E.g. my >10 years old i586-notebook at home uses a hand-crafted, minimized install-set of packages, with any package which is not necessarily required to run this box having been removed or not even installed. As smolt is non-essential, this machine has never seen smolt. Also, this machine hasn't seen a "full upgrade" ever since an initial Fedora install (years ago), but had been updated/upgraded using networked command-line yum/apt updates/upgrades. Ralf From drago01 at gmail.com Sun Jul 1 08:52:02 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 01 Jul 2007 10:52:02 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <1183279032.3772.0.camel@pensja.lam.pl> References: <20070620184020.GH23569@redhat.com> <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> <46876699.90801@gmail.com> <1183279032.3772.0.camel@pensja.lam.pl> Message-ID: <46876B32.1060309@gmail.com> Leszek Matok wrote: > Dnia 01-07-2007, nie o godzinie 10:32 +0200, dragoran napisa?(a): > >> you could try >> rpm -q --queryformat %{ARCH} kernel >> > Especially on FC6... > > ... do you mean the bug where anaconda selected the wrong kernel? we could first check if we are >=F7 > Lam > From j.w.r.degoede at hhs.nl Sun Jul 1 09:25:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 01 Jul 2007 11:25:34 +0200 Subject: OpenSceneGraph In-Reply-To: <1183269446.23976.13.camel@mccallum.corsepiu.local> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> <468665FD.4080407@cs.nmsu.edu> <1183269446.23976.13.camel@mccallum.corsepiu.local> Message-ID: <4687730E.1080701@hhs.nl> Ralf Corsepius wrote: > The background behind all this: > > Do people consider it worth to have OSG-1 and OSG-2 packages in > parallel? > Note I'm not an OSG user, but judging from this thread, yes that sounds like the best solution. > The run-time environments/packages could rather easily be made > installable in parallel (e.g. by introducing a set of OSG-2 packages), > but implementing this for the devel packages would be non-trivial. > If it really is a lot of pain to make them parallel installable, why not make the -devel packages conflict each other? Its not pretty but developers should be able to cope with that, and normal users don't need these packages. Regards, Hans From sundaram at fedoraproject.org Sun Jul 1 09:20:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 14:50:24 +0530 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <1183279404.23976.33.camel@mccallum.corsepiu.local> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <20070630231540.GK15787@puariko.nirvana> <1183251817.10368.4.camel@vader.jdub.homelinux.org> <4687635E.4060601@dev.intechnology.co.uk> <1183279404.23976.33.camel@mccallum.corsepiu.local> Message-ID: <468771D8.5000403@fedoraproject.org> Ralf Corsepius wrote: > Also, this machine hasn't seen a "full upgrade" ever since an initial > Fedora install (years ago), but had been updated/upgraded using > networked command-line yum/apt updates/upgrades. Not related to this topic but how well has these upgrades work for you? Rahul From buildsys at fedoraproject.org Sun Jul 1 09:36:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 1 Jul 2007 05:36:45 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-01 Message-ID: <20070701093645.213E2152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 11 arrows-0.6-4.fc6 digikam-0.9.1-3.fc6 exaile-0.2.10-1.fc6 gmediaserver-0.12.0-10.fc6 jd-1.9.5-1.fc6 NEW JSDoc-1.10.2-3.fc6 : Produces javadoc-style documentation from JavaScript sourcefiles libupnp-1.6.0-1.fc6 ren-1.0-12.fc6 ushare-0.9.10-3.fc6 xeuphoric-0.18.2-7.fc6 NEW zoneminder-1.22.3-6.fc6 : A camera monitoring and analysis tool Packages built and released for Fedora Extras 5: 3 arrows-0.6-4.fc5 jd-1.9.5-1.fc5 ren-1.0-12.fc5 Changes in Fedora Extras 6: arrows-0.6-4.fc6 ---------------- * Sat Jun 30 2007 Hans de Goede 0.6-4 - Don't crash when reaching level 5 (and 10, 15, etc) (bz 246347) * Sat Nov 25 2006 Hans de Goede 0.6-3 - Honor $RPM_OPT_FLAGS (bz 225098) digikam-0.9.1-3.fc6 ------------------- * Sat Jun 30 2007 Marcin Garski 0.9.1-3 - Delete original .desktop * Fri Jun 29 2007 Marcin Garski 0.9.1-2 - Fix .desktop category and encoding (#240644) exaile-0.2.10-1.fc6 ------------------- * Sat Jun 30 2007 Deji Akingunola - 0.2.10-1 - New release gmediaserver-0.12.0-10.fc6 -------------------------- * Tue Jun 26 2007 Karol Trzcionka - 0.12.0-10 - Change %pre section and add requires(pre) - Rebuild with new libupnp (v1.6.0) * Mon May 07 2007 Karol Trzcionka - 0.12.0-9 - Rebuild with new libupnp version jd-1.9.5-1.fc6 -------------- * Sat Jun 30 2007 Mamoru Tasaka - 1.9.5-1 - 1.9.5 JSDoc-1.10.2-3.fc6 ------------------ * Sat Jun 23 2007 Matej Cepl - 1.10.2-3 - Added GPL text as new source - documentation files (*.tmpl, *.css) shouldn't be executable. - limited ownership of perl_vendorlib direcotries. libupnp-1.6.0-1.fc6 ------------------- * Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 - Update to version 1.6.0 * Tue May 01 2007 Eric Tanguy - 1.4.6-1 - Update to version 1.4.6 * Sat Apr 21 2007 Eric Tanguy - 1.4.4-1 - Update to version 1.4.4 ren-1.0-12.fc6 -------------- * Sat Jun 30 2007 lonely wolf - 1.0-12 - fix preserving of man timestamp. Thanks Patrice Dumas for reporting it. ushare-0.9.10-3.fc6 ------------------- * Sat May 05 2007 Eric Tanguy - 0.9.10-3 - Rebuild for libupnp-1.6.0 * Sat May 05 2007 Eric Tanguy - 0.9.10-2 - Rebuild xeuphoric-0.18.2-7.fc6 ---------------------- * Fri Jun 29 2007 Ian Chapman 0.18.2-7.fc6 - Various cleanups to the SPEC including conforming to new guidelines - Fix BZ #245091 - Additional .desktop files for other emulator models - Encoding fixes for documentation - Fixed installation of broken man page zoneminder-1.22.3-6.fc6 ----------------------- * Sat Jun 30 2007 Martin Ebourne - 1.22.3-6 - Disable crashtrace on ppc * Sat Jun 30 2007 Martin Ebourne - 1.22.3-5 - Fix uid for directories in /var/lib/zoneminder * Tue Jun 26 2007 Martin Ebourne - 1.22.3-4 - Added perl Archive::Tar dependency - Disabled web interface due to lack of access control on the event images * Sun Jun 10 2007 Martin Ebourne - 1.22.3-3 - Changes recommended in review by Jason Tibbitts Changes in Fedora Extras 5: arrows-0.6-4.fc5 ---------------- * Sat Jun 30 2007 Hans de Goede 0.6-4 - Don't crash when reaching level 5 (and 10, 15, etc) (bz 246347) * Sat Nov 25 2006 Hans de Goede 0.6-3 - Honor $RPM_OPT_FLAGS (bz 225098) jd-1.9.5-1.fc5 -------------- * Sat Jun 30 2007 Mamoru Tasaka - 1.9.5-1 - 1.9.5 ren-1.0-12.fc5 -------------- * Sat Jun 30 2007 lonely wolf - 1.0-12 - fix preserving of man timestamp. Thanks Patrice Dumas for reporting it. 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 Jul 1 09:50:25 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Sun, 01 Jul 2007 09:50:25 -0000 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-01 Message-ID: <20070701095025.23446.42659@extras64.linux.duke.edu> ====================================================================== The results in this summary consider unreleased updates in the build-system's needsign-queue! ====================================================================== Summary of broken packages (by owner): atkac AT redhat.com bind-devel - 31:9.3.4-6.fc6.i386 (32 days) berrange AT redhat.com python-virtinst - 0.103.0-1.fc6.noarch (14 days) davidz AT redhat.com livecd-tools - 008-1.fc6.noarch (57 days) livecd-tools - 008-1.fc6.noarch (57 days) krh AT redhat.com compiz-devel - 0.3.6-2.fc6.i386 (137 days) poppler-devel - 0.5.4-5.fc6.i386 (192 days) roland AT redhat.com elfutils-devel - 0.128-2.fc6.i386 (12 days) elfutils-libelf-devel - 0.128-2.fc6.i386 (12 days) than AT redhat.com kdeedu - 3.5.7-1.fc6.i386 (3 days) kdeutils - 6:3.5.7-1.fc6.i386 (3 days) veillard AT redhat.com opal-devel - 2.2.5-1.fc6.i386 (129 days) ====================================================================== Broken packages in fedora-core-updates-6-ppc: python-virtinst-0.103.0-1.fc6.noarch requires libvirt-python >= 0:0.2.1 ====================================================================== Broken packages in fedora-core-updates-6-x86_64: bind-devel-31:9.3.4-6.fc6.i386 requires libdns.so.22 bind-devel-31:9.3.4-6.fc6.i386 requires libbind9.so.0 bind-devel-31:9.3.4-6.fc6.i386 requires libisccc.so.0 bind-devel-31:9.3.4-6.fc6.i386 requires liblwres.so.9 bind-devel-31:9.3.4-6.fc6.i386 requires libisccfg.so.1 bind-devel-31:9.3.4-6.fc6.i386 requires libisc.so.11 compiz-devel-0.3.6-2.fc6.i386 requires libdecoration.so.0 elfutils-devel-0.128-2.fc6.i386 requires elfutils-devel-static-i386 = 0:0.128-2.fc6 elfutils-libelf-devel-0.128-2.fc6.i386 requires elfutils-libelf-devel-static-i386 = 0:0.128-2.fc6 kdeedu-3.5.7-1.fc6.i386 requires libpython2.4.so.1.0 kdeutils-6:3.5.7-1.fc6.i386 requires libpython2.4.so.1.0 opal-devel-2.2.5-1.fc6.i386 requires libopal_linux_x86_r.so.2.2 poppler-devel-0.5.4-5.fc6.i386 requires libpoppler-qt.so.1 ====================================================================== Broken packages in fedora-extras-needsign-6-i386: livecd-tools-008-1.fc6.noarch requires dosfstools >= 0:2.11-8 ====================================================================== Broken packages in fedora-extras-needsign-6-x86_64: livecd-tools-008-1.fc6.noarch requires dosfstools >= 0:2.11-8 From buildsys at redhat.com Sun Jul 1 10:24:24 2007 From: buildsys at redhat.com (Build System) Date: Sun, 1 Jul 2007 06:24:24 -0400 Subject: rawhide report: 20070701 changes Message-ID: <200707011024.l61AOOaf007632@porkchop.devel.redhat.com> New package JSDoc Produces javadoc-style documentation from JavaScript sourcefiles New package python-elixir A declarative mapper for SQLAlchemy New package zoneminder A camera monitoring and analysis tool Updated Packages: OpenSceneGraph-2.0-4.fc8 ------------------------ * Sat Jun 30 2007 Ralf Cors??pius - 2.0-4 - Cleanup CVS. - Add OSG1_Producer define. * Fri Jun 29 2007 Ralf Cors??pius - 2.0-3 - Re-add (but don't ship) *.pc. - Let OpenSceneGraph "Obsolete: Producer". - Let OpenSceneGraph-devel "Obsolete: Producer-devel". * Wed Jun 27 2007 Ralf Cors??pius - 2.0-2 - Build docs. arrows-0.6-4.fc8 ---------------- * Sat Jun 30 2007 Hans de Goede 0.6-4 - Don't crash when reaching level 5 (and 10, 15, etc) (bz 246347) asymptote-1.32-1.fc8 -------------------- * Sat Jun 30 2007 Jose Pedro Oliveira - 1.32-1 - Update to 1.32. - vim-common triggers: correction and improvements (#246131). cegui-0.5.0b-4.fc8 ------------------ * Sat Jun 30 2007 Ian Chapman 0.5.0b-4.fc8 - release bump emacs-vm-8.0.1.465-1.fc8 ------------------------ * Thu Jun 28 2007 Jonathan G. Underwood - 8.0.1.465-1 - Update to bugfix release 8.0.1 (fixes BZ #245780) exaile-0.2.10-1.fc8 ------------------- * Sat Jun 30 2007 Deji Akingunola - 0.2.10-1 - New release * Fri Mar 30 2007 Deji Akingunola - 0.2.9-1 - New release * Tue Jan 09 2007 Deji Akingunola - 0.2.8-1 - New release gpsd-2.34-7.fc8 --------------- * Sat Jun 30 2007 Matthew Truch - 2.34-7 - Make sure the logo is actually included (via the spec file). I need to wake up before I try even trivial updates. * Sat Jun 30 2007 Matthew Truch - 2.34-6 - Learn how to use search and replace (aka fix all instances of gpsd-logo.png spelled incorrectly as gspd-logo.png). * Sat Jun 30 2007 Matthew Truch - 2.34-5 - Fix desktop file and logo file name. hotwire-0.575-1.fc8 ------------------- * Sat Jun 30 2007 Colin Walters - 0.575-1 - new upstream - add icon goo - update url kernel-2.6.21-1.3243.fc8 ------------------------ * Sat Jun 30 2007 Dave Jones - 2.6.22-rc6-git4 notecase-1.5.8-1.fc8 -------------------- * Sat Jun 30 2007 Damien Durand 1.5.8-1 - Ugrade to 1.5.8 openct-0.6.12-0.1.pre3.fc8 -------------------------- * Sat Jun 30 2007 Ville Skytt?? - 0.6.12-0.1.pre3 - 0.6.12-pre3. - Add LSB comment block to init script. - Use vanilla upstream udev rules, requires >= 098. pcsc-tools-1.4.9-1.fc8 ---------------------- * Sat Jun 30 2007 Ville Skytt?? - 1.4.9-1 - 1.4.9. - Drop Encoding key from desktop entry. ren-1.0-12.fc8 -------------- * Sat Jun 30 2007 lonely wolf - 1.0-12 - fix preserving of man timestamp. Thanks Patrice Dumas for reporting it. revisor-2.0.4.0-1.fc8 --------------------- * Wed Jun 27 2007 Jonathan Steffan 2.0.4.0-1 - Bugfixes from 2.0.3.x - Start of all the new features of 2.0.4 * Sun Jun 24 2007 Jeroen van Meeuwen 2.0.3.12-1 - Removed excludearchs ppc, ppc64 and added some logic to the spec file including a patch to disable livecd composure. - Fixed bug in repository configuration - Re-enabled CLI * Sat Jun 23 2007 Jeroen van Meeuwen 2.0.3.11-1 - Adding comps-f7 to our distribution - Removing pungi configuration files - Fixed a major bug in unlinking / unmounting the left-overs of a previous live media run. - Enabled translation - Added ExcludeArch: ppc, ppc64. Our dependency livecd-tools is not available for these archs. scim-tomoe-0.6.0-1.fc8 ---------------------- * Fri Jun 29 2007 Jens Petersen - 0.6.0-1 - update to 0.6.0 release - buildrequire perl-XML-Parser for intltool, and gettext testdisk-6.7-1.fc8 ------------------ * Fri Jun 29 2007 Christophe Grenier 6.7-1 - Update to latest version xca-0.6.3-2.fc8 --------------- * Sat Jun 30 2007 Enrico Scholz - 0.6.3-2 - improved desktop-integration by registering MIME type and icons - disabled ppc64 build (bz #246324) * Thu Jun 14 2007 Enrico Scholz - 0.6.3-1 - updated to 0.6.3; rediffed patches - fixed build xemacs-21.5.28-4.fc8 -------------------- * Sat Jun 30 2007 Ville Skytt?? - 21.5.28-4 - Turn on syntax highlighting with lazy-lock by default. - Drop Application and X-Fedora categories and Encoding from desktop entry. - Move diff-switches default from skeleton init.el to site-start.el. * Sun Jun 24 2007 Ville Skytt?? - 21.5.28-3 - Apply upstream fix for #245017. * Wed Jun 06 2007 Ville Skytt?? - 21.5.28-2 - Set more dirs explicitly until upstream configure honors them better. - Borrow DESTDIR install patch from openSUSE. - Add pkgconfig file to -devel. xeuphoric-0.18.2-7.fc8 ---------------------- * Fri Jun 29 2007 Ian Chapman 0.18.2-7.fc8 - Various cleanups to the SPEC including conforming to new guidelines - Fix BZ #245091 - Additional .desktop files for other emulator models - Encoding fixes for documentation - Fixed installation of broken man page Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From kagesenshi.87 at gmail.com Sun Jul 1 10:37:31 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sun, 1 Jul 2007 18:37:31 +0800 Subject: Compiz Fusion? In-Reply-To: <46875E58.3030106@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> Message-ID: On 7/1/07, dragoran wrote: [snip] > > Like dragoran said, I also agree that ccp is a better choice .. > > because if we insist in using gconf, desktop-effects and gnome-wm need > > to do checking whether to load ccp or to load gconf plugin .. plus, > > the compizconfig-settings-manager requires user to use ccp plugin and > > it doesnt work with gconf plugin (compizconfig-backend-gconf != gconf > > plugin) .. > > > +1 also using ccp allows us to use the compiz-settings tools and not > require user to use gconf-editor. > > for ccp, desktop-effects surely requires patching because the current > > desktop-effects is using gconf and not libcompizconfig .. > > > yes I now.. but what is the compiz maintainers opinion on this? > krh? I just emailed him about this .. lets wait for his response [snip] > >> > about desktop-effects .. for systems with AIGLX, an environment var > >> > need to be exported before launching it to make it work > >> > > >> > export LIBGL_ALWAYS_INDIRECT=1 > >> > >> this should then be added to gnome-wm to because on login > >> desktop-effects is > >> not inolved. > >> > > > > after the patch, the env var no longer requires exporting .. > it doesn't have to be exported. just call setenv() in desktop-effects.c > and in gnome-wm start compiz with LIBGL_ALWAYS_INDIRECT=1 compiz ... > some cards doesnt require the env export (eg: nvidia) .. and for fglrx, it require a LD_PRELOAD to a library file from fglrx driver package instead (I heard XGL no longer required .. I dont have any ati cards , couldnt test it) .. ref: http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 aiglx-default.patch and tfp-server-extension.patch already removed the requirement for LIBGL_ALWAYS_INDIRECT .. so this is no longer a problem .. those 2 patches were taken from compiz 0.3.6 src.rpm btw .. > btw. I would suggest to use --ignore-desktop-hints by default. because > else compiz uses viewports *and* workspaces at the same time when > started via desktop-effects ...which is just weird. > about the gnome-wm patch .. aint that need to be applied in gnome-session rpm?? .. another thing . I just added fusion-icon packages into the repo .. fusion-icon is an app similar to beryl-manager .. -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From drago01 at gmail.com Sun Jul 1 11:15:21 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 01 Jul 2007 13:15:21 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> Message-ID: <46878CC9.4030106@gmail.com> Hikaru Amano wrote: > [...] > I just emailed him about this .. lets wait for his response > ok > [...] > > some cards doesnt require the env export (eg: nvidia) .. and for > fglrx, it require a LD_PRELOAD to a library file from fglrx driver > package instead (I heard XGL no longer required .. I dont have any ati > cards , couldnt test it) .. > > ref: http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 > > aiglx-default.patch and tfp-server-extension.patch already removed the > requirement for LIBGL_ALWAYS_INDIRECT .. so this is no longer a > problem .. > > those 2 patches were taken from compiz 0.3.6 src.rpm btw .. > ok >> btw. I would suggest to use --ignore-desktop-hints by default. because >> else compiz uses viewports *and* workspaces at the same time when >> started via desktop-effects ...which is just weird. >> > > about the gnome-wm patch .. aint that need to be applied in > gnome-session rpm?? .. > yes or better upstream. > another thing . > I just added fusion-icon packages into the repo .. fusion-icon is an > app similar to beryl-manager .. > ok From Axel.Thimm at ATrpms.net Sun Jul 1 11:19:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 13:19:43 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <1183267266.22027.14.camel@localhost> References: <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <1183267266.22027.14.camel@localhost> Message-ID: <20070701111943.GF28605@puariko.nirvana> On Sun, Jul 01, 2007 at 12:21:06AM -0500, Callum Lerwick wrote: > On Sat, 2007-06-30 at 19:07 -0400, Alan Cox wrote: > > On Sun, Jul 01, 2007 at 12:14:20AM +0200, Axel Thimm wrote: > > > I also wonder what the 2.1% i386 are. These can't be true i386, or if > > > they are they can't be 30x as many as i586. > > > > I'd been wondering if those are qemu/vmware/xen or something similar ? > > Generally those will report what the host CPU really is, as they're > "virtualized" but they're still running on the host CPU. Though qemu's > software mode may be different. I always run with kqemu, and Windows XP > detects the Athlon 64 I'm running on. Well, smolt does keep the database and by correlating vendor and CPU one would get a finer grained picture of the i386 systems. At least VMware offers a BIOS vendor string pointing to itself. But since there are ~8% VMware system but only ~2% i386 systems, at least 3/4 of the VMware systems cannot report i386. BTW also quite a high value, VMware guests at 8%? Can we detect xen/qemu guests to have stats on physical vs virtual hosts? -- 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 alcapcom at gmail.com Sun Jul 1 11:56:52 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Sun, 01 Jul 2007 13:56:52 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> Message-ID: <46879684.8080805@gmail.com> Hikaru Amano a ?crit : > some cards doesnt require the env export (eg: nvidia) .. and for > fglrx, it require a LD_PRELOAD to a library file from fglrx driver > package instead (I heard XGL no longer required .. I dont have any ati > cards , couldnt test it) .. > > ref: http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 To make this working compiz need to use texture copy instead of texture_from_pixmap method[1] (because of the fact the fglrx driver don't have support for texture_from_pixmap). That functionality can be ported from beryl. Maybe a little patch to compiz must applied too[2] If that's doable, I could happily forgot that nightmare Xgl review ;-) [1] http://lists.freedesktop.org/archives/compiz/2007-June/002448.html [2] http://lists.freedesktop.org/archives/compiz/2007-June/002446.html Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Sun Jul 1 11:59:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jul 2007 13:59:10 +0200 Subject: OpenSceneGraph In-Reply-To: <4687730E.1080701@hhs.nl> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> <468665FD.4080407@cs.nmsu.edu> <1183269446.23976.13.camel@mccallum.corsepiu.local> <4687730E.1080701@hhs.nl> Message-ID: <1183291151.23976.42.camel@mccallum.corsepiu.local> On Sun, 2007-07-01 at 11:25 +0200, Hans de Goede wrote: > Ralf Corsepius wrote: > > The background behind all this: > > > > Do people consider it worth to have OSG-1 and OSG-2 packages in > > parallel? > > > > Note I'm not an OSG user, but judging from this thread, yes that sounds like > the best solution. It's an option I've been considering. Unfortunately OSG upstream has committed a couple of decisions which render parallel installation complicated (e.g. they dropped pkgconfig support :( ) > > The run-time environments/packages could rather easily be made > > installable in parallel (e.g. by introducing a set of OSG-2 packages), > > but implementing this for the devel packages would be non-trivial. > > If it really is a lot of pain to make them parallel installable, The devel libs conflict, so the only option I see is installing OSG-2's devel libs into a %{_libdir}/osg-2.0 subdir. > why not make > the -devel packages conflict each other? That's one option. > Its not pretty but developers should > be able to cope with that, and normal users don't need these packages. This would be fine with me. Trying to gain clarity on other people's opinions had been the reason for why I am asking ;) I had hopedn, people were answering "nobody cares about OSG-1, go ahead and dump OSG-1" ... Ralf From drago01 at gmail.com Sun Jul 1 11:59:22 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 01 Jul 2007 13:59:22 +0200 Subject: Compiz Fusion? In-Reply-To: <46879684.8080805@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> Message-ID: <4687971A.9010004@gmail.com> Alphonse Van Assche wrote: > Hikaru Amano a ?crit : > >> some cards doesnt require the env export (eg: nvidia) .. and for >> fglrx, it require a LD_PRELOAD to a library file from fglrx driver >> package instead (I heard XGL no longer required .. I dont have any ati >> cards , couldnt test it) .. >> >> ref: http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 >> > > To make this working compiz need to use texture copy instead of > texture_from_pixmap method[1] (because of the fact the fglrx driver > don't have support for texture_from_pixmap). That functionality can be > ported from beryl. Maybe a little patch to compiz must applied too[2] > > If that's doable, I could happily forgot that nightmare Xgl review ;-) > > that should be done upstream but I doubt that david would merge this in compiz-core ... is it possible to do it as a plugin? create any required hocks to compiz and send that patch upstream. > [1] http://lists.freedesktop.org/archives/compiz/2007-June/002448.html > [2] http://lists.freedesktop.org/archives/compiz/2007-June/002446.html > > Alphonse > > From bpepple at fedoraproject.org Sun Jul 1 13:00:04 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 01 Jul 2007 09:00:04 -0400 Subject: FESCo Meeting Summary for 2007-06-28 Message-ID: <1183294804.2974.0.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Rex Dieter (rdieter) * Christian Iseli (c4chris) * Warren Togami (warren) * Josh Boyer (jwb) * Tom Callaway (spot) == Summary == FPC CommitIDs Proposal * FESCo had no objects to the Fedora Packaging Committee's proposal for allowing freeform use of version control system data in the release field of snapshot packages. For more information please refer to: http://fedoraproject.org/wiki/PackagingDrafts/CommitIDs Feature Policy Draft * FESCo had a long discussion of John Poelstra's Feature Policy Draft. John will work on incorporating some of the suggestions into his proposal. For more details, please refer to the IRC log. http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft All new packages must be reviewed before cvs import * FESCo approved spot's proposal that all new packages (including compat packages) must be reviewed before cvs import. Opening FESCo election vote to more people * FESCo approved a proposal to expand the pool of people eligible to vote for the upcoming FESCo election. This was done since FESCo's new scope of responsibilities affects many different parts of the project. Misc * jwb proposed that future proposal drafts be sent to public mailing lists, so more community feedback can be gathered. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070628 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 sundaram at fedoraproject.org Sun Jul 1 14:03:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 19:33:20 +0530 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <1183294804.2974.0.camel@kennedy> References: <1183294804.2974.0.camel@kennedy> Message-ID: <4687B428.5000401@fedoraproject.org> Brian Pepple wrote: > For full IRC log: > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070628 > I would appreciate if FESCo or anyone interested look at and commented about the suitability of this as I requested earlier. https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html During Fedora 7 time frame the FESCo decision to not to rebuilds was just for the release in part because it was late during the release cycle and the decision whether we wanted to do rebuilds every cycle or not going further was not supposed to be happening earlier this time. Just a reminder again. Also in fedora-maintainers I posted a mail about wiki naming long back and as FESCo using the Extras name space for posting the meeting minutes or agenda isn't suitable anymore, it has to decide and move it to a new location. Rahul From jwboyer at jdub.homelinux.org Sun Jul 1 14:33:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 01 Jul 2007 09:33:08 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <468771D8.5000403@fedoraproject.org> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <20070630231540.GK15787@puariko.nirvana> <1183251817.10368.4.camel@vader.jdub.homelinux.org> <4687635E.4060601@dev.intechnology.co.uk> <1183279404.23976.33.camel@mccallum.corsepiu.local> <468771D8.5000403@fedoraproject.org> Message-ID: <1183300388.2921.0.camel@vader.jdub.homelinux.org> On Sun, 2007-07-01 at 14:50 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > > Also, this machine hasn't seen a "full upgrade" ever since an initial > > Fedora install (years ago), but had been updated/upgraded using > > networked command-line yum/apt updates/upgrades. > > Not related to this topic but how well has these upgrades work for you? I've done yum upgrades from FC5 -> FC6 -> F7 on several machines of various architectures. All have worked fine, with perhaps one or two already documented manual fixes needed. josh From jkeating at redhat.com Sun Jul 1 14:41:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 1 Jul 2007 10:41:42 -0400 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <4686D2EA.9040703@di.uminho.pt> References: <200706301055.46506.jkeating@redhat.com> <4686D2EA.9040703@di.uminho.pt> Message-ID: <200707011041.47992.jkeating@redhat.com> On Saturday 30 June 2007 18:02:18 Jose Pedro Oliveira wrote: > Right now we don't have an easy way to pull all the perl core modules > into he build system. Perhaps you missed the sarcasm. Saying "we don't have an easy way to pull all the perl core modules in" sounds to me like "we don't want to figure out what perl modules we're actually using and ask for them, we'd rather everything be there and not care. -- 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 Sun Jul 1 14:42:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 1 Jul 2007 10:42:35 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <4686E172.3000202@fedoraproject.org> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> Message-ID: <200707011042.35797.jkeating@redhat.com> On Saturday 30 June 2007 19:04:18 Rahul Sundaram wrote: > EPEL isn't targeted for Fedora. I did refer to the discussion. Think > about this from the end user perspective rather than from the project > perspective. "Fedora" is more than a distribution. -- 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 Sun Jul 1 14:46:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 1 Jul 2007 10:46:16 -0400 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <4687B428.5000401@fedoraproject.org> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> Message-ID: <200707011046.16736.jkeating@redhat.com> On Sunday 01 July 2007 10:03:20 Rahul Sundaram wrote: > During Fedora 7 time frame the FESCo decision to not to rebuilds was > just for the release in part because it was late during the release > cycle and the decision whether we wanted to do rebuilds every cycle or > not going further was not supposed to be happening earlier this time. > Just a reminder again. And I'm reminding you again that /if/ we do a rebuild, it will be coordinated with the tools team if they have any features up coming that would take advantage of a rebuild. As of yet I haven't seen any input from the tools team regarding this so no decision on if/when should be made yet. -- 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 Sun Jul 1 14:49:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 1 Jul 2007 10:49:04 -0400 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630221420.GF15787@puariko.nirvana> References: <20070620184020.GH23569@redhat.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> Message-ID: <200707011049.04431.jkeating@redhat.com> On Saturday 30 June 2007 18:14:20 Axel Thimm wrote: > I also wonder what the 2.1% i386 are. These can't be true i386, or if > they are they can't be 30x as many as i586. I do believe there was a bug early on in smolt where all ix86 systems were detected as i386. -- 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 Sun Jul 1 15:11:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 01 Jul 2007 20:41:17 +0530 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <200707011046.16736.jkeating@redhat.com> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> <200707011046.16736.jkeating@redhat.com> Message-ID: <4687C415.9040303@fedoraproject.org> Jesse Keating wrote: > On Sunday 01 July 2007 10:03:20 Rahul Sundaram wrote: >> During Fedora 7 time frame the FESCo decision to not to rebuilds was >> just for the release in part because it was late during the release >> cycle and the decision whether we wanted to do rebuilds every cycle or >> not going further was not supposed to be happening earlier this time. >> Just a reminder again. > > And I'm reminding you again that /if/ we do a rebuild, it will be coordinated > with the tools team if they have any features up coming that would take > advantage of a rebuild. You are stating your view point which is well known by now but the last time I asked for a decision on this, it was decided against by FESCo just for Fedora 7 release. FESCo has so far not made a decision about mass rebuilds in general afaik. Rahul From bpepple at fedoraproject.org Sun Jul 1 15:21:38 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 01 Jul 2007 11:21:38 -0400 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <4687B428.5000401@fedoraproject.org> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> Message-ID: <1183303298.2974.11.camel@kennedy> On Sun, 2007-07-01 at 19:33 +0530, Rahul Sundaram wrote: > > I would appreciate if FESCo or anyone interested look at and commented > about the suitability of this as I requested earlier. > > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html > > During Fedora 7 time frame the FESCo decision to not to rebuilds was > just for the release in part because it was late during the release > cycle and the decision whether we wanted to do rebuilds every cycle or > not going further was not supposed to be happening earlier this time. > Just a reminder again. I was tentatively planning on having FESCo decide this around the end of July / beginning of August, since we need still need input from the tool team as to whether the tool-chain warrants a mass-rebuild for F8. > Also in fedora-maintainers I posted a mail about wiki naming long back > and as FESCo using the Extras name space for posting the meeting minutes > or agenda isn't suitable anymore, it has to decide and move it to a new > location. I agree with you that we need to move the lingering items on the wiki away from the Extras name space, but that's been a fairly low-priority item right now. /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 mmcgrath at redhat.com Sun Jul 1 15:38:12 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 01 Jul 2007 10:38:12 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <200707011049.04431.jkeating@redhat.com> References: <20070620184020.GH23569@redhat.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <200707011049.04431.jkeating@redhat.com> Message-ID: <4687CA64.8040700@redhat.com> Jesse Keating wrote: > On Saturday 30 June 2007 18:14:20 Axel Thimm wrote: > >> I also wonder what the 2.1% i386 are. These can't be true i386, or if >> they are they can't be 30x as many as i586. >> > > I do believe there was a bug early on in smolt where all ix86 systems were > detected as i386. > I can confirm this. I'm thinking about deleting profiles prior to a few weeks before the F7 launch that are i386 boxes just to avoid confusion. (they can always re-register) -Mike From rvinyard at cs.nmsu.edu Sun Jul 1 15:47:51 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sun, 01 Jul 2007 09:47:51 -0600 Subject: OpenSceneGraph In-Reply-To: <1183291151.23976.42.camel@mccallum.corsepiu.local> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> <468665FD.4080407@cs.nmsu.edu> <1183269446.23976.13.camel@mccallum.corsepiu.local> <4687730E.1080701@hhs.nl> <1183291151.23976.42.camel@mccallum.corsepiu.local> Message-ID: <4687CCA7.7000305@cs.nmsu.edu> Here is Ben's (VTP upstream) reply regarding OSG 2.0: > Rick, > > 2.0 changes the OSG API a fair deal, and doesn't have any compelling > features that i've yet seen. Hence, not much hurry on the adoption. We'll > probably move to it after the next VTP release. Ralf Corsepius wrote: > On Sun, 2007-07-01 at 11:25 +0200, Hans de Goede wrote: > >> Ralf Corsepius wrote: >> >>> The background behind all this: >>> >>> Do people consider it worth to have OSG-1 and OSG-2 packages in >>> parallel? >>> >> Note I'm not an OSG user, but judging from this thread, yes that sounds like >> the best solution. >> > It's an option I've been considering. Unfortunately OSG upstream has > committed a couple of decisions which render parallel installation > complicated (e.g. they dropped pkgconfig support :( ) > > >>> The run-time environments/packages could rather easily be made >>> installable in parallel (e.g. by introducing a set of OSG-2 packages), >>> but implementing this for the devel packages would be non-trivial. >>> >> If it really is a lot of pain to make them parallel installable, >> > The devel libs conflict, so the only option I see is installing OSG-2's > devel libs into a %{_libdir}/osg-2.0 subdir. > Personally, I'd rather see the OSG-1 libs in an osg-1.0 subdir, and basically treat the OSG-1 packages as legacy packages. That way, the OpenSceneGraph package can just move ahead to 2.0 and packages that need OSG-1 will have to explicitly state it. >> why not make >> the -devel packages conflict each other? >> > That's one option. > I rather not see that. From Axel.Thimm at ATrpms.net Sun Jul 1 15:47:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 17:47:47 +0200 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <1183303298.2974.11.camel@kennedy> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> <1183303298.2974.11.camel@kennedy> Message-ID: <20070701154747.GA27402@puariko.nirvana> On Sun, Jul 01, 2007 at 11:21:38AM -0400, Brian Pepple wrote: > On Sun, 2007-07-01 at 19:33 +0530, Rahul Sundaram wrote: > > > > I would appreciate if FESCo or anyone interested look at and commented > > about the suitability of this as I requested earlier. > > > > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html > > > > During Fedora 7 time frame the FESCo decision to not to rebuilds was > > just for the release in part because it was late during the release > > cycle and the decision whether we wanted to do rebuilds every cycle or > > not going further was not supposed to be happening earlier this time. > > Just a reminder again. > > I was tentatively planning on having FESCo decide this around the end of > July / beginning of August, since we need still need input from the tool > team as to whether the tool-chain warrants a mass-rebuild for F8. But one of the questions is whether mass rebuilds need to be done irrespective of that input. Not that the team is not compentent, but we had the same input for F7 and found it not proper at several instances already and bridge-utils is still compiled against 2.6.18 headers (just an example). So the top question is: Always have mass rebuilds, no matter what, or delegate this decision to a releng/tools team? The more you wait for the decision the more it will become a moot point as there will be no time to do rebuilds. -- 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 Sun Jul 1 15:50:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 17:50:15 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <4687CA64.8040700@redhat.com> References: <20070620184020.GH23569@redhat.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <200707011049.04431.jkeating@redhat.com> <4687CA64.8040700@redhat.com> Message-ID: <20070701155015.GB27402@puariko.nirvana> On Sun, Jul 01, 2007 at 10:38:12AM -0500, Mike McGrath wrote: > Jesse Keating wrote: > >On Saturday 30 June 2007 18:14:20 Axel Thimm wrote: > > > >>I also wonder what the 2.1% i386 are. These can't be true i386, or if > >>they are they can't be 30x as many as i586. > >> > > > >I do believe there was a bug early on in smolt where all ix86 systems were > >detected as i386. > > > > I can confirm this. I'm thinking about deleting profiles prior to a few > weeks before the F7 launch that are i386 boxes just to avoid confusion. > (they can always re-register) BTW I registered some RHEL boxes and they don't show up in "OS" stats. -- 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 bpepple at fedoraproject.org Sun Jul 1 16:04:34 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 01 Jul 2007 12:04:34 -0400 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <20070701154747.GA27402@puariko.nirvana> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> <1183303298.2974.11.camel@kennedy> <20070701154747.GA27402@puariko.nirvana> Message-ID: <1183305874.2974.21.camel@kennedy> On Sun, 2007-07-01 at 17:47 +0200, Axel Thimm wrote: > On Sun, Jul 01, 2007 at 11:21:38AM -0400, Brian Pepple wrote: > > > > I was tentatively planning on having FESCo decide this around the end of > > July / beginning of August, since we need still need input from the tool > > team as to whether the tool-chain warrants a mass-rebuild for F8. > > But one of the questions is whether mass rebuilds need to be done > irrespective of that input. Not that the team is not compentent, but > we had the same input for F7 and found it not proper at several > instances already and bridge-utils is still compiled against 2.6.18 > headers (just an example). > > So the top question is: Always have mass rebuilds, no matter what, or > delegate this decision to a releng/tools team? That question is actually the item I have on the schedule to discuss (which like said I was planning on doing around the end of July). It's the first item in the priority 2 section: http://fedoraproject.org/wiki/Development/Schedule Later, /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 Axel.Thimm at ATrpms.net Sun Jul 1 16:19:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Jul 2007 18:19:05 +0200 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <1183305874.2974.21.camel@kennedy> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> <1183303298.2974.11.camel@kennedy> <20070701154747.GA27402@puariko.nirvana> <1183305874.2974.21.camel@kennedy> Message-ID: <20070701161905.GC27402@puariko.nirvana> On Sun, Jul 01, 2007 at 12:04:34PM -0400, Brian Pepple wrote: > On Sun, 2007-07-01 at 17:47 +0200, Axel Thimm wrote: > > On Sun, Jul 01, 2007 at 11:21:38AM -0400, Brian Pepple wrote: > > > > > > I was tentatively planning on having FESCo decide this around the end of > > > July / beginning of August, since we need still need input from the tool > > > team as to whether the tool-chain warrants a mass-rebuild for F8. > > > > But one of the questions is whether mass rebuilds need to be done > > irrespective of that input. Not that the team is not compentent, but > > we had the same input for F7 and found it not proper at several > > instances already and bridge-utils is still compiled against 2.6.18 > > headers (just an example). > > > > So the top question is: Always have mass rebuilds, no matter what, or > > delegate this decision to a releng/tools team? > > That question is actually the item I have on the schedule to discuss > (which like said I was planning on doing around the end of July). OK, if there really is enough time to discuss it in August, that would be fine with me. I just think that Jesse for example would not want the rebuilds to happen shortly before freeze time and freeze is scheduled to happen at Aug 27th. Past experience shows that it would have to be started to be discussed in fesco now, otherwise it will just not make it in time. But I also wonder: While I'd prefer to have a clear decision on rebuilding no matter what the toolchain changes: given that gcc 4.2 is already getting "old" and Fedora is about tracking recent technologies it would really be a shame not to have it in the November release (where gcc 4.2 will be half a year old). So from the perspective of Fedora's goals, gcc 4.2 has to make it into F8. And that alone is probably reason enough to do the rebuilds. Still fesco should decide on a general policy independent of toolschain matters. This time perhaps gcc 4.2 could save the discussion, but in F9 time people will be arguing that F8 was only rebuilt because of gcc 4.2. > It's the first item in the priority 2 section: > http://fedoraproject.org/wiki/Development/Schedule > > Later, > /B -- 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 rc040203 at freenet.de Sun Jul 1 16:44:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jul 2007 18:44:11 +0200 Subject: OpenSceneGraph In-Reply-To: <4687CCA7.7000305@cs.nmsu.edu> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> <468665FD.4080407@cs.nmsu.edu> <1183269446.23976.13.camel@mccallum.corsepiu.local> <4687730E.1080701@hhs.nl> <1183291151.23976.42.camel@mccallum.corsepiu.local> <4687CCA7.7000305@cs.nmsu.edu> Message-ID: <1183308251.23976.51.camel@mccallum.corsepiu.local> On Sun, 2007-07-01 at 09:47 -0600, Rick L Vinyard Jr wrote: > Here is Ben's (VTP upstream) reply regarding OSG 2.0: > > Rick, > > > > 2.0 changes the OSG API a fair deal, and doesn't have any compelling > > features that i've yet seen. Hence, not much hurry on the adoption. We'll > > probably move to it after the next VTP release. > > Ralf Corsepius wrote: > > On Sun, 2007-07-01 at 11:25 +0200, Hans de Goede wrote: > > > >> Ralf Corsepius wrote: > >> > >>> The background behind all this: > >>> > >>> Do people consider it worth to have OSG-1 and OSG-2 packages in > >>> parallel? > >>> > >> Note I'm not an OSG user, but judging from this thread, yes that sounds like > >> the best solution. > >> > > It's an option I've been considering. Unfortunately OSG upstream has > > committed a couple of decisions which render parallel installation > > complicated (e.g. they dropped pkgconfig support :( ) > > > > > >>> The run-time environments/packages could rather easily be made > >>> installable in parallel (e.g. by introducing a set of OSG-2 packages), > >>> but implementing this for the devel packages would be non-trivial. > >>> > >> If it really is a lot of pain to make them parallel installable, > >> > > The devel libs conflict, so the only option I see is installing OSG-2's > > devel libs into a %{_libdir}/osg-2.0 subdir. > > > Personally, I'd rather see the OSG-1 libs in an osg-1.0 subdir, This would be incompatible to OSG-1 as it has been shipped until now. > and > basically treat the OSG-1 packages as legacy packages. That way, the > OpenSceneGraph package can just move ahead to 2.0 and packages that need > OSG-1 will have to explicitly state it. This is the replacing "OSG-1 by compat-OSG-1 packages" idea. It's only applicable to the run-time packages, but not to the devel packages. > >> why not make > >> the -devel packages conflict each other? > >> > > That's one option. > > > I rather not see that. Neither do I, but ... it seems inevitable. Ralf From rc040203 at freenet.de Sun Jul 1 17:05:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 01 Jul 2007 19:05:15 +0200 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <468771D8.5000403@fedoraproject.org> References: <1182365094.4102.17.camel@hodge> <200706201446.05150.jkeating@redhat.com> <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <20070630230729.GB15010@devserv.devel.redhat.com> <20070630231540.GK15787@puariko.nirvana> <1183251817.10368.4.camel@vader.jdub.homelinux.org> <4687635E.4060601@dev.intechnology.co.uk> <1183279404.23976.33.camel@mccallum.corsepiu.local> <468771D8.5000403@fedoraproject.org> Message-ID: <1183309515.23976.70.camel@mccallum.corsepiu.local> On Sun, 2007-07-01 at 14:50 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > > Also, this machine hasn't seen a "full upgrade" ever since an initial > > Fedora install (years ago), but had been updated/upgraded using > > networked command-line yum/apt updates/upgrades. > > Not related to this topic but how well has these upgrades work for you? It's the way I've been installing Fedora on all of my machines for years. Sometimes it had worked smoothly, sometimes it hasn't. FC6->FC7 upgrades using yum/apt and package-cleanup worked comparatively smoothly. Other upgrades before had been a PITA (Esp. upgrading FC5->FC6 had been a real disaster.) The only major difference between using this procedure on i586s in comparison to better cpus is * Tightness on resources occasionally hitting very badly: - RAM: yum and apt both bombed out during "upgrades" due to lack of memory. Work-around: manually install packages using rpm/yum/apt. Also critical wrt to RAM: SELinux (autolabel'ing running out of memory!): Work-around: Manually run the SELinux tools or disable SELinux. - CPU-speed: yum and apt are sloooow. "yum update" runs take in the order of hours. * Limitations of the RH-config tools (No X11 nor Gnome on this machine. IMO, Fedora lacks "usable no-X11 config tools".). Ralf From a.badger at gmail.com Sun Jul 1 17:35:00 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 01 Jul 2007 10:35:00 -0700 Subject: FESCo Meeting Summary for 2007-06-28 In-Reply-To: <20070701161905.GC27402@puariko.nirvana> References: <1183294804.2974.0.camel@kennedy> <4687B428.5000401@fedoraproject.org> <1183303298.2974.11.camel@kennedy> <20070701154747.GA27402@puariko.nirvana> <1183305874.2974.21.camel@kennedy> <20070701161905.GC27402@puariko.nirvana> Message-ID: <1183311300.15601.59.camel@localhost.localdomain> On Sun, 2007-07-01 at 18:19 +0200, Axel Thimm wrote: > On Sun, Jul 01, 2007 at 12:04:34PM -0400, Brian Pepple wrote: > > On Sun, 2007-07-01 at 17:47 +0200, Axel Thimm wrote: > > > So the top question is: Always have mass rebuilds, no matter what, or > > > delegate this decision to a releng/tools team? > > > > That question is actually the item I have on the schedule to discuss > > (which like said I was planning on doing around the end of July). > > OK, if there really is enough time to discuss it in August, that would > be fine with me. I just think that Jesse for example would not want > the rebuilds to happen shortly before freeze time and freeze is > scheduled to happen at Aug 27th. > > Past experience shows that it would have to be started to be discussed > in fesco now, otherwise it will just not make it in time. > [snip] > Still fesco should decide on a general policy independent of > toolschain matters. This time perhaps gcc 4.2 could save the > discussion, but in F9 time people will be arguing that F8 was only > rebuilt because of gcc 4.2. I have to agree with Axel here. The decision whether or not to rebuild is one that is contentious because it is pitting engineering *necessity* against end-user *expectation* (with a tiny bit of trying to mitigate Murphy thrown in to further stir the pot.) So discussing this early to get all the issues on the table and to gather any appropriate data to make a decision is important. However, there are two factors that call for delaying: 1) the FESCo elections. If this is truly going to run to lengthy discussion, then it's probably best for the new FESCo to pick this topic up and run with it. 2) We should be trying to hash this out on the list and record it on a wiki page so FESCo can look at the wiki, ask specific questions, and then come to a decision otherwise the topic will be discussed in the meeting to even more length than it already has the potential for. So... here's a wiki page: http://fedoraproject.org/wiki/Development/Schedule/RebuildingPackages I think we should discuss on the list pros and cons and *record them* on this page so we have a clear picture of where the argument stands, and what questions might need to be answered. If all the arguments have been expressed and organized on that page then it really does boil down to FESCo weighing the pros and cons and simply making a decision. -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 rvinyard at cs.nmsu.edu Sun Jul 1 18:00:41 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Sun, 01 Jul 2007 12:00:41 -0600 Subject: OpenSceneGraph In-Reply-To: <1183308251.23976.51.camel@mccallum.corsepiu.local> References: <1183036409.24184.72.camel@mccallum.corsepiu.local> <468665FD.4080407@cs.nmsu.edu> <1183269446.23976.13.camel@mccallum.corsepiu.local> <4687730E.1080701@hhs.nl> <1183291151.23976.42.camel@mccallum.corsepiu.local> <4687CCA7.7000305@cs.nmsu.edu> <1183308251.23976.51.camel@mccallum.corsepiu.local> Message-ID: <4687EBC9.8050306@cs.nmsu.edu> Ralf Corsepius wrote: > On Sun, 2007-07-01 at 09:47 -0600, Rick L Vinyard Jr wrote: > >> Ralf Corsepius wrote: >> >>> The devel libs conflict, so the only option I see is installing OSG-2's >>> devel libs into a %{_libdir}/osg-2.0 subdir. >>> >> Personally, I'd rather see the OSG-1 libs in an osg-1.0 subdir, >> > This would be incompatible to OSG-1 as it has been shipped until now. > True. But, so is upgrading to OSG-2 (which I think is fine). >> and >> basically treat the OSG-1 packages as legacy packages. That way, the >> OpenSceneGraph package can just move ahead to 2.0 and packages that need >> OSG-1 will have to explicitly state it. >> > This is the replacing "OSG-1 by compat-OSG-1 packages" idea. It's only > applicable to the run-time packages, but not to the devel packages. > Why is it not applicable to devel packages? There are others that have: avahi-compat-howl-devel avahi-compat-libdns_sd-devel compat-guichan05-devel compat-guile-16-devel compat-libgda-devel compat-libosip2-devel compat-wxGTK-common-devel compat-wxGTK-devel compat-wxGTK2-devel compat-wxGTK26-devel From eric.tanguy at univ-nantes.fr Sun Jul 1 18:20:31 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sun, 01 Jul 2007 20:20:31 +0200 Subject: rpms/libupnp/FC-6 .cvsignore, 1.8, 1.9 libupnp.spec, 1.12, 1.13 sources, 1.8, 1.9 In-Reply-To: <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> References: <200706251734.l5PHYUt6009790@cvs-int.fedora.redhat.com> <20070626104811.f3c3a474.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1183314031.2913.2.camel@bureau.maison> > On Mon, 25 Jun 2007 13:34:30 -0400, Eric Tanguy (tanguy) wrote: > >> Author: tanguy >> >> Update of /cvs/extras/rpms/libupnp/FC-6 > >> %changelog >> +* Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 >> +- Update to version 1.6.0 >> + > > Blacklisted for now together with ushare. > It breaks dependencies in several packages. > > Run "repoquery --whatrequires libupnp.so.2", use rpmdev-diff, announce > such ABI breakage on fedora-maintainers list, and if such a version > upgrade is really necessary, coordinate rebuilds appropriately. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > gmediaserver, ushare and libupnp are released for extras 6. Could you release ushare and libupnp for extra 5 because gmediaserver has no branch for extra 5. Thanks Eric From peter at thecodergeek.com Sun Jul 1 19:55:36 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 01 Jul 2007 12:55:36 -0700 Subject: Compiz Fusion? In-Reply-To: <46879684.8080805@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> Message-ID: <1183319736.3592.6.camel@tuxhugs> On Sun, 2007-07-01 at 13:56 +0200, Alphonse Van Assche wrote: > To make this working compiz need to use texture copy instead of > texture_from_pixmap method[1] (because of the fact the fglrx driver > don't have support for texture_from_pixmap). That functionality can be > ported from beryl. Maybe a little patch to compiz must applied too[2] Maybe; but adding hacks to workaround a known-broken piece of proprietary software instead of getting the recent R300/Avivo drivers working properly for AIGLX seems entirely like a step backwards to me... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Sun Jul 1 20:00:30 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 01 Jul 2007 15:00:30 -0500 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070701155015.GB27402@puariko.nirvana> References: <20070620184020.GH23569@redhat.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <20070630221420.GF15787@puariko.nirvana> <200707011049.04431.jkeating@redhat.com> <4687CA64.8040700@redhat.com> <20070701155015.GB27402@puariko.nirvana> Message-ID: <468807DE.3090607@redhat.com> Axel Thimm wrote: > > BTW I registered some RHEL boxes and they don't show up in "OS" stats. > There's a limit at the end of some of those queries (like OS). We're working on caching the queries so we can enable the full stats again (and the devices page) that works just about ready, expect it in the next week or so. -Mike From stickster at gmail.com Sun Jul 1 20:46:20 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 01 Jul 2007 16:46:20 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <200707011042.35797.jkeating@redhat.com> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707011042.35797.jkeating@redhat.com> Message-ID: <1183322780.31412.7.camel@localhost.localdomain> On Sun, 2007-07-01 at 10:42 -0400, Jesse Keating wrote: > On Saturday 30 June 2007 19:04:18 Rahul Sundaram wrote: > > EPEL isn't targeted for Fedora. I did refer to the discussion. Think > > about this from the end user perspective rather than from the project > > perspective. > > "Fedora" is more than a distribution. Two suggestions: 1. Short required blurb at the top of all README.Fedora such as: "This documentation file is provided by the Fedora Project, from which this package is derived for use by a number of distributions. For more information about this derivation, refer to ." 2. Making use of the $DISTVAR in Makefile.common: --- Makefile.common.original 2007-07-01 16:43:18.000000000 -0400 +++ Makefile.common 2007-07-01 16:44:00.000000000 -0400 @@ -25,7 +25,7 @@ DIST = $(word 2, $(BRANCHINFO)) DISTVAR = $(word 3, $(BRANCHINFO)) DISTVAL = $(word 4, $(BRANCHINFO)) -DIST_DEFINES = --define "dist $(DIST)" --define "$(DISTVAR) $(DISTVAL)" +DIST_DEFINES = --define "dist $(DIST)" --define "distvar $(DISTVAR)" --define "$(DISTVAR) $(DISTVAL)" BUILD_FLAGS ?= $(shell echo $(KOJI_FLAGS)) Then simply use README.%{distvar} in the spec. My personal preference is alternative #1 because like others I see value in spreading the Fedora brand name. If someone's already looking through README files it's hard to make a case that they'll turn up their noses at README.Fedora, simply because of the name, in the absence of any other docs covering their needs. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Sun Jul 1 22:11:35 2007 From: opensource at till.name (Till Maas) Date: Mon, 02 Jul 2007 00:11:35 +0200 Subject: Memtest86 on release isos / where to fill bugs against iso images? Message-ID: <200707020011.37424.opensource@till.name> Hiyas, memtest86 is not included in the Fedora 7 release isos, but the release notes mention this feature. I cannot find it on the i386 DVD, the x86 Live CD and the i386 rescue CD. The isolinux/options.msg on the rescue CD also mention memtest86. Regards, Till From caillon at redhat.com Mon Jul 2 05:12:30 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 02 Jul 2007 01:12:30 -0400 Subject: RFE: Use generic names in packages In-Reply-To: <46875F69.6000605@fedoraproject.org> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> <20070630233910.GN15787@puariko.nirvana> <468717AE.4050402@fedoraproject.org> <1183269759.23976.17.camel@mccallum.corsepiu.local> <46875F69.6000605@fedoraproject.org> Message-ID: <4688893E.9070708@redhat.com> Rahul Sundaram wrote: > Ralf Corsepius wrote: > >> Rahul, you are wasting our time, by having made an issue from a >> non-issue. Users aren't as dumb as you seem to think. > > You got to stop assuming what I think of users. If you consider merely > asking for comments wasting time you are free to ignore this thread and > let people who have constructive suggestions participate. Thanks. And if people ignore a thread, then people assume there are no objections and proceed further. Don't discourage criticism. From sundaram at fedoraproject.org Mon Jul 2 06:33:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jul 2007 12:03:47 +0530 Subject: RFE: Use generic names in packages In-Reply-To: <4688893E.9070708@redhat.com> References: <468479A9.4050000@fedoraproject.org> <4684896C.3020604@redhat.com> <46849208.1050103@fedoraproject.org> <1183094681.21296.37.camel@localhost.localdomain> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <20070630231022.GJ15787@puariko.nirvana> <4686E3A7.1070106@fedoraproject.org> <20070630232235.GM15787@puariko.nirvana> <4686E819.8030207@fedoraproject.org> <20070630233910.GN15787@puariko.nirvana> <468717AE.4050402@fedoraproject.org> <1183269759.23976.17.camel@mccallum.corsepiu.local> <46875F69.6000605@fedoraproject.org> <4688893E.9070708@redhat.com> Message-ID: <46889C4B.2020201@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Ralf Corsepius wrote: >> >>> Rahul, you are wasting our time, by having made an issue from a >>> non-issue. Users aren't as dumb as you seem to think. >> >> You got to stop assuming what I think of users. If you consider merely >> asking for comments wasting time you are free to ignore this thread >> and let people who have constructive suggestions participate. Thanks. > > And if people ignore a thread, then people assume there are no > objections and proceed further. Don't discourage criticism. Criticism is fine when it is productive. Sarcasm is not. Rahul From vpivaini at cs.helsinki.fi Mon Jul 2 08:41:24 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Mon, 2 Jul 2007 11:41:24 +0300 Subject: Finding man files: CVS or RPM repositories? Message-ID: <200707021141.31212.vpivaini@cs.helsinki.fi> Hi, (CC'd to docs-list) My summer project[1] is at a stage where I need to think about finding all of the man pages in a Fedora release. I have basic CVS integration working so that the user can specify a package and a branch and it imports the man pages from that package to the wiki (by downloading the source tarball). You can read more about the status of my project from my newest weekly report[2]. But what do you think is the best way of finding all of the man pages in a release? - Do a "cvs -co", parse it, download every source package and search for man files? - Or download filelists.xml from a repository mirror, parse it to find every package that contains man pages, then download the RPMs and extract the man pages from them? - Any other ideas? And in any case, how to handle package updates? I'm starting to be in favour of the RPM repository choice. It was pointed to me in the comments of my blog[3] that sometimes the man files are edited in the .spec file and so taking the files from the binary RPMS might be a good thing. Handling package updates would also be somewhat simple if I used RPM repositories, yum does that all the time ;) Thanks in advance for your comments! [1] http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio [2] http://vpv.kapsi.fi/blog/2007/07/01/weekly-report-week-26-so-many-questions/ [3] http://vpv.kapsi.fi/blog/2007/07/01/weekly-report-week-26-so-many-questions/#comment-11 -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From seg at haxxed.com Mon Jul 2 08:48:02 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 02 Jul 2007 03:48:02 -0500 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: References: <200706281946.25821.jkeating@redhat.com> <200706291556.34321.opensource@till.name> <200706291009.55937.jam@zoidtechnologies.com> Message-ID: <1183366082.30130.11.camel@localhost> On Fri, 2007-06-29 at 16:30 +0200, Matej Cepl wrote: > On Fri, 29 Jun 2007 10:09:55 -0400, Jeff MacDonald scripst: > > +1 to use ISO-style, but please list UTC *and* local time for the > > outage. > > What local time? Why should EDT matter to me or other people living > somewhere else than on the eastern shore of the United States (and maybe > in Brazil, I am not sure)? Speaking as someone from the midwestern United States, I am very used to dealing with PST and EST, as so many technological things are based on the east and west coasts. Online services, cable TV stations and whatnot. They're only an hour/two hours off from my local time anyway. Whereas when I see a UTC date, I just go "Huh? Is that today or tomorrow?". But then I've never been any good with numbers... Seems to me, just posting both local time and UTC should cover both sides of the globe reasonably well. -------------- next part -------------- A non-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 Mon Jul 2 08:55:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jul 2007 10:55:39 +0200 Subject: Finding man files: CVS or RPM repositories? In-Reply-To: <200707021141.31212.vpivaini@cs.helsinki.fi> References: <200707021141.31212.vpivaini@cs.helsinki.fi> Message-ID: <4688BD8B.9010608@hhs.nl> Ville-Pekka Vainio wrote: > Hi, > > (CC'd to docs-list) > > My summer project[1] is at a stage where I need to think about finding all of > the man pages in a Fedora release. I have basic CVS integration working so > that the user can specify a package and a branch and it imports the man pages > from that package to the wiki (by downloading the source tarball). You can > read more about the status of my project from my newest weekly report[2]. > Hi, You're probably busy enough as is, but in case you have time another very interesting source for man pages is Debian packages, Debina creates a manpage for every package in the case upstream doesn't provide one. Some of them are useless (boilerplate) but some are quite good. Taking a look at the Debian manpages and submiytting bugs for packages who could benefit from them would be a great thing todo. Now all you need is 48 hrs in a day :) Regards, Hans > But what do you think is the best way of finding all of the man pages in a > release? > > - Do a "cvs -co", parse it, download every source package and search for man > files? > That might be the best, as sometimes packages contain man pages which do not get installed with make install, and thus do not end up in the rpm. While at it you might try to automatically also check the manpages in the rpm and if there are manpages in the sources which are not in the rpm file a bug (this can also be done automatically). Regards, Hans From pmatilai at laiskiainen.org Mon Jul 2 09:05:57 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 2 Jul 2007 12:05:57 +0300 (EEST) Subject: RFE: Use generic names in packages In-Reply-To: <1183322780.31412.7.camel@localhost.localdomain> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707011042.35797.jkeating@redhat.com> <1183322780.31412.7.camel@localhost.localdomain> Message-ID: On Sun, 1 Jul 2007, Paul W. Frields wrote: > On Sun, 2007-07-01 at 10:42 -0400, Jesse Keating wrote: >> On Saturday 30 June 2007 19:04:18 Rahul Sundaram wrote: >>> EPEL isn't targeted for Fedora. I did refer to the discussion. Think >>> about this from the end user perspective rather than from the project >>> perspective. >> >> "Fedora" is more than a distribution. > > Two suggestions: > > 1. Short required blurb at the top of all README.Fedora such as: > "This documentation file is provided by the Fedora Project, from > which this package is derived for use by a number of distributions. For > more information about this derivation, refer to ." > > 2. Making use of the $DISTVAR in Makefile.common: > > --- Makefile.common.original 2007-07-01 16:43:18.000000000 -0400 > +++ Makefile.common 2007-07-01 16:44:00.000000000 -0400 > @@ -25,7 +25,7 @@ > DIST = $(word 2, $(BRANCHINFO)) > DISTVAR = $(word 3, $(BRANCHINFO)) > DISTVAL = $(word 4, $(BRANCHINFO)) > -DIST_DEFINES = --define "dist $(DIST)" --define "$(DISTVAR) $(DISTVAL)" > +DIST_DEFINES = --define "dist $(DIST)" --define "distvar $(DISTVAR)" > --define "$(DISTVAR) $(DISTVAL)" > > BUILD_FLAGS ?= $(shell echo $(KOJI_FLAGS)) > > > Then simply use README.%{distvar} in the spec. My personal preference > is alternative #1 because like others I see value in spreading the > Fedora brand name. If someone's already looking through README files > it's hard to make a case that they'll turn up their noses at > README.Fedora, simply because of the name, in the absence of any other > docs covering their needs. 2) is one solution to "which repository this package came from" type of question, but if/when the package behaves exactly the same whether it's on RHEL (from EPEL) or Fedora, why should the name change? It's not distro-specific but packaging specific information so README.epel vs README.somethingelse is just wrong in that case. README.packaging (not distribution) or similar would be to the point. 1) is a good option, it just means defining the README.something to mean README., not README. whereas it currently means vaguely both or either. - Panu - From nicolas.mailhot at laposte.net Mon Jul 2 09:21:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 2 Jul 2007 11:21:11 +0200 (CEST) Subject: RFE: Use generic names in packages In-Reply-To: References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707011042.35797.jkeating@redhat.com> <1183322780.31412.7.camel@localhost.localdomain> Message-ID: <23217.192.54.193.51.1183368071.squirrel@rousalka.dyndns.org> Le Lun 2 juillet 2007 11:05, Panu Matilainen a ?crit : > On Sun, 1 Jul 2007, Paul W. Frields wrote: >> 2. Making use of the $DISTVAR in Makefile.common: > 2) is one solution to "which repository this package came from" type > of question Could someone explain to me why repotags were not secure enough to answer this question, but dumping a cleartext file in %doc is? -- Nicolas Mailhot From alcapcom at gmail.com Mon Jul 2 09:44:48 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Mon, 02 Jul 2007 11:44:48 +0200 Subject: Compiz Fusion? In-Reply-To: <1183319736.3592.6.camel@tuxhugs> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <1183117882.22649.0.camel@localhost.localdomain> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> Message-ID: <4688C910.2000503@gmail.com> Peter Gordon a ?crit : > On Sun, 2007-07-01 at 13:56 +0200, Alphonse Van Assche wrote: >> To make this working compiz need to use texture copy instead of >> texture_from_pixmap method[1] (because of the fact the fglrx driver >> don't have support for texture_from_pixmap). That functionality can be >> ported from beryl. Maybe a little patch to compiz must applied too[2] > > Maybe; but adding hacks to workaround a known-broken piece of > proprietary software instead of getting the recent R300/Avivo drivers > working properly for AIGLX seems entirely like a step backwards to me... > Well, I have just saying this to let know that the fglrx driver *cannot* be used with AIGLX without the above hacks and at this time we don't have Xgl in Fedora so in my eyes a choice must be done. Using XGL as a temporary hack or making temporary hacks to let users use compiz with AIGLX. If we don't do one of them, then we forgot a big part of the Fedora users. Yes, ATI driver suck for many reasons proprietary/not intensive developed/etc... but many people have such cards and saying that we don't care about it is just saying we don't care about a big part of our users, I think that's not good for Fedora. I'm personally sure that many people have switch to GNU/Linux these last year just to have a wobbly desktop with all these eye candy stuffs. I like eye candy as a awesome propaganda piece for the GNU/Linux desktops too. Just my 2 cent of the day. Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pmatilai at laiskiainen.org Mon Jul 2 09:50:40 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 2 Jul 2007 12:50:40 +0300 (EEST) Subject: RFE: Use generic names in packages In-Reply-To: <23217.192.54.193.51.1183368071.squirrel@rousalka.dyndns.org> References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707011042.35797.jkeating@redhat.com> <1183322780.31412.7.camel@localhost.localdomain> <23217.192.54.193.51.1183368071.squirrel@rousalka.dyndns.org> Message-ID: On Mon, 2 Jul 2007, Nicolas Mailhot wrote: > Le Lun 2 juillet 2007 11:05, Panu Matilainen a ?crit : >> On Sun, 1 Jul 2007, Paul W. Frields wrote: > >>> 2. Making use of the $DISTVAR in Makefile.common: > >> 2) is one solution to "which repository this package came from" type >> of question > > Could someone explain to me why repotags were not secure enough to > answer this question, but dumping a cleartext file in %doc is? My point was that while 1) would appear to be a reasonable thing to do, it's a solution to wrong problem. Those readme files aren't there to tell the user where the package came from, but to document packaging specific issues such as deviations from upstream behavior, default paths etc. - Panu - From pmatilai at laiskiainen.org Mon Jul 2 09:53:08 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 2 Jul 2007 12:53:08 +0300 (EEST) Subject: RFE: Use generic names in packages In-Reply-To: References: <46847475.6000405@fedoraproject.org> <20070630220232.GE15787@puariko.nirvana> <4686E172.3000202@fedoraproject.org> <200707011042.35797.jkeating@redhat.com> <1183322780.31412.7.camel@localhost.localdomain> <23217.192.54.193.51.1183368071.squirrel@rousalka.dyndns.org> Message-ID: On Mon, 2 Jul 2007, Panu Matilainen wrote: > On Mon, 2 Jul 2007, Nicolas Mailhot wrote: >> Le Lun 2 juillet 2007 11:05, Panu Matilainen a ?crit : >>> On Sun, 1 Jul 2007, Paul W. Frields wrote: >> >>>> 2. Making use of the $DISTVAR in Makefile.common: >> >>> 2) is one solution to "which repository this package came from" type >>> of question >> >> Could someone explain to me why repotags were not secure enough to >> answer this question, but dumping a cleartext file in %doc is? > > My point was that while 1) would appear to be a reasonable thing to do, it's > a solution to wrong problem. Those readme files aren't there to tell the user > where the package came from, but to document packaging specific issues such > as deviations from upstream behavior, default paths etc. Duh, that should be "2) would appear..." Need more coffee, desperately. - Panu - From debarshi.ray at gmail.com Mon Jul 2 09:57:34 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 2 Jul 2007 15:27:34 +0530 Subject: Pirut: Edit -> Repositories Message-ID: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> I see that the Edit->Repository menu item is not yet implemented till Pirut 1.3.8. I am going to write one for the offline package management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am making for this year's Summer of Code (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay). Do you already have some plans or suggestions in mind regarding the design and/or functionality of Edit->Repository that I can base my work on? Otherwise I can create one which will benefit both Pirut and my application. Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at redhat.com Mon Jul 2 10:11:38 2007 From: buildsys at redhat.com (Build System) Date: Mon, 2 Jul 2007 06:11:38 -0400 Subject: rawhide report: 20070702 changes Message-ID: <200707021011.l62ABc5p025805@porkchop.devel.redhat.com> Updated Packages: darcs-1.0.9-3.fc8 ----------------- * Wed Jun 27 2007 Jeremy Hinegardner - 1.0.9-3 - clean rpmlint warnings/errors - move PreReq to Requires(post) - move make check to 'check' section - mark config files as such dejavu-fonts-2.18-1.fc8 ----------------------- * Sun Jul 01 2007 Nicolas Mailhot ??? 2.18-1 ??? 2.18 final ??? Major new release adding Tifinagh (????????????), N'ko (??????) and Georgian (???????????????) (Georgian created by Besarion Paata Gugushvili ???????????????????????? ??????????????? ???????????????????????????) emacs-common-muse-3.03-1.fc8 ---------------------------- * Mon Jul 02 2007 Jonathan G. Underwood - 3.03-1 - Update to version 3.03 - Fix up the sub-package Requires to depend on release-version - Correct location of installed xemacs files hunspell-pl-0.20070701-1.fc8 ---------------------------- katapult-0.3.2.1-1.fc8 ---------------------- * Mon Jul 02 2007 Chitlesh Goorah - 0.3.2.1-1 - new upstream release * Sun Jul 01 2007 Chitlesh Goorah - 0.3.1.4-5 - Fast track sources libqalculate-0.9.6-1.fc8 ------------------------ * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release liferea-1.2.18-1.fc8 -------------------- * Sun Jul 01 2007 Brian Pepple - 1.2.18-1 - Update to 1.2.18. openldap-2.3.34-5.fc8 --------------------- * Fri Jun 29 2007 Jan Safranek 2.3.34-5.fc8 - smbk5pwd added (#220895) - correctly distribute modules between servers and servers-sql packages perl-Compress-Raw-Bzip2-2.005-1.fc8 ----------------------------------- perl-Compress-Raw-Zlib-2.005-1.fc8 ---------------------------------- perl-IO-Compress-Base-2.005-1.fc8 --------------------------------- perl-IO-Compress-Bzip2-2.005-1.fc8 ---------------------------------- pidgin-libnotify-0.13-1.fc8 --------------------------- * Sun Jul 01 2007 Peter Gordon - 0.13-1 - Update to new upstream release (0.13). - Drop renamed-to-pidgin patch (fixed upstream): - renamed-to-pidgin.patch - Alphabetize BuildRequires (aesthetic-only change). qalculate-gtk-0.9.6-1.fc8 ------------------------- * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release qalculate-kde-0.9.6-1.fc8 ------------------------- * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release selinux-policy-3.0.1-4.fc8 -------------------------- * Sun Jul 01 2007 Dan Walsh 3.0.1-4 - fix squid - Fix rpm running as uid * Tue Jun 26 2007 Dan Walsh 3.0.1-3 - Fix syslog declaration * Tue Jun 26 2007 Dan Walsh 3.0.1-2 - Allow avahi to access inotify - Remove a lot of bogus security_t:filesystem avcs Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.i386 requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.i386 requires libCEGUIBase.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.x86_64 requires libCEGUIBase.so.0()(64bit) conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.x86_64 requires libCEGUIBase.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 chess - 1.0-5.fc7.ppc requires libCEGUIBase.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 ogre-samples - 1.2.5-2.fc8.ppc requires libCEGUIBase.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) ogre-samples - 1.2.5-2.fc8.ppc64 requires libCEGUIBase.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From buc at odusz.so-cdu.ru Mon Jul 2 10:56:04 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 02 Jul 2007 14:56:04 +0400 Subject: Mail accounts in heterogeneous environments In-Reply-To: <1183206337.4870.0.camel@aragorn> References: <46853CDB.60206@odu.neva.ru> <1183206337.4870.0.camel@aragorn> Message-ID: <4688D9C4.4050302@odu.neva.ru> Trever L. Adams wrote: > Dmitry Butskoy wrote: > >> - Are there some another solution for the support of "SPA against >> domain" by Linux MTA/pop/imap servers in Fedora? >> >> Regards, >> Dmitry Butskoy >> > > Thank you for asking all of these questions. I am looking at doing a lot > of these and have not yet asked these. It seems a lot of software > (server) works with much of this, however, I would like to see > (hopefully in F8) the ability to do SPA like stuff on everything (client > and servers). After the adding of SPA support for smtp/pop3/imap servers in Fedora, it seems that we shall close to solution of this problem. At least in application level. There are enough number of applications for which NTLM implementation looks useful and which already supports it (Mozilla, Evolutiion, Squid, Apache, etc.) > Particularly, I would like to see the ability to have a > REAL cifs implementation. Right now, everything is done as the one who > mounted (or --user) the fs. Can we get an AD version of this so that > permissions get used and mapped as much as possible to Linux fs > permissions and so that the user who requests the operation is the user > used, not root, not --user, etc.? > Such a mapping is implemented in Samba's winbind daemon (i.e. SID->uid mapping etc.). The issue is how to report this mapping to kernel level. Perhaps it is a task for some user-level filesystem over FUSE ?... ~buc From drago01 at gmail.com Mon Jul 2 11:00:39 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 2 Jul 2007 13:00:39 +0200 Subject: Memtest86 on release isos / where to fill bugs against iso images? In-Reply-To: <200707020011.37424.opensource@till.name> References: <200707020011.37424.opensource@till.name> Message-ID: On 7/2/07, Till Maas wrote: > > Hiyas, > > memtest86 is not included in the Fedora 7 release isos, but the release > notes > mention this feature. I cannot find it on the i386 DVD, the x86 Live CD > and > the i386 rescue CD. The isolinux/options.msg on the rescue CD also mention > memtest86. try to fill them against distrubution Regards, > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Mon Jul 2 11:08:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Jul 2007 16:38:29 +0530 Subject: Memtest86 on release isos / where to fill bugs against iso images? In-Reply-To: References: <200707020011.37424.opensource@till.name> Message-ID: <4688DCAD.6030204@fedoraproject.org> dragoran wrote: > > > On 7/2/07, *Till Maas* > wrote: > > Hiyas, > > memtest86 is not included in the Fedora 7 release isos, but the > release notes > mention this feature. I cannot find it on the i386 DVD, the x86 Live > CD and > the i386 rescue CD. The isolinux/options.msg on the rescue CD also > mention > memtest86. > > > try to fill them against distrubution I have reassigned your earlier bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245497 Rahul From skvidal at linux.duke.edu Mon Jul 2 12:05:41 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 02 Jul 2007 08:05:41 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> Message-ID: <1183377941.15032.23.camel@cutter> On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray wrote: > I see that the Edit->Repository menu item is not yet implemented till > Pirut 1.3.8. I am going to write one for the offline package > management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am > making for this year's Summer of Code > (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay). > > Do you already have some plans or suggestions in mind regarding the > design and/or functionality of Edit->Repository that I can base my > work on? Otherwise I can create one which will benefit both Pirut and > my application. > one already exists. Look up 'repoman'. -sv From tla at rasmil.dk Mon Jul 2 12:16:44 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Mon, 02 Jul 2007 14:16:44 +0200 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> Message-ID: <4688ECAC.8020406@rasmil.dk> Debarshi 'Rishi' Ray wrote: > I see that the Edit->Repository menu item is not yet implemented till > Pirut 1.3.8. I am going to write one for the offline package > management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am > making for this year's Summer of Code > (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay). > > Do you already have some plans or suggestions in mind regarding the > design and/or functionality of Edit->Repository that I can base my > work on? Otherwise I can create one which will benefit both Pirut and > my application. > > Thanks, > Debarshi I have also created a 'system-config-repositories' tool to edit repositories, feel free to use any code you like. http://tim.yum-extender.org/blog/2007/02/12/yum-repository-configuration-tool/ http://yumex.svn.sourceforge.net/viewvc/yumex/trunk/system-config-repo/ Tim From debarshi.ray at gmail.com Mon Jul 2 12:26:50 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 2 Jul 2007 17:56:50 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <4688ECAC.8020406@rasmil.dk> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <4688ECAC.8020406@rasmil.dk> Message-ID: <3170f42f0707020526k20c8d0bj905a09d1eb6c010a@mail.gmail.com> Thanks. By the way is there any decision on whether Pirut should have the "configure repository" functionality, or it should be restricted to repoman or system-config-repositories? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From ssorce at redhat.com Mon Jul 2 13:58:15 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Jul 2007 09:58:15 -0400 Subject: Mail accounts in heterogeneous environments In-Reply-To: <4688D9C4.4050302@odu.neva.ru> References: <46853CDB.60206@odu.neva.ru> <1183206337.4870.0.camel@aragorn> <4688D9C4.4050302@odu.neva.ru> Message-ID: <1183384695.3567.10.camel@localhost.localdomain> On Mon, 2007-07-02 at 14:56 +0400, Dmitry Butskoy wrote: > Trever L. Adams wrote: > > Dmitry Butskoy wrote: > > > >> - Are there some another solution for the support of "SPA against > >> domain" by Linux MTA/pop/imap servers in Fedora? > >> > >> Regards, > >> Dmitry Butskoy > >> > > > > Thank you for asking all of these questions. I am looking at doing a lot > > of these and have not yet asked these. It seems a lot of software > > (server) works with much of this, however, I would like to see > > (hopefully in F8) the ability to do SPA like stuff on everything (client > > and servers). > > After the adding of SPA support for smtp/pop3/imap servers in Fedora, it > seems that we shall close to solution of this problem. At least in > application level. There are enough number of applications for which > NTLM implementation looks useful and which already supports it (Mozilla, > Evolutiion, Squid, Apache, etc.) While I am all for supporting NTLM, what I'd really like to see is Kerberos support. Some of these services use SASL/GSSAPI, but there are still too many that does not. One idea I am dreaming of is to make it possible to install a "local" kerberos realm on each fedora installation. This would make it possible to kerberize services and have SSO with your own machine services (think of accessing the CUPS web interface or your own home via apache without password prompts as your auth is done via kerberos). > > Particularly, I would like to see the ability to have a > > REAL cifs implementation. Right now, everything is done as the one who > > mounted (or --user) the fs. Can we get an AD version of this so that > > permissions get used and mapped as much as possible to Linux fs > > permissions and so that the user who requests the operation is the user > > used, not root, not --user, etc.? > > > > Such a mapping is implemented in Samba's winbind daemon (i.e. SID->uid > mapping etc.). The issue is how to report this mapping to kernel level. > Perhaps it is a task for some user-level filesystem over FUSE ?... No the problem is different, the problem is re-authenticating users and opening a new session when they walk in a mount point. CIFS is not NFS, the server does NOT trust the clients, you can't mount authenticating as Joe and then tell the server: "hey I am Jim, let me access his files". You must re-auth as Jim to _prove_ you really are. So the real problem is not much about mapping (there is no real mapping problem cause the WHOAMI call can tell you what's Joe and Jim's SIDs and anything else does not really matter as a client. The real problem is to re-auth. Where do you get the credentials? The very best way is to use Kerberos (NFSv4 does this for example) so that all you need is to have a ticket on your system and the kernel can use it on your behalf when you walk mount-points. Unfortunately using kerberos is easier said than done, as you can't simply link to libkrb5 in the kernel. So you need a helper daemon and an upcall mechanism ... difficult to do, but we will eventually get there. Another way is to cache credentials and use NTLM, but that's not alway available anyway (some AD environments starts mandating Kerberos only). All this stuff is planned, it is just a matter of time and deciding on the correct upcall machs. Simo. From buildsys at fedoraproject.org Mon Jul 2 14:32:06 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Jul 2007 10:32:06 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-02 Message-ID: <20070702143206.67C1A152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 5: 3 ekg-1.7-1.fc5 libqalculate-0.9.6-1.fc5 qalculate-gtk-0.9.6-1.fc5 Changes in Fedora Extras 5: ekg-1.7-1.fc5 ------------- * Fri Jun 29 2007 Dominik Mierzejewski 1.7-1 - 1.7 final - enable voip support (gsm is in Fedora now) - remove redundant BR: autoconf - support giflib - fixes CVE-2007-166{3,4,5} (bug #246034) libqalculate-0.9.6-1.fc5 ------------------------ * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release qalculate-gtk-0.9.6-1.fc5 ------------------------- * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From katzj at redhat.com Mon Jul 2 14:42:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 02 Jul 2007 10:42:01 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> Message-ID: <1183387321.10801.17.camel@aglarond.local> On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray wrote: > I see that the Edit->Repository menu item is not yet implemented till > Pirut 1.3.8. I am going to write one for the offline package > management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am > making for this year's Summer of Code > (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay). > > Do you already have some plans or suggestions in mind regarding the > design and/or functionality of Edit->Repository that I can base my > work on? Otherwise I can create one which will benefit both Pirut and > my application. There's definitely need to flesh out and actually have the menu item in pirut be useful. There's already some code in various places (repoman and system-config-repositories in yumex are standalone... I think there's also some code in revisor). But I'm not all that sold on the UI with either... I think the place to start is with writing up some use cases and then trying to do some mockups from there before ever writing any code. Then the tricky part is likely to be doing the config reading/writing in a way that's not lossy. repoman actually has a good start on some of this, but it'd be nice to actually work towards getting that code into yum itself so that every tool doesn't have to re-invent those bits. Jeremy From skvidal at linux.duke.edu Mon Jul 2 15:00:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 02 Jul 2007 11:00:07 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: <1183387321.10801.17.camel@aglarond.local> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> Message-ID: <1183388407.26110.3.camel@cutter> On Mon, 2007-07-02 at 10:42 -0400, Jeremy Katz wrote: > On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray wrote: > > I see that the Edit->Repository menu item is not yet implemented till > > Pirut 1.3.8. I am going to write one for the offline package > > management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am > > making for this year's Summer of Code > > (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay). > > > > Do you already have some plans or suggestions in mind regarding the > > design and/or functionality of Edit->Repository that I can base my > > work on? Otherwise I can create one which will benefit both Pirut and > > my application. > > There's definitely need to flesh out and actually have the menu item in > pirut be useful. There's already some code in various places (repoman > and system-config-repositories in yumex are standalone... I think > there's also some code in revisor). But I'm not all that sold on the UI > with either... > > I think the place to start is with writing up some use cases and then > trying to do some mockups from there before ever writing any code. > > Then the tricky part is likely to be doing the config reading/writing in > a way that's not lossy. repoman actually has a good start on some of > this, but it'd be nice to actually work towards getting that code into > yum itself so that every tool doesn't have to re-invent those bits. that's fine - provided we aren't pulling in the gui portion of repoman. I have no interest in dragging along gtk bits in/around yum. -sv From greno at verizon.net Mon Jul 2 15:12:20 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 02 Jul 2007 11:12:20 -0400 Subject: Package requests: python-egenix-mxdatetime and python-urwid Message-ID: <468915D4.2080002@verizon.net> I would like to request that the following packages be added to Fedora: python-egenix-mxdatetime # or alternatively egenix mx base python-urwid From cweyl at alumni.drew.edu Mon Jul 2 15:39:26 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 2 Jul 2007 08:39:26 -0700 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <200707011041.47992.jkeating@redhat.com> References: <200706301055.46506.jkeating@redhat.com> <4686D2EA.9040703@di.uminho.pt> <200707011041.47992.jkeating@redhat.com> Message-ID: <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> On 7/1/07, Jesse Keating wrote: > On Saturday 30 June 2007 18:02:18 Jose Pedro Oliveira wrote: > > Right now we don't have an easy way to pull all the perl core modules > > into he build system. > > Perhaps you missed the sarcasm. Saying "we don't have an easy way to pull all > the perl core modules in" sounds to me like "we don't want to figure out what > perl modules we're actually using and ask for them, we'd rather everything be > there and not care. I know I'm opening myself up to sarcasm here, but in this case it's really not warranted. Perl packaging in fedora has a long history, with a comprehensive set of guidelines and packaging customs enforced as law by reviewers and the SIG. This change breaks one of the fundamental assertions of those guidelines: "don't BR core modules; that's sloppy packaging and they are guaranteed to always be installed anyways." While there are serious arguments on both sides of this perl split, the request for a meta-package to emulate the prior behaviour (especially on one's own system) is not a presumptively irrational request. -Chris -- Chris Weyl Ex astris, scientia From ruben at rubenkerkhof.com Mon Jul 2 16:27:43 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Mon, 2 Jul 2007 18:27:43 +0200 Subject: Package requests: python-egenix-mxdatetime and python-urwid In-Reply-To: <468915D4.2080002@verizon.net> References: <468915D4.2080002@verizon.net> Message-ID: <670E8430-C906-4302-BBBA-DE55D91B845D@rubenkerkhof.com> On 2-jul-2007, at 17:12, Gerry Reno wrote: > I would like to request that the following packages be added to > Fedora: > > python-egenix-mxdatetime # or alternatively egenix mx base > python-urwid Please add them to the wishlist at http://fedoraproject.org/wiki/PackageMaintainers/WishList Ruben From tcallawa at redhat.com Mon Jul 2 16:27:33 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Jul 2007 11:27:33 -0500 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> References: <200706301055.46506.jkeating@redhat.com> <4686D2EA.9040703@di.uminho.pt> <200707011041.47992.jkeating@redhat.com> <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> Message-ID: <1183393654.4103.12.camel@localhost.localdomain> On Mon, 2007-07-02 at 08:39 -0700, Chris Weyl wrote: > While there are serious arguments on both sides of this perl split, > the request for a meta-package to emulate the prior behaviour > (especially on one's own system) is not a presumptively irrational > request. I don't see anything wrong with a perl metapackage, perl-core. Would that be preferred to a yum group? ~spot From jkeating at redhat.com Mon Jul 2 16:49:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 12:49:28 -0400 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <1183393654.4103.12.camel@localhost.localdomain> References: <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> <1183393654.4103.12.camel@localhost.localdomain> Message-ID: <200707021249.32821.jkeating@redhat.com> On Monday 02 July 2007 12:27:33 Tom "spot" Callaway wrote: > I don't see anything wrong with a perl metapackage, perl-core. > > Would that be preferred to a yum group? I have a bit of a surface loathing of metapackages. Why is it that perl packages can't BuildRequire what they need? Is there real good reason why a seemingly arbitrary rule like "don't BR 'core' perl packages" should continue to exist, especially now that there is no clear distinction of what is 'core' and what isn't? -- 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 Mon Jul 2 16:53:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 12:53:35 -0400 Subject: Plan for Today's (20070702) Release Engineering meeting Message-ID: <200707021253.35881.jkeating@redhat.com> Below you will find a list of topics that we'd like to go over in the next RelEng meeting that is scheduled for Today, Monday at 1700 UTC in #fedora-meeting on irc.freenode.org: /topic RELENG-Meeting - Fedora 5 shutdown - JesseKeating /topic RELENG-Meeting - Fedora 8 Schedule Adjustments - JesseKeating /topic RELENG-Meeting - Fedora Signing Server - JesseKeating /topic RELENG-Meeting - perl-devel in buildroots - JesseKeating /topic RELENG-Meeting - Open Discussion You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Open Discussion" phase. If your name/nick is on above list please update the status on the ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That way all the other RelEng members and interested contributors know whats up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... -- 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 cweyl at alumni.drew.edu Mon Jul 2 17:10:10 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 2 Jul 2007 10:10:10 -0700 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <1183393654.4103.12.camel@localhost.localdomain> References: <200706301055.46506.jkeating@redhat.com> <4686D2EA.9040703@di.uminho.pt> <200707011041.47992.jkeating@redhat.com> <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> <1183393654.4103.12.camel@localhost.localdomain> Message-ID: <7dd7ab490707021010j208e5bc4n1245ca1eab735246@mail.gmail.com> On 7/2/07, Tom spot Callaway wrote: > On Mon, 2007-07-02 at 08:39 -0700, Chris Weyl wrote: > > > While there are serious arguments on both sides of this perl split, > > the request for a meta-package to emulate the prior behaviour > > (especially on one's own system) is not a presumptively irrational > > request. > > I don't see anything wrong with a perl metapackage, perl-core. > > Would that be preferred to a yum group? I'd certainly prefer it to a yum group, for a number of reasons. (e.g. minimum versioning of requires in 'perl-core' if we do end up with different levels available out there, for one. apt for two ) -Chris -- Chris Weyl Ex astris, scientia From cweyl at alumni.drew.edu Mon Jul 2 17:23:04 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 2 Jul 2007 10:23:04 -0700 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <200707021249.32821.jkeating@redhat.com> References: <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> <1183393654.4103.12.camel@localhost.localdomain> <200707021249.32821.jkeating@redhat.com> Message-ID: <7dd7ab490707021023s36433a8djf8bbe33f8c4e6011@mail.gmail.com> On 7/2/07, Jesse Keating wrote: > On Monday 02 July 2007 12:27:33 Tom "spot" Callaway wrote: > > I don't see anything wrong with a perl metapackage, perl-core. > > > > Would that be preferred to a yum group? > > I have a bit of a surface loathing of metapackages. > > Why is it that perl packages can't BuildRequire what they need? Is there real > good reason why a seemingly arbitrary rule like "don't BR 'core' perl > packages" should continue to exist, especially now that there is no clear > distinction of what is 'core' and what isn't? Well, that's one of the things we're still -- slowly -- hashing out. The perl packaging practices evolved through practical application over years, before fedora.us even. It may seem arbitrary, much as "GPL or Artistic" not "Artistic or GPL" is, but consensus was reached on this point a _long_ time ago. Changing this practice, as we're currently being forced to at some level, is causing pain and cannot just be done overnight. It'll take time for a new consensus to evolve, which is both fine and good. Until that happens, we need to be flexible and accommodating to different approaches; it's all part of the process. Part of that is providing a way to emulate the prior behaviour on one's system -- and I can see applications outside packaging where Jane Q. Sysadmin may need to ensure "core perl" is installed on all the systems she manages. And -- while I'm generalizing here, it's safe to say that when people think of "core perl", they don't think of the way we're splitting perl. The distinction still exists, even if Fedora is doing things differently. -Chris -- Chris Weyl Ex astris, scientia From j.w.r.degoede at hhs.nl Mon Jul 2 17:40:28 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jul 2007 19:40:28 +0200 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <200707021253.35881.jkeating@redhat.com> References: <200707021253.35881.jkeating@redhat.com> Message-ID: <4689388C.807@hhs.nl> Jesse Keating wrote: > Below you will find a list of topics that we'd like to go over in the next > RelEng meeting that is scheduled for Today, Monday at 1700 UTC in > #fedora-meeting on irc.freenode.org: > > /topic RELENG-Meeting - Fedora 5 shutdown - JesseKeating > > /topic RELENG-Meeting - Fedora 8 Schedule Adjustments - JesseKeating > > /topic RELENG-Meeting - Fedora Signing Server - JesseKeating > > /topic RELENG-Meeting - perl-devel in buildroots - JesseKeating > > /topic RELENG-Meeting - Open Discussion > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Open > Discussion" phase. > > If your name/nick is on above list please update the status on the > ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That > way all the other RelEng members and interested contributors know whats up > ahead of the meeting. And we will avoid long delays in the meeting -- those > often arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > May I suggest adding: /topic RELENG-Meeting - Automatic promotion of updates from updates-testing Since some people do NOT want this, there should be an option with the initial update submission saying auto push / promote in X days with 3 <= X <= 30, or something like that. Regards, Hans From jwboyer at jdub.homelinux.org Mon Jul 2 17:31:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Jul 2007 12:31:55 -0500 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <4689388C.807@hhs.nl> References: <200707021253.35881.jkeating@redhat.com> <4689388C.807@hhs.nl> Message-ID: <1183397515.16523.31.camel@weaponx.rchland.ibm.com> On Mon, 2007-07-02 at 19:40 +0200, Hans de Goede wrote: > Jesse Keating wrote: > > Below you will find a list of topics that we'd like to go over in the next > > RelEng meeting that is scheduled for Today, Monday at 1700 UTC in > > #fedora-meeting on irc.freenode.org: > > > > /topic RELENG-Meeting - Fedora 5 shutdown - JesseKeating > > > > /topic RELENG-Meeting - Fedora 8 Schedule Adjustments - JesseKeating > > > > /topic RELENG-Meeting - Fedora Signing Server - JesseKeating > > > > /topic RELENG-Meeting - perl-devel in buildroots - JesseKeating > > > > /topic RELENG-Meeting - Open Discussion > > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Open > > Discussion" phase. > > > > If your name/nick is on above list please update the status on the > > ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That > > way all the other RelEng members and interested contributors know whats up > > ahead of the meeting. And we will avoid long delays in the meeting -- those > > often arise if someone describes the recent happenings on a topic directly in > > the meeting while all the others have to wait for his slow typing... > > > > > > May I suggest adding: > /topic RELENG-Meeting - Automatic promotion of updates from updates-testing > > Since some people do NOT want this, there should be an option with the initial > update submission saying auto push / promote in X days with 3 <= X <= 30, or > something like that. We already talked about that during the June 25th meeting. josh From jkeating at redhat.com Mon Jul 2 17:30:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 13:30:21 -0400 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <4689388C.807@hhs.nl> References: <200707021253.35881.jkeating@redhat.com> <4689388C.807@hhs.nl> Message-ID: <200707021330.21629.jkeating@redhat.com> On Monday 02 July 2007 13:40:28 Hans de Goede wrote: > May I suggest adding: > /topic RELENG-Meeting - Automatic promotion of updates from updates-testing > > Since some people do NOT want this, there should be an option with the > initial update submission saying auto push / promote in X days with 3 <= X > <= 30, or something like that. We talked about that last week. See last week's minutes: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-25 -- 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 Mon Jul 2 17:48:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jul 2007 19:48:44 +0200 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <200707021330.21629.jkeating@redhat.com> References: <200707021253.35881.jkeating@redhat.com> <4689388C.807@hhs.nl> <200707021330.21629.jkeating@redhat.com> Message-ID: <46893A7C.30200@hhs.nl> Jesse Keating wrote: > On Monday 02 July 2007 13:40:28 Hans de Goede wrote: >> May I suggest adding: >> /topic RELENG-Meeting - Automatic promotion of updates from updates-testing >> >> Since some people do NOT want this, there should be an option with the >> initial update submission saying auto push / promote in X days with 3 <= X >> <= 30, or something like that. > > We talked about that last week. See last week's minutes: > > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-25 > Thanks! It says there: "It's up to releng and QA to create a framework around how it should work." Has such a framework been created, if not isn't that something that should be discussed? Regards, Hans From jkeating at redhat.com Mon Jul 2 17:40:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 13:40:12 -0400 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <46893A7C.30200@hhs.nl> References: <200707021253.35881.jkeating@redhat.com> <200707021330.21629.jkeating@redhat.com> <46893A7C.30200@hhs.nl> Message-ID: <200707021340.12856.jkeating@redhat.com> On Monday 02 July 2007 13:48:44 Hans de Goede wrote: > Thanks! > > It says there: "It's up to releng and QA to create a framework around how > it should work." Has such a framework been created, if not isn't that > something that should be discussed? That's part of the topic heading. All that rel-eng has agreed upon thus far is the constraints to auto pushing. QA may add more. Ultimately it's up to Luke Macken to develop it, or somebody to provide patches for 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 mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 2 17:45:09 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 03 Jul 2007 02:45:09 +0900 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <4689388C.807@hhs.nl> References: <200707021253.35881.jkeating@redhat.com> <4689388C.807@hhs.nl> Message-ID: <468939A5.2000802@ioa.s.u-tokyo.ac.jp> Hans de Goede wrote, at 07/03/2007 02:40 AM +9:00: > Jesse Keating wrote: >> Below you will find a list of topics that we'd like to go over in the >> next RelEng meeting that is scheduled for Today, Monday at 1700 UTC in >> #fedora-meeting on irc.freenode.org: >> >> >> You want something to be discussed? > May I suggest adding: > /topic RELENG-Meeting - Automatic promotion of updates from updates-testing Also I want to have this issue discussed again. Currently I see one package * which stays in updates-testing for more than 3 weeks * several people reported on Japanese Fedora BBS that the updates-testing package fixed the issues they had been meeting and they wanted to have the package pushed to stable * even I requested the maintainer to push to stable Current state is unpleasant to me. Mamoru From tla at rasmil.dk Mon Jul 2 17:38:16 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Mon, 02 Jul 2007 19:38:16 +0200 Subject: Pirut: Edit -> Repositories In-Reply-To: <1183387321.10801.17.camel@aglarond.local> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> Message-ID: <46893808.7090405@rasmil.dk> Jeremy Katz wrote: > On Mon, 2007-07-02 at 15:27 +0530, Debarshi 'Rishi' Ray wrote: > >> I see that the Edit->Repository menu item is not yet implemented till >> Pirut 1.3.8. I am going to write one for the offline package >> management tool (http://fedoraproject.org/wiki/DebarshiRay/rum) I am >> making for this year's Summer of Code >> (http://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay). >> >> Do you already have some plans or suggestions in mind regarding the >> design and/or functionality of Edit->Repository that I can base my >> work on? Otherwise I can create one which will benefit both Pirut and >> my application. >> > > There's definitely need to flesh out and actually have the menu item in > pirut be useful. There's already some code in various places (repoman > and system-config-repositories in yumex are standalone... I think > there's also some code in revisor). But I'm not all that sold on the UI > with either... > > I think the place to start is with writing up some use cases and then > trying to do some mockups from there before ever writing any code. > > Then the tricky part is likely to be doing the config reading/writing in > a way that's not lossy. repoman actually has a good start on some of > this, but it'd be nice to actually work towards getting that code into > yum itself so that every tool doesn't have to re-invent those bits. > > Jeremy > > Sounds like a good idea, the config write routine in yum will remove all the # comment lines and mix all the options. I fixed the mixing in system-config-repo by building a extra layer on the yum config API, but it don't take care off the # comments. I would be a good idea to teach yum to save config files, without losing information. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Jul 2 17:50:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 13:50:28 -0400 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: <468939A5.2000802@ioa.s.u-tokyo.ac.jp> References: <200707021253.35881.jkeating@redhat.com> <4689388C.807@hhs.nl> <468939A5.2000802@ioa.s.u-tokyo.ac.jp> Message-ID: <200707021350.28962.jkeating@redhat.com> On Monday 02 July 2007 13:45:09 Mamoru Tasaka wrote: > Currently I see one package > * which stays in updates-testing for more than 3 weeks > * several people reported on Japanese Fedora BBS that the updates-testing > ? package fixed the issues they had been meeting and they wanted to have > ? the package pushed to stable > * even I requested the maintainer to push to stable > Current state is unpleasant to me. Ultimately the maintainer will have final say whether something gets pushed to stable or not. I really don't want to allow a maintainer proposing an update, and then somebody else coming along and pushing it without the original maintainer's blessing (yes, there are some exceptions, like security updates or whatnot). If we had the automatic promotion of upgrades feature, the maintainer could have set a timeout and had it happen automatically unless they (or somebody else) stopped it. But aside from that nobody else should be able to promote it behind the maintainer's back. -- 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 kagesenshi.87 at gmail.com Mon Jul 2 18:07:06 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 3 Jul 2007 02:07:06 +0800 Subject: Compiz Fusion? In-Reply-To: <4688C910.2000503@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> Message-ID: On 7/2/07, Alphonse Van Assche wrote: > Peter Gordon a ?crit : > > On Sun, 2007-07-01 at 13:56 +0200, Alphonse Van Assche wrote: > >> To make this working compiz need to use texture copy instead of > >> texture_from_pixmap method[1] (because of the fact the fglrx driver > >> don't have support for texture_from_pixmap). That functionality can be > >> ported from beryl. Maybe a little patch to compiz must applied too[2] > > > > Maybe; but adding hacks to workaround a known-broken piece of > > proprietary software instead of getting the recent R300/Avivo drivers > > working properly for AIGLX seems entirely like a step backwards to me... > > > Well, I have just saying this to let know that the fglrx driver *cannot* > be used with AIGLX without the above hacks and at this time we don't > have Xgl in Fedora so in my eyes a choice must be done. Using XGL as a > temporary hack or making temporary hacks to let users use compiz with > AIGLX. If we don't do one of them, then we forgot a big part of the > Fedora users. does that mean its working? or is it not? or is it working after patching? > > Yes, ATI driver suck for many reasons proprietary/not intensive > developed/etc... but many people have such cards and saying that we > don't care about it is just saying we don't care about a big part of our > users, I think that's not good for Fedora. In my place, ATi users are more than NVidia users, its a pain when trying to promote Fedora to them .. and with fglrx is broken in F7 .. I have no idea what to answer if they asked .. > I'm personally sure that many > people have switch to GNU/Linux these last year just to have a wobbly > desktop with all these eye candy stuffs. I like eye candy as a awesome > propaganda piece for the GNU/Linux desktops too. +1. the Wow factor... > > Just my 2 cent of the day. > Alphonse > back to topic , I just rewrote desktop-effects in .py to make use compizconfig-python .. attached them together with this email .. -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: desktop-effects.glade Type: application/x-glade Size: 16488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: desktop-effects.py Type: text/x-python Size: 5887 bytes Desc: not available URL: From jam at zoidtechnologies.com Mon Jul 2 18:18:45 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Mon, 2 Jul 2007 14:18:45 -0400 Subject: koji.fedoraproject.org Unplanned outage | 6/28/07 - 6:00PM EDT In-Reply-To: <1183366082.30130.11.camel@localhost> References: <200706281946.25821.jkeating@redhat.com> <1183366082.30130.11.camel@localhost> Message-ID: <200707021418.45994.jam@zoidtechnologies.com> On Monday 02 July 2007 4:48 am, Callum Lerwick wrote: > > Seems to me, just posting both local time and UTC should cover both > sides of the globe reasonably well. +1 regards, -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From greno at verizon.net Mon Jul 2 18:28:48 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 02 Jul 2007 14:28:48 -0400 Subject: Package requests: python-egenix-mxdatetime and python-urwid In-Reply-To: <670E8430-C906-4302-BBBA-DE55D91B845D@rubenkerkhof.com> References: <468915D4.2080002@verizon.net> <670E8430-C906-4302-BBBA-DE55D91B845D@rubenkerkhof.com> Message-ID: <468943E0.6040803@verizon.net> Ruben Kerkhof wrote: > > On 2-jul-2007, at 17:12, Gerry Reno wrote: > >> I would like to request that the following packages be added to Fedora: >> >> python-egenix-mxdatetime # or alternatively egenix mx base >> python-urwid > > Please add them to the wishlist at > http://fedoraproject.org/wiki/PackageMaintainers/WishList > > Ruben > Could someone with edit privileges please add these packages to the wiki wishlist. I don't have any way to edit the page or the time to figure out how to get through the signup process right now. Thanks, Gerry From valent.turkovic at gmail.com Mon Jul 2 18:45:44 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 2 Jul 2007 20:45:44 +0200 Subject: how to install online-desktop? Message-ID: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> How can one install online-desktop? by reading instructions on this link: http://developer.mugshot.org/wiki/Online_Desktop_Project it looks like simple "yum install online-desktop" should work, but on my system it says that there are no such packages. Is my system miss configured? Am I missing some yum repository? Or are author of this page a little ahead of them selves? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From jkeating at redhat.com Mon Jul 2 18:46:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 14:46:38 -0400 Subject: how to install online-desktop? In-Reply-To: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> Message-ID: <200707021446.39036.jkeating@redhat.com> On Monday 02 July 2007 14:45:44 Valent Turkovic wrote: > it looks like simple "yum install online-desktop" should work, but on > my system it says that there are no such packages. > > Is my system miss configured? Am I missing some yum repository? Or are > author of this page a little ahead of them selves? 'yum install bigboard' -- 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 valent.turkovic at gmail.com Mon Jul 2 18:54:55 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 2 Jul 2007 20:54:55 +0200 Subject: how to install online-desktop? In-Reply-To: <200707021446.39036.jkeating@redhat.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> Message-ID: <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> Nope, that package also doesn't exist. See for yourself: # yum install bigboard Loading "downloadonly" plugin Loading "presto" plugin Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Setting up Presto Reading Presto metadata in from local files Nothing to do On 7/2/07, Jesse Keating wrote: > On Monday 02 July 2007 14:45:44 Valent Turkovic wrote: > > it looks like simple "yum install online-desktop" should work, but on > > my system it says that there are no such packages. > > > > Is my system miss configured? Am I missing some yum repository? Or are > > author of this page a little ahead of them selves? > > 'yum install bigboard' > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From dr.diesel at gmail.com Mon Jul 2 19:02:08 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 2 Jul 2007 14:02:08 -0500 Subject: how to install online-desktop? In-Reply-To: <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> Message-ID: <2a28d2ab0707021202s65e1f9c0hf88f7972dfc9e535@mail.gmail.com> Works fine for me. Came from development. On 7/2/07, Valent Turkovic wrote: > Nope, that package also doesn't exist. See for yourself: > > # yum install bigboard > Loading "downloadonly" plugin > Loading "presto" plugin > Loading "installonlyn" plugin > Setting up Install Process > Parsing package install arguments > Setting up Presto > Reading Presto metadata in from local files > Nothing to do > > > > > On 7/2/07, Jesse Keating wrote: > > On Monday 02 July 2007 14:45:44 Valent Turkovic wrote: > > > it looks like simple "yum install online-desktop" should work, but on > > > my system it says that there are no such packages. > > > > > > Is my system miss configured? Am I missing some yum repository? Or are > > > author of this page a little ahead of them selves? > > > > 'yum install bigboard' > > > > -- > > Jesse Keating > > Release Engineer: Fedora > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241 > Skype: valent.turkovic > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- On Tap: HopZilla and a Belgian Tripel Fermentating: Imperial English Pale Ale Fermentating: Guinness Extra Extra Imperial Stout Fermentating: Belgian Tripel Dry Next: Brutal Blackend Bitter From jeff at ocjtech.us Mon Jul 2 19:02:21 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 02 Jul 2007 14:02:21 -0500 Subject: how to install online-desktop? In-Reply-To: <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> Message-ID: <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> On Mon, 2007-07-02 at 20:54 +0200, Valent Turkovic wrote: > Nope, that package also doesn't exist. See for yourself: > > # yum install bigboard > Loading "downloadonly" plugin > Loading "presto" plugin > Loading "installonlyn" plugin > Setting up Install Process > Parsing package install arguments > Setting up Presto > Reading Presto metadata in from local files > Nothing to do I believe that bigboard is only available for F-7 and rawhide. 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 poelstra at redhat.com Mon Jul 2 19:08:03 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 02 Jul 2007 12:08:03 -0700 Subject: Feature Process Proposal v0.2 Message-ID: <46894D13.5080206@redhat.com> As requested here: https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00025.html Please find the latest updated version here: http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft Please add your comments and proposed changes to the bottom of the wiki page so that all concerns and clarifications can easily be collected and addressed in one place. This proposal is scheduled for review and a vote at the FESCo meeting on 2007-07-05. Thank you for your feedback, John From jwboyer at jdub.homelinux.org Mon Jul 2 19:18:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Jul 2007 14:18:37 -0500 Subject: how to install online-desktop? In-Reply-To: <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> Message-ID: <1183403917.16523.44.camel@weaponx.rchland.ibm.com> On Mon, 2007-07-02 at 14:02 -0500, Jeffrey C. Ollie wrote: > On Mon, 2007-07-02 at 20:54 +0200, Valent Turkovic wrote: > > Nope, that package also doesn't exist. See for yourself: > > > > # yum install bigboard > > Loading "downloadonly" plugin > > Loading "presto" plugin > > Loading "installonlyn" plugin > > Setting up Install Process > > Parsing package install arguments > > Setting up Presto > > Reading Presto metadata in from local files > > Nothing to do > > I believe that bigboard is only available for F-7 and rawhide. Only rawhide as I understand it. josh From dr.diesel at gmail.com Mon Jul 2 19:22:52 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Mon, 2 Jul 2007 14:22:52 -0500 Subject: how to install online-desktop? In-Reply-To: <1183403917.16523.44.camel@weaponx.rchland.ibm.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> <1183403917.16523.44.camel@weaponx.rchland.ibm.com> Message-ID: <2a28d2ab0707021222t6d8442f0s232a0337ce84cce8@mail.gmail.com> Hold off anyhow. Today it simply crashed and deleted by top menu bar!!! On 7/2/07, Josh Boyer wrote: > On Mon, 2007-07-02 at 14:02 -0500, Jeffrey C. Ollie wrote: > > On Mon, 2007-07-02 at 20:54 +0200, Valent Turkovic wrote: > > > Nope, that package also doesn't exist. See for yourself: > > > > > > # yum install bigboard > > > Loading "downloadonly" plugin > > > Loading "presto" plugin > > > Loading "installonlyn" plugin > > > Setting up Install Process > > > Parsing package install arguments > > > Setting up Presto > > > Reading Presto metadata in from local files > > > Nothing to do > > > > I believe that bigboard is only available for F-7 and rawhide. > > Only rawhide as I understand it. > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- On Tap: HopZilla and a Belgian Tripel Fermentating: Imperial English Pale Ale Fermentating: Guinness Extra Extra Imperial Stout Fermentating: Belgian Tripel Dry Next: Brutal Blackend Bitter From j.w.r.degoede at hhs.nl Mon Jul 2 19:55:04 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jul 2007 21:55:04 +0200 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish Message-ID: <46895818.6040006@hhs.nl> Hi All, I've received a bug report requesting me to update ogre from 1.2.x to 1.4.x for F-7 and devel, see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241900 Ian Chapman has already updated cegui from 0.4.x to 0.5.x, which is necessary for the new ogre. The new cegui is available in updates-testing. ogre and chess (the only ogre dependend package in Fedora afaik) will get updated soon too. So if you plan on packaging any ogre using packages, please hold off until this is resolved. If you have any privately compiled ogre using packages, and you think this ABI change during a stable release is bad form, please yell loud now while this can still be reverted. Thanks! Regards, Hans From walters at redhat.com Mon Jul 2 19:47:54 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 02 Jul 2007 15:47:54 -0400 Subject: how to install online-desktop? In-Reply-To: <2a28d2ab0707021222t6d8442f0s232a0337ce84cce8@mail.gmail.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> <1183403917.16523.44.camel@weaponx.rchland.ibm.com> <2a28d2ab0707021222t6d8442f0s232a0337ce84cce8@mail.gmail.com> Message-ID: <1183405675.2705.22.camel@neutron.verbum.private> On Mon, 2007-07-02 at 14:22 -0500, Dr. Diesel wrote: > Hold off anyhow. Today it simply crashed The crash is probably the gnome-menus library which is fixed (but probably you don't have the update yet). > and deleted by top menu bar!!! You can switch back by running "god-mode 0" from a command prompt. Also, much newer versions of various packages are making their way to F7. From valent.turkovic at gmail.com Mon Jul 2 19:49:42 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 2 Jul 2007 21:49:42 +0200 Subject: how to install online-desktop? In-Reply-To: <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> Message-ID: <64b14b300707021249n36ad43f8wa8098daffd9e0724@mail.gmail.com> I have fedora 7. I found this resource: http://ftp.linux.ncsu.edu/pub/fedora/linux/updates/testing/7/i386/ and I installed rpm files manually. I don't have developement yum repository enabled in F7 - is that needed for yum to install it automatically? On 7/2/07, Jeffrey C. Ollie wrote: > On Mon, 2007-07-02 at 20:54 +0200, Valent Turkovic wrote: > > Nope, that package also doesn't exist. See for yourself: > > > > # yum install bigboard > > Loading "downloadonly" plugin > > Loading "presto" plugin > > Loading "installonlyn" plugin > > Setting up Install Process > > Parsing package install arguments > > Setting up Presto > > Reading Presto metadata in from local files > > Nothing to do > > I believe that bigboard is only available for F-7 and rawhide. > > Jeff > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From alcapcom at gmail.com Mon Jul 2 19:52:30 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Mon, 02 Jul 2007 21:52:30 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> Message-ID: <4689577E.7070602@gmail.com> Hikaru Amano a ?crit : > On 7/2/07, Alphonse Van Assche wrote: >> Peter Gordon a ?crit : >> > On Sun, 2007-07-01 at 13:56 +0200, Alphonse Van Assche wrote: >> >> To make this working compiz need to use texture copy instead of >> >> texture_from_pixmap method[1] (because of the fact the fglrx driver >> >> don't have support for texture_from_pixmap). That functionality can be >> >> ported from beryl. Maybe a little patch to compiz must applied too[2] >> > >> > Maybe; but adding hacks to workaround a known-broken piece of >> > proprietary software instead of getting the recent R300/Avivo drivers >> > working properly for AIGLX seems entirely like a step backwards to >> me... >> > >> Well, I have just saying this to let know that the fglrx driver *cannot* >> be used with AIGLX without the above hacks and at this time we don't >> have Xgl in Fedora so in my eyes a choice must be done. Using XGL as a >> temporary hack or making temporary hacks to let users use compiz with >> AIGLX. If we don't do one of them, then we forgot a big part of the >> Fedora users. > > does that mean its working? or is it not? or is it working after patching? Unfortunately no, that don't work out of the box and the copy method don't have many chance to be add to compiz, maybe like dragoran say that can be implement as a plugin? > >> >> Yes, ATI driver suck for many reasons proprietary/not intensive >> developed/etc... but many people have such cards and saying that we >> don't care about it is just saying we don't care about a big part of our >> users, I think that's not good for Fedora. > > In my place, ATi users are more than NVidia users, its a pain when > trying to promote Fedora to them .. and with fglrx is broken in F7 .. > I have no idea what to answer if they asked .. There is a workaround, take a look there [1]on the Fedora Forum and a temporary Xgl repo is available here[2]. [1] http://www.fedoraforum.org/forum/showthread.php?t=156961&page=1&pp=15&highlight=fglrx [2] http://fedoraxgl.tuxfamily.org/index.php?title=Installation_en_all. > back to topic , > > I just rewrote desktop-effects in .py to make use compizconfig-python .. > > attached them together with this email .. Nice!, I have just see a little error, the path of the mesa libGL provided by the fglrx package is /usr/lib/fglrx/libGL.so.1.2 instead of /usr/lib/fglrx/libGL.so.1.2.xlibmesa. Alphonse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From valent.turkovic at gmail.com Mon Jul 2 19:53:42 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 2 Jul 2007 21:53:42 +0200 Subject: how to install online-desktop? In-Reply-To: <1183405675.2705.22.camel@neutron.verbum.private> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> <1183403917.16523.44.camel@weaponx.rchland.ibm.com> <2a28d2ab0707021222t6d8442f0s232a0337ce84cce8@mail.gmail.com> <1183405675.2705.22.camel@neutron.verbum.private> Message-ID: <64b14b300707021253q43c1c512q8ce7d97bbb7f0d78@mail.gmail.com> uf, this just bailed me out... online-desktop seams really unstable. On 7/2/07, Colin Walters wrote: > On Mon, 2007-07-02 at 14:22 -0500, Dr. Diesel wrote: > > Hold off anyhow. Today it simply crashed > > The crash is probably the gnome-menus library which is fixed (but > probably you don't have the update yet). > > > and deleted by top menu bar!!! > > You can switch back by running "god-mode 0" from a command prompt. > > Also, much newer versions of various packages are making their way to > F7. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From Jochen at herr-schmitt.de Mon Jul 2 19:58:22 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 02 Jul 2007 21:58:22 +0200 Subject: Package requests: python-egenix-mxdatetime and python-urwid In-Reply-To: <468943E0.6040803@verizon.net> References: <468915D4.2080002@verizon.net> <670E8430-C906-4302-BBBA-DE55D91B845D@rubenkerkhof.com> <468943E0.6040803@verizon.net> Message-ID: <468958DE.2030406@herr-schmitt.de> Gerry Reno schrieb: > Could someone with edit privileges please add these packages to the > wiki wishlist. I don't have any way to edit the page or the time to > figure out how to get through the signup process right now. Done. Best Regards: Jochen Schmitt From greno at verizon.net Mon Jul 2 20:00:17 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 02 Jul 2007 16:00:17 -0400 Subject: Package requests: python-egenix-mxdatetime and python-urwid In-Reply-To: <468958DE.2030406@herr-schmitt.de> References: <468915D4.2080002@verizon.net> <670E8430-C906-4302-BBBA-DE55D91B845D@rubenkerkhof.com> <468943E0.6040803@verizon.net> <468958DE.2030406@herr-schmitt.de> Message-ID: <46895951.3090608@verizon.net> Jochen Schmitt wrote: > Gerry Reno schrieb: >> Could someone with edit privileges please add these packages to the >> wiki wishlist. I don't have any way to edit the page or the time to >> figure out how to get through the signup process right now. > Done. > > Best Regards: > > Jochen Schmitt > Thanks, Gerry From Jochen at herr-schmitt.de Mon Jul 2 20:02:51 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 02 Jul 2007 22:02:51 +0200 Subject: how to install online-desktop? In-Reply-To: <64b14b300707021253q43c1c512q8ce7d97bbb7f0d78@mail.gmail.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> <1183403917.16523.44.camel@weaponx.rchland.ibm.com> <2a28d2ab0707021222t6d8442f0s232a0337ce84cce8@mail.gmail.com> <1183405675.2705.22.camel@neutron.verbum.private> <64b14b300707021253q43c1c512q8ce7d97bbb7f0d78@mail.gmail.com> Message-ID: <468959EB.7060505@herr-schmitt.de> Valent Turkovic schrieb: >> Also, much newer versions of various packages are making their way to >> F7. >> I have saw a F-7 branch in the cvs, so you can hope, that we will get an update for this package in F-7. Best Regards: Jochen Schmitt From Jochen at herr-schmitt.de Mon Jul 2 20:08:15 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 02 Jul 2007 22:08:15 +0200 Subject: how to install online-desktop? In-Reply-To: <468959EB.7060505@herr-schmitt.de> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> <1183403917.16523.44.camel@weaponx.rchland.ibm.com> <2a28d2ab0707021222t6d8442f0s232a0337ce84cce8@mail.gmail.com> <1183405675.2705.22.camel@neutron.verbum.private> <64b14b300707021253q43c1c512q8ce7d97bbb7f0d78@mail.gmail.com> <468959EB.7060505@herr-schmitt.de> Message-ID: <46895B2F.5080409@herr-schmitt.de> Jochen Schmitt schrieb: > I have saw a F-7 branch in the cvs, so you can hope, that we will get > an update > for this package in F-7. > I have try to build it on my own machine. I think, it will take a while, until we will ge it in F-7 because there are some dependencies on F-7 which are not fulfill now. Best Regards: Jochen Schmitt From walters at redhat.com Mon Jul 2 20:10:30 2007 From: walters at redhat.com (Colin Walters) Date: Mon, 02 Jul 2007 16:10:30 -0400 Subject: how to install online-desktop? In-Reply-To: <64b14b300707021249n36ad43f8wa8098daffd9e0724@mail.gmail.com> References: <64b14b300707021145p1103d497ua4f014c182430959@mail.gmail.com> <200707021446.39036.jkeating@redhat.com> <64b14b300707021154s463f4075m4c7968654edd0f18@mail.gmail.com> <1183402941.10996.20.camel@lt21223.campus.dmacc.edu> <64b14b300707021249n36ad43f8wa8098daffd9e0724@mail.gmail.com> Message-ID: <1183407030.2705.25.camel@neutron.verbum.private> On Mon, 2007-07-02 at 21:49 +0200, Valent Turkovic wrote: > I have fedora 7. > > I found this resource: > http://ftp.linux.ncsu.edu/pub/fedora/linux/updates/testing/7/i386/ > > and I installed rpm files manually. > > I don't have developement yum repository enabled in F7 - is that > needed for yum to install it automatically? No; packages will move from the testing repository to the main one after a period of time. From mspevack at redhat.com Mon Jul 2 20:18:06 2007 From: mspevack at redhat.com (Max Spevack) Date: Mon, 2 Jul 2007 16:18:06 -0400 (EDT) Subject: Reminder -- Vote in the Fedora Board election Message-ID: I would like to remind everyone to vote in the Fedora Board elections, which are currently ongoing. If you are getting this message multiple times, I'm sorry. It's being sent to various lists. The Fedora Board's membership changes on a rotating basis. This election is for 3 of the 9 Fedora Board seats. The Fedora Board is the Fedora Project's "executive committee" and is ultimately accountable for everything that happens within Fedora, and delegates responsibillity to various sub-projects accordingly. Information about the candidates and voting is available here: http://fedoraproject.org/wiki/Board/Elections Voting will end at 11:59 PM UTC on Sunday July 8th. Anyone who has signed the Fedora CLA is eligible to vote. Thank you, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From drago01 at gmail.com Mon Jul 2 20:19:21 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 02 Jul 2007 22:19:21 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> Message-ID: <46895DC9.2040305@gmail.com> Hikaru Amano wrote: > On 7/2/07, Alphonse Van Assche wrote: >> Peter Gordon a ?crit : >> > On Sun, 2007-07-01 at 13:56 +0200, Alphonse Van Assche wrote: >> >> To make this working compiz need to use texture copy instead of >> >> texture_from_pixmap method[1] (because of the fact the fglrx driver >> >> don't have support for texture_from_pixmap). That functionality >> can be >> >> ported from beryl. Maybe a little patch to compiz must applied too[2] >> > >> > Maybe; but adding hacks to workaround a known-broken piece of >> > proprietary software instead of getting the recent R300/Avivo drivers >> > working properly for AIGLX seems entirely like a step backwards to >> me... >> > >> Well, I have just saying this to let know that the fglrx driver *cannot* >> be used with AIGLX without the above hacks and at this time we don't >> have Xgl in Fedora so in my eyes a choice must be done. Using XGL as a >> temporary hack or making temporary hacks to let users use compiz with >> AIGLX. If we don't do one of them, then we forgot a big part of the >> Fedora users. > > does that mean its working? or is it not? or is it working after > patching? > >> >> Yes, ATI driver suck for many reasons proprietary/not intensive >> developed/etc... but many people have such cards and saying that we >> don't care about it is just saying we don't care about a big part of our >> users, I think that's not good for Fedora. > > In my place, ATi users are more than NVidia users, its a pain when > trying to promote Fedora to them .. and with fglrx is broken in F7 .. > I have no idea what to answer if they asked .. > >> I'm personally sure that many >> people have switch to GNU/Linux these last year just to have a wobbly >> desktop with all these eye candy stuffs. I like eye candy as a awesome >> propaganda piece for the GNU/Linux desktops too. > > +1. the Wow factor... > >> >> Just my 2 cent of the day. >> Alphonse >> > > back to topic , > > I just rewrote desktop-effects in .py to make use compizconfig-python .. > > attached them together with this email .. > > great ;) some comments: def env_nvidia(): if not getoutput('xdpyinfo 2>/dev/null|grep NV-GLX') == '': print '* nvidia found, exporting: __GL_YIELD=nothing ' return '__GL_YIELD=nothing ' else: return '' this is no longer needed when the cfs scheduler is used which is in the rawhide kernels right now and should go upstream in kernel 2.6.23. don't just print errors like "can't start compiz" uses gtk.MessageDialog with gtk.MESSAGE_ERROR. From drago01 at gmail.com Mon Jul 2 20:20:54 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 02 Jul 2007 22:20:54 +0200 Subject: Compiz Fusion? In-Reply-To: <46895DC9.2040305@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> <46895DC9.2040305@gmail.com> Message-ID: <46895E26.8000602@gmail.com> dragoran wrote: > [...] > don't just print errors like "can't start compiz" uses > gtk.MessageDialog with gtk.MESSAGE_ERROR. sorry missed the comments on the top...(you already have planed this) ;) > > From packages at amiga-hardware.com Mon Jul 2 20:24:06 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 02 Jul 2007 21:24:06 +0100 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish In-Reply-To: <46895818.6040006@hhs.nl> References: <46895818.6040006@hhs.nl> Message-ID: <46895EE6.8000503@amiga-hardware.com> Hans de Goede wrote: > Ian Chapman has already updated cegui from 0.4.x to 0.5.x, which is > necessary for the new ogre. The new cegui is available in > updates-testing. ogre and chess (the only ogre dependend package in > Fedora afaik) will get updated soon too. I will also push the new cegui for FC6 once the new ogre has been released Hans. I believe the dependancies on it are the same, chess and ogre. -- Ian Chapman. From drago01 at gmail.com Mon Jul 2 20:34:50 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 02 Jul 2007 22:34:50 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> Message-ID: <4689616A.2020908@gmail.com> Hikaru Amano wrote: > back to topic , > > I just rewrote desktop-effects in .py to make use compizconfig-python .. > > attached them together with this email .. > attached a version with the error dialog (left the nvidia stuff for now). whats still mising is support for gettext (translations) -------------- next part -------------- A non-text attachment was scrubbed... Name: desktop-effects.py Type: text/x-python Size: 6076 bytes Desc: not available URL: From drago01 at gmail.com Mon Jul 2 20:35:28 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 02 Jul 2007 22:35:28 +0200 Subject: Compiz Fusion? In-Reply-To: <4689616A.2020908@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46850CF6.4080206@redhat.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> <4689616A.2020908@gmail.com> Message-ID: <46896190.4060308@gmail.com> dragoran wrote: > Hikaru Amano wrote: >> back to topic , >> >> I just rewrote desktop-effects in .py to make use compizconfig-python .. >> >> attached them together with this email .. >> > attached a version with the error dialog (left the nvidia stuff for now). > whats still mising is support for gettext (translations) > resend with typo fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: desktop-effects.py Type: text/x-python Size: 6077 bytes Desc: not available URL: From rvinyard at cs.nmsu.edu Mon Jul 2 20:30:54 2007 From: rvinyard at cs.nmsu.edu (Rick L Vinyard Jr) Date: Mon, 02 Jul 2007 14:30:54 -0600 Subject: VTP (Virtual Terrain Project) on Fedora In-Reply-To: <46868D58.1090105@tvtransilvania.ro> References: <4686695A.2020509@cs.nmsu.edu> <46868D58.1090105@tvtransilvania.ro> Message-ID: <4689607E.2010308@cs.nmsu.edu> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246524 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246525 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246526 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246527 Alexandru Ciobanu wrote: > KH KH wrote: >>> If anyone is interested in testing let me know and I'll post the srpms >>> for Mini, quikgrid and minizip along with the current VTP patch that >>> I'm >>> working on. >> >> I'm interested in it! > > +1 > From j.w.r.degoede at hhs.nl Mon Jul 2 21:04:46 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jul 2007 23:04:46 +0200 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish In-Reply-To: <46895EE6.8000503@amiga-hardware.com> References: <46895818.6040006@hhs.nl> <46895EE6.8000503@amiga-hardware.com> Message-ID: <4689686E.5010106@hhs.nl> Ian Chapman wrote: > Hans de Goede wrote: > >> Ian Chapman has already updated cegui from 0.4.x to 0.5.x, which is >> necessary for the new ogre. The new cegui is available in >> updates-testing. ogre and chess (the only ogre dependend package in >> Fedora afaik) will get updated soon too. > > I will also push the new cegui for FC6 once the new ogre has been > released Hans. I believe the dependancies on it are the same, chess and > ogre. > Hmm, I'm not so sure if thats a good plan. I don't like breaking soname's, no F-7 is still somewhat new. But FC-6 is by Fedora standards now proven and trusted, should we go breaking soname's there? Regards, Hans From valent.turkovic at gmail.com Mon Jul 2 21:23:11 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 2 Jul 2007 23:23:11 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 Message-ID: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> Hi, here are some of my ideas in which I see that Fedora can improve general user and desktop experience and usability. I would like you to see my comment and suggestion in the manner I made them - I don't mean to be a critic but only an objective observer that loves usind Fedora at home and also at work and would like to see more people do so - and I belive that with some of ideas I have here more people would use Fedora and be more productive. * NTFS support during installation there should be NTFS support built in to anaconda so that ntfs partitions are automatically recognized and added to /etc/fstab - and that users are given an option to make them read-only or to be mounted in read-write mode. * Beagle and Deskbar installed by default these applications make all the difference for an desktop user between an "OK" user experience and "wonderful" user experience. Work flow using these two applications is radically improved and this is what should be showcased as a "Modern linux desktop". - also I would add a beagle firefox plugin which also makes all the difference when you need some resource you saw online but didn't bookmark it or put it on del.ico.us - these apps don't waste resources, and the memory footprint is really not that much, especially if put in context that you really have to look hard these days for a system that has less or equal to 256MB of memory. I tested beagle on 3 laptop systems with fedora 6 / 7 and one desktop with also fedora 6 / 7 and I didn't have a single issue. So for me not to have in installed in Fedora 7 was a big disappointment. * Tomboy installed by default - I have all the same arguments here as I do for Beagle and Deskbar * Firefox to have it's original icon in gnome panel the icon fedora uses makes me search for firefox icon all the time. I guess that I'm not the only one. Firefox has one of the most recognisable icons I have ever seen and simply don't see why fedora uses non-firefox icon. It just confuses users. * Desktop shortcut for joining Fedora IRC (aka "Get Live Help") Fedora is about freedom+communication, right? Why not make this statement more that just a nice slogan. If you installed saabyon linux you could experienced for yourself what this really means. I as a new user to gentoo (sabayon is based on gentoo) was really blown away with this feature. It is really, really simple to implement and gives a real meaning to a communication friendly linux distro. In sabayon link to their IRC chat has a simple name "Get Live Help" and it work fabulous! I didn't have any Portage experience so I poped in IRC chat room and was on my way after I got quick help. Whis kind of help was precious to me and would love to see it in fedora as one of it's main features and not just as a slogan. screenshot: http://www.flickr.com/photo_zoom.gne?id=382063978&size=l * Desktop folder with examples of what "this linux thing" can do :) This is especially important for a live cd versions. Ubuntu has this "feature" on each of their live cd's as a folder on desktop. In these folder you can see and test for yourself some filetypes and apps that work woth them. So for example you open examples folder and see how some spreadsheets work in "this linux thing" by simply clicking on the spreadsheat that they placed in there and also for some text documents, images and the most important thing - there is an video clip. And it is a really nice video about the meaning of Ubuntu project. I saw some great videos on redhat magazine page and it is a shame that these aren't part of Fedora 7 live cd's. I hope you see the great value in video presentation and include some great videos on Fedora 8 live CD. ubuntu examples: http://johnny.chadda.se/wp-content/uploads/2006/06/Ubuntu_Examples.png and another: http://knowledge76.com/images/thumb/800px-Dapper_examples.png * a working Burning app for Fedora Gnome desktop Put any new user in front of fresh Fedora 7 desktop and ask them to burn some files to CD or DVD - any watch them as they wiggle unpleasantly as they can't find any burning app under gnome desktop. Puting a link for nautils burner under "Places / CD - DVD Recoder" doesn't help. If you choose atleast not to include Brassero as the default burning app under gnome then at least thre should be a link for "CD Recoder" placed somewhere under "Applications" menu and not "Places" menu. I have some other ideas, suggestions and improvements I would love to see but these are the main ones. I hope you see all of my suggestions to Fedora desktop in the manner they were written - as my intention was to be as objective as possible and not to be a critic. I love Fedora and it is definitely by my opinion the best distro for Desktop users (yes, even better than Ubuntu). Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From packages at amiga-hardware.com Mon Jul 2 21:29:48 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 02 Jul 2007 22:29:48 +0100 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish In-Reply-To: <4689686E.5010106@hhs.nl> References: <46895818.6040006@hhs.nl> <46895EE6.8000503@amiga-hardware.com> <4689686E.5010106@hhs.nl> Message-ID: <46896E4C.4060608@amiga-hardware.com> Hans de Goede wrote: > Hmm, I'm not so sure if thats a good plan. I don't like breaking > soname's, no F-7 is still somewhat new. But FC-6 is by Fedora standards > now proven and trusted, should we go breaking soname's there? If there was a stack of items in the Fedora repo that depended on 0.4.x I'd be a lot less inclined, but with so few packages depending on it, I think the impact would be negligable but if you'd rather leave ogre and chess as is, I won't push for FC6. -- Ian Chapman. From j.w.r.degoede at hhs.nl Mon Jul 2 21:49:30 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Jul 2007 23:49:30 +0200 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish In-Reply-To: <46896E4C.4060608@amiga-hardware.com> References: <46895818.6040006@hhs.nl> <46895EE6.8000503@amiga-hardware.com> <4689686E.5010106@hhs.nl> <46896E4C.4060608@amiga-hardware.com> Message-ID: <468972EA.3030401@hhs.nl> Ian Chapman wrote: > Hans de Goede wrote: > >> Hmm, I'm not so sure if thats a good plan. I don't like breaking >> soname's, no F-7 is still somewhat new. But FC-6 is by Fedora >> standards now proven and trusted, should we go breaking soname's there? > > If there was a stack of items in the Fedora repo that depended on 0.4.x > I'd be a lot less inclined, but with so few packages depending on it, I > think the impact would be negligable but if you'd rather leave ogre and > chess as is, I won't push for FC6. > I agree the stack within Fedora is small, I'm afraid however that people might have manually installed packages depending on this, and I don't want to cause breakage to those. I must admit chances of this happening are small though. So if there is a strong desire to upgrade for FC-6 too, then I can live with that. Regards, Hans From packages at amiga-hardware.com Mon Jul 2 21:38:38 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 02 Jul 2007 22:38:38 +0100 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> Message-ID: <4689705E.2070702@amiga-hardware.com> Valent Turkovic wrote: > > * NTFS support during installation > there should be NTFS support built in to anaconda so that ntfs > partitions are automatically recognized and added to /etc/fstab Providing that was optional, ie they should only go into the fstab if the user wants them there. > * Firefox to have it's original icon in gnome panel > the icon fedora uses makes me search for firefox icon all the time. I > guess that I'm not the only one. Firefox has one of the most > recognisable icons I have ever seen and simply don't see why fedora > uses non-firefox icon. It just confuses users. That has something to do with the default icon not direcly using Firefox, it uses the user's preferred browser which by default is Firefox but if it's changed could launch something else. I forget the exact mechanics of it. -- Ian Chapman. From naheemzaffar at gmail.com Mon Jul 2 21:43:10 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 2 Jul 2007 22:43:10 +0100 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <4689705E.2070702@amiga-hardware.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <4689705E.2070702@amiga-hardware.com> Message-ID: <3adc77210707021443v7b32531do6ab40f574a9cc8e6@mail.gmail.com> On 02/07/07, Ian Chapman wrote: > Valent Turkovic wrote: > > > > * NTFS support during installation > > there should be NTFS support built in to anaconda so that ntfs > > partitions are automatically recognized and added to /etc/fstab > > Providing that was optional, ie they should only go into the fstab if > the user wants them there. > In other words, just include ntfs-config in the dafault install? From packages at amiga-hardware.com Mon Jul 2 21:54:38 2007 From: packages at amiga-hardware.com (Ian Chapman) Date: Mon, 02 Jul 2007 22:54:38 +0100 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish In-Reply-To: <468972EA.3030401@hhs.nl> References: <46895818.6040006@hhs.nl> <46895EE6.8000503@amiga-hardware.com> <4689686E.5010106@hhs.nl> <46896E4C.4060608@amiga-hardware.com> <468972EA.3030401@hhs.nl> Message-ID: <4689741E.8020003@amiga-hardware.com> Hans de Goede wrote: > I agree the stack within Fedora is small, I'm afraid however that people > might have manually installed packages depending on this, and I don't > want to cause breakage to those. > I must admit chances of this happening > are small though. Yes I agree that is a concern but I also feel in the few scenarios where this is the case, the same user would be capable of manually installing an updated version. > So if there is a strong desire to upgrade for FC-6 > too, then I can live with that. Well it's partly for selfish reasons because I'd find it convenient :-) But also I had a BZ request for the new version because the one that was shipping was too old. So if you can live with it, I'll go ahead. -- Ian Chapman. From greno at verizon.net Mon Jul 2 22:09:05 2007 From: greno at verizon.net (Gerry Reno) Date: Mon, 02 Jul 2007 18:09:05 -0400 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> Message-ID: <46897781.1040505@verizon.net> Valent Turkovic wrote: > Hi, > > here are some of my ideas in which I see that Fedora can improve > general user and desktop experience and usability. I would like you to > see my comment and suggestion in the manner I made them - I don't mean > to be a critic but only an objective observer that loves usind Fedora > at home and also at work and would like to see more people do so - and > I belive that with some of ideas I have here more people would use > Fedora and be more productive. > > * NTFS support during installation > there should be NTFS support built in to anaconda so that ntfs > partitions are automatically recognized and added to /etc/fstab - and > that users are given an option to make them read-only or to be mounted > in read-write mode. > > * Beagle and Deskbar installed by default > these applications make all the difference for an desktop user between > an "OK" user experience and "wonderful" user experience. Work flow > using these two applications is radically improved and this is what > should be showcased as a "Modern linux desktop". > - also I would add a beagle firefox plugin which also makes all the > difference when you need some resource you saw online but didn't > bookmark it or put it on del.ico.us > - these apps don't waste resources, and the memory footprint is really > not that much, especially if put in context that you really have to > look hard these days for a system that has less or equal to 256MB of > memory. I tested beagle on 3 laptop systems with fedora 6 / 7 and one > desktop with also fedora 6 / 7 and I didn't have a single issue. So > for me not to have in installed in Fedora 7 was a big disappointment. > > * Tomboy installed by default > - I have all the same arguments here as I do for Beagle and Deskbar > > * Firefox to have it's original icon in gnome panel > the icon fedora uses makes me search for firefox icon all the time. I > guess that I'm not the only one. Firefox has one of the most > recognisable icons I have ever seen and simply don't see why fedora > uses non-firefox icon. It just confuses users. > > * Desktop shortcut for joining Fedora IRC (aka "Get Live Help") > Fedora is about freedom+communication, right? Why not make this > statement more that just a nice slogan. If you installed saabyon linux > you could experienced for yourself what this really means. I as a new > user to gentoo (sabayon is based on gentoo) was really blown away with > this feature. It is really, really simple to implement and gives a > real meaning to a communication friendly linux distro. > In sabayon link to their IRC chat has a simple name "Get Live Help" > and it work fabulous! I didn't have any Portage experience so I poped > in IRC chat room and was on my way after I got quick help. Whis kind > of help was precious to me and would love to see it in fedora as one > of it's main features and not just as a slogan. > screenshot: http://www.flickr.com/photo_zoom.gne?id=382063978&size=l > > * Desktop folder with examples of what "this linux thing" can do :) > This is especially important for a live cd versions. Ubuntu has this > "feature" on each of their live cd's as a folder on desktop. In these > folder you can see and test for yourself some filetypes and apps that > work woth them. So for example you open examples folder and see how > some spreadsheets work in "this linux thing" by simply clicking on the > spreadsheat that they placed in there and also for some text > documents, images and the most important thing - there is an video > clip. And it is a really nice video about the meaning of Ubuntu > project. I saw some great videos on redhat magazine page and it is a > shame that these aren't part of Fedora 7 live cd's. I hope you see the > great value in video presentation and include some great videos on > Fedora 8 live CD. > ubuntu examples: > http://johnny.chadda.se/wp-content/uploads/2006/06/Ubuntu_Examples.png > and another: > http://knowledge76.com/images/thumb/800px-Dapper_examples.png > > * a working Burning app for Fedora Gnome desktop > Put any new user in front of fresh Fedora 7 desktop and ask them to > burn some files to CD or DVD - any watch them as they wiggle > unpleasantly as they can't find any burning app under gnome desktop. > Puting a link for nautils burner under "Places / CD - DVD Recoder" > doesn't help. If you choose atleast not to include Brassero as the > default burning app under gnome then at least thre should be a link > for "CD Recoder" placed somewhere under "Applications" menu and not > "Places" menu. > > > I have some other ideas, suggestions and improvements I would love to > see but these are the main ones. I hope you see all of my suggestions > to Fedora desktop in the manner they were written - as my intention > was to be as objective as possible and not to be a critic. I love > Fedora and it is definitely by my opinion the best distro for Desktop > users (yes, even better than Ubuntu). > > Valent. Valent, I agree with you. As far as desktop users, the out-of-the-box Linux experience has to be Wow! with little demos of Wow! The installer Anaconda has to be flawless. It still had some hiccups in F7 which I think was related to libata. Another thing in Disk Druid that I would like to see is the ability to install on a degraded RAID-1 array where I declare RAID-1 but then the second mirror is missing. I install this way all the time on systems and then when I add the second hard drive later and place it into the array, it just syncs. Want to go back to just a single drive - no problem. Just fault the device and remove it. No complicated remounting filesystems or anything - very smooth. This way you're always on an md device. I would like to see this actually become the default. From my perspective dealing mostly with servers, I would like to see libata get back support for all the previous controllers that were lost. Like HighPoint. We got killed with F7 when we put in on a few boxes with HighPoint controllers and the kernel would not even boot. Much scrambling then ensued. All-in-all just make everything that's in F7 work well so that the initial experience for new-to-Fedora folks is really great. my 2c, Gerry From rc040203 at freenet.de Mon Jul 2 23:21:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Jul 2007 01:21:59 +0200 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: <200707021249.32821.jkeating@redhat.com> References: <7dd7ab490707020839m6dd76747o32cf1e4b5e07d011@mail.gmail.com> <1183393654.4103.12.camel@localhost.localdomain> <200707021249.32821.jkeating@redhat.com> Message-ID: <1183418520.23976.316.camel@mccallum.corsepiu.local> On Mon, 2007-07-02 at 12:49 -0400, Jesse Keating wrote: > On Monday 02 July 2007 12:27:33 Tom "spot" Callaway wrote: > > I don't see anything wrong with a perl metapackage, perl-core. > > > > Would that be preferred to a yum group? > > I have a bit of a surface loathing of metapackages. > > Why is it that perl packages can't BuildRequire what they need? Technically nothing. Practically, "customary habits". The situation perl currently is in is comparable to X11 before its split. People are used to certain habits and don't want to let loose. > Is there real > good reason why a seemingly arbitrary rule like "don't BR 'core' perl > packages" should continue to exist, especially now that there is no clear > distinction of what is 'core' and what isn't? No, there isn't. I consider this perl-core package a very questionable move - More bluntly: I hereby ask Tom to revert it. Ralf From jeff at ocjtech.us Tue Jul 3 01:10:31 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 02 Jul 2007 20:10:31 -0500 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> Message-ID: <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> On Mon, 2007-07-02 at 23:23 +0200, Valent Turkovic wrote: > > * Beagle and Deskbar installed by default > these applications make all the difference for an desktop user between > an "OK" user experience and "wonderful" user experience. Work flow > using these two applications is radically improved and this is what > should be showcased as a "Modern linux desktop". > - also I would add a beagle firefox plugin which also makes all the > difference when you need some resource you saw online but didn't > bookmark it or put it on del.ico.us > - these apps don't waste resources, and the memory footprint is really > not that much, especially if put in context that you really have to > look hard these days for a system that has less or equal to 256MB of > memory. I tested beagle on 3 laptop systems with fedora 6 / 7 and one > desktop with also fedora 6 / 7 and I didn't have a single issue. So > for me not to have in installed in Fedora 7 was a big disappointment. There was a recent discussion on this topic and the decision was to remove Beagle from the default install because for too many users Beagle would suck up 100% CPU and leave the machine virtually unusable. See the archives for details. Once Beagle matures some more and causes fewer problems like this having Beagle in the default install can be reconsidered. 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 davej at redhat.com Tue Jul 3 04:37:28 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 00:37:28 -0400 Subject: Inaccuracy of smolt i586 count - was 586 kernels. In-Reply-To: <20070630230551.GA15010@devserv.devel.redhat.com> References: <1182365330.4102.19.camel@hodge> <20070620191035.GJ23569@redhat.com> <20070620174224.65b9c8f6.zaitcev@redhat.com> <20070621114255.GD15961@devserv.devel.redhat.com> <2a28d2ab0706210450g62f423dfj6fbe7ac46a1a9834@mail.gmail.com> <2213AB64-DEA8-4C2C-B911-7C696A6F0B2A@dev.intechnology.co.uk> <46868B83.5030006@redhat.com> <20070630174007.GA3405@devserv.devel.redhat.com> <4686A644.2040700@redhat.com> <20070630230551.GA15010@devserv.devel.redhat.com> Message-ID: <20070703043728.GA15789@redhat.com> On Sat, Jun 30, 2007 at 07:05:51PM -0400, Alan Cox wrote: > On Sat, Jun 30, 2007 at 01:51:48PM -0500, Mike McGrath wrote: > > I guess I could look at it another way, what info can I grab so its > > useful to the developers to make decisions about this stuff :) > > Depends what DaveJ plans for FC8 > > For current rpm you want to check that > > 1. All CPUs report family 6 or higher > 2. All CPUs have the cmov flag in their cpuid capability bits Right now, my plan for F8 is to probably revert the changes I made so far, and reintroduce a 586 build. Unless someone steps up to do whatever needs to change in rpm/gcc. (The latter, I doubt is really changable without buy-in from the gcc community, which I expect will be opposed to changing defacto behaviour). Dave -- http://www.codemonkey.org.uk From davej at redhat.com Tue Jul 3 04:40:40 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 00:40:40 -0400 Subject: rawhide report: 20070625 changes In-Reply-To: <1182765242.2519.2.camel@work> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> <1182765242.2519.2.camel@work> Message-ID: <20070703044040.GB15789@redhat.com> On Mon, Jun 25, 2007 at 10:54:02AM +0100, Richard Hughes wrote: > On Mon, 2007-06-25 at 05:43 -0400, Build System wrote: > > kernel-2.6.21-1.3235.fc8 > > ------------------------ > > * Sat Jun 23 2007 Dave Jones > > - DMI based module autoloading. > > Cool. Does that mean we can get rid of the userspace dmi/modprobe hacks? That's the plan. So far only msi-laptop has been converted, so asus-acpi, thinkpad-acpi etc still need the ugly rc.sysinit hack. Dave -- http://www.codemonkey.org.uk From j.w.r.degoede at hhs.nl Tue Jul 3 07:33:54 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 03 Jul 2007 09:33:54 +0200 Subject: Headsup: cegui and ogre soname changing update to hit F7-updates soonish In-Reply-To: <4689741E.8020003@amiga-hardware.com> References: <46895818.6040006@hhs.nl> <46895EE6.8000503@amiga-hardware.com> <4689686E.5010106@hhs.nl> <46896E4C.4060608@amiga-hardware.com> <468972EA.3030401@hhs.nl> <4689741E.8020003@amiga-hardware.com> Message-ID: <4689FBE2.5090606@hhs.nl> Ian Chapman wrote: > Hans de Goede wrote: > >> I agree the stack within Fedora is small, I'm afraid however that >> people might have manually installed packages depending on this, and I >> don't want to cause breakage to those. >> I must admit chances of this happening are small though. > > Yes I agree that is a concern but I also feel in the few scenarios where > this is the case, the same user would be capable of manually installing > an updated version. > >> So if there is a strong desire to upgrade for FC-6 too, then I can >> live with that. > > Well it's partly for selfish reasons because I'd find it convenient :-) > But also I had a BZ request for the new version because the one that was > shipping was too old. So if you can live with it, I'll go ahead. > Ok, Go ahaead, please let me know asap when cegui is build, then I'll do ogre and chess immediately after that. Regards, Hans From valent.turkovic at gmail.com Tue Jul 3 07:56:49 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 09:56:49 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <3adc77210707021443v7b32531do6ab40f574a9cc8e6@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <4689705E.2070702@amiga-hardware.com> <3adc77210707021443v7b32531do6ab40f574a9cc8e6@mail.gmail.com> Message-ID: <64b14b300707030056t41d61707m338642acac1c8578@mail.gmail.com> On 7/2/07, Naheem Zaffar wrote: > On 02/07/07, Ian Chapman wrote: > > Valent Turkovic wrote: > > > > > > * NTFS support during installation > > > there should be NTFS support built in to anaconda so that ntfs > > > partitions are automatically recognized and added to /etc/fstab > > > > Providing that was optional, ie they should only go into the fstab if > > the user wants them there. > > > In other words, just include ntfs-config in the dafault install? It needs to be in anaconda. If anaconda runs ntfs-config or does it it's own way I as a user don't care. To be clear I don't have any NTFS partitions on my system but I saw this as a mayor showstopper for users with windows partition trying this great new thing called fedora linux. Users new to linux and fedora install it and can't access their data (on NTFS partitions). They don't know why it doesn't work and why is their partition grayed out during the install. This should JustWork out of the box. They don't know about ntfs-3g and ntfs-config and if you tell them to open a "dos window" and type some commands to it they will probably run away from fedora desktop screaming :) -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jul 3 08:04:03 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 10:04:03 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <46897781.1040505@verizon.net> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <46897781.1040505@verizon.net> Message-ID: <64b14b300707030104v729ec279yd85441d27d9fd3ab@mail.gmail.com> > Valent, > I agree with you. As far as desktop users, the out-of-the-box Linux > experience has to be Wow! with little demos of Wow! The installer > Anaconda has to be flawless. It still had some hiccups in F7 which I > think was related to libata. Another thing in Disk Druid that I would > like to see is the ability to install on a degraded RAID-1 array where I > declare RAID-1 but then the second mirror is missing. I install this > way all the time on systems and then when I add the second hard drive > later and place it into the array, it just syncs. Want to go back to > just a single drive - no problem. Just fault the device and remove it. > No complicated remounting filesystems or anything - very smooth. This > way you're always on an md device. I would like to see this actually > become the default. I don't use raid setups but I plan to do some time soon and I completely agree with you - your suggestions would be great. Maybe this is worth staring a separate thread and lobing for it? ;) >All-in-all just make everything that's in > F7 work well so that the initial experience for new-to-Fedora folks is > really great. I would like also to see this; especially user switcher which caused me a lot of data and time loss! Really great idea but buggy as hell! And then when I see they removed beagle because it was "buggy" but work for me on lots of systems (7 desktops) I tried flawlessly - and then fedora includes this totally new and buggy feature :( > my 2c, > Gerry add another 2c :) Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From hughsient at gmail.com Tue Jul 3 08:48:25 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 03 Jul 2007 09:48:25 +0100 Subject: rawhide report: 20070625 changes In-Reply-To: <20070703044040.GB15789@redhat.com> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> <1182765242.2519.2.camel@work> <20070703044040.GB15789@redhat.com> Message-ID: <1183452505.2312.5.camel@work> On Tue, 2007-07-03 at 00:40 -0400, Dave Jones wrote: > That's the plan. > So far only msi-laptop has been converted, so asus-acpi, thinkpad-acpi > etc still need the ugly rc.sysinit hack. There's a version of thinkpad_acpi that has this[1], which is destined to go upstream in .23. Would you like me to split out the autoloading part and file a bugzilla, or could we just use the new code? Thanks, Richard. [1] http://article.gmane.org/gmane.linux.acpi.ibm-acpi.devel/542 From debarshi.ray at gmail.com Tue Jul 3 09:33:20 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 3 Jul 2007 15:03:20 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <1183388407.26110.3.camel@cutter> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <1183388407.26110.3.camel@cutter> Message-ID: <3170f42f0707030233k7f8ee259q6ea7d0d4ab817c84@mail.gmail.com> >> Then the tricky part is likely to be doing the config reading/writing in >> a way that's not lossy. repoman actually has a good start on some of >> this, but it'd be nice to actually work towards getting that code into >> yum itself so that every tool doesn't have to re-invent those bits. > that's fine - provided we aren't pulling in the gui portion of repoman. > I have no interest in dragging along gtk bits in/around yum. I think Jeremy was taking about an interface, similar to Repository.enable/disable and RepoStorage.enableRepo/disableRepo, which will do the file handling. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Tue Jul 3 09:37:27 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 3 Jul 2007 15:07:27 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <1183387321.10801.17.camel@aglarond.local> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> Message-ID: <3170f42f0707030237q640ab3a3m8c06393fe4c1842a@mail.gmail.com> > I think the place to start is with writing up some use cases and then > trying to do some mockups from there before ever writing any code. I have a preliminary design. When it is ready I shall put it up and let you know. Would love to have your comments then. :-) > Then the tricky part is likely to be doing the config reading/writing in > a way that's not lossy. repoman actually has a good start on some of > this, but it'd be nice to actually work towards getting that code into > yum itself so that every tool doesn't have to re-invent those bits. For the time being we can atleast have a GUI interface that does what 'yum --enablerepo' and 'yum --disablerepo' does, and then incorporate the .repo file handling part gradually. What do you think? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From nlv19665 at natlab.research.philips.com Tue Jul 3 09:44:05 2007 From: nlv19665 at natlab.research.philips.com (LIN QIU) Date: Tue, 03 Jul 2007 11:44:05 +0200 Subject: newbie: what's the most convenient and safest way to update from FC3 to FC6 or further? In-Reply-To: <20070703093732.F23E073140@hormel.redhat.com> References: <20070703093732.F23E073140@hormel.redhat.com> Message-ID: <1183455845.31727.23.camel@pc67244168.ddns.htc.nl.philips.com> hi, I am a newbie to linux, had used Fedore3 for one month, since it is not supported now and many softwares I am trying to download are for higher Fedore version. Is there some convenient and safe way to update to FC6 or FC7 without compromising my current working environment much? (I mean like just update the kernel) LIN From sundaram at fedoraproject.org Tue Jul 3 09:53:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 15:23:55 +0530 Subject: newbie: what's the most convenient and safest way to update from FC3 to FC6 or further? In-Reply-To: <1183455845.31727.23.camel@pc67244168.ddns.htc.nl.philips.com> References: <20070703093732.F23E073140@hormel.redhat.com> <1183455845.31727.23.camel@pc67244168.ddns.htc.nl.philips.com> Message-ID: <468A1CB3.4050002@fedoraproject.org> LIN QIU wrote: > hi, > > I am a newbie to linux, had used Fedore3 for one month, > since it is not supported now and many softwares I am trying to download > are for higher Fedore version. > > Is there some convenient and safe way to update to FC6 or FC7 without > compromising my current working environment much? (I mean like just > update the kernel) You can either upgrade using the installer or do a backup of your data and do a fresh installation. Yum upgrades are possible not recommended. Rahul From buildsys at fedoraproject.org Tue Jul 3 10:41:14 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 3 Jul 2007 06:41:14 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-03 Message-ID: <20070703104114.4D9E1152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 30 asymptote-1.32-1.fc6 babel-0.8.1-1.fc6 darcs-1.0.9-3.fc6 ebtables-2.0.8-1.fc6 ekg-1.7-1.fc6 emacs-common-muse-3.03-2.fc6 git-1.5.2.2-1.fc6 gutenprint-5.0.1-2.fc6 katapult-0.3.2.1-1.fc6 koffice-1.6.3-1.fc6 koffice-langpack-1.6.3-1.fc6 libqalculate-0.9.6-1.fc6 perl-DBIx-DBSchema-0.33-1.fc6 perl-File-Remove-0.36-2.fc6 php-pear-Benchmark-1.2.7-1.fc6 php-pear-Date-Holidays-0.17.1-2.fc6 php-pear-HTML-Common-1.2.4-1.fc6 php-pear-HTML-QuickForm-3.2.9-1.fc6 php-pear-HTML-Table-1.8.1-1.fc6 php-pear-Image-Canvas-0.3.1-1.fc6 php-pear-Net-URL-1.0.15-1.fc6 NEW php-pear-Phlickr-0.2.7-2.fc6 : Phlickr is a PHP5 based api kit used with the Flickr API php-pear-Structures-DataGrid-DataSource-MDB2-0.1.10-1.fc6 pidgin-libnotify-0.13-1.fc6 python-genshi-0.4.2-1.fc6 NEW python-isprelink-0.1.2-2.fc6 : Python module to determine if a file has been prelinked qalculate-gtk-0.9.6-1.fc6 qalculate-kde-0.9.6-1.fc6 testdisk-6.7-1.fc6 zabbix-1.4.1-1.fc6 Changes in Fedora Extras 6: asymptote-1.32-1.fc6 -------------------- * Sat Jun 30 2007 Jose Pedro Oliveira - 1.32-1 - Update to 1.32. - vim-common triggers: correction and improvements (#246131). babel-0.8.1-1.fc6 ----------------- * Mon Jul 02 2007 Jeffrey C. Ollie - 0.8.1-1 - Update to 0.8.1 - Remove upstreamed patch. darcs-1.0.9-3.fc6 ----------------- * Wed Jun 27 2007 Jeremy Hinegardner - 1.0.9-3 - clean rpmlint warnings/errors - move PreReq to Requires(post) - move make check to 'check' section - mark config files as such * Wed Jun 27 2007 Jeremy Hinegardner - 1.0.9-2 - added ExcludeArch: ppc64 * Wed Jun 27 2007 Jeremy Hinegardner - 1.0.9-1 - update to 1.0.9 * Mon Feb 19 2007 Jens Petersen - 1.0.9-0.1.rc2 - update to 1.0.9rc2 which builds with ghc66 * Fri Feb 02 2007 Jens Petersen - 1.0.8-5 - rebuild for ncurses replacing termcap (#226754) * Wed Nov 01 2006 Jens Petersen - 1.0.8-4 - rebuild for new libcurl ebtables-2.0.8-1.fc6 -------------------- * Mon Jul 02 2007 Tom "spot" Callaway 2.0.8-1 - final 2.0.8 release ekg-1.7-1.fc6 ------------- * Fri Jun 29 2007 Dominik Mierzejewski 1.7-1 - 1.7 final - enable voip support (gsm is in Fedora now) - remove redundant BR: autoconf - support giflib - fixes CVE-2007-166{3,4,5} (bug #246034) emacs-common-muse-3.03-2.fc6 ---------------------------- * Mon Jul 02 2007 Jonathan G. Underwood - 3.03-2 - Add BuildRequires for tetex-latex so pdf files get built * Mon Jul 02 2007 Jonathan G. Underwood - 3.03-1 - Update to version 3.03 - Fix up the sub-package Requires to depend on release-version - Correct location of installed xemacs files git-1.5.2.2-1.fc6 ----------------- * Mon Jul 02 2007 James Bowes 1.5.2.2-1 - git-1.5.2.2 gutenprint-5.0.1-2.fc6 ---------------------- * Mon Jul 02 2007 Tim Waugh 5.0.1-2 - The foomatic package requires system-config-printer-libs for the update script. katapult-0.3.2.1-1.fc6 ---------------------- * Mon Jul 02 2007 Chitlesh Goorah - 0.3.2.1-1 - new upstream release * Sun Jul 01 2007 Chitlesh Goorah - 0.3.1.4-5 - Fast track sources koffice-1.6.3-1.fc6 ------------------- * Fri Jun 01 2007 Rex Dieter 1.6.3-1 - koffice-1.6.3 koffice-langpack-1.6.3-1.fc6 ---------------------------- * Fri Jun 01 2007 Rex Dieter 1.6.3-1 - koffice-l10n-1.6.3 libqalculate-0.9.6-1.fc6 ------------------------ * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release perl-DBIx-DBSchema-0.33-1.fc6 ----------------------------- * Mon Jul 02 2007 Ralf Cors?pius - 0.33-1 - Upstream update. perl-File-Remove-0.36-2.fc6 --------------------------- * Sat Jun 02 2007 Ralf Cors?pius - 0.36-2 - Increment release due to koji suckage. * Sat Jun 02 2007 Ralf Cors?pius - 0.36-1 - Upsteam update. - BR: perl(ExtUtils::MakeMaker). - BR: perl(Test::More). * Mon Nov 27 2006 Ralf Cors?pius - 0.34-1 - Upstream update. - Fix URL in Source0. php-pear-Benchmark-1.2.7-1.fc6 ------------------------------ * Mon Jul 02 2007 Christopher Stone 1.2.7-1 - Upstream Sync php-pear-Date-Holidays-0.17.1-2.fc6 ----------------------------------- * Mon Jul 02 2007 Christopher Stone 0.17.1-2 - Add files to %{_bindir} * Mon Jul 02 2007 Christopher Stone 0.17.1-1 - Upstream Sync - Update license file php-pear-HTML-Common-1.2.4-1.fc6 -------------------------------- * Mon Jul 02 2007 Christopher Stone 1.2.4-1 - Upstream sync - Update license file php-pear-HTML-QuickForm-3.2.9-1.fc6 ----------------------------------- * Mon Jul 02 2007 Christopher Stone 3.2.9-1 - Upstream sync - Update license file php-pear-HTML-Table-1.8.1-1.fc6 ------------------------------- * Mon Jul 02 2007 Christopher Stone 1.8.1-1 - Upstream sync php-pear-Image-Canvas-0.3.1-1.fc6 --------------------------------- * Mon Jul 02 2007 Christopher Stone 0.3.1-1 - Upstream Sync php-pear-Net-URL-1.0.15-1.fc6 ----------------------------- * Mon Jul 02 2007 Christopher Stone 1.0.15-1 - Upstream sync php-pear-Phlickr-0.2.7-2.fc6 ---------------------------- * Sat Jun 30 2007 Michael Stahnke - 0.2.7-2 - Upstream URL changed - Sourceforge has project directory lowercased - Bug # 245694 * Tue Jun 26 2007 Michael Stahnke - 0.2.7-1 - Initial Package php-pear-Structures-DataGrid-DataSource-MDB2-0.1.10-1.fc6 --------------------------------------------------------- * Mon Jul 02 2007 Christopher Stone 0.1.10-1 - Upstream sync pidgin-libnotify-0.13-1.fc6 --------------------------- * Sun Jul 01 2007 Peter Gordon - 0.13-1 - Update to new upstream release (0.13). - Drop renamed-to-pidgin patch (fixed upstream): - renamed-to-pidgin.patch - Alphabetize BuildRequires (aesthetic-only change). python-genshi-0.4.2-1.fc6 ------------------------- * Thu Jun 21 2007 Jeffrey C. Ollie - 0.4.2-1 - Update to 0.4.2 python-isprelink-0.1.2-2.fc6 ---------------------------- * Fri Jun 29 2007 Jeffrey C. Ollie - 0.1.2-2 - Upstream tarball is different from what I was using, adapt. * Tue Jun 26 2007 Jeffrey C. Ollie - 0.1.2-1 - First version for Fedora qalculate-gtk-0.9.6-1.fc6 ------------------------- * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release qalculate-kde-0.9.6-1.fc6 ------------------------- * Sun Jul 01 2007 Deji Akingunola - 0.9.6-1 - Update to new release testdisk-6.7-1.fc6 ------------------ * Sun Jul 01 2007 Christophe Grenier 6.7-1 - Update to latest version - Fix incorrect polish characters in spec file (BZ#244382) zabbix-1.4.1-1.fc6 ------------------ * Mon Jul 02 2007 Jarod Wilson 1.4.1-1 - New upstream release For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at redhat.com Tue Jul 3 10:52:15 2007 From: buildsys at redhat.com (Build System) Date: Tue, 3 Jul 2007 06:52:15 -0400 Subject: rawhide report: 20070703 changes Message-ID: <200707031052.l63AqF9r027892@porkchop.devel.redhat.com> New package atanks Remake of a classic DOS game "Scorched Earth" New package c2050 Converts bitcmyk data to Lexmark 2050 printer language New package ois Open Input System, OO gaming input library New package pbm2l7k Converts PBM stream to Lexmark 7000, 7200 and 5700 printer language New package perl-Gearman Distributed job system New package perl-Gearman-Server Function call "router" and load balancer New package php-magpierss MagpieRSS is an RSS parser written in PHP New package php-pear-Phlickr Phlickr is a PHP5 based api kit used with the Flickr API New package python-isprelink Python module to determine if a file has been prelinked New package tcl-tcldict Tcl dictionary extension New package tk-tktreectrl Flexible listbox widget for Tk Removed package g-wrap Updated Packages: R-2.5.1-1.fc8 ------------- * Mon Jul 02 2007 Tom "spot" Callaway 2.5.1-1 - drop patch, upstream fixed - bump to 2.5.1 * Mon Apr 30 2007 Tom "spot" Callaway 2.5.0-2 - patch from Martyn Plummer fixes .pc files - add new BR: gcc-objc * Wed Apr 25 2007 Tom "spot" Callaway 2.5.0-1 - bump to 2.5.0 apcupsd-3.14.1-2.fc8 -------------------- * Sat Jun 02 2007 - Orion Poplawski - 3.14.1-2 - Add patch for linux USB UPS detection (bug #245864) babel-0.8.1-1.fc8 ----------------- * Mon Jul 02 2007 Jeffrey C. Ollie - 0.8.1-1 - Update to 0.8.1 - Remove upstreamed patch. bigboard-0.4.9-1.fc8 -------------------- * Mon Jul 02 2007 Colin Walters - 0.4.9-1 - 0.4.9 (b.r.c 246417) bind-31:9.5.0a5-2.fc8 --------------------- * Mon Jul 02 2007 Adam Tkac 31:9.5.0a5-2.fc8 - minor changes in default configuration - fix h_errno assigment during resolver initialization (unbounded recursion, #245857) - removed wrong patch to #150288 chess-1.0-6.fc8 --------------- * Sun Jul 01 2007 Hans de Goede 1.0-6 - Port to Ogre 1.4.x + OIS ebtables-2.0.8-1.fc8 -------------------- * Mon Jul 02 2007 Tom "spot" Callaway 2.0.8-1 - final 2.0.8 release emacs-common-muse-3.03-2.fc8 ---------------------------- * Mon Jul 02 2007 Jonathan G. Underwood - 3.03-2 - Add BuildRequires for tetex-latex so pdf files get built fetchmail-6.3.8-1.fc8 --------------------- * Mon Jul 02 2007 Vitezslav Crhonek - 6.3.8-1 - Update to fetchmail-6.3.8 (#246445) glibmm24-2.13.6-3.fc8 --------------------- * Tue Jul 03 2007 Mamoru Tasaka - 2.13.6-3 - Rebuild against newest GLib (due to #245141, #245634) gnokii-0.6.16-1.fc8 ------------------- * Mon Jul 02 2007 - Bastien Nocera - 0.6.16-1 - New upstream release - Update smsd name change patch - ppm2nokia, waitcall and todologo have moved to gnokii-extras, as per upstream gnome-user-docs-2.18.2-1.fc8 ---------------------------- * Mon Jul 02 2007 Matthias Clasen - 2.18.2-1 - Update to 2.18.2 gnucash-2.1.5-1.fc8 ------------------- * Mon Jul 02 2007 Bill Nottingham - 2.1.5-1 - update to 2.1.5 gtk2-2.11.5-1.fc8 ----------------- * Mon Jul 02 2007 Matthias Clasen - 2.11.5-1 - Update to 2.11.5 * Tue Jun 19 2007 Matthias Clasen - 2.11.4-1 - Update to 2.11.4 * Sun Jun 17 2007 Matthias Clasen - 2.11.3-4 - Update versioned dependencies (#244602) gtkmm24-2.11.3-2.fc8 -------------------- * Tue Jul 03 2007 Mamoru Tasaka - 2.11.3-2 - Rebuild against newest GLib (due to #245141, #245634) gutenprint-5.0.1-2.fc8 ---------------------- * Mon Jul 02 2007 Tim Waugh 5.0.1-2 - Fix up foomatic PPD files after upgrade (bug #246448). jd-1.9.5-1.fc8 -------------- * Sat Jun 30 2007 Mamoru Tasaka - 1.9.5-1 - 1.9.5 * Mon Jun 25 2007 Mamoru Tasaka - 1.9.5-0.6.rc070625 - 1.9.5 rc 070625 * Sat Jun 16 2007 Mamoru Tasaka - 1.9.5-0.5.beta070616 - 1.9.5 beta 070616 jwhois-4.0-1 ------------ * Mon Jul 02 2007 Vitezslav Crhonek - 4.0-1 - Update to 4.0 (#246455) kernel-2.6.21-1.3244.fc8 ------------------------ * Mon Jul 02 2007 Dave Jones - 2.6.22-rc7. kipi-plugins-0.1.4-1.fc8 ------------------------ * Mon Jul 02 2007 Rex Dieter 0.1.4-1 - kipi-plugins-0.1.4(final) libdaemon-0.11-2.fc8 -------------------- * Mon Jul 02 2007 Dan Williams - 0.11-2 - Fix double-free bug when closing daemon file descriptor (avahi.org #148) liferea-1.2.19-1.fc8 -------------------- * Mon Jul 02 2007 Brian Pepple - 1.2.19-1 - Update to 1.2.19. mdadm-2.6.2-1.fc8 ----------------- * Mon Jul 02 2007 Doug Ledford - 2.6.2-1 - Update to latest upstream - Remove requirement for /usr/sbin/sendmail - it's optional and not on by default, and sendmail isn't *required* for mdadm itself to work, and isn't even required for the monitoring capability to work, just if you want to have the monitoring capability do the automatic email thing instead of run your own program (and if you use the program option of the monitor capability, your program could email you in a different manner entirely) microcode_ctl-1:1.17-1.38.fc8 ----------------------------- * Mon Jul 02 2007 Dave Jones - Update to upstream 1.17 nexuiz-data-2.3-2.fc8 --------------------- * Mon Jul 02 2007 Jon Ciesla - 2.3-2 - Added disttag. ocaml-3.10.0-1.fc8 ------------------ * Sat Jun 02 2007 Gerard Milmeister - 3.10.0-1 - new version 3.10.0 - split off devel packages - rename subpackages to use ocaml- prefix * Thu May 24 2007 Gerard Milmeister - 3.09.3-2 - added ocamlobjinfo * Sat Dec 02 2006 Gerard Milmeister - 3.09.3-1 - new version 3.09.3 ogre-1.4.2-1.fc8 ---------------- * Sat Jun 30 2007 Hans de Goede 1.4.2-1 - New upstream release 1.4.2 - Warning as always with a new upstream ogre release this breaks the ABI and changes the soname! - Warning this release also breaks the API! openmpi-1.2.3-2.fc8 ------------------- * Mon Jul 02 2007 Doug Ledford - 1.2.3-2 - Fix dangling symlink issue caused by a bad macro usage - Resolves: bz246450 pango-1.17.4-1.fc8 ------------------ * Mon Jul 02 2007 Matthias Clasen - 1.17.4-1 - Update to 1.17.4 * Mon Jul 02 2007 Matthias Clasen - 1.17.3-1 - Update to 1.17.3 - Drop ancient Obsoletes perl-DBIx-DBSchema-0.33-1.fc8 ----------------------------- * Mon Jul 02 2007 Ralf Cors??pius - 0.33-1 - Upstream update. perl-DateTime-1:0.38-1.fc8 -------------------------- * Mon Jul 02 2007 Steven Pritchard 1:0.38-1 - Update to DateTime 0.38. - Update to DateTime::TimeZone 0.6602. - BR Test::Pod::Coverage. * Mon Apr 02 2007 Steven Pritchard 1:0.37-3 - Drop BR DateTime::Format::* to avoid circular build deps. * Mon Apr 02 2007 Steven Pritchard 1:0.37-2 - Filter Win32::TieRegistry dependency. - Do the provides filter like we do in cpanspec. - Drop some macro usage. perl-Digest-SHA1-2.11-2 ----------------------- * Thu May 24 2007 Ville Skytt?? - 2.11-2 - Sync with latest rpmdevtools perl spec template. - BuildRequire perl(ExtUtils::MakeMaker). - Convert docs to UTF-8. * Wed Jul 12 2006 Jesse Keating - 2.11-1.2.1 - rebuild * Fri Feb 10 2006 Jesse Keating - 2.11-1.2 - bump again for double-long bug on ppc(64) perl-File-Remove-0.36-1.fc8 --------------------------- * Sat Jun 02 2007 Ralf Cors??pius - 0.37-1 - Upsteam update. - BR: perl(ExtUtils::MakeMaker). - BR: perl(Test::More). * Mon Nov 27 2006 Ralf Cors??pius - 0.34-1 - Upstream update. - Fix URL in Source0. * Fri Nov 03 2006 Ralf Cors??pius - 0.33-1 - Upstream update. perl-IO-Compress-Zlib-2.005-1.fc8 --------------------------------- perl-XML-SAX-0.16-1.fc8 ----------------------- * Mon Jul 02 2007 Jose Pedro Oliveira - 0.16-1 - Update to 0.16. - Brings specfile closer to Fedora Perl template. - Corrects Source0 URL (upstream maintainer has changed). - Move Requires filter into spec, and add Provides filter. php-5.2.3-4 ----------- * Mon Jul 02 2007 Joe Orton 5.2.3-4 - obsolete php-dbase php-pear-Benchmark-1.2.7-1.fc8 ------------------------------ php-pear-Date-Holidays-0.17.1-2.fc8 ----------------------------------- * Mon Jul 02 2007 Christopher Stone 0.17.1-2 - Add files to %{_bindir} php-pear-HTML-Common-1.2.4-1.fc8 -------------------------------- * Mon Jul 02 2007 Christopher Stone 1.2.4-1 - Upstream sync - Update license file php-pear-HTML-QuickForm-3.2.9-1.fc8 ----------------------------------- * Mon Jul 02 2007 Christopher Stone 3.2.9-1 - Upstream sync - Update license file php-pear-HTML-Table-1.8.1-1.fc8 ------------------------------- php-pear-Image-Canvas-0.3.1-1.fc8 --------------------------------- * Mon Jul 02 2007 Christopher Stone 0.3.1-1 - Upstream Sync php-pear-Net-URL-1.0.15-1.fc8 ----------------------------- php-pear-SOAP-0.11.0-1.fc8 -------------------------- * Mon Jul 02 2007 Remi Collet 0.11.0-1 - update to 0.11.0 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.10-1.fc8 --------------------------------------------------------- * Mon Jul 02 2007 Christopher Stone 0.1.10-1 - Upstream sync python-telepathy-0.13.13-1.fc8 ------------------------------ * Mon Jul 02 2007 Brian Pepple - 0.13.13-1 - Update to 0.13.13. - Add minimum ver of dbus-python. scim-bridge-0.4.13-1.fc8 ------------------------ * Mon Jul 02 2007 Huang Peng - 0.4.13-1 - Update to 0.4.13 selinux-policy-3.0.1-6.fc8 -------------------------- * Mon Jul 02 2007 Dan Walsh 3.0.1-5 - Default to user_u:system_r:unconfined_t system-config-language-1.2.3-1.fc8 ---------------------------------- * Tue Jul 03 2007 Lingning Zhang - 1.2.3 - fix bug245872 and bug241744. system-config-users-1.2.60-1.fc8 -------------------------------- * Thu Jun 28 2007 Nils Philippsen - 1.2.60 - don't barf on inconsistent groups - use integers instead of strings for various user parameters (#226976, patch by Miloslav Trmac) tar-2:1.17-1.fc8 ---------------- * Thu Jun 28 2007 Radek Brich 2:1.17-1 - new upstream version - patch for wildcards (#206841), restoring old behavior - patch for testsuite - update -xattrs patch - drop 13 obsolete patches vixie-cron-4:4.1-83.fc8 ----------------------- * Mon Jul 02 2007 Marcela Maslanova - 4:4.1-83 - fix 246396, tmp directory, typo in crontab.1 - Resolves: rhbz#246396 xorg-x11-server-1.3.0.0-13.fc8 ------------------------------ * Mon Jul 02 2007 Adam Jackson 1.3.0.0-13 - Add IDLETIME sync counter for great powersaving justice. - Conditionalise default font path for F7 spec compatibility. zabbix-1.4.1-1.fc8 ------------------ * Mon Jul 02 2007 Jarod Wilson 1.4.1-1 - New upstream release Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.i386 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.x86_64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.ppc requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) rpy - 0.4.6-16.fc7.ppc64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From aportal at univ-montp2.fr Tue Jul 3 10:50:52 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Tue, 3 Jul 2007 12:50:52 +0200 Subject: Unable to access a bug Message-ID: <200707031250.52929.aportal@univ-montp2.fr> Hi, Yesterday, I reported a bug (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246508) that was closed as duplicate of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223175 but I can't see and follow this bug because: "Access Denied You are not authorized to access bug #223175. " Why I'm not authorized to access this bug? Regards, 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 kagesenshi.87 at gmail.com Tue Jul 3 11:26:21 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 3 Jul 2007 19:26:21 +0800 Subject: Compiz Fusion? In-Reply-To: <4689616A.2020908@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> <4689616A.2020908@gmail.com> Message-ID: On 7/3/07, dragoran wrote: > Hikaru Amano wrote: > > back to topic , > > > > I just rewrote desktop-effects in .py to make use compizconfig-python .. > > > > attached them together with this email .. > > > attached a version with the error dialog (left the nvidia stuff for now). > whats still mising is support for gettext (translations) > Nice!. Thanx ! :D the timeout dialog is now working (might be buggy though) .. attached together the tarball On 7/3/07, Alphonse Van Assche wrote: > Nice!, I have just see a little error, the path of the mesa libGL > provided by the fglrx package is /usr/lib/fglrx/libGL.so.1.2 instead of > /usr/lib/fglrx/libGL.so.1.2.xlibmesa. Issit? .. the howto post in opencompositing.org forum states /usr/lib/fglrx/libGL.so.1.2.xlibmesa. http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 hurm .. I wonder where are krh and jwilson .. I wonder if I'm doing stuff correctly .. -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From kagesenshi.87 at gmail.com Tue Jul 3 11:27:21 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 3 Jul 2007 19:27:21 +0800 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> <4689616A.2020908@gmail.com> Message-ID: On 7/3/07, Hikaru Amano wrote: > On 7/3/07, dragoran wrote: > > Hikaru Amano wrote: > > > back to topic , > > > > > > I just rewrote desktop-effects in .py to make use compizconfig-python .. > > > > > > attached them together with this email .. > > > > > attached a version with the error dialog (left the nvidia stuff for now). > > whats still mising is support for gettext (translations) > > > > Nice!. Thanx ! :D > > the timeout dialog is now working (might be buggy though) .. attached > together the tarball > > On 7/3/07, Alphonse Van Assche wrote: > > Nice!, I have just see a little error, the path of the mesa libGL > > provided by the fglrx package is /usr/lib/fglrx/libGL.so.1.2 instead of > > /usr/lib/fglrx/libGL.so.1.2.xlibmesa. > > Issit? .. the howto post in opencompositing.org forum states > /usr/lib/fglrx/libGL.so.1.2.xlibmesa. > > http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 > > > hurm .. > I wonder where are krh and jwilson .. I wonder if I'm doing stuff correctly .. > yikes .. Attached the tarball in _this_ email .. -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: pydesktop-effects-0.1.tar.bz2 Type: application/x-bzip2 Size: 31275 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Jul 3 12:32:58 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 03 Jul 2007 07:32:58 -0500 Subject: Unable to access a bug References: <200707031250.52929.aportal@univ-montp2.fr> Message-ID: Alain PORTAL wrote: > Hi, > > Yesterday, I reported a bug > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246508) that was > closed as duplicate of > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223175 but I can't > see and follow this bug because: "Access Denied > You are not authorized to access bug #223175. " > > Why I'm not authorized to access this bug? bugs can be marked as private, for various reasons, like security-sensitive issues. -- Rex From kanarip at kanarip.com Tue Jul 3 12:38:44 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 03 Jul 2007 14:38:44 +0200 Subject: Unable to access a bug In-Reply-To: References: <200707031250.52929.aportal@univ-montp2.fr> Message-ID: <468A4354.4080705@kanarip.com> Rex Dieter wrote: > Alain PORTAL wrote: > >> Hi, >> >> Yesterday, I reported a bug >> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246508) that was >> closed as duplicate of >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223175 but I can't >> see and follow this bug because: "Access Denied >> You are not authorized to access bug #223175. " >> >> Why I'm not authorized to access this bug? > > bugs can be marked as private, for various reasons, like security-sensitive > issues. > In this case it concerns renaming a translation module so that translator scripts are easier to write and maintain. I'm not sure how that relates to anything private. Kind regards, Jeroen van Meeuwen -kanarip From valent.turkovic at gmail.com Tue Jul 3 12:40:52 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 14:40:52 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> Message-ID: <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> > There was a recent discussion on this topic and the decision was to > remove Beagle from the default install because for too many users Beagle > would suck up 100% CPU and leave the machine virtually unusable. See the > archives for details. Once Beagle matures some more and causes fewer > problems like this having Beagle in the default install can be > reconsidered. > > Jeff > The beagle was disabled (I'm on bugzilla for that beagle bug and also I was active in discussions on mailing lists when that happened) but IMHO the reasoning that was for it to not be installed by default would make Fedora 7 look like Fedora Core 3 if it was applied to fedora as a whole and not only to beagle. I have substantially tested beagle on 7 different desktops and had ZERO problems. Also the bug in bugzilla is really vague. I have much more problems with other features in Fedora 7; like user switcher which, if you haven't used it, causes data losses and time losses. When other user logs in then after some time first X session just crashes taking all apps and all the work that has been going on there down with it! This is a MUCH more severe bug that beagle can produce and it is still installed by default on all Fedora 7 desktops. This is inconsistent. Either don't include any of new fetures that aren't rock-solid in Fedora 7, 8, 9, etc, or give us these great apps and iron the bugs out along the was. Fedora team should have left beagle installed an on by default and hunt down and squashed that bug. I contacted beagle maintainers for fedora and offered them my hand in testing if beagle is now good enough for prime time. here is the bugzilla link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jul 3 12:50:26 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 14:50:26 +0200 Subject: Fedora 8 codename suggestion: Infinity Message-ID: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> I saw a post for Fedora 8 theme called infinity and it just clicked! One of Fedora 8 codenames to consider is Infinity. Why? Because number 8 rotated in 90 degrees shows infinity. Simple and clear message. just my 2c ps. it is so obvious that probably somebody all ready posted this :) -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From sundaram at fedoraproject.org Tue Jul 3 12:53:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 18:23:28 +0530 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> Message-ID: <468A46C8.4040600@fedoraproject.org> Valent Turkovic wrote: > I saw a post for Fedora 8 theme called infinity and it just clicked! > One of Fedora 8 codenames to consider is Infinity. Why? Because number > 8 rotated in 90 degrees shows infinity. Simple and clear message. > > just my 2c > > ps. it is so obvious that probably somebody all ready posted this :) Codenames aren't decided like this. http://www.redhat.com/magazine/024oct06/features/rh_speaks/ See From sundaram at fedoraproject.org Tue Jul 3 12:57:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 18:27:11 +0530 Subject: Unable to access a bug In-Reply-To: <468A4354.4080705@kanarip.com> References: <200707031250.52929.aportal@univ-montp2.fr> <468A4354.4080705@kanarip.com> Message-ID: <468A47A7.3050909@fedoraproject.org> Jeroen van Meeuwen wrote: > Rex Dieter wrote: >> Alain PORTAL wrote: >> >>> Hi, >>> >>> Yesterday, I reported a bug >>> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246508) that was >>> closed as duplicate of >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223175 but I can't >>> see and follow this bug because: "Access Denied >>> You are not authorized to access bug #223175. " >>> >>> Why I'm not authorized to access this bug? >> bugs can be marked as private, for various reasons, like security-sensitive >> issues. >> > > In this case it concerns renaming a translation module so that > translator scripts are easier to write and maintain. I'm not sure how > that relates to anything private. It is being closed against RHEL which frequently does have confidential information. Fedora bug should just be tracked independently IMO and the bug reopened. Rahul From mattdm at mattdm.org Tue Jul 3 13:29:16 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 Jul 2007 09:29:16 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468A46C8.4040600@fedoraproject.org> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> Message-ID: <20070703132916.GA8077@jadzia.bu.edu> On Tue, Jul 03, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > >I saw a post for Fedora 8 theme called infinity and it just clicked! > >One of Fedora 8 codenames to consider is Infinity. Why? Because number > >8 rotated in 90 degrees shows infinity. Simple and clear message. > >just my 2c > >ps. it is so obvious that probably somebody all ready posted this :) > Codenames aren't decided like this. Sure they are. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From greno at verizon.net Tue Jul 3 13:44:19 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 03 Jul 2007 09:44:19 -0400 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> Message-ID: <468A52B3.4090501@verizon.net> Valent Turkovic wrote: >> There was a recent discussion on this topic and the decision was to >> remove Beagle from the default install because for too many users Beagle >> would suck up 100% CPU and leave the machine virtually unusable. See the >> archives for details. Once Beagle matures some more and causes fewer >> problems like this having Beagle in the default install can be >> reconsidered. >> >> Jeff >> > > The beagle was disabled (I'm on bugzilla for that beagle bug and also > I was active in discussions on mailing lists when that happened) but > IMHO the reasoning that was for it to not be installed by default > would make Fedora 7 look like Fedora Core 3 if it was applied to > fedora as a whole and not only to beagle. > > I have substantially tested beagle on 7 different desktops and had > ZERO problems. Also the bug in bugzilla is really vague. I have much > more problems with other features in Fedora 7; like user switcher > which, if you haven't used it, causes data losses and time losses. > When other user logs in then after some time first X session just > crashes taking all apps and all the work that has been going on there > down with it! This is a MUCH more severe bug that beagle can produce > and it is still installed by default on all Fedora 7 desktops. This is > inconsistent. Either don't include any of new fetures that aren't > rock-solid in Fedora 7, 8, 9, etc, or give us these great apps and > iron the bugs out along the was. Fedora team should have left beagle > installed an on by default and hunt down and squashed that bug. > > I contacted beagle maintainers for fedora and offered them my hand in > testing if beagle is now good enough for prime time. > here is the bugzilla link: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 > Hi Valent, I have to agree with the decision to drop beagle as default. On my desktop I have many thousands of files and documents that I would like beagle to catalog but it was consuming huge amount of system resource when it was running trying to do this. At first I didn't know why things were so sluggish and then 'top' showed beagle consuming everything. 'beagle' needs to get some intelligent throttling and perhaps just some bugs fixed before I'll try it again. Gerry From aportal at univ-montp2.fr Tue Jul 3 13:41:49 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Tue, 3 Jul 2007 15:41:49 +0200 Subject: Unable to access a bug In-Reply-To: <468A47A7.3050909@fedoraproject.org> References: <200707031250.52929.aportal@univ-montp2.fr> <468A4354.4080705@kanarip.com> <468A47A7.3050909@fedoraproject.org> Message-ID: <200707031541.49214.aportal@univ-montp2.fr> Le Tuesday 03 July 2007 14:57:11 Rahul Sundaram, vous avez ?crit?: > Jeroen van Meeuwen wrote: > > Rex Dieter wrote: > >> Alain PORTAL wrote: > >>> Hi, > >>> > >>> Yesterday, I reported a bug > >>> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246508) that was > >>> closed as duplicate of > >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223175 but I can't > >>> see and follow this bug because: "Access Denied > >>> You are not authorized to access bug #223175. " > >>> > >>> Why I'm not authorized to access this bug? > >> > >> bugs can be marked as private, for various reasons, like > >> security-sensitive issues. > > > > In this case it concerns renaming a translation module so that > > translator scripts are easier to write and maintain. I'm not sure how > > that relates to anything private. > > It is being closed against RHEL which frequently does have confidential > information. Fedora bug should just be tracked independently IMO and the > bug reopened. OK, I reopen it Thanks 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 skvidal at linux.duke.edu Tue Jul 3 13:43:27 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 03 Jul 2007 09:43:27 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <20070703132916.GA8077@jadzia.bu.edu> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> Message-ID: <1183470207.31613.15.camel@cutter> On Tue, 2007-07-03 at 09:29 -0400, Matthew Miller wrote: > On Tue, Jul 03, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > > >I saw a post for Fedora 8 theme called infinity and it just clicked! > > >One of Fedora 8 codenames to consider is Infinity. Why? Because number > > >8 rotated in 90 degrees shows infinity. Simple and clear message. > > >just my 2c > > >ps. it is so obvious that probably somebody all ready posted this :) > > Codenames aren't decided like this. > > Sure they are. > well, we would need to get from moonshine to infinity. And infinity has to pass legal. -sv From laurent.rineau__fedora at normalesup.org Tue Jul 3 13:48:42 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 3 Jul 2007 15:48:42 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A52B3.4090501@verizon.net> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> Message-ID: <200707031548.42818@rineau.tsetse> On Tuesday 03 July 2007 15:44:19 Gerry Reno wrote: > Hi Valent, > I have to agree with the decision to drop beagle as default. On my > desktop I have many thousands of files and documents that I would like > beagle to catalog but it was consuming huge amount of system resource > when it was running trying to do this. +1 -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From greno at verizon.net Tue Jul 3 13:55:57 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 03 Jul 2007 09:55:57 -0400 Subject: Suggestion: Disk Druid changes Message-ID: <468A556D.7030102@verizon.net> Hi all, As I mentioned in another post, I have been using a technique that at least for me greatly simplifies moving to and from RAID-1 on any system. I do this by installing the system on a degraded RAID-1 array and then later it is very simple to make the system true RAID by just adding the missing drive/partitions. From the other Fedora 8/9 wishlist post: Another thing in Disk Druid that I would like to see is the ability to install on a degraded RAID-1 array where I declare RAID-1 but then the second mirror is missing. I install this way all the time on systems and then when I add the second hard drive later and place it into the array, it just syncs. Want to go back to just a single drive - no problem. Just fault the device and remove it. No complicated remounting filesystems or anything - very smooth. This way you're always on an md device. I would like to see this actually become the default. It makes it very easy to convert a system to RAID-1 later on if the user would like to do so without any complicated procedures necessary. Gerry From valent.turkovic at gmail.com Tue Jul 3 13:58:38 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 15:58:38 +0200 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468A46C8.4040600@fedoraproject.org> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> Message-ID: <64b14b300707030658y4e2f80fex8c8616709a6b371d@mail.gmail.com> On 7/3/07, Rahul Sundaram wrote: > Valent Turkovic wrote: > > I saw a post for Fedora 8 theme called infinity and it just clicked! > > One of Fedora 8 codenames to consider is Infinity. Why? Because number > > 8 rotated in 90 degrees shows infinity. Simple and clear message. > > > > just my 2c > > > > ps. it is so obvious that probably somebody all ready posted this :) > > Codenames aren't decided like this. > > http://www.redhat.com/magazine/024oct06/features/rh_speaks/ > > See This is only a suggestion. Take it or leave it, it's your (all of you) choice. and I see that it is the way by this copy/paste: "With the last release (Fedora Core 5) we decided to let the community of Fedora contributors both supply a list of possible names and vote on the pre-cleared names to pick the release name. This tradition continued with Fedora Core 6, although the survey link got shared in many more places. With the next release of Fedora, we will be taking advantage of the hard work done on the Fedora Voting System which would restrict votes to those individuals whom have Fedora Accounts and thus are contributors in one way or another." -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jul 3 14:05:43 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 16:05:43 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A52B3.4090501@verizon.net> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> Message-ID: <64b14b300707030705o4b41844w701e2f22293461b6@mail.gmail.com> On 7/3/07, Gerry Reno wrote: > Valent Turkovic wrote: > >> There was a recent discussion on this topic and the decision was to > >> remove Beagle from the default install because for too many users Beagle > >> would suck up 100% CPU and leave the machine virtually unusable. See the > >> archives for details. Once Beagle matures some more and causes fewer > >> problems like this having Beagle in the default install can be > >> reconsidered. > >> > >> Jeff > >> > > > > The beagle was disabled (I'm on bugzilla for that beagle bug and also > > I was active in discussions on mailing lists when that happened) but > > IMHO the reasoning that was for it to not be installed by default > > would make Fedora 7 look like Fedora Core 3 if it was applied to > > fedora as a whole and not only to beagle. > > > > I have substantially tested beagle on 7 different desktops and had > > ZERO problems. Also the bug in bugzilla is really vague. I have much > > more problems with other features in Fedora 7; like user switcher > > which, if you haven't used it, causes data losses and time losses. > > When other user logs in then after some time first X session just > > crashes taking all apps and all the work that has been going on there > > down with it! This is a MUCH more severe bug that beagle can produce > > and it is still installed by default on all Fedora 7 desktops. This is > > inconsistent. Either don't include any of new fetures that aren't > > rock-solid in Fedora 7, 8, 9, etc, or give us these great apps and > > iron the bugs out along the was. Fedora team should have left beagle > > installed an on by default and hunt down and squashed that bug. > > > > I contacted beagle maintainers for fedora and offered them my hand in > > testing if beagle is now good enough for prime time. > > here is the bugzilla link: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 > > > Hi Valent, > I have to agree with the decision to drop beagle as default. On my > desktop I have many thousands of files and documents that I would like > beagle to catalog but it was consuming huge amount of system resource > when it was running trying to do this. At first I didn't know why > things were so sluggish and then 'top' showed beagle consuming > everything. 'beagle' needs to get some intelligent throttling and > perhaps just some bugs fixed before I'll try it again. > > Gerry Why don't you engage a little of your time and track which files cause this problem. I also have thousands of files and I don't see any performance issues using beagle. If you would contribute and get involved with hunting these bugs you experience than we all would benefit. I'm volunteering my time and my other resources to fixing beagle bugs - but I just don't experience any since Fedora Core 5 (then there were plenty of bugs). If you find which files are causing you problems please mail them to me and I'll report bugs and work with beagle team to fix them. There. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jul 3 14:06:44 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 16:06:44 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <200707031548.42818@rineau.tsetse> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> Message-ID: <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> On 7/3/07, Laurent Rineau wrote: > On Tuesday 03 July 2007 15:44:19 Gerry Reno wrote: > > Hi Valent, > > I have to agree with the decision to drop beagle as default. On my > > desktop I have many thousands of files and documents that I would like > > beagle to catalog but it was consuming huge amount of system resource > > when it was running trying to do this. > > +1 Why don't you engage a little of your time and track which files cause this problem. I also have thousands of files and I don't see any performance issues using beagle. If you would contribute and get involved with hunting these bugs you experience than we all would benefit. I'm volunteering my time and my other resources to fixing beagle bugs - but I just don't experience any since Fedora Core 5 (then there were plenty of bugs). If you find which files are causing you problems please mail them to me and I'll report bugs and work with beagle team to fix them. There. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jul 3 14:09:15 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 16:09:15 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <200707031548.42818@rineau.tsetse> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> Message-ID: <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> On 7/3/07, Laurent Rineau wrote: > On Tuesday 03 July 2007 15:44:19 Gerry Reno wrote: > > Hi Valent, > > I have to agree with the decision to drop beagle as default. On my > > desktop I have many thousands of files and documents that I would like > > beagle to catalog but it was consuming huge amount of system resource > > when it was running trying to do this. > > +1 > Show me the money! Or put you money where your mouth is. Or any other slogan fits here nicely. Show us exactly where you have issues with beagle and with which files and help us all fix these bugs. Complaining only doesn't help anybody. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From oliver at linux-kernel.at Tue Jul 3 14:10:11 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 03 Jul 2007 16:10:11 +0200 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <64b14b300707030658y4e2f80fex8c8616709a6b371d@mail.gmail.com> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <64b14b300707030658y4e2f80fex8c8616709a6b371d@mail.gmail.com> Message-ID: <468A58C3.7060802@linux-kernel.at> On 07/03/2007 03:58 PM, Valent Turkovic wrote: > On 7/3/07, Rahul Sundaram wrote: >> Valent Turkovic wrote: >> > I saw a post for Fedora 8 theme called infinity and it just clicked! >> > One of Fedora 8 codenames to consider is Infinity. Why? Because number >> > 8 rotated in 90 degrees shows infinity. Simple and clear message. >> > >> > just my 2c >> > >> > ps. it is so obvious that probably somebody all ready posted this :) >> >> Codenames aren't decided like this. >> >> http://www.redhat.com/magazine/024oct06/features/rh_speaks/ >> >> See > > This is only a suggestion. Take it or leave it, it's your (all of you) > choice. > > and I see that it is the way by this copy/paste: > > "With the last release (Fedora Core 5) we decided to let the community > of Fedora contributors both supply a list of possible names and vote > on the pre-cleared names to pick the release name. This tradition > continued with Fedora Core 6, although the survey link got shared in > many more places. With the next release of Fedora, we will be taking > advantage of the hard work done on the Fedora Voting System which > would restrict votes to those individuals whom have Fedora Accounts > and thus are contributors in one way or another." Just connect it to Moonshine/F7... And everything is fine. -of From valent.turkovic at gmail.com Tue Jul 3 14:13:40 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 3 Jul 2007 16:13:40 +0200 Subject: how do I continue using rawhide? Message-ID: <64b14b300707030713u544280b4x6aec929f2ac2751a@mail.gmail.com> I had fedora 7 test 4 (rawhide) installed. When Fedora 7 was released my yum repositories updated them selves to official Fedora 7 yum repos. How do I continue using rawhide? Are this now FC8 rpms? This all is really confusing for me so please clarify it for me or just point me in the right direction with a few wiki links or some articles. Thank you, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From pertusus at free.fr Tue Jul 3 14:16:53 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Jul 2007 16:16:53 +0200 Subject: how do I continue using rawhide? In-Reply-To: <64b14b300707030713u544280b4x6aec929f2ac2751a@mail.gmail.com> References: <64b14b300707030713u544280b4x6aec929f2ac2751a@mail.gmail.com> Message-ID: <20070703141653.GE3057@free.fr> On Tue, Jul 03, 2007 at 04:13:40PM +0200, Valent Turkovic wrote: > I had fedora 7 test 4 (rawhide) installed. When Fedora 7 was released > my yum repositories updated them selves to official Fedora 7 yum > repos. > > How do I continue using rawhide? Are this now FC8 rpms? > > This all is really confusing for me so please clarify it for me or > just point me in the right direction with a few wiki links or some > articles. Not a real answer, but I know that this has been discussed. And a hint, look at files in /etc/yum.repos.d/, and set enable=1 for the repository you want to use. -- Pat From drago01 at gmail.com Tue Jul 3 14:17:32 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 3 Jul 2007 16:17:32 +0200 Subject: how do I continue using rawhide? In-Reply-To: <64b14b300707030713u544280b4x6aec929f2ac2751a@mail.gmail.com> References: <64b14b300707030713u544280b4x6aec929f2ac2751a@mail.gmail.com> Message-ID: On 7/3/07, Valent Turkovic wrote: > > I had fedora 7 test 4 (rawhide) installed. When Fedora 7 was released > my yum repositories updated them selves to official Fedora 7 yum > repos. > > How do I continue using rawhide? Are this now FC8 rpms? > > This all is really confusing for me so please clarify it for me or > just point me in the right direction with a few wiki links or some > articles. yum --enablerepo=development update -------------- next part -------------- An HTML attachment was scrubbed... URL: From kanarip at kanarip.com Tue Jul 3 14:18:39 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 03 Jul 2007 16:18:39 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> Message-ID: <468A5ABF.1050801@kanarip.com> Valent Turkovic wrote: > On 7/3/07, Laurent Rineau wrote: >> On Tuesday 03 July 2007 15:44:19 Gerry Reno wrote: >> > Hi Valent, >> > I have to agree with the decision to drop beagle as default. On my >> > desktop I have many thousands of files and documents that I would like >> > beagle to catalog but it was consuming huge amount of system resource >> > when it was running trying to do this. >> >> +1 > > Why don't you engage a little of your time and track which files cause > this problem. I also have thousands of files and I don't see any > performance issues using beagle. If you would contribute and get > involved with hunting these bugs you experience than we all would > benefit. > I'm volunteering my time and my other resources to fixing beagle bugs > - but I just don't experience any since Fedora Core 5 (then there were > plenty of bugs). If you find which files are causing you problems > please mail them to me and I'll report bugs and work with beagle team > to fix them. > > There. > I think we all appreciate that you do take the time and fix beagle right up so that one day we may all reconsider using beagle and have it installed and enabled by default. However, just because you do take that time doesn't mean we all have to. Some of us may just take enough time to yum -y remove \*beagle\*, like me, and that's all they ever do with beagle. In fact, I'll yum install the latest and greatest beagle now, and see if it consumes what I find to be too much CPU during the initial indexing. Kind regards, Jeroen van Meeuwen -kanarip From alcapcom at gmail.com Tue Jul 3 14:20:07 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Tue, 03 Jul 2007 16:20:07 +0200 Subject: Compiz Fusion? In-Reply-To: References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> <4689616A.2020908@gmail.com> Message-ID: <468A5B17.1060808@gmail.com> Hikaru Amano a ?crit : > Issit? .. the howto post in opencompositing.org forum states > /usr/lib/fglrx/libGL.so.1.2.xlibmesa. > > http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 I have see that there too but on my box LibGL* files don't contain .xlibmesa extension. To be sure, I have build the RPM packages from the ATI installer and no trace of this extension there too, so the libGL with this extension come probably from packages for another distrib. rpm -qlp ATI-* | grep -i libgl on the generated package returns: /usr/lib/fglrx/libGL.so.1 /usr/lib/fglrx/libGL.so.1.2 /usr/lib/fglrx/libGL.so Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From kanarip at kanarip.com Tue Jul 3 14:20:49 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 03 Jul 2007 16:20:49 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> Message-ID: <468A5B41.4040106@kanarip.com> Valent Turkovic wrote: > On 7/3/07, Laurent Rineau wrote: >> On Tuesday 03 July 2007 15:44:19 Gerry Reno wrote: >> > Hi Valent, >> > I have to agree with the decision to drop beagle as default. On my >> > desktop I have many thousands of files and documents that I would like >> > beagle to catalog but it was consuming huge amount of system resource >> > when it was running trying to do this. >> >> +1 >> > > Show me the money! Or put you money where your mouth is. Or any other > slogan fits here nicely. > > Show us exactly where you have issues with beagle and with which files > and help us all fix these bugs. Complaining only doesn't help anybody. > Turning evil on your (potential) userbase doesn't help anybody either. Jeroen "The problem is choice" van Meeuwen -kanarip From sundaram at fedoraproject.org Tue Jul 3 14:23:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 19:53:43 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <46893808.7090405@rasmil.dk> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> Message-ID: <468A5BEF.40309@fedoraproject.org> Tim Lauridsen wrote: >> > Sounds like a good idea, the config write routine in yum will remove all > the # comment lines and mix all the options. > I fixed the mixing in system-config-repo by building a extra layer on > the yum config API, but it don't take care off the # comments. > I would be a good idea to teach yum to save config files, without losing > information. This might be a good time to rethink whether Pirut and YumEx should be merged together. Recent YumEx changes have made it look more and more like Pirut and Pirut is started to grow more features similar to YumEx. Looks like they are converging to me. Any reasons not to merge? Rahul From dwmw2 at infradead.org Tue Jul 3 14:27:27 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Jul 2007 10:27:27 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183470207.31613.15.camel@cutter> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> Message-ID: <1183472847.29081.21.camel@shinybook.infradead.org> On Tue, 2007-07-03 at 09:43 -0400, seth vidal wrote: > On Tue, 2007-07-03 at 09:29 -0400, Matthew Miller wrote: > > On Tue, Jul 03, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote: > > > >I saw a post for Fedora 8 theme called infinity and it just clicked! > > > >One of Fedora 8 codenames to consider is Infinity. Why? Because number > > > >8 rotated in 90 degrees shows infinity. Simple and clear message. > > > >just my 2c > > > >ps. it is so obvious that probably somebody all ready posted this :) > > > Codenames aren't decided like this. > > > > Sure they are. > > > > well, we would need to get from moonshine to infinity. And infinity has > to pass legal. As long as we spell it ? -- dwmw2 From greno at verizon.net Tue Jul 3 14:33:36 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 03 Jul 2007 10:33:36 -0400 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030705o4b41844w701e2f22293461b6@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <64b14b300707030705o4b41844w701e2f22293461b6@mail.gmail.com> Message-ID: <468A5E40.4090002@verizon.net> Valent Turkovic wrote: > > Why don't you engage a little of your time and track which files cause > this problem. I also have thousands of files and I don't see any > performance issues using beagle. If you would contribute and get > involved with hunting these bugs you experience than we all would > benefit. > I'm volunteering my time and my other resources to fixing beagle bugs > - but I just don't experience any since Fedora Core 5 (then there were > plenty of bugs). If you find which files are causing you problems > please mail them to me and I'll report bugs and work with beagle team > to fix them. > > There. > > Valent, Respectfully, I contribute a great deal of my deal to probably 30-40 open source community projects. Please do not be offended, but I have little interest in 'beagle'. It's a nice-to-have but also a I-really-don't-miss-it if it's not there. The problems that I had with beagle on desktops occurred on nearly every desktop that we had where it was running. So this is not just isolated to my files or to some particular file that I have. And many other people have had exactly the same experience so for those of you who are interested in working with beagle I would think it would be easy to develop a test data set of files that exhibits the problem and work from there. Regards, Gerry From kanarip at kanarip.com Tue Jul 3 14:40:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 03 Jul 2007 16:40:40 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A5ABF.1050801@kanarip.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5ABF.1050801@kanarip.com> Message-ID: <468A5FE8.3070707@kanarip.com> Jeroen van Meeuwen wrote: > In fact, I'll yum install the latest and greatest beagle now, and see if > it consumes what I find to be too much CPU during the initial indexing. > Replying to myself, I see my ~/rpmbuild (which I /happily/ use as an archive) is being indexed with: /usr/lib/rpm/rpmq -q --package --queryformat [%{*:xml}?] /path/to/rpm Apparently it's threaded, because this one happily consuming 100% CPU, happily locking up my funky beryl desktop. Then it seems beagle-helper catches some output because it gets too excited and happily consumes like 20% CPU next to the 100-20% CPU being consumed by the other happy process. Thanks for the reminder, sometime in the future I'll try again. Kind regards, Jeroen van Meeuwen -kanarip From alcapcom at gmail.com Tue Jul 3 14:40:54 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Tue, 03 Jul 2007 16:40:54 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> Message-ID: <468A5FF6.6030108@gmail.com> Valent Turkovic a ?crit : > I'm volunteering my time and my other resources to fixing beagle bugs > - but I just don't experience any since Fedora Core 5 (then there were > plenty of bugs). I you will see beagle slowdown your whole system. Just place some big pdf files in a directory and index it, you will see pdf2html or so take the whole CPU time and you Desktop entirely no usable without killing these processes. I was really happy to no have to yum remove \*beagle\* on F7. Cheers, Alphonse -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From snecklifter at gmail.com Tue Jul 3 15:05:50 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 3 Jul 2007 16:05:50 +0100 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> Message-ID: <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> Hello Valent, On 02/07/07, Valent Turkovic wrote: > > > * NTFS support during installation +1 * Beagle and Deskbar installed by default I'm afraid I also experience a RAM-rinsing with this installed. Google Desktop, recently released under a proprietary license, is even buggier. I have had it running for three days now and it has yet to complete its indexing. /me remembers its beta. Hopefully this app along with others like tracker will make the beagle team sort out the issues above - I think they may have been resting on their laurels a little. * Tomboy installed by default Personally, I have never found the need for yellow stickies on my desktop. * Firefox to have it's original icon in gnome panel I can only guess this is a licensing issue a-la-iceweasel. * Desktop shortcut for joining Fedora IRC (aka "Get Live Help") +1 although should this need a specific support channel? * Desktop folder with examples of what "this linux thing" can do :) +1 - I do not think that the default homepage in firefox is enough. * a working Burning app for Fedora Gnome desktop I have no problems burning in fedora - what exactly is the issue you have here? Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Tue Jul 3 15:08:25 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 11:08:25 -0400 Subject: rawhide report: 20070625 changes In-Reply-To: <1183452505.2312.5.camel@work> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> <1182765242.2519.2.camel@work> <20070703044040.GB15789@redhat.com> <1183452505.2312.5.camel@work> Message-ID: <20070703150825.GD6974@redhat.com> On Tue, Jul 03, 2007 at 09:48:25AM +0100, Richard Hughes wrote: > On Tue, 2007-07-03 at 00:40 -0400, Dave Jones wrote: > > That's the plan. > > So far only msi-laptop has been converted, so asus-acpi, thinkpad-acpi > > etc still need the ugly rc.sysinit hack. > > There's a version of thinkpad_acpi that has this[1], which is destined > to go upstream in .23. Would you like me to split out the autoloading > part and file a bugzilla, or could we just use the new code? If you're desperate to test it, throw me a diff, otherwise we'll pick it up in a few weeks when we move forward to .23rc Dave -- http://www.codemonkey.org.uk From hughsient at gmail.com Tue Jul 3 15:09:36 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 03 Jul 2007 16:09:36 +0100 Subject: rawhide report: 20070625 changes In-Reply-To: <20070703150825.GD6974@redhat.com> References: <200706250943.l5P9hSi6017988@porkchop.devel.redhat.com> <1182765242.2519.2.camel@work> <20070703044040.GB15789@redhat.com> <1183452505.2312.5.camel@work> <20070703150825.GD6974@redhat.com> Message-ID: <1183475376.13813.0.camel@work> On Tue, 2007-07-03 at 11:08 -0400, Dave Jones wrote: > > > There's a version of thinkpad_acpi that has this[1], which is > destined > > to go upstream in .23. Would you like me to split out the > autoloading > > part and file a bugzilla, or could we just use the new code? > > If you're desperate to test it, throw me a diff, otherwise we'll pick > it up in a few weeks when we move forward to .23rc No, that's okay. I didn't know if we were going to stabilize on .22 or just carry on with the RC's. Richard. From mmcgrath at redhat.com Mon Jul 2 20:33:17 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 02 Jul 2007 15:33:17 -0500 Subject: Outage Notification - 2007-07-10 03:00 UTC Message-ID: <4689610D.7090103@redhat.com> There will be an outage starting at 2007-07-10 03:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2007-07-10 03:00 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Reason for Outage: Upgrading db1 and moving services to db2. This is a substantial change, please be patient. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From a.badger at gmail.com Tue Jul 3 15:10:38 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Jul 2007 08:10:38 -0700 Subject: Packaging Guideline update:: Static Libraries Message-ID: <1183475438.5355.43.camel@localhost.localdomain> The static libraries changes passed two weeks ago have now been officially written into the Guidelines[1]_. These changes are: 1) If the library you depend on only provides a static library, you can link to it without asking FESCo provided that your BuildRequires is for the -devel subpackage. BuildRequire'ing the -devel means the subpackage will link against the dynamic library when/if it becomes available. If you BuildRequire the -static version you still must make your request of FESCo. 2) You are now asked to add yourself to the initialcclist of any library that you are linking to statically (whether via BR: -static or one of the exceptions) so that you will be more aware of any security issues that arise in the library. [1]_: http://fedoraproject.org/wiki/Packaging/Guidelines#StaticLinkage Thank you, -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: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From david at lovesunix.net Tue Jul 3 15:20:38 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 03 Jul 2007 17:20:38 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> Message-ID: <1183476038.3063.20.camel@dawkins> tir, 03 07 2007 kl. 16:09 +0200, skrev Valent Turkovic: > On 7/3/07, Laurent Rineau wrote: > > On Tuesday 03 July 2007 15:44:19 Gerry Reno wrote: > > > Hi Valent, > > > I have to agree with the decision to drop beagle as default. On my > > > desktop I have many thousands of files and documents that I would like > > > beagle to catalog but it was consuming huge amount of system resource > > > when it was running trying to do this. > > > > +1 > > > > Show me the money! Or put you money where your mouth is. Or any other > slogan fits here nicely. > > Show us exactly where you have issues with beagle and with which files > and help us all fix these bugs. Complaining only doesn't help anybody. Upstream Beagle already has a great guide to helping you, help them spot problem areas, I would suggest reading that. I think Beagles biggest problem is that it's not really useful, it's not integrated anywhere, it's just a search service right now. Places like your media player e.g. could have their database populated in a dynamic manner using technology like Beagle but currently they don't. Even if we enabled Beagle by default we would not gain a lot and it's still suffering from a number of issues (such as not even surviving 5 secs on Development currently). - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From mattdm at mattdm.org Tue Jul 3 15:24:40 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 Jul 2007 11:24:40 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183470207.31613.15.camel@cutter> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> Message-ID: <20070703152440.GA19883@jadzia.bu.edu> On Tue, Jul 03, 2007 at 09:43:27AM -0400, seth vidal wrote: > > > Codenames aren't decided like this. > > Sure they are. > well, we would need to get from moonshine to infinity. And infinity has > to pass legal. Yeah. I'm having a bit of trouble with the first (although, perhaps with enough moonshine....). And who knows about the second. But random suggestions being put forth is a perfectly valid and important part of the process. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jdieter at gmail.com Tue Jul 3 15:35:49 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 03 Jul 2007 18:35:49 +0300 Subject: Is ext2 initrd support missing in F7 kernel? Message-ID: <1183476949.3438.7.camel@jndwidescreen.lesbg.loc> This is probably mostly geared towards Dave, but has ext2 initrd support been removed from the Fedora 7 kernel (or the kernel in general)? With FC6, I used a modified version of the updateDiskless script that came with system-config-netboot to build an initrd for use by netboot computers. Since updating the system to F7, I'm getting "No filesystem could mount root, tried: iso9660" as it tries to load the initrd where the initrd is in ext2 format. I know that earlier when there were some other blocksize errors in FC6, the error would be "No filesystem could mount root, tried: ext2, iso9660", which is why I'm assuming ext2 support has been removed. Any suggestions? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Tue Jul 3 15:37:36 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 03 Jul 2007 08:37:36 -0700 Subject: Finding man files: CVS or RPM repositories? In-Reply-To: <4688BD8B.9010608@hhs.nl> References: <200707021141.31212.vpivaini@cs.helsinki.fi> <4688BD8B.9010608@hhs.nl> Message-ID: <1183477056.7419.272.camel@erato.phig.org> On Mon, 2007-07-02 at 10:55 +0200, Hans de Goede wrote: > You're probably busy enough as is, but in case you have time another very > interesting source for man pages is Debian packages, Debina creates a manpage > for every package in the case upstream doesn't provide one. > > Some of them are useless (boilerplate) but some are quite good. Taking a look > at the Debian manpages and submiytting bugs for packages who could benefit from > them would be a great thing todo. Now all you need is 48 hrs in a day :) Fortunately, the point of Ville-Pekka's project is to provide a Wiki (Moin) interface in front of the man pages, then a way to submit changes back up stream. In the end, we'll be inviting the whole Fedora community to help fix man pages, all via the Wiki. Once that gets going, that's when I recommend we look cross-stream at what other distros provide and can we contribute to those as well. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Tue Jul 3 15:50:50 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jul 2007 11:50:50 -0400 Subject: Is ext2 initrd support missing in F7 kernel? In-Reply-To: <1183476949.3438.7.camel@jndwidescreen.lesbg.loc> References: <1183476949.3438.7.camel@jndwidescreen.lesbg.loc> Message-ID: <20070703155050.GA8802@redhat.com> On Tue, Jul 03, 2007 at 06:35:49PM +0300, Jonathan Dieter wrote: > This is probably mostly geared towards Dave, but has ext2 initrd support > been removed from the Fedora 7 kernel (or the kernel in general)? With > FC6, I used a modified version of the updateDiskless script that came > with system-config-netboot to build an initrd for use by netboot > computers. >From FC-6 -> F-7 it got switched from =y to =m I'm blanking on the reason why that change was made right now. Dave -- http://www.codemonkey.org.uk From jdieter at gmail.com Tue Jul 3 16:01:31 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 03 Jul 2007 19:01:31 +0300 Subject: Is ext2 initrd support missing in F7 kernel? In-Reply-To: <20070703155050.GA8802@redhat.com> References: <1183476949.3438.7.camel@jndwidescreen.lesbg.loc> <20070703155050.GA8802@redhat.com> Message-ID: <1183478491.3692.1.camel@jndwidescreen.lesbg.loc> On Tue, 2007-07-03 at 11:50 -0400, Dave Jones wrote: > On Tue, Jul 03, 2007 at 06:35:49PM +0300, Jonathan Dieter wrote: > > This is probably mostly geared towards Dave, but has ext2 initrd support > > been removed from the Fedora 7 kernel (or the kernel in general)? With > > FC6, I used a modified version of the updateDiskless script that came > > with system-config-netboot to build an initrd for use by netboot > > computers. > > From FC-6 -> F-7 it got switched from =y to =m > I'm blanking on the reason why that change was made right now. Sweet! So...is there any way to load a module so an initrd can be loaded? Or do I need to try rebuilding the kernel each time it comes out? Thanks, Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Tue Jul 3 16:04:33 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 3 Jul 2007 21:34:33 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468A5BEF.40309@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> Message-ID: <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> https://fedoraproject.org/wiki/Usability/Objectives/Pirut There are some designs already available on the above link. Can I have a look at the source code used to create them? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From notting at redhat.com Tue Jul 3 16:10:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Jul 2007 12:10:55 -0400 Subject: Is ext2 initrd support missing in F7 kernel? In-Reply-To: <1183478491.3692.1.camel@jndwidescreen.lesbg.loc> References: <1183476949.3438.7.camel@jndwidescreen.lesbg.loc> <20070703155050.GA8802@redhat.com> <1183478491.3692.1.camel@jndwidescreen.lesbg.loc> Message-ID: <20070703161054.GA5718@nostromo.devel.redhat.com> Jonathan Dieter (jdieter at gmail.com) said: > Sweet! So...is there any way to load a module so an initrd can be > loaded? Or do I need to try rebuilding the kernel each time it comes > out? Why do you need to use ext2 vs initramfs? Bill From sundaram at fedoraproject.org Tue Jul 3 16:16:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 21:46:20 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> Message-ID: <468A7654.4040600@fedoraproject.org> Debarshi 'Rishi' Ray wrote: > https://fedoraproject.org/wiki/Usability/Objectives/Pirut > > There are some designs already available on the above link. Can I have > a look at the source code used to create them? I remember Thomas blogging about this long back. Don't think the changes were submitted back. Contact https://fedoraproject.org/wiki/ThomasCanniot Rahul From debarshi.ray at gmail.com Tue Jul 3 16:21:08 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 3 Jul 2007 21:51:08 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468A7654.4040600@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> <468A7654.4040600@fedoraproject.org> Message-ID: <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> > Contact https://fedoraproject.org/wiki/ThomasCanniot I had CC'ed him in the previous mail. :-) Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jdieter at gmail.com Tue Jul 3 16:23:08 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 03 Jul 2007 19:23:08 +0300 Subject: Is ext2 initrd support missing in F7 kernel? In-Reply-To: <20070703161054.GA5718@nostromo.devel.redhat.com> References: <1183476949.3438.7.camel@jndwidescreen.lesbg.loc> <20070703155050.GA8802@redhat.com> <1183478491.3692.1.camel@jndwidescreen.lesbg.loc> <20070703161054.GA5718@nostromo.devel.redhat.com> Message-ID: <1183479788.3692.8.camel@jndwidescreen.lesbg.loc> On Tue, 2007-07-03 at 12:10 -0400, Bill Nottingham wrote: > Jonathan Dieter (jdieter at gmail.com) said: > > Sweet! So...is there any way to load a module so an initrd can be > > loaded? Or do I need to try rebuilding the kernel each time it comes > > out? > > Why do you need to use ext2 vs initramfs? > Honestly, it's because ext2 was the format used by the script, so works out-of-the-box. I've been trying to get initramfs working since I saw ext2 support was gone, but I'm running into other problems (like init as a bash script just plain refusing to load when bash is at /bin/bash in the initramfs). But I do think you're right, that initramfs is the correct way to go. I guess I'll get to play around with it until I get it working. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Tue Jul 3 16:27:59 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 03 Jul 2007 09:27:59 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUL-02 Message-ID: <468A790F.7050204@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jul-02 Please make corrections and clarifications to the wiki page. == Fedora 5 shutdown == * f13 - We're well on our way to shutting down FC5 * f13 - http://fedoraproject.org/wiki/ReleaseEngineering/Fedora5Shutdown * warren - had trouble getting repoclosure to behave and will finish up whatever needs to be done Decision: warren wrapping things up == Fedora 8 Schedule Adjustments == * Freeze dates do not line up on the correct week days * Supposed to be freezes on Tuesdays, and target the next Thursday (one week +2 days) for release * Make minor corrections +/-1 day Decisions: * schedule dates will be adjusted to follow format of Freeze on Tuesday, release on following Thursday (week +2days). New schedule will be proposed to FESCo * GA changes by one day later to November 8th. * Let RHEL Engineering know == Fedora Signing Server == * It is very clear to us that we need more than just me signing/pushing f7 updates however we also don't want to be giving more people the pass phrase to the gpg key. So we need some form of a signing server. * Draft spec for the signing server by f13 is here: http://fedoraproject.org/wiki/JesseKeating/SigningServerSpecDraft * f13 is requesting input on the spec (from those that haven't given it to me already) * make what is there more official * use it to evaluate some existing code (not open source yet) to determine if it's worth the up front cost of open sourcing it vs writing our own. Decision: None at this time == perl-devel in build roots == * perl-devel in the minimal build root was supposed to be a short term "hack" for getting Fedora 7 out the door, to be removed for Fedora 8. It is still there. * it is scheduled for removal today Decision: removal of 'perl-devel' from minimal build roots is put on hold until a final vote comes out of Fedora Packaging Committee and ratified by FESCo == image composes in the colo == * talk with mike/infrastructure and get things set so that we can do Official (tm) tree/live image composes on hardware in the colo (hosted data center) Decision: topic added to next weeks meeting using this week to determine where we are for accomplishing this goal. From mcepl at redhat.com Tue Jul 3 16:16:22 2007 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 03 Jul 2007 18:16:22 +0200 Subject: Finding man files: CVS or RPM repositories? References: <200707021141.31212.vpivaini@cs.helsinki.fi> <4688BD8B.9010608@hhs.nl> <1183477056.7419.272.camel@erato.phig.org> Message-ID: On Tue, 03 Jul 2007 08:37:36 -0700, Karsten Wade scripst: > Fortunately, the point of Ville-Pekka's project is to provide a Wiki > (Moin) interface in front of the man pages, then a way to submit changes > back up stream. > > In the end, we'll be inviting the whole Fedora community to help fix man > pages, all via the Wiki. Can we get rid of troff in this process as well, and switch to Docbook XML (IIRC Solaris has already done this)? It's 21st century now. ;-) Mat?j From sundaram at fedoraproject.org Tue Jul 3 16:32:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 22:02:27 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> <468A7654.4040600@fedoraproject.org> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> Message-ID: <468A7A1B.1060602@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> Contact https://fedoraproject.org/wiki/ThomasCanniot > > I had CC'ed him in the previous mail. :-) > I only see Jeremy on the CC list. Rahul From poelstra at redhat.com Tue Jul 3 16:34:47 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 03 Jul 2007 09:34:47 -0700 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468A46C8.4040600@fedoraproject.org> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> Message-ID: <468A7AA7.6030700@redhat.com> Rahul Sundaram said the following on 07/03/2007 05:53 AM Pacific Time: > Valent Turkovic wrote: >> I saw a post for Fedora 8 theme called infinity and it just clicked! >> One of Fedora 8 codenames to consider is Infinity. Why? Because number >> 8 rotated in 90 degrees shows infinity. Simple and clear message. >> >> just my 2c >> >> ps. it is so obvious that probably somebody all ready posted this :) > > Codenames aren't decided like this. > > http://www.redhat.com/magazine/024oct06/features/rh_speaks/ > > See > Why does Fedora wait until the last minute to assign the name for a release? Why not name it up front? I didn't see that discussed in the article. Also looked here: http://fedoraproject.org/wiki/ReleaseEngineering/Overview#head-e9609316ab3f0c5957229f75546a1cd8d9535dcc Thanks, John From debarshi.ray at gmail.com Tue Jul 3 16:35:39 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 3 Jul 2007 22:05:39 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468A7A1B.1060602@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> <468A7654.4040600@fedoraproject.org> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> Message-ID: <3170f42f0707030935k559547c2tae2666cff778516c@mail.gmail.com> > I only see Jeremy on the CC list. Here is a portion of the mail's header. :-) Message-ID: <3170f42f0707030904w2b194fbcm43a13f48e02c403 at mail.gmail.com> Date: Tue, 3 Jul 2007 21:34:33 +0530 From: "Debarshi 'Rishi' Ray" Reply-To: debarshi.ray at gmail.com To: "Development discussions related to Fedora Core" Subject: Re: Pirut: Edit -> Repositories Cc: "Jeremy Katz" , "Sankarshan Mukhopadhyay" , splinux at fedoraproject.org, mrtom at fedoraproject.org Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Tue Jul 3 16:37:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 22:07:51 +0530 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468A7AA7.6030700@redhat.com> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <468A7AA7.6030700@redhat.com> Message-ID: <468A7B5F.7080804@fedoraproject.org> John Poelstra wrote: > Rahul Sundaram said the following on 07/03/2007 05:53 AM Pacific Time: >> Valent Turkovic wrote: >>> I saw a post for Fedora 8 theme called infinity and it just clicked! >>> One of Fedora 8 codenames to consider is Infinity. Why? Because number >>> 8 rotated in 90 degrees shows infinity. Simple and clear message. >>> >>> just my 2c >>> >>> ps. it is so obvious that probably somebody all ready posted this :) >> >> Codenames aren't decided like this. >> >> http://www.redhat.com/magazine/024oct06/features/rh_speaks/ >> >> See >> > > Why does Fedora wait until the last minute to assign the name for a > release? Why not name it up front? I answered that when the question was asked by you in fedora-art list. Did you miss that or wanted to get answers from others too? https://www.redhat.com/archives/fedora-art-list/2007-July/msg00003.html Rahul From sundaram at fedoraproject.org Tue Jul 3 16:38:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 03 Jul 2007 22:08:57 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707030935k559547c2tae2666cff778516c@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> <468A7654.4040600@fedoraproject.org> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <3170f42f0707030935k559547c2tae2666cff778516c@mail.gmail.com> Message-ID: <468A7BA1.2000805@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> I only see Jeremy on the CC list. > > Here is a portion of the mail's header. :-) > Strange. Thunderbird only shows one CC. Rahul From nicolas.mailhot at laposte.net Tue Jul 3 16:41:16 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Jul 2007 18:41:16 +0200 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468A7AA7.6030700@redhat.com> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <468A7AA7.6030700@redhat.com> Message-ID: <1183480876.10418.1.camel@rousalka.dyndns.org> Le mardi 03 juillet 2007 ? 09:34 -0700, John Poelstra a ?crit : > Why does Fedora wait until the last minute to assign the name for a > release? Why not name it up front? I didn't see that discussed in the > article. Because traditionally getting to name a release is a reward for making it out of the door, and doing it before sort of defeats the purpose. -- 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 bpepple at fedoraproject.org Tue Jul 3 17:47:15 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 03 Jul 2007 13:47:15 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUL-02 In-Reply-To: <468A790F.7050204@redhat.com> References: <468A790F.7050204@redhat.com> Message-ID: <1183484835.2790.9.camel@kennedy> On Tue, 2007-07-03 at 09:27 -0700, John Poelstra wrote: > > == perl-devel in build roots == > * perl-devel in the minimal build root was supposed to be a short term "hack" for getting Fedora 7 out the door, to be removed for Fedora 8. It is still there. > * it is scheduled for removal today > Decision: removal of 'perl-devel' from minimal build roots is put on hold until a final vote comes out of Fedora Packaging Committee and ratified by FESCo Does it seem odd to anyone else that the FPC is driving this? To me this seems more like an issue that should be in FESCo. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 jkeating at redhat.com Tue Jul 3 17:55:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 13:55:53 -0400 Subject: Fedora Rel-Eng Meeting Recap 2007-JUL-02 In-Reply-To: <1183484835.2790.9.camel@kennedy> References: <468A790F.7050204@redhat.com> <1183484835.2790.9.camel@kennedy> Message-ID: <200707031355.53769.jkeating@redhat.com> On Tuesday 03 July 2007 13:47:15 Brian Pepple wrote: > Does it seem odd to anyone else that the FPC is driving this? ?To me > this seems more like an issue that should be in FESCo. FPC just punted to FESCo. All is well (: -- 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 Jul 3 18:30:43 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 3 Jul 2007 10:30:43 -0800 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183480876.10418.1.camel@rousalka.dyndns.org> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <468A7AA7.6030700@redhat.com> <1183480876.10418.1.camel@rousalka.dyndns.org> Message-ID: <604aa7910707031130q55b4b715j256276acd58a2f9e@mail.gmail.com> On 7/3/07, Nicolas Mailhot wrote: > Because traditionally getting to name a release is a reward for making > it out of the door, and doing it before sort of defeats the purpose. My gut feeling tells me that keeping the final codename unknown until nearly release time also marginally helps delineate laypress "reviews" of test releases from "reviews" of final releases. If the codename was set early in the testing phase..or even before it.. we would undoubtedly see "articles" using the codename in association with a test release in a manner which would lead to audience confusion. I get a special sort of warm feeling when people stumble into test2 era reviews, post release day, and assume they are still relevant. It's such a special feeling that I'd hate to cheapen its specialness by doing anything that would make it mundane and common. -jef From kevin at scrye.com Tue Jul 3 18:41:00 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 3 Jul 2007 12:41:00 -0600 Subject: rsyslog in f8? Message-ID: <20070703124100.2e704168@ghistelwchlohm.scrye.com> Greetings. The rsyslog package has been approved and is ready to enter the collection. I just thought I would ask if anyone has any issues or concerns with switching to rsyslog for default system logger in f8? See: http://fedoraproject.org/wiki/Releases/FeatureRsyslog and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243831 Would it be helpfull to get it pushed out for f7/devel without any Obsoletes first so folks can test it? Or should we just replace sysklogd in devel right off? Note that if FESCo approves the features policy, it would be up to them to approve or ack this feature, I'm just asking if anyone has any gotchas or issues we should look at before it's added. thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jul 3 18:46:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 14:46:08 -0400 Subject: rsyslog in f8? In-Reply-To: <20070703124100.2e704168@ghistelwchlohm.scrye.com> References: <20070703124100.2e704168@ghistelwchlohm.scrye.com> Message-ID: <200707031446.09235.jkeating@redhat.com> On Tuesday 03 July 2007 14:41:00 Kevin Fenzi wrote: > The rsyslog package has been approved and is ready to enter the > collection. I just thought I would ask if anyone has any issues or > concerns with switching to rsyslog for default system logger in f8? > > See: > > http://fedoraproject.org/wiki/Releases/FeatureRsyslog > and > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243831 > > Would it be helpfull to get it pushed out for f7/devel without any > Obsoletes first so folks can test it? Or should we just replace > sysklogd in devel right off? Instead of looking at this as a 'new default logger', perhaps it would be better to look at this as a 'rsyslogd is obsoleting sysklogd'. Think of it purely within the scope of one package is replacing the other, due to things like sysklogd being dead upstream. In that context, we can do the replacement now and be happy. It's a different subject as to if we want to "switch the default logger" or perhaps "switch to different logging options by default", and that could use some discussion with various folks. However that is an aside to the pure technical thing of rsyslogd is replacing sysklogd. -- 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 poelstra at redhat.com Tue Jul 3 19:40:49 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 03 Jul 2007 12:40:49 -0700 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468A7B5F.7080804@fedoraproject.org> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <468A7AA7.6030700@redhat.com> <468A7B5F.7080804@fedoraproject.org> Message-ID: <468AA641.8080107@redhat.com> Rahul Sundaram said the following on 07/03/2007 09:37 AM Pacific Time: > I answered that when the question was asked by you in fedora-art list. > Did you miss that or wanted to get answers from others too? > > https://www.redhat.com/archives/fedora-art-list/2007-July/msg00003.html > > Rahul > It appears I did :) Sorry, it appears my InboxZero foo has gotten too strong. http://www.43folders.com/2006/03/14/delete/ From kwhiskerz at yahoo.ca Tue Jul 3 19:43:54 2007 From: kwhiskerz at yahoo.ca (kwhiskerz) Date: Tue, 3 Jul 2007 13:43:54 -0600 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 Message-ID: <200707031343.54452.kwhiskerz@yahoo.ca> I am definitely opposed to the inclusion of such nuisance programs like Beagle and ilk (google desktop has slipped into Sun Java and Adobe Flash, I think, unless a custom install is chosen - or was that only in Windows?). My last experience with Beagle was not good. Huge use of CPU, like 100% frequently throughout the day, the indexing of personal material, like my personal journal, recording of sites I have visited and having them indexed, even if they were of no interest to me, simply because a search machine presented them as a possibility, taking up lots of space on my drive, huge risk of breech of confidentiality and privacy, etc. No, no, no! From Lam at Lam.pl Tue Jul 3 20:21:45 2007 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 03 Jul 2007 22:21:45 +0200 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183470207.31613.15.camel@cutter> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> Message-ID: <1183494105.12007.4.camel@pensja.lam.pl> > well, we would need to get from moonshine to infinity My observation is that with enough moonshine, people approach infinity quite quick (generally: infinite wisdom, infinite strength). Too bad Zod wanted infinite power :) 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 greno at verizon.net Tue Jul 3 20:29:30 2007 From: greno at verizon.net (Gerry Reno) Date: Tue, 03 Jul 2007 16:29:30 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183494105.12007.4.camel@pensja.lam.pl> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> Message-ID: <468AB1AA.2060400@verizon.net> Leszek Matok wrote: >> well, we would need to get from moonshine to infinity >> > My observation is that with enough moonshine, people approach infinity > quite quick (generally: infinite wisdom, infinite strength). Too bad Zod > wanted infinite power :) > > Lam > Or as Buzz Lightyear would say, "To infinity, and beyond!" From vpivaini at cs.helsinki.fi Tue Jul 3 20:55:04 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 3 Jul 2007 23:55:04 +0300 Subject: Finding man files: CVS or RPM repositories? In-Reply-To: References: <200707021141.31212.vpivaini@cs.helsinki.fi> <1183477056.7419.272.camel@erato.phig.org> Message-ID: <200707032355.09494.vpivaini@cs.helsinki.fi> Matej Cepl kirjoitti viestiss??n (l?hetysaika tiistai, 3. hein?kuu 2007 19:16:22): > On Tue, 03 Jul 2007 08:37:36 -0700, Karsten Wade scripst: > > Fortunately, the point of Ville-Pekka's project is to provide a Wiki > > (Moin) interface in front of the man pages, then a way to submit changes > > back up stream. > > > > In the end, we'll be inviting the whole Fedora community to help fix man > > pages, all via the Wiki. > > Can we get rid of troff in this process as well, and switch to Docbook > XML (IIRC Solaris has already done this)? It's 21st century now. ;-) > > Mat?j For the first phase of my project, publication of man pages, I'm using only DocBook XML already. The man pages are converted to DocBook with doclifter and Moin can display DocBook XML as "normal-looking" wiki pages. The editing part seems to be somewhat of a problem. The end users should be able to edit the man pages with wiki markup, since DocBook XML might be a bit difficult and scary for someone who sees it for the first time. So far the idea is to convert troff into wiki markup for user editing and then export DocBook XML from the wiki markup. That XML could then be again converted to "anything" the upstream projects need. But the point is, how can we make sure that this troff -> wiki -> docbook -> troff (or something else) series of conversions doesn't lose any information? -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Tue Jul 3 21:14:21 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 3 Jul 2007 21:14:21 +0000 (UTC) Subject: Plan for Today's (20070702) Release Engineering meeting References: <200707021253.35881.jkeating@redhat.com> <4689388C.807@hhs.nl> <468939A5.2000802@ioa.s.u-tokyo.ac.jp> <200707021350.28962.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > If we had the automatic promotion of upgrades feature, the maintainer could > have set a timeout and had it happen automatically unless they (or somebody > else) stopped it. But aside from that nobody else should be able to promote > it behind the maintainer's back. But can the system please send nagmails to the maintainers automatically, let's say once a week? Manually adding a comment to every single update which has been in testing for weeks (I only start at 2 weeks, but that's only because there are way too many 1-week-old updates, I'd suggest starting at 1 week for the automatic nags) starts getting old pretty quickly. Kevin Kofler From jkeating at redhat.com Tue Jul 3 21:20:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Jul 2007 17:20:07 -0400 Subject: Plan for Today's (20070702) Release Engineering meeting In-Reply-To: References: <200707021253.35881.jkeating@redhat.com> <200707021350.28962.jkeating@redhat.com> Message-ID: <200707031720.08435.jkeating@redhat.com> On Tuesday 03 July 2007 17:14:21 Kevin Kofler wrote: > But can the system please send nagmails to the maintainers automatically, > let's say once a week? Manually adding a comment to every single update > which has been in testing for weeks (I only start at 2 weeks, but that's > only because there are way too many 1-week-old updates, I'd suggest > starting at 1 week for the automatic nags) starts getting old pretty > quickly. As stated earlier (maybe even in this thread) that's already on the feature list, and Luke may have already implemented it in the development code. If not, I'm sure he'd be happy to see patches. -- 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 debarshi.ray at gmail.com Tue Jul 3 21:54:08 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 03:24:08 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468A7BA1.2000805@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> <468A7654.4040600@fedoraproject.org> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <3170f42f0707030935k559547c2tae2666cff778516c@mail.gmail.com> <468A7BA1.2000805@fedoraproject.org> Message-ID: <3170f42f0707031454r190bbad8u1ba5dc4965633ee@mail.gmail.com> >>> I only see Jeremy on the CC list. >> Here is a portion of the mail's header. :-) > Strange. Thunderbird only shows one CC. Might be a bug. :-) Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From lsof at nodata.co.uk Tue Jul 3 22:12:24 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 04 Jul 2007 00:12:24 +0200 Subject: rsyslog in f8? In-Reply-To: <20070703124100.2e704168@ghistelwchlohm.scrye.com> References: <20070703124100.2e704168@ghistelwchlohm.scrye.com> Message-ID: <1183500744.5894.2.camel@sb-home> Am Dienstag, den 03.07.2007, 12:41 -0600 schrieb Kevin Fenzi: > Greetings. > > The rsyslog package has been approved and is ready to enter the > collection. I just thought I would ask if anyone has any issues or > concerns with switching to rsyslog for default system logger in f8? > > See: > > http://fedoraproject.org/wiki/Releases/FeatureRsyslog > and > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243831 > > Would it be helpfull to get it pushed out for f7/devel without any > Obsoletes first so folks can test it? Or should we just replace > sysklogd in devel right off? > > Note that if FESCo approves the features policy, it would be up to them > to approve or ack this feature, I'm just asking if anyone has any > gotchas or issues we should look at before it's added. > > thanks, > > kevin > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Does rsyslog support store and forward logging? Like a good version of sysklogd's centalised host logging, but with an unlimited buffer size (i.e. store-to-file until acknowledged or okayed by central log server, then truncate file). From alain.portal at free.fr Tue Jul 3 22:30:58 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Wed, 4 Jul 2007 00:30:58 +0200 Subject: Pirut: Edit -> Repositories In-Reply-To: <468A7A1B.1060602@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> Message-ID: <200707040030.58814.alain.portal@free.fr> Le mardi 03 juillet 2007, Rahul Sundaram a ?crit : > Debarshi 'Rishi' Ray wrote: > >> Contact https://fedoraproject.org/wiki/ThomasCanniot > > > > I had CC'ed him in the previous mail. :-) > > I only see Jeremy on the CC list. I confirm, using kmail. Regards Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From snecklifter at gmail.com Tue Jul 3 22:45:15 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 3 Jul 2007 23:45:15 +0100 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <468AB1AA.2060400@verizon.net> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> <468AB1AA.2060400@verizon.net> Message-ID: <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> On 03/07/07, Gerry Reno wrote: > > > Or as Buzz Lightyear would say, "To infinity, and beyond!" > Debian have already stamped their mark on all things Toy Story. So, to get from Moonshine to Infinity: Moonshine is frequently distilled in radiators. A radiator's prime function is to transfer thermal energy. Thermal energy is the difference between the internal energy of an object and the energy it would possess at absolute zero and the peak emittance wavelength of black-body radiation shifts to infinity at absolute zero. Ta-da! Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Tue Jul 3 22:48:02 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 03 Jul 2007 18:48:02 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> <468AB1AA.2060400@verizon.net> <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> Message-ID: <1183502882.31613.65.camel@cutter> On Tue, 2007-07-03 at 23:45 +0100, Chris Brown wrote: > On 03/07/07, Gerry Reno wrote: > > Or as Buzz Lightyear would say, "To infinity, and beyond!" > > Debian have already stamped their mark on all things Toy Story. > > So, to get from Moonshine to Infinity: > > Moonshine is frequently distilled in radiators. > A radiator's prime function is to transfer thermal energy. > Thermal energy is the difference between the internal energy of an > object and the energy it would possess at absolute zero and the peak > emittance wavelength of black-body radiation shifts to infinity at > absolute zero. > by 'get to' we mean: moonshine is an example/member of X inifinity is an example/member of X so your example above doesn't work. -sv From ssorce at redhat.com Tue Jul 3 22:56:26 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 03 Jul 2007 18:56:26 -0400 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183502882.31613.65.camel@cutter> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> <468AB1AA.2060400@verizon.net> <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> <1183502882.31613.65.camel@cutter> Message-ID: <1183503386.16302.13.camel@localhost.localdomain> On Tue, 2007-07-03 at 18:48 -0400, seth vidal wrote: > On Tue, 2007-07-03 at 23:45 +0100, Chris Brown wrote: > > On 03/07/07, Gerry Reno wrote: > > > > Or as Buzz Lightyear would say, "To infinity, and beyond!" > > > > Debian have already stamped their mark on all things Toy Story. > > > > So, to get from Moonshine to Infinity: > > > > Moonshine is frequently distilled in radiators. > > A radiator's prime function is to transfer thermal energy. > > Thermal energy is the difference between the internal energy of an > > object and the energy it would possess at absolute zero and the peak > > emittance wavelength of black-body radiation shifts to infinity at > > absolute zero. > > > > by 'get to' we mean: > > moonshine is an example/member of X > inifinity is an example/member of X > > so your example above doesn't work. Search for "moonshine infinity" in google, you'll find it :-) Simo. From snecklifter at gmail.com Tue Jul 3 23:13:44 2007 From: snecklifter at gmail.com (Chris Brown) Date: Wed, 4 Jul 2007 00:13:44 +0100 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183502882.31613.65.camel@cutter> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> <468AB1AA.2060400@verizon.net> <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> <1183502882.31613.65.camel@cutter> Message-ID: <364d303b0707031613h65066c4aiaf3b5b3257404afa@mail.gmail.com> On 03/07/07, seth vidal wrote: > > On Tue, 2007-07-03 at 23:45 +0100, Chris Brown wrote: > > On 03/07/07, Gerry Reno wrote: > > > > Or as Buzz Lightyear would say, "To infinity, and beyond!" > > > > Debian have already stamped their mark on all things Toy Story. > > > > So, to get from Moonshine to Infinity: > > > > Moonshine is frequently distilled in radiators. > > A radiator's prime function is to transfer thermal energy. > > Thermal energy is the difference between the internal energy of an > > object and the energy it would possess at absolute zero and the peak > > emittance wavelength of black-body radiation shifts to infinity at > > absolute zero. > > > > by 'get to' we mean: > > moonshine is an example/member of X > inifinity is an example/member of X > > so your example above doesn't work. Ah, didn't understand the rules. Okay, how about: "They both have tin in" /me wanders off to find something more productive to do... -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bojan at rexursive.com Wed Jul 4 00:15:20 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 4 Jul 2007 00:15:20 +0000 (UTC) Subject: Fedora Rel-Eng Meeting Recap 2007-JUL-02 References: <468A790F.7050204@redhat.com> Message-ID: John Poelstra redhat.com> writes: > * Draft spec for the signing server by f13 is here: http://fedoraproject.org/wiki/JesseKeating/SigningServerSpecDraft Just one comment here, regarding the draft itself. The Fedora Account System would be used for authentication, which makes sense, but a single compromised account may mean trojaned packages. I know, not very likely (Or is it? Do we force password complexity on folks? Mandatory password changes?), but better be paranoid... Would it be possible to organise that multiple authorised users have to approve the package for signing before it actually gets signed? That way there are at least some checks and balances in the system. -- Bojan From notting at redhat.com Wed Jul 4 01:09:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Jul 2007 21:09:39 -0400 Subject: Parallel Booting In-Reply-To: <20070625164435.GB19608@nostromo.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> Message-ID: <20070704010938.GA9335@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > - where are the benchmarks? What's the actual gain? Not seeing any other benchmarks, I decided to test this. Fairly standard box - P4, ata_piix, 1G memory. Stock desktop install, fully up to date with updates and updates-testing as of this afternoon. A 'normal' boot to gdm is about 56.9 seconds. I installed prcsys, and edited the startup scripts to add LSB dependencies as attached. I then booted with prcsys and parallel init. The new boot time was... 56.3 and 56.6 seconds. So, for all this work, we get a 0.6%-1.1% speedup. Oh, and we get 62 AVCs from SELinux in the process. What's the point of this again? > - how would this be useful for the case where facilities that are provided > are determined at runtime (say, NetworkManager providing $network instead > of /etc/init.d/network, or $remote_fs being provided by either rc.sysinit > or /etc/init.d/netfs, depending on configuration). Similarly, you may > want a meta-dependency for 'authorization available', which would be > at different times depending on whether or not you're using local > passwords, KRB5, etc. > - does this work with dbus system activation? I also don't see how it handles either of these. Bill From notting at redhat.com Wed Jul 4 01:28:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Jul 2007 21:28:07 -0400 Subject: Parallel Booting In-Reply-To: <20070704010938.GA9335@nostromo.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> Message-ID: <20070704012807.GA9687@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Bill Nottingham (notting at redhat.com) said: > > - where are the benchmarks? What's the actual gain? > > Not seeing any other benchmarks, I decided to test this. > > Fairly standard box - P4, ata_piix, 1G memory. Stock desktop install, fully > up to date with updates and updates-testing as of this afternoon. > > A 'normal' boot to gdm is about 56.9 seconds. I installed > prcsys, and edited the startup scripts to add LSB dependencies > as attached. Oops, changes attached. Bill -------------- next part -------------- S00microcode_ctl:# Required-Start: $local_fs S04readahead_early:# Required-Start: $local_fs S05kudzu:# Required-Start: $local_fs S06cpuspeed:# Required-Start: $local_fs S08ip6tables:# Required-Start: $syslog S08iptables:# Required-Start: $syslog S10network:# Required-Start: $syslog iptables ip6tables S11auditd:# Required-Start: $syslog $local_fs S12restorecond:# Required-Start: $local_fs S12syslog:# Required-Start: S13irqbalance:# Required-Start: $local_fs S13mcstrans:# Required-Start: $local_fs S13rpcbind:# Required-Start: $local_fs S13setroubleshoot:# Required-Start: $network $local_fs S14nfslock:# Required-Start: $network rpcbind S15mdmonitor:# Required-Start: sendmail $network $local_fs S18rpcidmapd:# Required-Start: rpcbind $network S19rpcgssd:# Required-Start: rpcbind $network S22messagebus:# Required-Start: $local_fs $syslog S25bluetooth:# Required-Start: $network $local_fs S25netfs:# Required-Start: $network nfslock S25pcscd:# Required-Start: $local_fs $syslog S26hidd:# Required-Start: $local_fs $network S28autofs:# Required-Start: $network $local_fs S50hplip:# Required-Start: $local_fs S55cups:# Required-Start: $network $local_fs S55sshd:# Required-Start: $network $syslog $local_fs S80sendmail:# Required-Start: $network $named $local_fs S90ConsoleKit:# Required-Start: messagebus haldaemon S90crond:# Required-Start: $syslog $local_fs S90xfs:# Required-Start: $local_fs S95anacron:# Required-Start: $local_fs S95atd:# Required-Start: $syslog $local_fs S97dhcdbd:# Required-Start: messagebus S97yum-updatesd:# Required-Start: $network $local_fs $named messagebus S98avahi-daemon:# Required-Start: $network S98haldaemon:# Required-Start: messagebus S99smartd:# Required-Start: $local_fs From bojan at rexursive.com Wed Jul 4 02:32:33 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 4 Jul 2007 02:32:33 +0000 (UTC) Subject: Parallel Booting References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> Message-ID: Bill Nottingham redhat.com> writes: > So, for all this work, we get a 0.6%-1.1% speedup. Oh, and we get > 62 AVCs from SELinux in the process. What's the point of this again? Yeah, not very useful it would seem... What happened to this? http://fedoraproject.org/wiki/FCNewInit/xdm Is it being worked on? (Yeah, I know - I should probably not ask questions, but submit patches :-) >From a desktop users' point of view, the "magic" thing is the login screen. By the time they type in/pick the username and password, other stuff would have already started in the background, but the "boot time" would appear shorter. Isn't that the trick used on Windaz boxes as well? -- Bojan From fedora at leemhuis.info Wed Jul 4 04:46:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jul 2007 06:46:13 +0200 Subject: Thursday releases (was Re: Fedora Rel-Eng Meeting Recap 2007-JUL-02) In-Reply-To: <468A790F.7050204@redhat.com> References: <468A790F.7050204@redhat.com> Message-ID: <468B2615.2010603@leemhuis.info> On 03.07.2007 18:27, John Poelstra wrote: > [...] > == Fedora 8 Schedule Adjustments == > * Freeze dates do not line up on the correct week days > * Supposed to be freezes on Tuesdays, and target the next Thursday (one week +2 days) for release Just wondering: Why target a Thursday as release date? With the "Don't release on Fridays, Weekends and Mondays" approach that we had in the past (and likely still have?) we would have to slip five days if there is a important bug found in the last minute that requires to respin and slip one day. CU thl From tla at rasmil.dk Wed Jul 4 04:51:50 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 04 Jul 2007 06:51:50 +0200 Subject: Pirut: Edit -> Repositories In-Reply-To: <468A5BEF.40309@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> Message-ID: <468B2766.5000908@rasmil.dk> Rahul Sundaram wrote: > Tim Lauridsen wrote: > >>> >> Sounds like a good idea, the config write routine in yum will remove >> all the # comment lines and mix all the options. >> I fixed the mixing in system-config-repo by building a extra layer on >> the yum config API, but it don't take care off the # comments. >> I would be a good idea to teach yum to save config files, without >> losing information. > > This might be a good time to rethink whether Pirut and YumEx should be > merged together. Recent YumEx changes have made it look more and more > like Pirut and Pirut is started to grow more features similar to > YumEx. Looks like they are converging to me. Any reasons not to merge? > > Rahul > I purposed it a couple of times to Jeremy, most of the things pirut and yumex does, is the same, installing package groups and find and install/remove selected packages. there are both build on the top of the yum api, but there is some differences. pirut tries to be more simple, with the same look as the package selection as in anaconda. Yumex add more advanced features like selecting what repositories to use and also it is more verbose (I like to see what is going on ) and i have tried to made it as responsive as possible. (I have done some ugly threaded stuff to update gui). A merge would be fine to me, but it is mostly about where we want to go with the package manager in Fedora, do we want a simple tools or do we want tools with lot of possibilities for the more advanced user. Tim From tla at rasmil.dk Wed Jul 4 04:58:30 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 04 Jul 2007 06:58:30 +0200 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <3170f42f0707030904w2b194fbcm43a13f48e02c403@mail.gmail.com> Message-ID: <468B28F6.70706@rasmil.dk> Debarshi 'Rishi' Ray wrote: > https://fedoraproject.org/wiki/Usability/Objectives/Pirut > > There are some designs already available on the above link. Can I have > a look at the source code used to create them? > > Thanks, > Debarshi All the code for selecting repositories to use you can find in yumex. http://svn.sourceforge.net/viewvc/yumex/trunk/yumex/src/ Tim From valent.turkovic at gmail.com Wed Jul 4 05:52:41 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jul 2007 07:52:41 +0200 Subject: how do I continue using rawhide? In-Reply-To: References: <64b14b300707030713u544280b4x6aec929f2ac2751a@mail.gmail.com> Message-ID: <64b14b300707032252h252d86ffne330ee7eaa0a9f97@mail.gmail.com> On 7/3/07, dragoran wrote: > > > On 7/3/07, Valent Turkovic wrote: > > I had fedora 7 test 4 (rawhide) installed. When Fedora 7 was released > > my yum repositories updated them selves to official Fedora 7 yum > > repos. > > > > How do I continue using rawhide? Are this now FC8 rpms? > > > > This all is really confusing for me so please clarify it for me or > > just point me in the right direction with a few wiki links or some > > articles. > > yum --enablerepo=development update > This worked. Thank you. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From paul at all-the-johnsons.co.uk Wed Jul 4 06:52:53 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 04 Jul 2007 07:52:53 +0100 Subject: Realtek 8185 wireless card Message-ID: <1183531973.13139.3.camel@T7.Linux> Hi, Is there an out the box driver for the realtek 8185 wireless chipset available under rawhide or do I need to use ndiswrapper and some other magic to get it working? If I need to use ndiswrapper, is there a way to automate it being found on boot up so neither I nor my partner have to mess with anything? (I don't mind messing, but she's an Windows bod and doesn't like messing with things incase she screws everything up - she still doesn't get that the only thing she can mess up is her home area - bless ;-p) 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 valent.turkovic at gmail.com Wed Jul 4 07:10:45 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jul 2007 09:10:45 +0200 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <1183503386.16302.13.camel@localhost.localdomain> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> <468AB1AA.2060400@verizon.net> <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> <1183502882.31613.65.camel@cutter> <1183503386.16302.13.camel@localhost.localdomain> Message-ID: <64b14b300707040010v5ba2c5ebo8f75774575db4228@mail.gmail.com> On 7/4/07, Simo Sorce wrote: > On Tue, 2007-07-03 at 18:48 -0400, seth vidal wrote: > > On Tue, 2007-07-03 at 23:45 +0100, Chris Brown wrote: > > > On 03/07/07, Gerry Reno wrote: > > > > > > Or as Buzz Lightyear would say, "To infinity, and beyond!" > > > > > > Debian have already stamped their mark on all things Toy Story. > > > > > > So, to get from Moonshine to Infinity: > > > > > > Moonshine is frequently distilled in radiators. > > > A radiator's prime function is to transfer thermal energy. > > > Thermal energy is the difference between the internal energy of an > > > object and the energy it would possess at absolute zero and the peak > > > emittance wavelength of black-body radiation shifts to infinity at > > > absolute zero. > > > > > > > by 'get to' we mean: > > > > moonshine is an example/member of X > > inifinity is an example/member of X > > > > so your example above doesn't work. > > Search for "moonshine infinity" in google, you'll find it :-) > > Simo. Lost in the moonshine's infinity... I love it :) and we all ready have a soundtrack to go with it :) google is a smart beast :) -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jul 4 07:17:56 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jul 2007 09:17:56 +0200 Subject: Fedora 8 codename suggestion: Infinity In-Reply-To: <64b14b300707040010v5ba2c5ebo8f75774575db4228@mail.gmail.com> References: <64b14b300707030550w2d30f07em899bf5977a0b4b59@mail.gmail.com> <468A46C8.4040600@fedoraproject.org> <20070703132916.GA8077@jadzia.bu.edu> <1183470207.31613.15.camel@cutter> <1183494105.12007.4.camel@pensja.lam.pl> <468AB1AA.2060400@verizon.net> <364d303b0707031545h735a0f57ne69a1162cfc33bfd@mail.gmail.com> <1183502882.31613.65.camel@cutter> <1183503386.16302.13.camel@localhost.localdomain> <64b14b300707040010v5ba2c5ebo8f75774575db4228@mail.gmail.com> Message-ID: <64b14b300707040017r763fa840hf6420aa34c78c7c0@mail.gmail.com> > Lost in the moonshine's infinity... I love it :) and we all ready have > a soundtrack to go with it :) google is a smart beast :) here is the soundtrack :) http://www.djtunes.com/player.php?mode=bundle&bundle=10111&track=50587&startOnTrack=2 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jul 4 07:31:45 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 09:31:45 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <200707031343.54452.kwhiskerz@yahoo.ca> References: <200707031343.54452.kwhiskerz@yahoo.ca> Message-ID: <1183534305.5484.9.camel@fedora> On Tue, 2007-07-03 at 13:43 -0600, kwhiskerz wrote: > I am definitely opposed to the inclusion of such nuisance programs > like Beagle > and ilk (google desktop has slipped into Sun Java and Adobe Flash, I > think, > unless a custom install is chosen - or was that only in Windows?). > > My last experience with Beagle was not good. Huge use of CPU, like > 100% > frequently throughout the day, the indexing of personal material, like > my > personal journal, recording of sites I have visited and having them > indexed, > even if they were of no interest to me, simply because a search > machine > presented them as a possibility, taking up lots of space on my drive, > huge > risk of breech of confidentiality and privacy, etc. > > No, no, no! Yes, yes, yes! Do you actually know how beagle project works? beagne is not google desktop! it doesn't upload any information from your desktop to any server! Please make yourself more acquainted with the project before going off and saying such nonsenses! Did you take the time to report back your issues with beagle? I have issues with firefox taking 100% of my CPU, chould it also be removed from default install? And what does beagle have to do with windows?!? Or you are referring to Microsoft making you install IE by default on windows and other peaces of software that you can't choose not to install? From j.w.r.degoede at hhs.nl Wed Jul 4 07:59:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 04 Jul 2007 09:59:58 +0200 Subject: Massive size increases in certain packages In-Reply-To: <1179763650.3547.92.camel@enki.eridu> References: <464CBCA2.8050500@cora.nwra.com> <464D607E.1050307@hhs.nl> <464DD1E2.5080900@cora.nwra.com> <464DE424.6080407@hhs.nl> <1179514701.26613.35.camel@localhost.localdomain> <1179762016.3547.91.camel@enki.eridu> <1179763650.3547.92.camel@enki.eridu> Message-ID: <468B537E.8000101@hhs.nl> Paul Nasrat wrote: > On Mon, 2007-05-21 at 18:00 +0200, Goede, J.W.R. de wrote: > >> Well, >> >> I can confirm that this does NOT work properly on a recent >> rawhide system. >> >> Maybe the problem is that I exclude dirs, and that the size >> calculation still dives into the dir, and doesn't see the >> files in there as excluded? > > Yeah that seems to be the case, can you come up with a simple test spec > reproducer and file in bugzilla please. > > Paul > > Hi Paul, Sometime ago we had the above discussion, should I still BZ this, ifso in which BZ, RH or rpm.org? Regards, Hans From valent.turkovic at gmail.com Wed Jul 4 08:08:29 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 10:08:29 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> Message-ID: <1183536509.5484.39.camel@fedora> On Tue, 2007-07-03 at 16:05 +0100, Chris Brown wrote: > Hello Valent, > > On 02/07/07, Valent Turkovic wrote: > > * NTFS support during installation > > +1 > > > * Beagle and Deskbar installed by default > > I'm afraid I also experience a RAM-rinsing with this installed. Google > Desktop, recently released under a proprietary license, is even > buggier. I have had it running for three days now and it has yet to > complete its indexing. /me remembers its beta. Hopefully this app > along with others like tracker will make the beagle team sort out the > issues above - I think they may have been resting on their laurels a > little. On my system it consumes around 20MB or RAM. Is that a waste? I don't thin so. So what if Google desktop for linux uses around 10MB, beagle is much more integrated with linux desktop. I hope beagle gets to 10MB as soon as possible, but 20MB is not that bad for the benefit of desktop search it gives. My Firefox currently uses 152MB on my system with lost of tabs open, Evolution 38MB, Azureus 75MB on a good day and around 150MB when it gets going... OpenOffice Writer 38MB... and so on... > * Tomboy installed by default > > Personally, I have never found the need for yellow stickies on my > desktop. > > > * Firefox to have it's original icon in gnome panel > > I can only guess this is a licensing issue a-la-iceweasel. > > > * Desktop shortcut for joining Fedora IRC (aka "Get Live > Help") > > +1 although should this need a specific support channel? > > > * Desktop folder with examples of what "this linux thing" can > do :) > > +1 - I do not think that the default homepage in firefox is enough. > > > * a working Burning app for Fedora Gnome desktop > > I have no problems burning in fedora - what exactly is the issue you > have here? > > > Regards > Chris > > > > -- > http://www.chruz.com > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From valent.turkovic at gmail.com Wed Jul 4 08:12:14 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 10:12:14 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> Message-ID: <1183536734.5484.44.camel@fedora> > * Firefox to have it's original icon in gnome panel > > I can only guess this is a licensing issue a-la-iceweasel. Nope. Firefox icon is present on firefox shortcut in gnome menu. > > * Desktop shortcut for joining Fedora IRC (aka "Get Live > Help") > > +1 although should this need a specific support channel? I think so too. > * Desktop folder with examples of what "this linux thing" can > do :) > > +1 - I do not think that the default homepage in firefox is enough. Completely agree. > * a working Burning app for Fedora Gnome desktop > > I have no problems burning in fedora - what exactly is the issue you > have here? I don't know anybody in Croatia that uses windows default app to burn disks. It was mentioned that gnome burning is modeled by default MS windows burning app. Everybody here uses Nero Burning Rom, or at least 80% of windows users. Maybe that is a local thing, but I believe that it is also the case in the rest of the Europe and the US. One thing also that I have observed is that users don't insert blank cd/dvd first. First thing they do is to look for the burning app, compile the list of files for burning and only then they insert bland cd or dvd. If you have some other experience with new users please share it with us. It is easy to test this. Put some folder on the desktop and say to your coworker, sister, brother or a friend to burn it to a blank CD and watch what they do. Did you test for do this? I did and this is my experience. That is why we need a better and more usable way to burn data under fedora gnome desktop. From valent.turkovic at gmail.com Wed Jul 4 08:26:31 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 10:26:31 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183476038.3063.20.camel@dawkins> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> <1183476038.3063.20.camel@dawkins> Message-ID: <1183537591.5484.51.camel@fedora> On Tue, 2007-07-03 at 17:20 +0200, David Nielsen wrote: > Upstream Beagle already has a great guide to helping you, help them > spot > problem areas, I would suggest reading that. I'll check that out. > I think Beagles biggest problem is that it's not really useful, it's > not > integrated anywhere, it's just a search service right now. Places like > your media player e.g. could have their database populated in a > dynamic > manner using technology like Beagle but currently they don't. Can you please explain how would that work in a little more detail? I get great benefit from beagle searching my mail, web pages and local documents... how would I benefit from beagle integration to amarok or audacious or some other player I use? I don't see what beagle would do there so please explain. > Even if we > enabled Beagle by default we would not gain a lot and it's still > suffering from a number of issues (such as not even surviving 5 secs > on > Development currently). I have tested and proved it works great on development, see here for more details: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245521 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 From valent.turkovic at gmail.com Wed Jul 4 08:28:24 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 10:28:24 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A5B41.4040106@kanarip.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> <468A5B41.4040106@kanarip.com> Message-ID: <1183537704.5484.53.camel@fedora> On Tue, 2007-07-03 at 16:20 +0200, Jeroen van Meeuwen wrote: > Turning evil on your (potential) userbase doesn't help anybody either. I'm just a fedora user, I don't have a userbase, yet :) I'm not a beagle devel, just one concerned fedora desktop user. From emmanuel.seyman at club-internet.fr Wed Jul 4 08:52:12 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 4 Jul 2007 10:52:12 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183536734.5484.44.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> Message-ID: <20070704085212.GA11680@orient.maison.lan> * Valent Turkovic [04/07/2007 10:45] : > > > * Firefox to have it's original icon in gnome panel > > > > I can only guess this is a licensing issue a-la-iceweasel. > > Nope. Firefox icon is present on firefox shortcut in gnome menu. The Firefox icon in the menu launches firefox. The Web browser icon in the gnome panel lauches htmlview which in turn launches whatever your favourite web browser is (the default is firefox but that's easily changed) so I'm not sure changing the icon is justified. Emmanuel From sundaram at fedoraproject.org Wed Jul 4 09:11:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 14:41:40 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468B2766.5000908@rasmil.dk> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> Message-ID: <468B644C.1020507@fedoraproject.org> Tim Lauridsen wrote: >> > I purposed it a couple of times to Jeremy, most of the things pirut and > yumex does, is the same, installing package groups and find and > install/remove selected packages. there are both build on the top of the > yum api, but there is some differences. > pirut tries to be more simple, with the same look as the package > selection as in anaconda. > Yumex add more advanced features like selecting what repositories to use > and also it is more verbose (I like to see what is going on ) and i have > tried to made it as responsive as possible. (I have done some ugly > threaded stuff to update gui). > A merge would be fine to me, but it is mostly about where we want to go > with the package manager in Fedora, do we want a simple tools or do we > want tools with lot of possibilities for the more advanced user. Well I understand the original arguments against it which I have been supportive of but it looks like the tools are converging. Whatever advanced features are in Yumex end up being requested against Pirut. I would say there is more value in merging together now. Rahul From sankarshan.mukhopadhyay at gmail.com Wed Jul 4 09:28:54 2007 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Wed, 04 Jul 2007 14:58:54 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468B2766.5000908@rasmil.dk> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> Message-ID: <468B6856.4090007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Lauridsen wrote: > A merge would be fine to me, but it is mostly about where we want to go > with the package manager in Fedora, do we want a simple tools or do we > want tools with lot of possibilities for the more advanced user. Simplicity is a desirable goal and rightly one should strive for it, the question remains would a merged tool ie an extended/improved/feature rich Pirut or a Yumex with possible extensions serve the ends ? And of course, would at the end the choice will boil down to a single tool ? :Sankarshan - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGi2hWXQZpNTcrCzMRAkA/AJsEO9NNzMc6t/a9amletwzdJL2w8QCgsjkG ZlaSONjHY+psIucye+FOB14= =1vsx -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Wed Jul 4 10:02:26 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 12:02:26 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A5FF6.6030108@gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5FF6.6030108@gmail.com> Message-ID: <1183543346.5484.56.camel@fedora> On Tue, 2007-07-03 at 16:40 +0200, Alphonse Van Assche wrote: > I you will see beagle slowdown your whole system. Just place some big > pdf files in a directory and index it, you will see pdf2html or so > take > the whole CPU time and you Desktop entirely no usable without killing > these processes. I was really happy to no have to yum remove \*beagle > \* > on F7. I tested it and here are the results: http://www.youtube.com/watch?v=b8P_X8UK2fQ You can see that pdf file of 5MB does start to use CPU at 100% but it has high nice value so it doesn't slow down my desktop. I believe this is not a bug, but a feature :) From valent.turkovic at gmail.com Wed Jul 4 10:03:23 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 12:03:23 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A52B3.4090501@verizon.net> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> Message-ID: <1183543403.5484.58.camel@fedora> On Tue, 2007-07-03 at 09:44 -0400, Gerry Reno wrote: > Hi Valent, > I have to agree with the decision to drop beagle as default. On my > desktop I have many thousands of files and documents that I would > like > beagle to catalog but it was consuming huge amount of system resource > when it was running trying to do this. At first I didn't know why > things were so sluggish and then 'top' showed beagle consuming > everything. 'beagle' needs to get some intelligent throttling and > perhaps just some bugs fixed before I'll try it again. > > Gerry Please check out this video: http://www.youtube.com/watch?v=b8P_X8UK2fQ From valent.turkovic at gmail.com Wed Jul 4 10:04:43 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 12:04:43 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A5E40.4090002@verizon.net> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <64b14b300707030705o4b41844w701e2f22293461b6@mail.gmail.com> <468A5E40.4090002@verizon.net> Message-ID: <1183543483.5484.60.camel@fedora> On Tue, 2007-07-03 at 10:33 -0400, Gerry Reno wrote: > Valent, > Respectfully, I contribute a great deal of my deal to probably > 30-40 > open source community projects. Please do not be offended, but I > have > little interest in 'beagle'. It's a nice-to-have but also a > I-really-don't-miss-it if it's not there. The problems that I had > with > beagle on desktops occurred on nearly every desktop that we had where > it > was running. So this is not just isolated to my files or to some > particular file that I have. And many other people have had exactly > the > same experience so for those of you who are interested in working > with > beagle I would think it would be easy to develop a test data set of > files that exhibits the problem and work from there. > > Regards, > Gerry Gerry thank you for your valuable reply. From d.lesca at solinos.it Wed Jul 4 10:08:43 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Wed, 04 Jul 2007 12:08:43 +0200 Subject: [Fwd: F7: Howto monitoring a Hardware sata raid controller] Message-ID: <1183543723.5223.29.camel@lesca.home.solinos.it> Hi, why I have not obtained answers to my message? I have perhaps offend someone? I have formulate the question bad? (my english is bad, sorry) It is OT for this list? In this ML none know about my question? This problem is a lot important for me ... Please someone can tell to me somethings ? Many thanks! ------- Messaggio inoltrato ------- > Da: Dario Lesca > Rispondi-a: For users of Fedora > A: Fedora Project List > Oggetto: F7: Howto monitoring a Hardware sata raid controller > Data: Mon, 02 Jul 2007 19:03:56 +0200 > > Hi, I have a Server HP with this controller RAID: > > 00:1f.2 RAID bus controller: Intel Corporation 82801GR/GH (ICH7 Family) > SATA RAID Controller (rev 01) > > I have configure the 2 disk in hardware RAID-1 mode (F7 can manage this > controller raid). > > Fedora use this modules: > # cat /etc/modprobe.conf > alias eth0 tg3 > alias eth1 tg3 > alias scsi_hostadapter ahci > alias scsi_hostadapter1 ata_piix > > All work great, but the disk (and controller) do not warn if a disk is > break (or hot-remove), until I reboot the server. > > It's possible to monitoring the state of RAID controller via software? > > Someone can point me on right way? > This is my smolt ID: > > http://smolt.fedoraproject.org/show?UUID=b5f5c6b3-26d4-4577-ae2e-89e5fcc33175 > > -- > Many thanks... > > -- > Dario Lesca > -- Dario Lesca From valent.turkovic at gmail.com Wed Jul 4 10:08:41 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 12:08:41 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468A5FE8.3070707@kanarip.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5ABF.1050801@kanarip.com> <468A5FE8.3070707@kanarip.com> Message-ID: <1183543721.5484.64.camel@fedora> On Tue, 2007-07-03 at 16:40 +0200, Jeroen van Meeuwen wrote: > Replying to myself, I see my ~/rpmbuild (which I /happily/ use as an > archive) is being indexed with: > > /usr/lib/rpm/rpmq -q --package --queryformat [%{*:xml}?] /path/to/rpm > > Apparently it's threaded, because this one happily consuming 100% CPU, > happily locking up my funky beryl desktop. Then it seems beagle-helper > catches some output because it gets too excited and happily consumes > like 20% CPU next to the 100-20% CPU being consumed by the other happy > process. > > Thanks for the reminder, sometime in the future I'll try again. Please look at this video: http://www.youtube.com/watch?v=b8P_X8UK2fQ is the use-case you are having really a bug? Beagle has to index files in order to make desktop search possible. Every process that actually does something uses 100% of the cpu - only issue is how well it plays with the desktiop. Beagle should be running a high NICE so it shouldn't impact your desktop experience while it indexes files... To me your experience with beagle just shows that beagle is working and it doesn't show that beagle is buggy and kills your system. From valent.turkovic at gmail.com Wed Jul 4 10:13:47 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 12:13:47 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <20070704085212.GA11680@orient.maison.lan> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> Message-ID: <1183544027.5484.67.camel@fedora> On Wed, 2007-07-04 at 10:52 +0200, Emmanuel Seyman wrote: > The Firefox icon in the menu launches firefox. > > The Web browser icon in the gnome panel lauches htmlview which in turn > launches whatever your favourite web browser is (the default is > firefox > but that's easily changed) so I'm not sure changing the icon is > justified. > > Emmanuel I understand you and see your logic, but can you also see how this confuses users? I believe that when default browsing app changes so should the icon. Starting a default browser app is like a roulet - you see an icon but you place bets before clicking it and then see what app starts after you click it. It should be unambiguous which apps starts from just looking at the icon. If it is firefox it should be firefox icon, if it is other some other browser that the icon should be also changer to it's default icon. From nicu_fedora at nicubunu.ro Wed Jul 4 10:22:29 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 04 Jul 2007 13:22:29 +0300 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183544027.5484.67.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> Message-ID: <468B74E5.10207@nicubunu.ro> Valent Turkovic wrote: > > Starting a default browser app is like a roulet - you see an icon but > you place bets before clicking it and then see what app starts after you Not at all, after a default install the icon will start Firefox and this does not change until you go to change the default manually (or unistall Firefox, if that was possible, but isn't) > click it. It should be unambiguous which apps starts from just looking > at the icon. If it is firefox it should be firefox icon, if it is other It is unambiguous: the default web browser is launched. This is a task-oriented philosophy instead of application-oriented. In the same vein, the menu option titled "Word Processor" will launch OOo Writer and Movie Player will launch Totem, it is not a discrimination against Firefox. > some other browser that the icon should be also changer to it's default > icon. Keeping up with your YouTube links: http://fedora.nicubunu.ro/firefox_panel.gif -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From buildsys at redhat.com Wed Jul 4 10:25:22 2007 From: buildsys at redhat.com (Build System) Date: Wed, 4 Jul 2007 06:25:22 -0400 Subject: rawhide report: 20070704 changes Message-ID: <200707041025.l64APMTb014716@porkchop.devel.redhat.com> New package dtc Device Tree Compiler New package gnome-launch-box Funky application launcher New package mrxvt A lightweight multi-tabbed terminal emulator for X New package msmtp SMTP client New package php-spyc A simple php yaml class New package sofia-sip Sofia SIP User-Agent library New package stardict-dic-en English(en) dictionaries for StarDict New package uread Utilities for unformatted fortran files Updated Packages: MySQL-python-1.2.2-3.fc8 ------------------------ * Tue Jul 03 2007 Tom Lane 1.2.2-3 - Ooops, previous fix for quoting bug was wrong, because it converted the version_info tuple to a string in Python's eyes Resolves: #246366 anthy-9100-1.fc8 ---------------- * Tue Jul 03 2007 Akira TAGOH - 9100-1 - New upstream release. * Wed Jun 13 2007 Akira TAGOH - 9011-1 - New upstream release apr-util-1.2.8-8 ---------------- * Tue Jul 03 2007 Joe Orton 1.2.8-8 - add fix for attribute namespace handling in apr_xml (PR 41908) at-3.1.10-12.fc8 ---------------- * Tue Jul 03 2007 Marcela Maslanova - 3.1.10-12 - crashing atd - work only for root, still broken some functions - Resolves: rhbz#243064 claws-mail-2.10.0-1.fc8 ----------------------- * Tue Jul 03 2007 Andreas Bierfert - 2.10.0-1 - version upgrade - fix #246230 * Tue May 15 2007 Andreas Bierfert 2.9.2-1 - version upgrade * Sat Apr 21 2007 Andreas Bierfert 2.9.1-1 - version upgrade which fixes CVE-2007-1558 (see #237293) fwbackups-1.43.0-0.2.rc3.fc7 ---------------------------- * Wed Jun 20 2007 Stewart Adam 1.43.0-0.2.rc3 - Update to 1.43.0 rc3 (see CHANGELOG file for details on version changes) gnupg2-2.0.4-1.fc7 ------------------ * Fri May 18 2007 Rex Dieter 2.0.4-1 - gnupg-2.0.4 gnuplot-4.2.0-2.fc8 ------------------- * Tue Jul 03 2007 Ivana Varekova - 4.2.0-2 - Resolves: #246316 remove info-look.20.{2,3}.el groff-1.18.1.4-5.fc8 -------------------- * Mon Jul 02 2007 Marcela Maslanova - 1.18.1.4-5 - Resolves: rhbz#245934 * Tue Feb 27 2007 Marcela Maslanova - 1.18.1.4-4 - merge review - rhbz#225859 review initscripts-8.54.1-1 -------------------- * Mon Jun 25 2007 Bill Nottingham 8.54.1-1 - netfs: check for rpcbind, not portmap (#245595) kbd-1.12-23.fc8 --------------- * Tue Jul 03 2007 Vitezslav Crhonek - 1.12-23 - Rebuilt * Tue Jul 03 2007 Vitezslav Crhonek - 1.12-22 - Fix sun12x22 font missing unicode mapping table Resolves: #244628 kernel-2.6.22-0.5.rc7.git2.fc8 ------------------------------ * Tue Jul 03 2007 Dave Jones - Update to latest utrace. (just diff changes, no code changes) * Tue Jul 03 2007 Dave Jones - 2.6.22-rc7-git2 * Tue Jul 03 2007 Dave Jones - 2.6.22-rc7-git2 ktorrent-2.2-1.fc8 ------------------ * Tue Jul 03 2007 Roland Wolters 2.2-1 - update to upstream 2.2: - cleaner UI - - New file selection dialog - Statistics plugin with pretty graphs - Possibility to open as many tabs as you want - Diskspace monitoring and stopping of downloads when the diskspace drops below a certain value - Individual torrent speed limits - Full disk preallocation to avoid fragmentation * Wed Jun 13 2007 Roland Wolters 2.2rc1-1 - update to upstream 2.2rc1 * Fri Mar 09 2007 Roland Wolters 2.1.2-2 - update to upstream 2.1.2 liferea-1.2.19-2.fc8 -------------------- * Tue Jul 03 2007 Brian Pepple - 1.2.19-2 - Bump. mantis-1.0.8-1.fc8 ------------------ * Tue Jul 03 2007 Gianluca Sforna - 1.0.8-1 - new upstream release - add Require: php-adodb (and remove embedded one) - remove duplicate docs mdadm-2.6.2-2.fc8 ----------------- * Mon Jul 02 2007 Doug Ledford - 2.6.2-2 - Fix a file leak issue when mdadm is in monitor mode - Update mdadm init script so that status will always run and so return codes are standards compliant - Fix assembly of version 1 superblock devices - Make the attempt to create an already running device have a clearer error message - Allow the creation of a degraded raid4 array like we allow for raid5 - Make mdadm actually pay attention to raid4 devices when in monitor mode - Make the mdmonitor script use daemon() correctly - Fix a bug where manage mode would not add disks correctly under certain conditions - Resolves: bz244582, bz242688, bz230207, bz169596, bz171862, bz171938 - Resolves: bz174642, bz224272, bz186524 mysql++-2.3.0-1.fc8 ------------------- * Tue Jul 03 2007 Remi Collet 2.3.0-1 - update to 2.3.0 perl-BSD-Resource-1.28-2.fc8 ---------------------------- * Sat Jun 30 2007 Steven Pritchard 1.28-2 - Fix find option order. - Use fixperms macro instead of our own chmod incantation. - Remove check macro cruft. - Remove redundant BR perl. - BR ExtUtils::MakeMaker, Test::More, Test::Pod, and Test::Pod::Coverage. - Patch t/setrlimit.t to fix bogus test failure. - Set OPTIMIZE when running Makefile.PL, not make. * Wed Jul 12 2006 Jesse Keating - 1.28-1.fc6.1 - rebuild * Mon Jun 05 2006 Jason Vas Dias - 1.28-1 - upgrade to upstream version 1.28 perl-Bit-Vector-6.4-3.fc8 ------------------------- * Sat Jun 30 2007 Steven Pritchard 6.4-3 - Fix find option order. - Use fixperms macro instead of our own chmod incantation. - Remove check macro cruft. - Improve Summary. - Remove redundant perl build dependency. - BR ExtUtils::MakeMaker. - Set OPTIMIZE when we run Makefile.PL, not make. - BR perl(Carp::Clan) instead of perl-Carp-Clan. - Remove redundant Carp::Clan dependency. - Filter unversioned Provides: perl(Bit::Vector) * Wed Jul 12 2006 Jesse Keating - 6.4-2.2.2.1 - rebuild * Fri Feb 10 2006 Jesse Keating - 6.4-2.2.2 - bump again for double-long bug on ppc(64) perl-RPM-Specfile-1.51-4.fc8 ---------------------------- * Tue Jul 03 2007 Robin Norwood 1.51-4 - Fix issues reported by Steven in package review. - Untabify spec file. - Escape macro in changelog perl-YAML-Tiny-1.12-1.fc8 ------------------------- * Fri Jun 08 2007 Steven Pritchard 1.12-1 - Update to 1.12. perl-version-1:0.7203-1.fc8.1 ----------------------------- * Tue Jul 03 2007 Tom "spot" Callaway 1:0.7203-1.1 - add BR: Test::More * Tue Jul 03 2007 Tom "spot" Callaway 1:0.7203-1 - i love perl versioning. bumping to 0.7203 pygtksourceview-1.90.1-3.fc8 ---------------------------- quagga-0:0.99.7-1.fc8 --------------------- * Tue Jul 03 2007 Martin Bacovsky - 0.99.7-1 - upgrade to new upstream 0.99.7 - resolves: #240488: CVE-2007-1995 Quagga bgpd DoS roundcubemail-0.1-0.6rc1.1.fc8 ------------------------------ * Tue Jul 03 2007 Jon Ciesla = 0.1-0.6rc1.1 - New upstream release, all GPL, all current languages included. selinux-policy-3.0.2-1.fc8 -------------------------- system-config-language-1.2.4-1.fc8 ---------------------------------- * Tue Jul 03 2007 Lingning Zhang - 1.2.4 - fix bug241747 and bug246578. taarich-1.20051120-7.fc8 ------------------------ * Tue Jul 03 2007 Dan Kenigsberg 1.20051120-7 - change spec encoding to UTF8 (bug 246580) taskjuggler-2.4.0-2.fc8 ----------------------- * Tue Jul 03 2007 Ondrej Vasik - 2.4.0-2 - new tarball from upstream(previous had one blocker included) tkdnd-1.0a2-8.fc8 ----------------- * Tue Jul 03 2007 Sander Hoentjen - 1.0a2-8 - Move to tcl_sitearch udev-113-2.fc8 -------------- * Wed Jun 27 2007 Harald Hoyer - 113-2 - added more firewire symlinks (#240770) - minor rule patches wammu-0.19-3.fc8 ---------------- wine-0.9.40-1.fc8 ----------------- * Tue Jul 03 2007 Andreas Bierfert - 0.9.40-1 - version upgrade * Mon Jun 18 2007 Andreas Bierfert - 0.9.39-2 - fix desktop entries xmoto-0.3.0-1.fc8 ----------------- * Wed Jun 20 2007 Jon Ciesla 0.3.0-1 - Bumped to upstream. * Mon Mar 19 2007 Jon Ciesla 0.2.7-1 - Bumped to upstream, fixed man issues. * Fri Mar 16 2007 Jon Ciesla 0.2.6-2 - Bumped release, build mistake. xmoto-edit-0.2.4-8.fc8 ---------------------- * Tue Jul 03 2007 Jon Ciesla 0.2.4-8 - Fixed BZ 246572. xorg-x11-drv-i810-2.1.0-1.fc8 ----------------------------- * Tue Jul 03 2007 Adam Jackson 2.1.0-1 - xf86-video-intel 2.1.0. xorg-x11-drv-nv-2.1.1-1.fc8 --------------------------- * Tue Jul 03 2007 Adam Jackson 2.1.1-1 - xf86-video-nv 2.1.1. Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kernel - 2.6.22-0.5.rc7.git2.fc8.i686 requires mkinitrd >= 0:6.0.9-7.1 kernel-PAE - 2.6.22-0.5.rc7.git2.fc8.i686 requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-Bit-Vector - 6.4-3.fc8.i386 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.i386 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.i386 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kernel - 2.6.22-0.5.rc7.git2.fc8.x86_64 requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Bit-Vector - 6.4-3.fc8.x86_64 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.x86_64 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.x86_64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kernel - 2.6.22-0.5.rc7.git2.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel - 2.6.22-0.5.rc7.git2.fc8.ppc requires mkinitrd >= 0:6.0.9-7.1 kernel-kdump - 2.6.22-0.5.rc7.git2.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel-smp - 2.6.22-0.5.rc7.git2.fc8.ppc requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Bit-Vector - 6.4-3.fc8.ppc requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.ppc requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.ppc requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kernel - 2.6.22-0.5.rc7.git2.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel-kdump - 2.6.22-0.5.rc7.git2.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) perl-Bit-Vector - 6.4-3.fc8.ppc64 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.ppc64 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) rpy - 0.4.6-16.fc7.ppc64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From valent.turkovic at gmail.com Wed Jul 4 10:41:09 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 4 Jul 2007 12:41:09 +0200 Subject: a legal way to include 3rd party repositories in fedora? Message-ID: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> I understand all about why it is not possible for fedora not to include codecs and non-gpl software. Also I understand that directly linking from Fedora or an official Fedora website to http://rpm.livna.org is considered "contributory infingement" But if it there was a gpl package in fedora (something like fedora helper[1]) that prompted you to enable it only if you are in a county in which it is legal to do so, and then presents a disclaimer that says that it is unlegal to enable this program for linking to 3rd party repost if you are in the US and if you do so Fedora/Red Hat are not held responsible. Would this make it legal for Fedora to include such package and distribute it? This way fedora is not directly linking to 3rd party repos. Cam somebody (preferably Red Hat lawyers or somebody close to them) explain this "contributory infingement" thing. Was there a such discussion where Red Hat lawyers actually explained what can and can't be done? If it was is it somewhere on the record for review? [1] http://www.brandonhutchinson.com/Fedora_Helper.html -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From debarshi.ray at gmail.com Wed Jul 4 10:45:06 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 16:15:06 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468B644C.1020507@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B644C.1020507@fedoraproject.org> Message-ID: <3170f42f0707040345w1fcbd8aexe2eb6a64adbc6320@mail.gmail.com> > Well I understand the original arguments against it which I have been > supportive of but it looks like the tools are converging. Whatever > advanced features are in Yumex end up being requested against Pirut. By "it" you refer to Yumex? What were the arguments? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From rc040203 at freenet.de Wed Jul 4 11:04:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Jul 2007 13:04:24 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> Message-ID: <1183547065.23976.382.camel@mccallum.corsepiu.local> On Wed, 2007-07-04 at 12:41 +0200, Valent Turkovic wrote: > I understand all about why it is not possible for fedora not to > include codecs and non-gpl software. This understanding is incorrect. It is not possible for Fedora to include SW * which would violate applicable laws (E.g. US patent laws) * whose licenses impose restrictions which violate Fedora's policies on OSS. This does NOT mean it is NOT possible to ship non-GPL'ed SW nor codecs as part of Fedora. Ralf From laurent.rineau__fedora at normalesup.org Wed Jul 4 11:15:51 2007 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Wed, 4 Jul 2007 13:15:51 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183543721.5484.64.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <468A5FE8.3070707@kanarip.com> <1183543721.5484.64.camel@fedora> Message-ID: <200707041315.51788@rineau.tsetse> On Wednesday 04 July 2007 12:08:41 Valent Turkovic wrote: > On Tue, 2007-07-03 at 16:40 +0200, Jeroen van Meeuwen wrote: > > Replying to myself, I see my ~/rpmbuild (which I /happily/ use as an > > archive) is being indexed with: > > > > /usr/lib/rpm/rpmq -q --package --queryformat [%{*:xml}?] /path/to/rpm > > > > Apparently it's threaded, because this one happily consuming 100% CPU, > > happily locking up my funky beryl desktop. Then it seems beagle-helper > > catches some output because it gets too excited and happily consumes > > like 20% CPU next to the 100-20% CPU being consumed by the other happy > > process. > > > > Thanks for the reminder, sometime in the future I'll try again. > > Please look at this video: > http://www.youtube.com/watch?v=b8P_X8UK2fQ > > is the use-case you are having really a bug? Beagle has to index files > in order to make desktop search possible. Every process that actually > does something uses 100% of the cpu - only issue is how well it plays > with the desktiop. Beagle should be running a high NICE so it shouldn't > impact your desktop experience while it indexes files... > To me your experience with beagle just shows that beagle is working and > it doesn't show that beagle is buggy and kills your system. Exhibiting one case where does things nicely is not a justification. On my desktop, Beagle is regularly browsing my files. I am not even sure that is has indexed all my documents, even if I am using it for six months. I regularly (about once a week) need to trigger beagle-shutdown when my load is high, even though the beagle daemon has nice=19. You can blame the kernel scheduler, perhaps. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From sundaram at fedoraproject.org Wed Jul 4 11:17:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 16:47:48 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707040345w1fcbd8aexe2eb6a64adbc6320@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B644C.1020507@fedoraproject.org> <3170f42f0707040345w1fcbd8aexe2eb6a64adbc6320@mail.gmail.com> Message-ID: <468B81DC.1060002@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> Well I understand the original arguments against it which I have been >> supportive of but it looks like the tools are converging. Whatever >> advanced features are in Yumex end up being requested against Pirut. > > By "it" you refer to Yumex? What were the arguments? I am referring to merging yumex and pirut. The arguments against that was already described by Tim Lauridsen. Rahul From giallu at gmail.com Wed Jul 4 11:31:41 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 4 Jul 2007 13:31:41 +0200 Subject: rawhide report: 20070704 changes In-Reply-To: <200707041025.l64APMTb014716@porkchop.devel.redhat.com> References: <200707041025.l64APMTb014716@porkchop.devel.redhat.com> Message-ID: On 7/4/07, Build System wrote: > > kernel-2.6.22-0.5.rc7.git2.fc8 > ------------------------------ wow... kernel now follows naming guidelines? From pbrobinson at gmail.com Wed Jul 4 11:41:28 2007 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 4 Jul 2007 12:41:28 +0100 Subject: rawhide report: 20070704 changes In-Reply-To: References: <200707041025.l64APMTb014716@porkchop.devel.redhat.com> Message-ID: <5256d0b0707040441r71bddce4i244feac4f0806456@mail.gmail.com> > > kernel-2.6.22-0.5.rc7.git2.fc8 > > ------------------------------ > > wow... kernel now follows naming guidelines? Yep. See Dave's blog post http://kernelslacker.livejournal.com/85363.html From kagesenshi.87 at gmail.com Wed Jul 4 12:32:57 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Wed, 4 Jul 2007 20:32:57 +0800 Subject: Pirut: Edit -> Repositories In-Reply-To: <468B6856.4090007@gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> Message-ID: On 7/4/07, Sankarshan Mukhopadhyay > > A merge would be fine to me, but it is mostly about where we want to go > > with the package manager in Fedora, do we want a simple tools or do we > > want tools with lot of possibilities for the more advanced user. > > Simplicity is a desirable goal and rightly one should strive for it, the > question remains would a merged tool ie an extended/improved/feature > rich Pirut or a Yumex with possible extensions serve the ends ? And of > course, would at the end the choice will boil down to a single tool ? +1 to a single tool for managing repos globally, rather than every apps have its own repo control, which is , IMHO, make stuff feels more complicated .. I like system-config-repo's and repoman's approach .. pirut just install/remove apps.. repoman/sysconfrepo for all-thing repository related .. and yumex for advanced users .. a textUI (eg: system-config-repo-tui) for enabling/disabling repos is also a nice thing to have .. it make it easier for writing automated scripts etc. (I had this problem before , enabling/disabling repos globally was a pain for a person who dont know much in manipulating strings in scripts like me - or maybe such app already exist but I dont know about it???) -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From christoph.wickert at nurfuerspam.de Wed Jul 4 12:49:44 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Wed, 04 Jul 2007 14:49:44 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> Message-ID: <1183553384.3677.47.camel@wicktop.localdomain> Am Montag, den 02.07.2007, 23:23 +0200 schrieb Valent Turkovic: > Hi, > [snipped] > > * NTFS support during installation > there should be NTFS support built in to anaconda so that ntfs > partitions are automatically recognized and added to /etc/fstab - and > that users are given an option to make them read-only or to be mounted > in read-write mode. How exactly should this happen? Another screen with questions like: "Do you want to mount your NTFS volumes? y/N" and "Do you want your NFTS volumes to be mounted read only? Y/n"? I don't think bothering people with more questions is necessary or useful. You already have the opportunity to configure NTFS mounts during install. Usually I tell anaconda/disc druid to mount my Windows partition to /mnt/windows. Now that we have ntfs-3g in default install, you have r/w access when you first boot your computer after install. For me this is enough. Personally I don't want partitions to be mounted automatically somewhere without being asked. I want control over my installation and I like to have a choice. > * Beagle and Deskbar installed by default > these applications make all the difference for an desktop user between > an "OK" user experience and "wonderful" user experience. This topic has already been beaten to death on this list before you raised it again. We did have beagle in the default install in FC6 and it was decided to take it out for F7. Please be so kind as to search the archives or at least read the Fedora Weekly News: http://fedoraproject.org/wiki/FWN/Issue88#head-7fdee0a1251926827abf631c707a2dadcb25ea10 BTW: If you speak German I suggest you search for beagle @ fedoraforum.de: 37 hits and 35 of them are complainants. > * Tomboy installed by default > - I have all the same arguments here as I do for Beagle and Deskbar deskbar and tomboy might be worth discussing, but I don't think many people are using them. So I'd say they should stay out. > * Desktop shortcut for joining Fedora IRC (aka "Get Live Help") Although this is a good idea I'm not sure how to achieve this technically: Yes, there is an IRC url scheme [1], but I'm not sure if all desktops are able to open IRC links. Other questions are: What application should be used to open this link and how to we make sure this application really is installed? > * Desktop folder with examples of what "this linux thing" can do :) Personally I hate "example" folders. "Example Pictures/Music/Playlists/Whatever" is the first thing I remove on a fresh installed Windows. > * a working Burning app for Fedora Gnome desktop > Put any new user in front of fresh Fedora 7 desktop and ask them to > burn some files to CD or DVD - any watch them as they wiggle > unpleasantly as they can't find any burning app under gnome desktop. > Puting a link for nautils burner under "Places / CD - DVD Recoder" > doesn't help. Really? I have been installing computers with fedora for a while now and giving them to my customers. _No_one_ has ever asked me how to burn CDs/DVDs. I have to admit that starting rhythmbox to burn audio discs is not really intuitive but it works. So IMO we shouldn't add duplicate functionality to the default install. Ok, that was just my 2 ? Christoph [1] http://www.w3.org/Addressing/draft-mirashi-url-irc-01.txt From alcapcom at gmail.com Wed Jul 4 13:12:46 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Wed, 04 Jul 2007 15:12:46 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183543346.5484.56.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5FF6.6030108@gmail.com> <1183543346.5484.56.camel@fedora> Message-ID: <468B9CCE.2010509@gmail.com> Valent Turkovic a ?crit : > On Tue, 2007-07-03 at 16:40 +0200, Alphonse Van Assche wrote: >> I you will see beagle slowdown your whole system. Just place some big >> pdf files in a directory and index it, you will see pdf2html or so >> take >> the whole CPU time and you Desktop entirely no usable without killing >> these processes. I was really happy to no have to yum remove \*beagle >> \* >> on F7. > > I tested it and here are the results: > http://www.youtube.com/watch?v=b8P_X8UK2fQ > > You can see that pdf file of 5MB does start to use CPU at 100% but it > has high nice value so it doesn't slow down my desktop. > I believe this is not a bug, but a feature :) > Sorry but your test is absolutely not correct. I have say *some* big pdf and the only pdf that you test is a text only pdf. In the real live many pdf contain images too. Another think that I have never understand is why beagle re-index always files that are already indexed. It was not in my dream that beagle was taking 100% of my CPU and make my system *totally* unusable and BTW I have never have so a problem when I build big RPM package that take 100% of the CPU. For example, when I build Xgl (a really big package) I can continue to browse, read mails with Thunderbird and coding in Eclipse on the other hand when beagle take 100% of the CPU I can difficultly open a gnome-terminal to kill him. If you are sure that everybody here say nothing true about beagle, It seems to me like a not constructive discuss and IMHO not the good way of doing if you will convince peoples here. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From valent.turkovic at gmail.com Wed Jul 4 13:17:56 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 15:17:56 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183553384.3677.47.camel@wicktop.localdomain> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183553384.3677.47.camel@wicktop.localdomain> Message-ID: <1183555076.5484.105.camel@fedora> On Wed, 2007-07-04 at 14:49 +0200, Christoph Wickert wrote: > How exactly should this happen? Another screen with questions like: > "Do > you want to mount your NTFS volumes? y/N" and "Do you want your NFTS > volumes to be mounted read only? Y/n"? I don't think bothering people > with more questions is necessary or useful. Offcource not. The devels can choose whic is technically better default (RO or RW) and only have an option in advanced mode to change it, or after the install of Fedora via some gui tool perhaps? > You already have the opportunity to configure NTFS mounts during > install. Usually I tell anaconda/disc druid to mount my Windows > partition to /mnt/windows. Now that we have ntfs-3g in default > install, > you have r/w access when you first boot your computer after install. Are you sure? I wouldn't be writing this if it worked. AFAIK you can't choose NTFS partitions in anaconda during the partitioning and give them mount points. NTFS partitons are grayed out and can't be even selected. If I'm wrong please correct me. > > * Beagle and Deskbar installed by default > > these applications make all the difference for an desktop user > between > > an "OK" user experience and "wonderful" user experience. > > This topic has already been beaten to death on this list before you > raised it again. We did have beagle in the default install in FC6 and > it > was decided to take it out for F7. Please be so kind as to search the > archives or at least read the Fedora Weekly News: > http://fedoraproject.org/wiki/FWN/Issue88#head-7fdee0a1251926827abf631c707a2dadcb25ea10 My point is that maintainer of the package said that he doesn't have time to work with this package and it is easier for him to remove it that look at some non-trivial problems. > BTW: If you speak German I suggest you search for beagle @ > fedoraforum.de: 37 hits and 35 of them are complainants. Well I would argue that the people who remove it are a minority, not the other way around. I have seen beagle installed on multiple systems and it is as unobtrusive as an app can be. I have tested it on Fedora Core6, multiple Fedora 7 installations and now I'm testing it on Rawhide. So I have extensive experience with beagle. Only saying "me too" to a forum, bugzilla entry or on a mailing list makes beagle look bad but only because the majority of people who don't have issues with beagle don't even go to these mailing lists or to bugzilla. If you have tested beagle on multiple systems and find it causing problems then please excuse me - show us your test results and that is ok. Has anybody of the 35 people on fedoraforum.de looked at the actual problem with beagle and saw where or why they have some issues? > > * Tomboy installed by default > > - I have all the same arguments here as I do for Beagle and Deskbar > > deskbar and tomboy might be worth discussing, but I don't think many > people are using them. So I'd say they should stay out. It depends what Fedora is trying to do. It if it is trying to be a linux Desktop and not only for us who are geeks then it should include nice apps by deafult - any maybe put some promo video material that explains what each app does. > > * Desktop shortcut for joining Fedora IRC (aka "Get Live Help") > > Although this is a good idea I'm not sure how to achieve this > technically: Yes, there is an IRC url scheme [1], but I'm not sure if > all desktops are able to open IRC links. Other questions are: What > application should be used to open this link and how to we make sure > this application really is installed? Why IRC url? It can be a shortcut to a script. At least there are multiple choices. Devels should make this choice, I trust them. Do you see some actual problem here? > > * Desktop folder with examples of what "this linux thing" can do :) > > Personally I hate "example" folders. "Example > Pictures/Music/Playlists/Whatever" is the first thing I remove on a > fresh installed Windows. Gnome also comes with these folders, I dislike them in Gnome also. You are confusing examples folders from windows and a much better example from Ubuntu example folder (and that is not in plural). If you haven't seen it please boot up any live ubuntu disc to see what it is all about. > > * a working Burning app for Fedora Gnome desktop > > Put any new user in front of fresh Fedora 7 desktop and ask them to > > burn some files to CD or DVD - any watch them as they wiggle > > unpleasantly as they can't find any burning app under gnome desktop. > > Puting a link for nautils burner under "Places / CD - DVD Recoder" > > doesn't help. > > Really? I have been installing computers with fedora for a while now > and > giving them to my customers. _No_one_ has ever asked me how to burn > CDs/DVDs. Do they burn discs? Do they even have burners? Do they even know they have a burning option? Have you asked your customer to burn a CD or a DVD and see what he/she does? Or you have had to teach them to use rhythmbox and gnome burning tool because they didn't know how to use it by them selves? > I have to admit that starting rhythmbox to burn audio discs is > not really intuitive but it works. And that is what I'm talking about! It has to be intuitive or it doesn't float. > So IMO we shouldn't add duplicate > functionality to the default install. There is no duplication if you add only a shortcut for gnome burner "burn:///" under gnome "Applications" menu instead of being only in "Places" menue - which is really not intuitive. From markg85 at gmail.com Wed Jul 4 13:19:27 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 15:19:27 +0200 Subject: Where did the Fedora 8 CVS go to? Message-ID: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> Hey, i was just about to donwload the latest kernel package but the CVS i know: http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=core isn't updated with the latest kernel.. it seems to be the latest F7 kernel (not even the latest). Some info: I have: kernel build 3194.fc7 That CVS has build: 3125 (older than what i have and mine was downloaded with normal updates) The kernel that is available for F8 (ftp://ftp.nluug.nl/pub/os/Linux/distr/fedora/linux/development/source/SRPMS/) is: 3244.f8 So now i wonder where the svn or cvs is with that kernel on it? or just the latest development files. Thanx, Mark. From oliver at linux-kernel.at Wed Jul 4 13:22:43 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 04 Jul 2007 15:22:43 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> Message-ID: <468B9F23.8000206@linux-kernel.at> On 07/04/2007 03:19 PM, Mark wrote: > Hey, > > i was just about to donwload the latest kernel package but the CVS i > know: > http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=core http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=extras Better look in extras repo :-) -of From markg85 at gmail.com Wed Jul 4 13:27:51 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 15:27:51 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <468B9F23.8000206@linux-kernel.at> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468B9F23.8000206@linux-kernel.at> Message-ID: <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> i thought they merged. guess that's not true for the CVS yet. Thanx for pointing me there. 2007/7/4, Oliver Falk : > On 07/04/2007 03:19 PM, Mark wrote: > > Hey, > > > > i was just about to donwload the latest kernel package but the CVS i > > know: > > http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=core > http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=extras > > Better look in extras repo :-) > > -of > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From opensource at till.name Wed Jul 4 13:31:52 2007 From: opensource at till.name (Till Maas) Date: Wed, 04 Jul 2007 15:31:52 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <468B9F23.8000206@linux-kernel.at> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468B9F23.8000206@linux-kernel.at> Message-ID: <200707041531.54941.opensource@till.name> On Mi Juli 4 2007, Oliver Falk wrote: > On 07/04/2007 03:19 PM, Mark wrote: > > Hey, > > > > i was just about to donwload the latest kernel package but the CVS i > > know: > > http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=core > > http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=extras > > Better look in extras repo :-) Extras in CVS is only an symlink(?) to pkgs, which is the official new CVS root: http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=pkgs Regards, Till From nicolas.mailhot at laposte.net Wed Jul 4 13:37:23 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 4 Jul 2007 15:37:23 +0200 (CEST) Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468B9F23.8000206@linux-kernel.at> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> Message-ID: <2294.192.54.193.51.1183556243.squirrel@rousalka.dyndns.org> Le Mer 4 juillet 2007 15:27, Mark a ?crit : > i thought they merged. > guess that's not true for the CVS yet. The merge target is the former extras cvs -- Nicolas Mailhot From opensource at till.name Wed Jul 4 13:44:55 2007 From: opensource at till.name (Till Maas) Date: Wed, 04 Jul 2007 15:44:55 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <2294.192.54.193.51.1183556243.squirrel@rousalka.dyndns.org> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> <2294.192.54.193.51.1183556243.squirrel@rousalka.dyndns.org> Message-ID: <200707041545.00111.opensource@till.name> On Mi Juli 4 2007, Nicolas Mailhot wrote: > Le Mer 4 juillet 2007 15:27, Mark a ?crit : > > i thought they merged. > > guess that's not true for the CVS yet. > > The merge target is the former extras cvs No, no, no, everything is in pkgs now. Regards, Till From sundaram at fedoraproject.org Wed Jul 4 13:46:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 19:16:38 +0530 Subject: rsyslog in f8? In-Reply-To: <20070703124100.2e704168@ghistelwchlohm.scrye.com> References: <20070703124100.2e704168@ghistelwchlohm.scrye.com> Message-ID: <468BA4BE.7020100@fedoraproject.org> Kevin Fenzi wrote: > Greetings. > > The rsyslog package has been approved and is ready to enter the > collection. I just thought I would ask if anyone has any issues or > concerns with switching to rsyslog for default system logger in f8? > > See: > > http://fedoraproject.org/wiki/Releases/FeatureRsyslog > and > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243831 > > Would it be helpfull to get it pushed out for f7/devel without any > Obsoletes first so folks can test it? Or should we just replace > sysklogd in devel right off? Would be better to push this into Fedora 7 too I think. Makes it easier to transition to a newer version. Rahul From sankarshan.mukhopadhyay at gmail.com Wed Jul 4 13:53:37 2007 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Wed, 04 Jul 2007 19:23:37 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> Message-ID: <468BA661.6070406@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hikaru Amano wrote: > +1 to a single tool for managing repos globally, rather than every > apps have its own repo control, which is , IMHO, make stuff feels more > complicated .. Umm...ok let me rephrase the query. Is this a move towards a single tool or is this a move towards a single way of handling repository information with multiple tools being able to access it and perhaps provide enhanced functionality. The second method does mean that the metadata required to be handle would perhaps require discussion - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGi6ZhXQZpNTcrCzMRAqV/AJ9S9GGvrnX8GYy/Ka1N+mcGCdZwwgCcDRGd bEYfYoTGXE33qXiKK67lqGo= =2hBT -----END PGP SIGNATURE----- From oliver at linux-kernel.at Wed Jul 4 13:50:47 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 04 Jul 2007 15:50:47 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468B9F23.8000206@linux-kernel.at> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> Message-ID: <468BA5B7.90007@linux-kernel.at> On 07/04/2007 03:27 PM, Mark wrote: > i thought they merged. it is. > guess that's not true for the CVS yet. it is merged, but under 'extras'. :-) > Thanx for pointing me there. no problem. From markg85 at gmail.com Wed Jul 4 13:57:58 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 15:57:58 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <468BA5B7.90007@linux-kernel.at> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468B9F23.8000206@linux-kernel.at> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> Message-ID: <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> and what is the cvs checkout line? lets take for example that i want to checkout the latest kernel. the documentation here is kinda outdated (Fedora Core 2 latest) http://cvs.fedora.redhat.com/docs.shtml. but the part where i'm losing it is here: CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/docs for the newest kernel this would mean?? tough gamble: viewcvs = http://cvs.fedora.redhat.com/viewcvs/devel/kernel/?root=extras CVSROOT=:pserver:anonymous at cvs.fedora.redhat.com:/cvs/devel/extras/kernel ?? Some documentation on this would be good :) 2007/7/4, Oliver Falk : > On 07/04/2007 03:27 PM, Mark wrote: > > i thought they merged. > > it is. > > > guess that's not true for the CVS yet. > > it is merged, but under 'extras'. :-) > > > Thanx for pointing me there. > > no problem. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From opensource at till.name Wed Jul 4 13:58:20 2007 From: opensource at till.name (Till Maas) Date: Wed, 04 Jul 2007 15:58:20 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <468BA5B7.90007@linux-kernel.at> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> Message-ID: <200707041558.22074.opensource@till.name> On Mi Juli 4 2007, Oliver Falk wrote: > it is merged, but under 'extras'. :-) It is merged under 'pkgs'! Regards, Till From oliver at linux-kernel.at Wed Jul 4 14:04:04 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 04 Jul 2007 16:04:04 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <200707041558.22074.opensource@till.name> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <200707041558.22074.opensource@till.name> Message-ID: <468BA8D4.2020300@linux-kernel.at> On 07/04/2007 03:58 PM, Till Maas wrote: > On Mi Juli 4 2007, Oliver Falk wrote: > >> it is merged, but under 'extras'. :-) > > It is merged under 'pkgs'! OOps. Did i send the link also with extras!? -of From valent.turkovic at gmail.com Wed Jul 4 14:05:43 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 16:05:43 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183547065.23976.382.camel@mccallum.corsepiu.local> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> Message-ID: <1183557943.5484.126.camel@fedora> On Wed, 2007-07-04 at 13:04 +0200, Ralf Corsepius wrote: > It is not possible for Fedora to include SW > * which would violate applicable laws (E.g. US patent laws) > * whose licenses impose restrictions which violate Fedora's policies > on OSS. Are your hands completely tied? I live and work by the moto "Where there is will there is a way." Meaning that when you want to do something you find a way to do so. So is this a case that Fedora Board and fedora devels don't see any importance to pursue this issue? I believe that if the decision was made to work this out, and if you put some of your smartest people to work on this together with lawyers that then a solution would be found. I understand that you have legal boundaries but there are legal mechanics that allow you to do some things even if that looks hard from your point of view. I'm not saying that you should just drop everything you are doing right now and focus all of your attention to solving this issue. I don't believe that is that crucial enough - but it would be nice if it was resolved. There are much important thing that Fedora needs and succeeds in doing with each new version. But you also have to be realistic and acknowledge that people can't use Fedora Desktop effectively with out at least few "forbidden fruits" :) So if users have a real need to use them it would be nice to make it as easy as possible for users that want "forbidden items" to use them themselves - of course considering your legal boundaries. > This does NOT mean it is NOT possible to ship non-GPL'ed SW nor codecs > as part of Fedora. Can you please expand on this just a bit? From opensource at till.name Wed Jul 4 14:05:11 2007 From: opensource at till.name (Till Maas) Date: Wed, 04 Jul 2007 16:05:11 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> Message-ID: <200707041605.17602.opensource@till.name> On Mi Juli 4 2007, Mark wrote: > and what is the cvs checkout line? > lets take for example that i want to checkout the latest kernel. > > the documentation here is kinda outdated (Fedora Core 2 latest) > http://cvs.fedora.redhat.com/docs.shtml. There is uptodate documentation in the wiki: http://fedoraproject.org/wiki/PackageMaintainers/CvsAccess The following commandline checks out the kernel cvs devel branch: $ CVSROOT=:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs cvs co rpms/kernel/devel Regards, Till From nicolas.mailhot at laposte.net Wed Jul 4 14:12:22 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 4 Jul 2007 16:12:22 +0200 (CEST) Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <468BA8D4.2020300@linux-kernel.at> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <6e24a8e80707040627tde2425csb4b4db2783acd40e@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <200707041558.22074.opensource@till.name> <468BA8D4.2020300@linux-kernel.at> Message-ID: <3168.192.54.193.51.1183558342.squirrel@rousalka.dyndns.org> Le Mer 4 juillet 2007 16:04, Oliver Falk a ?crit : > On 07/04/2007 03:58 PM, Till Maas wrote: >> On Mi Juli 4 2007, Oliver Falk wrote: >> >>> it is merged, but under 'extras'. :-) >> >> It is merged under 'pkgs'! > > OOps. Did i send the link also with extras!? pkgs will exist for normal users when it's documented on http://cvs.fedoraproject.org/ Till then "use extras" is the user-friendly answer. -- Nicolas Mailhot From rc040203 at freenet.de Wed Jul 4 14:12:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Jul 2007 16:12:57 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183557943.5484.126.camel@fedora> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: <1183558378.23976.400.camel@mccallum.corsepiu.local> On Wed, 2007-07-04 at 16:05 +0200, Valent Turkovic wrote: > On Wed, 2007-07-04 at 13:04 +0200, Ralf Corsepius wrote: > > It is not possible for Fedora to include SW > > * which would violate applicable laws (E.g. US patent laws) > > * whose licenses impose restrictions which violate Fedora's policies > > on OSS. > > Are your hands completely tied? Partially. Legal issues are dictated by laws. Policies can be changed but I don't expect anybody outside of RH will be able to change something about them. > I live and work by the moto "Where there is will there is a way." > Meaning that when you want to do something you find a way to do so. You mean, you know, somebody who sells heroine or plutonium, so you're going to package it for Fedora? ;) Ralf From kagesenshi.87 at gmail.com Wed Jul 4 14:14:02 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Wed, 4 Jul 2007 22:14:02 +0800 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183557943.5484.126.camel@fedora> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: On 7/4/07, Valent Turkovic wrote: > On Wed, 2007-07-04 at 13:04 +0200, Ralf Corsepius wrote: > > It is not possible for Fedora to include SW > > * which would violate applicable laws (E.g. US patent laws) > > * whose licenses impose restrictions which violate Fedora's policies > > on OSS. > > Are your hands completely tied? > > I live and work by the moto "Where there is will there is a way." > Meaning that when you want to do something you find a way to do so. > > So is this a case that Fedora Board and fedora devels don't see any > importance to pursue this issue? > > I believe that if the decision was made to work this out, and if you put > some of your smartest people to work on this together with lawyers that > then a solution would be found. > > I understand that you have legal boundaries but there are legal > mechanics that allow you to do some things even if that looks hard from > your point of view. > > I'm not saying that you should just drop everything you are doing right > now and focus all of your attention to solving this issue. I don't > believe that is that crucial enough - but it would be nice if it was > resolved. > > There are much important thing that Fedora needs and succeeds in doing > with each new version. > > But you also have to be realistic and acknowledge that people can't use > Fedora Desktop effectively with out at least few "forbidden fruits" :) > > So if users have a real need to use them it would be nice to make it as > easy as possible for users that want "forbidden items" to use them > themselves - of course considering your legal boundaries. > > > > > This does NOT mean it is NOT possible to ship non-GPL'ed SW nor codecs > > as part of Fedora. > > Can you please expand on this just a bit? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > yum install revisor add whatever 3rd party repo's config rpm into the kickstart release the generated CD/DVD .. just dont name it Fedora -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From markg85 at gmail.com Wed Jul 4 14:18:34 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 16:18:34 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <200707041605.17602.opensource@till.name> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> Message-ID: <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> so there it's hidden ^_^ thanx. 2007/7/4, Till Maas : > On Mi Juli 4 2007, Mark wrote: > > and what is the cvs checkout line? > > lets take for example that i want to checkout the latest kernel. > > > > the documentation here is kinda outdated (Fedora Core 2 latest) > > http://cvs.fedora.redhat.com/docs.shtml. > > There is uptodate documentation in the wiki: > > http://fedoraproject.org/wiki/PackageMaintainers/CvsAccess > > The following commandline checks out the kernel cvs devel branch: > $ CVSROOT=:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs cvs co > rpms/kernel/devel > > Regards, > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From valent.turkovic at gmail.com Wed Jul 4 14:20:39 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 04 Jul 2007 16:20:39 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: <1183558839.5484.130.camel@fedora> On Wed, 2007-07-04 at 22:14 +0800, Hikaru Amano wrote: > yum install revisor > > add whatever 3rd party repo's config rpm into the kickstart > > release the generated CD/DVD .. just dont name it Fedora I'll probably do that, thanks Hikaru. So I can't use the name "Fedora Ultimate" or "Ultimate Fedora" ? From rc040203 at freenet.de Wed Jul 4 14:24:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Jul 2007 16:24:27 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: <1183559067.23976.408.camel@mccallum.corsepiu.local> On Wed, 2007-07-04 at 22:14 +0800, Hikaru Amano wrote: > On 7/4/07, Valent Turkovic wrote: > > On Wed, 2007-07-04 at 13:04 +0200, Ralf Corsepius wrote: > > > This does NOT mean it is NOT possible to ship non-GPL'ed SW nor codecs > > > as part of Fedora. > > > > Can you please expand on this just a bit? Sorry for having missed this part. It's all a legal and the policy issue. If your codec is OSI compliant (This does not mean it to be GPL'ed!!), there is nothing which would prevent you from making such a codec a part of Fedora. > yum install revisor > > add whatever 3rd party repo's config rpm into the kickstart > > release the generated CD/DVD .. just dont name it Fedora ... and make sure the product complies to the legal rules applicable to you, esp. when you should be wanting to sell it ;) Ralf From kagesenshi.87 at gmail.com Wed Jul 4 14:24:37 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Wed, 4 Jul 2007 22:24:37 +0800 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183558839.5484.130.camel@fedora> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> <1183558839.5484.130.camel@fedora> Message-ID: On 7/4/07, Valent Turkovic wrote: > On Wed, 2007-07-04 at 22:14 +0800, Hikaru Amano wrote: > > yum install revisor > > > > add whatever 3rd party repo's config rpm into the kickstart > > > > release the generated CD/DVD .. just dont name it Fedora > > I'll probably do that, thanks Hikaru. > > So I can't use the name "Fedora Ultimate" or "Ultimate Fedora" ? > IANAL, but IIRC, you can't .. its trademarked .. maybe you can call it Ultimate Blue Hat :P ... > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From markg85 at gmail.com Wed Jul 4 14:28:48 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 16:28:48 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> Message-ID: <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> oke.. now i'm having a little more complex question also about the kernel. when i do: "rpmbuild -ba kernel-2.6.spec" i get this output within about a minute: Wrote: /usr/src/redhat/SRPMS/kernel-2.6.21-1.3228.fc7.src.rpm Wrote: /usr/src/redhat/RPMS/i386/kernel-headers-2.6.21-1.3228.fc7.i386.rpm (this was tested with the F7 kernel source but i also tested it with the F8 kernel source. both have the same result as above.. just another version) and more but that's what i want to know. now when running the rpmbuild line i expected the full kernel to be compiled.. not just the headers and the source rpm. so the question is: how do i compile the kernel the fedora way? or is this the way how it should be done: http://www.howtoforge.com/kernel_compilation_fedora if that's the case i will just follow that tutorial. but this (couldn't find it on the wiki) is important information to get in the fedora wiki. And the reason why i want to have this new kernel is mainly because iwl (whatever the name was) just the wireless drivers that should be alot more stable in this kernel than in 2.6.21 2007/7/4, Mark : > so there it's hidden ^_^ thanx. > > > 2007/7/4, Till Maas : > > On Mi Juli 4 2007, Mark wrote: > > > and what is the cvs checkout line? > > > lets take for example that i want to checkout the latest kernel. > > > > > > the documentation here is kinda outdated (Fedora Core 2 latest) > > > http://cvs.fedora.redhat.com/docs.shtml. > > > > There is uptodate documentation in the wiki: > > > > http://fedoraproject.org/wiki/PackageMaintainers/CvsAccess > > > > The following commandline checks out the kernel cvs devel branch: > > $ CVSROOT=:pserver:anonymous at cvs.fedoraproject.org:/cvs/pkgs cvs co > > rpms/kernel/devel > > > > Regards, > > Till > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From skvidal at linux.duke.edu Wed Jul 4 14:34:24 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 04 Jul 2007 10:34:24 -0400 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183558839.5484.130.camel@fedora> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> <1183558839.5484.130.camel@fedora> Message-ID: <1183559665.31613.96.camel@cutter> On Wed, 2007-07-04 at 16:20 +0200, Valent Turkovic wrote: > On Wed, 2007-07-04 at 22:14 +0800, Hikaru Amano wrote: > > yum install revisor > > > > add whatever 3rd party repo's config rpm into the kickstart > > > > release the generated CD/DVD .. just dont name it Fedora > > I'll probably do that, thanks Hikaru. > > So I can't use the name "Fedora Ultimate" or "Ultimate Fedora" ? No, you may not. And you may not say 'based on fedora' 'derived from fedora' or anything like that afaik. -sv From opensource at till.name Wed Jul 4 14:38:38 2007 From: opensource at till.name (Till Maas) Date: Wed, 04 Jul 2007 16:38:38 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <3168.192.54.193.51.1183558342.squirrel@rousalka.dyndns.org> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA8D4.2020300@linux-kernel.at> <3168.192.54.193.51.1183558342.squirrel@rousalka.dyndns.org> Message-ID: <200707041638.40056.opensource@till.name> On Mi Juli 4 2007, Nicolas Mailhot wrote: > pkgs will exist for normal users when it's documented on > http://cvs.fedoraproject.org/ I did not know, that this page is still maintaned. I asked about this a long time ago, but today I found out, where to report bugs about this and opened two tickets: https://bugzilla.redhat.com/246730 https://bugzilla.redhat.com/246728 Regards, Till From bpepple at fedoraproject.org Wed Jul 4 14:58:18 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jul 2007 10:58:18 -0400 Subject: Final Reminder: FESCo Nomination Period Still Open Message-ID: <1183561098.2806.17.camel@kennedy> Hey all, Just a final reminder that there is still time to nominate yourself for the upcoming FESCo election, since the cutoff time is on July, 10 2007 0:00 UTC. All thirteen seats are up for election, and so far we only have 13 nominations. So, please consider running for FESCo if you have an interest, otherwise this may be a pretty dull election. ;) To add your nomination, please go to: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations The actual election will start on Thursday, 12 July 0:01 UTC and will last until Sunday, 22 July 23:59 UTC. The results will be posted to a public mailing list. The first meeting of the "new" FESCo will be on Thursday, July 26 2007 on #fedora-meeting at 17:00 UTC. A new chair will be elected there by the new members. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 kagesenshi.87 at gmail.com Wed Jul 4 15:16:37 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Wed, 4 Jul 2007 23:16:37 +0800 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183559665.31613.96.camel@cutter> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> <1183558839.5484.130.camel@fedora> <1183559665.31613.96.camel@cutter> Message-ID: On 7/4/07, seth vidal wrote: > On Wed, 2007-07-04 at 16:20 +0200, Valent Turkovic wrote: > > On Wed, 2007-07-04 at 22:14 +0800, Hikaru Amano wrote: > > > yum install revisor > > > > > > add whatever 3rd party repo's config rpm into the kickstart > > > > > > release the generated CD/DVD .. just dont name it Fedora > > > > I'll probably do that, thanks Hikaru. > > > > So I can't use the name "Fedora Ultimate" or "Ultimate Fedora" ? > > No, you may not. And you may not say 'based on fedora' 'derived from > fedora' or anything like that afaik. http://fedoraproject.org/wiki/Distribution#head-5a5cea96f0813a2767d5b4e7b215697a6042d8c3 Specifically, you may not modify the Fedora installation and maintain the Fedora name. The nearest you may do is completely rebrand the distribution to comply with the trademark guidelines, make your modifications, and distribute the product under a different name. You may also not then say that your product "contains Fedora" or is an alternate "edition" of Fedora. You may say that your product is "a derivative of Fedora" or is "built upon Fedora", but you must make it clear that your product is NOT Fedora. If you use the Fedora name in such a manner, you must also note that Fedora is a registered trademark, and not attempt to confuse users or allude to a non-existant relationship between you and the Fedora Project or Red Hat. > > -sv > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From a.badger at gmail.com Wed Jul 4 15:17:40 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jul 2007 08:17:40 -0700 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> Message-ID: <1183562260.3628.16.camel@localhost.localdomain> On Wed, 2007-07-04 at 16:28 +0200, Mark wrote: > oke.. now i'm having a little more complex question also about the kernel. > when i do: "rpmbuild -ba kernel-2.6.spec" i get this output within > about a minute: > > Wrote: /usr/src/redhat/SRPMS/kernel-2.6.21-1.3228.fc7.src.rpm > Wrote: /usr/src/redhat/RPMS/i386/kernel-headers-2.6.21-1.3228.fc7.i386.rpm > > (this was tested with the F7 kernel source but i also tested it with > the F8 kernel source. both have the same result as above.. just > another version) > > and more but that's what i want to know. now when running the rpmbuild > line i expected the full kernel to be compiled.. not just the headers > and the source rpm. so the question is: how do i compile the kernel > the fedora way? > > or is this the way how it should be done: > http://www.howtoforge.com/kernel_compilation_fedora if that's the case > i will just follow that tutorial. but this (couldn't find it on the > wiki) is important information to get in the fedora wiki. > > And the reason why i want to have this new kernel is mainly because > iwl (whatever the name was) just the wireless drivers that should be > alot more stable in this kernel than in 2.6.21 > This will help you:: http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Kernel.html In your specific case you're missing the --target $(uname -m) -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 markg85 at gmail.com Wed Jul 4 15:52:02 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 17:52:02 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <1183562260.3628.16.camel@localhost.localdomain> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> <1183562260.3628.16.camel@localhost.localdomain> Message-ID: <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> Thanx for the reply but i'm stuck after step 10. after step 10 it says: "You may then proceed as usual." and what is that? is that make rpm? or rpmbuild in some special location? the notice below step 10 says: "Normally, kernels for Fedora are built using the rpmbuild utility and a specfile. Your results may vary if you use the kernel's built-in make rpm target." but that doesn't answer the question.to me it indicates that both make rpm and rpmbuild are possible.. but than again.. where can i do rpmbuild on the kernel? That documentation should be expanded with the full guide for making a rpm. 2007/7/4, Toshio Kuratomi : > On Wed, 2007-07-04 at 16:28 +0200, Mark wrote: > > oke.. now i'm having a little more complex question also about the kernel. > > when i do: "rpmbuild -ba kernel-2.6.spec" i get this output within > > about a minute: > > > > Wrote: /usr/src/redhat/SRPMS/kernel-2.6.21-1.3228.fc7.src.rpm > > Wrote: /usr/src/redhat/RPMS/i386/kernel-headers-2.6.21-1.3228.fc7.i386.rpm > > > > (this was tested with the F7 kernel source but i also tested it with > > the F8 kernel source. both have the same result as above.. just > > another version) > > > > and more but that's what i want to know. now when running the rpmbuild > > line i expected the full kernel to be compiled.. not just the headers > > and the source rpm. so the question is: how do i compile the kernel > > the fedora way? > > > > or is this the way how it should be done: > > http://www.howtoforge.com/kernel_compilation_fedora if that's the case > > i will just follow that tutorial. but this (couldn't find it on the > > wiki) is important information to get in the fedora wiki. > > > > And the reason why i want to have this new kernel is mainly because > > iwl (whatever the name was) just the wireless drivers that should be > > alot more stable in this kernel than in 2.6.21 > > > > This will help you:: > http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Kernel.html > > In your specific case you're missing the --target $(uname -m) > > -Toshio > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From oliver at linux-kernel.at Wed Jul 4 15:59:20 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 04 Jul 2007 17:59:20 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> <1183562260.3628.16.camel@localhost.localdomain> <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> Message-ID: <468BC3D8.50308@linux-kernel.at> On 07/04/2007 05:52 PM, Mark wrote: > Thanx for the reply but i'm stuck after step 10. > after step 10 it says: "You may then proceed as usual." > and what is that? is that make rpm? or rpmbuild in some special location? > > the notice below step 10 says: "Normally, kernels for Fedora are built > using the rpmbuild utility and a specfile. Your results may vary if > you use the kernel's built-in make rpm target." but that doesn't > answer the question.to me it indicates that both make rpm and rpmbuild > are possible.. but than again.. where can i do rpmbuild on the kernel? > > That documentation should be expanded with the full guide for making a rpm. Either do > make i686 or > make srpm; rpmbuild --rebuild --target i686 *.src.rpm -of PS: Or any other platform you want. From markg85 at gmail.com Wed Jul 4 16:08:53 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 18:08:53 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <468BC3D8.50308@linux-kernel.at> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> <1183562260.3628.16.camel@localhost.localdomain> <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> <468BC3D8.50308@linux-kernel.at> Message-ID: <6e24a8e80707040908r82cc0cbl76f4795a874c610@mail.gmail.com> hmm.. make srpm doesn't seem to be valid "make: *** No rule to make target `srpm'. Stop." the issue that i have is that i would like to have the rpm itself to make the grub changes and add the file in the /boot folder. (so just the same that a default kernel rpm does).. i'm not quite sure if the current RPM will do this for me.. i'm just doing make i686 now and will see what hapens. 2007/7/4, Oliver Falk : > On 07/04/2007 05:52 PM, Mark wrote: > > Thanx for the reply but i'm stuck after step 10. > > after step 10 it says: "You may then proceed as usual." > > and what is that? is that make rpm? or rpmbuild in some special location? > > > > the notice below step 10 says: "Normally, kernels for Fedora are built > > using the rpmbuild utility and a specfile. Your results may vary if > > you use the kernel's built-in make rpm target." but that doesn't > > answer the question.to me it indicates that both make rpm and rpmbuild > > are possible.. but than again.. where can i do rpmbuild on the kernel? > > > > That documentation should be expanded with the full guide for making a rpm. > > Either do > > make i686 > or > > make srpm; rpmbuild --rebuild --target i686 *.src.rpm > > -of > > PS: Or any other platform you want. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mattdm at mattdm.org Wed Jul 4 16:37:53 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 4 Jul 2007 12:37:53 -0400 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> Message-ID: <20070704163753.GA4850@jadzia.bu.edu> On Wed, Jul 04, 2007 at 12:41:09PM +0200, Valent Turkovic wrote: > Also I understand that directly linking from Fedora or an official > Fedora website to http://rpm.livna.org is considered "contributory > infingement" *Could* be contributory infringement. An important distinction -- I don't think we admit any such thing, but are rather erroring on the side of caution. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From debarshi.ray at gmail.com Wed Jul 4 16:39:19 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 22:09:19 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> Message-ID: <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> Just a moment. I am getting lost on this. > +1 to a single tool for managing repos globally, rather than every > apps have its own repo control, which is , IMHO, make stuff feels more > complicated .. The YUM API already has a way to enable and disable repositories. The --enablerepo and --disablerepo flags directly use this. What seems to be lacking is a way to alter yum.conf and the .repo files so that the changes become persistent. Once this is available in the YUM API, all that an application needs to do is make calls to this API component to do the necessary configuration. So right now applications need to have their own repository control only if they want to alter the files, not if they want to enable or disable a repository for a single run of the program. What you refer to as "a single tool for managing repos globally" is actually the YUM API. Using that there can be 'n' number of frontends (GUI or CLI) which can configure repositories among other things too. > I like system-config-repo's and repoman's approach .. pirut just > install/remove apps.. repoman/sysconfrepo for all-thing repository > related .. and yumex for advanced users .. Why would one need a separate tool for doing each of these things? As far as I understand, one would only need to work with repositories if they want to install/update/remove some packages. Hence a tool which claims to be a package manager (GUI or CLI) should have all the features. eg., if A, B, and C claim to be package management tools, then each of them should have these features to some extent atleast. > a textUI (eg: system-config-repo-tui) for enabling/disabling repos is > also a nice thing to have .. it make it easier for writing automated > scripts etc. (I had this problem before , enabling/disabling repos > globally was a pain for a person who dont know much in manipulating > strings in scripts like me - or maybe such app already exist but I > dont know about it???) Again I can not visualize repository configuration as a separate thing from package management. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Wed Jul 4 16:41:17 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 22:11:17 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <200707040030.58814.alain.portal@free.fr> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <200707040030.58814.alain.portal@free.fr> Message-ID: <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> > > I only see Jeremy on the CC list. > I confirm, using kmail. Hence GMail's Web interface rocks. :-) Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Wed Jul 4 16:49:50 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 22:19:50 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468B6856.4090007@gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> Message-ID: <3170f42f0707040949t56fd6590w58004cb1a56fd846@mail.gmail.com> >> A merge would be fine to me, but it is mostly about where we want to go >> with the package manager in Fedora, do we want a simple tools or do we >> want tools with lot of possibilities for the more advanced user. > Simplicity is a desirable goal and rightly one should strive for it, the > question remains would a merged tool ie an extended/improved/feature > rich Pirut or a Yumex with possible extensions serve the ends ? And of > course, would at the end the choice will boil down to a single tool ? In certain cases the idea of a simple packagement tool can lead to oversimplification of things. For example for a very long time in the days of FC2 to FC5 Pirut would not work on LANs which connected to the Internet through a proxy. It would simply exit with a message: "Can not download package information". I have seen many many users who would really appreciate a simple tool getting stumped by this and dump Pirut for good. In such cases an option to set the proxy would have been wonderful. These very same users would happily use Synaptic after providing the necessary proxy settings for their network. My point is that a configuration option which lies within the menu does not really lead to loss of any simplicity. Rather it may enhance the usability of the entire application at times. Secondly, do we really a simple package manager and an advanced package manager? In my opinion this would be an overkill. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Wed Jul 4 16:52:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 22:22:17 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <200707040030.58814.alain.portal@free.fr> <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> Message-ID: <468BD041.6070207@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> > I only see Jeremy on the CC list. > >> I confirm, using kmail. > > Hence GMail's Web interface rocks. :-) I can't see how a CC list that is invisible to everybody else (assumed that is actually working) is going to be better than a CC list that is transparent to desktop clients. Rahul From mschwendt.tmp0701.nospam at arcor.de Wed Jul 4 16:56:52 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 4 Jul 2007 18:56:52 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040908r82cc0cbl76f4795a874c610@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> <1183562260.3628.16.camel@localhost.localdomain> <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> <468BC3D8.50308@linux-kernel.at> <6e24a8e80707040908r82cc0cbl76f4795a874c610@mail.gmail.com> Message-ID: <20070704185652.bc01f8a1.mschwendt.tmp0701.nospam@arcor.de> On Wed, 4 Jul 2007 18:08:53 +0200, Mark wrote: > hmm.. make srpm doesn't seem to be valid > "make: *** No rule to make target `srpm'. Stop." Run this in your Fedora CVS check-out. From debarshi.ray at gmail.com Wed Jul 4 16:54:38 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 22:24:38 +0530 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183557943.5484.126.camel@fedora> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: <3170f42f0707040954m2a5da471m8f0283ee36313ca7@mail.gmail.com> >> This does NOT mean it is NOT possible to ship non-GPL'ed SW nor codecs >> as part of Fedora. > Can you please expand on this just a bit? GPL is not the _only_ free software license. You can ship stuff released under the Apache license, BSD license, MIT license, GFDL, LGPL, etc.. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From bpepple at fedoraproject.org Wed Jul 4 16:55:58 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jul 2007 12:55:58 -0400 Subject: Plan for tomorrows (20070705) FESCO meeting Message-ID: <1183568158.2806.22.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- Feature Policy Draft - http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-meeting -- Statically link libuu (uulib-static) into klibido -- tibbs -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 debarshi.ray at gmail.com Wed Jul 4 16:57:30 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 22:27:30 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468BD041.6070207@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <200707040030.58814.alain.portal@free.fr> <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> <468BD041.6070207@fedoraproject.org> Message-ID: <3170f42f0707040957v6abb5e16n3deb21b087619c98@mail.gmail.com> > I can't see how a CC list that is invisible to everybody else (assumed > that is actually working) is going to be better than a CC list that is > transparent to desktop clients. I gave you the original mail headers. As long as the mail reaches its destination I do not care. :-/ Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tmz at pobox.com Wed Jul 4 16:57:42 2007 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 4 Jul 2007 12:57:42 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <200707040030.58814.alain.portal@free.fr> <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> Message-ID: <20070704165742.GE10550@psilocybe.teonanacatl.org> Debarshi 'Rishi' Ray wrote: >>> I only see Jeremy on the CC list. > >> I confirm, using kmail. > > Hence GMail's Web interface rocks. :-) No, it mustn't. If it rocked, it would have properly included the CC's. If you see them in gmail, then it's showing you things that are not there. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Between two evils, I always pick the one I never tried before. -- Mae West -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From sundaram at fedoraproject.org Wed Jul 4 16:58:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 22:28:24 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707040949t56fd6590w58004cb1a56fd846@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040949t56fd6590w58004cb1a56fd846@mail.gmail.com> Message-ID: <468BD1B0.6080703@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >>> A merge would be fine to me, but it is mostly about where we want to go >>> with the package manager in Fedora, do we want a simple tools or do we >>> want tools with lot of possibilities for the more advanced user. > >> Simplicity is a desirable goal and rightly one should strive for it, the >> question remains would a merged tool ie an extended/improved/feature >> rich Pirut or a Yumex with possible extensions serve the ends ? And of >> course, would at the end the choice will boil down to a single tool ? > > In certain cases the idea of a simple packagement tool can lead to > oversimplification of things. > > For example for a very long time in the days of FC2 to FC5 Pirut would > not work on LANs which connected to the Internet through a proxy. That doesn't make much sense. Pirut is a new tool introduced in FC5. system-config-packages which existed in previous versions didn't use yum, only had the capability to install packages from media and would have no need to connect to the Internet or use a proxy. Proxy settings would ideally be system wide and not require per application configuration. Rahul From kagesenshi.87 at gmail.com Wed Jul 4 17:02:22 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Thu, 5 Jul 2007 01:02:22 +0800 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> Message-ID: On 7/5/07, Debarshi 'Rishi' Ray wrote: > Just a moment. I am getting lost on this. > > > +1 to a single tool for managing repos globally, rather than every > > apps have its own repo control, which is , IMHO, make stuff feels more > > complicated .. > > The YUM API already has a way to enable and disable repositories. The > --enablerepo and --disablerepo flags directly use this. > > What seems to be lacking is a way to alter yum.conf and the .repo > files so that the changes become persistent. Once this is available in > the YUM API, all that an application needs to do is make calls to this > API component to do the necessary configuration. > yup .. I'm looking for a way to alter yum.conf and the .repo file to become persistent .. I have set up a LAN repo for newbies in my uni and was trying to make a one click installation script for it ... I dont want to tell them to manually edit all the .repo files one by one to disable the official repos and enable my repos... -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From sundaram at fedoraproject.org Wed Jul 4 17:02:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 22:32:58 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <3170f42f0707040957v6abb5e16n3deb21b087619c98@mail.gmail.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <200707040030.58814.alain.portal@free.fr> <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> <468BD041.6070207@fedoraproject.org> <3170f42f0707040957v6abb5e16n3deb21b087619c98@mail.gmail.com> Message-ID: <468BD2C2.6050602@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> I can't see how a CC list that is invisible to everybody else (assumed >> that is actually working) is going to be better than a CC list that is >> transparent to desktop clients. > > I gave you the original mail headers. As long as the mail reaches its > destination I do not care. :-/ If the web interface is mangling the headers in a way that makes it invisible to other clients then it is a bug and not a benefit. Rahul From tibbs at math.uh.edu Wed Jul 4 17:04:43 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jul 2007 12:04:43 -0500 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: <1183568158.2806.22.camel@kennedy> References: <1183568158.2806.22.camel@kennedy> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> /topic FESCO-meeting -- Statically link libuu (uulib-static) into BP> klibido -- tibbs -- BP> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 I think this was decided long ago, and in any case made moot by the updated static linking policy. - J< From a.badger at gmail.com Wed Jul 4 17:05:40 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jul 2007 10:05:40 -0700 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> <1183562260.3628.16.camel@localhost.localdomain> <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> Message-ID: <1183568740.3628.21.camel@localhost.localdomain> On Wed, 2007-07-04 at 17:52 +0200, Mark wrote: > Thanx for the reply but i'm stuck after step 10. > after step 10 it says: "You may then proceed as usual." > and what is that? is that make rpm? or rpmbuild in some special location? > > the notice below step 10 says: "Normally, kernels for Fedora are built > using the rpmbuild utility and a specfile. Your results may vary if > you use the kernel's built-in make rpm target." but that doesn't > answer the question.to me it indicates that both make rpm and rpmbuild > are possible.. but than again.. where can i do rpmbuild on the kernel? > > That documentation should be expanded with the full guide for making a rpm. > It depends on what you want to do. Your question seemed to be: How do I get "rpmbuild -ba kernel-2.6.spec" to produce kernel rpms. The answer is: rpmbuild -ba --target $(uname -m) kernel-2.6.spec I should have made it clearer in my original reply that the "--target...." was the only thing you needed to get from that page. If you want to make modifications to the kernel spec file, then the rest of that page becomes relevant. -Toshio > 2007/7/4, Toshio Kuratomi : > > On Wed, 2007-07-04 at 16:28 +0200, Mark wrote: > > > oke.. now i'm having a little more complex question also about the kernel. > > > when i do: "rpmbuild -ba kernel-2.6.spec" i get this output within > > > about a minute: > > > > > > Wrote: /usr/src/redhat/SRPMS/kernel-2.6.21-1.3228.fc7.src.rpm > > > Wrote: /usr/src/redhat/RPMS/i386/kernel-headers-2.6.21-1.3228.fc7.i386.rpm > > > > > > (this was tested with the F7 kernel source but i also tested it with > > > the F8 kernel source. both have the same result as above.. just > > > another version) > > > > > > and more but that's what i want to know. now when running the rpmbuild > > > line i expected the full kernel to be compiled.. not just the headers > > > and the source rpm. so the question is: how do i compile the kernel > > > the fedora way? > > > > > > or is this the way how it should be done: > > > http://www.howtoforge.com/kernel_compilation_fedora if that's the case > > > i will just follow that tutorial. but this (couldn't find it on the > > > wiki) is important information to get in the fedora wiki. > > > > > > And the reason why i want to have this new kernel is mainly because > > > iwl (whatever the name was) just the wireless drivers that should be > > > alot more stable in this kernel than in 2.6.21 > > > > > > > This will help you:: > > http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Kernel.html > > > > In your specific case you're missing the --target $(uname -m) > > > > -Toshio > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed Jul 4 17:07:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 04 Jul 2007 22:37:07 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> Message-ID: <468BD3BB.6080508@fedoraproject.org> Hikaru Amano wrote: > On 7/5/07, Debarshi 'Rishi' Ray wrote: >> Just a moment. I am getting lost on this. >> >> > +1 to a single tool for managing repos globally, rather than every >> > apps have its own repo control, which is , IMHO, make stuff feels more >> > complicated .. >> >> The YUM API already has a way to enable and disable repositories. The >> --enablerepo and --disablerepo flags directly use this. >> >> What seems to be lacking is a way to alter yum.conf and the .repo >> files so that the changes become persistent. Once this is available in >> the YUM API, all that an application needs to do is make calls to this >> API component to do the necessary configuration. >> > > yup .. I'm looking for a way to alter yum.conf and the .repo file to > become persistent .. I have set up a LAN repo for newbies in my uni > and was trying to make a one click installation script for it ... I > dont want to tell them to manually edit all the .repo files one by one > to disable the official repos and enable my repos... Rum (The original one, not Debarshi's) did have easy command line arguments for disabling/enabling repositories in a persistent manner. They probably have custom code to do this but you might want to take a look at that. Rahul From bpepple at fedoraproject.org Wed Jul 4 17:14:10 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jul 2007 13:14:10 -0400 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: References: <1183568158.2806.22.camel@kennedy> Message-ID: <1183569250.2806.23.camel@kennedy> On Wed, 2007-07-04 at 12:04 -0500, Jason L Tibbitts III wrote: > >>>>> "BP" == Brian Pepple writes: > > BP> /topic FESCO-meeting -- Statically link libuu (uulib-static) into > BP> klibido -- tibbs -- > BP> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 > > I think this was decided long ago, and in any case made moot by the > updated static linking policy. Yeah, your right. I'll go ahead and remove it from the schedule. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 christoph.wickert at nurfuerspam.de Wed Jul 4 17:15:04 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Wed, 04 Jul 2007 19:15:04 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183555076.5484.105.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183553384.3677.47.camel@wicktop.localdomain> <1183555076.5484.105.camel@fedora> Message-ID: <1183569304.3433.89.camel@wicktop.localdomain> Am Mittwoch, den 04.07.2007, 15:17 +0200 schrieb Valent Turkovic: > On Wed, 2007-07-04 at 14:49 +0200, Christoph Wickert wrote: > > How exactly should this happen? Another screen with questions like: > > "Do > > you want to mount your NTFS volumes? y/N" and "Do you want your NFTS > > volumes to be mounted read only? Y/n"? I don't think bothering people > > with more questions is necessary or useful. > > Offcource not. The devels can choose whic is technically better default > (RO or RW) and only have an option in advanced mode to change it, What advanced mode are you talking about? AFAIK we don't have an advanced mode. There's no such thing as "linux expert". > or > after the install of Fedora via some gui tool perhaps? But in the end it comes out to these two possibilities: 1. Do it automatically: Something that not all users like. I'd like to have control over what a the installation does. 2. Bother people with another question: No matter if it is during install or in firstboot, this sucks. > > You already have the opportunity to configure NTFS mounts during > > install. Usually I tell anaconda/disc druid to mount my Windows > > partition to /mnt/windows. Now that we have ntfs-3g in default > > install, > > you have r/w access when you first boot your computer after install. > > Are you sure? I wouldn't be writing this if it worked. AFAIK you can't > choose NTFS partitions in anaconda during the partitioning and give them > mount points. NTFS partitons are grayed out and can't be even selected. > If I'm wrong please correct me. I just looked it up and you are correct. Sorry, I could have sworn that it was possible. So IMO all there needs to be is possibility to give NTFS partitions a mount point, the rest should be done by the users. And I don't think this needs to be enabled by default, we could do this like we do with xfs for example. > > > * Beagle and Deskbar installed by default > > > these applications make all the difference for an desktop user > > between > > > an "OK" user experience and "wonderful" user experience. > > > > This topic has already been beaten to death on this list before you > > raised it again. We did have beagle in the default install in FC6 and > > it > > was decided to take it out for F7. Please be so kind as to search the > > archives or at least read the Fedora Weekly News: > > http://fedoraproject.org/wiki/FWN/Issue88#head-7fdee0a1251926827abf631c707a2dadcb25ea10 > > My point is that maintainer of the package said that he doesn't have > time to work with this package and it is easier for him to remove it > that look at some non-trivial problems. If this was the only problem I'm sure we would have already solved it by now. > > BTW: If you speak German I suggest you search for beagle @ > > fedoraforum.de: 37 hits and 35 of them are complainants. > > Well I would argue that the people who remove it are a minority, not the > other way around. 35 of 37 of doesn't look like a minority to me. ;) Most of the problems are like "My computer is horribly slow", "My computer locks up" or "My laptop battery is empty so much faster now". And most of them are solved with "yum remove beagle". > I have seen beagle installed on multiple systems and > it is as unobtrusive as an app can be. I have tested it on Fedora Core6, > multiple Fedora 7 installations and now I'm testing it on Rawhide. So I > have extensive experience with beagle. >From what I see from bugzilla [1] you have been testing it on a machine with 1536 MB RAM. There are at least 6 search processes running with 2.6% mem each. This comes out to ~ 240 MB in total. And now think about the people, who have only 512 MB RAM installed. > Only saying "me too" to a forum, bugzilla entry or on a mailing > list makes beagle look bad but only because the majority of people who > don't have issues with beagle don't even go to these mailing lists or to > bugzilla. I think the "me too"-people are not included, I only counted the threads but not the people. It's most likely that there is a large number of people who had the same symptoms, searched the forum and followed the advice to remove beagle without writing another "me too" comment. > If you have tested beagle on multiple systems and find it > causing problems then please excuse me - show us your test results and > that is ok. > > Has anybody of the 35 people on fedoraforum.de looked at the actual > problem with beagle and saw where or why they have some issues? You have to decide from which point of view your are talking. From a developer's point of view you are right: Users should file bugs, investigate the problem, do testing and troubleshooting to help beagle to improve. But from a users point of view, "yum remove beagle" is the answer in most cases. Most of the time your point of view is the user's, but now you suddenly switch to the developers sight. In your perspective users often are to stupid do even the most trivial tasks (like to install the applications they need with pirut), and now you expect them to do in depth bug hunting? That's not logical. BTW: Many of the developers say beagle simply is doomed, because it's written in mono. It's a failure of design itself. > > > * Tomboy installed by default > > > - I have all the same arguments here as I do for Beagle and Deskbar > > > > deskbar and tomboy might be worth discussing, but I don't think many > > people are using them. So I'd say they should stay out. > > It depends what Fedora is trying to do. It if it is trying to be a linux > Desktop and not only for us who are geeks then it should include nice > apps by deafult - any maybe put some promo video material that explains > what each app does. As I said above: On the one hand you are arguing users are not able to find out what an application does, on the other hand you expect them to do serious bug hunting? So what's your target audience then? > > > * Desktop shortcut for joining Fedora IRC (aka "Get Live Help") > > > > Although this is a good idea I'm not sure how to achieve this > > technically: Yes, there is an IRC url scheme [1], but I'm not sure if > > all desktops are able to open IRC links. Other questions are: What > > application should be used to open this link and how to we make sure > > this application really is installed? > > Why IRC url? It can be a shortcut to a script. At least there are > multiple choices. Devels should make this choice, I trust them. Do you > see some actual problem here? I'm afraid there needs to be a bunch of if-else-statements to cover every IRC client we ship. Maybe you can give us more details about how the sabayon guys have covered this? > > > * Desktop folder with examples of what "this linux thing" can do :) > > > > Personally I hate "example" folders. "Example > > Pictures/Music/Playlists/Whatever" is the first thing I remove on a > > fresh installed Windows. > > Gnome also comes with these folders, I dislike them in Gnome also. > You are confusing examples folders from windows and a much better > example from Ubuntu example folder (and that is not in plural). No, you are confusing an "examples" folder with xdg-user-dirs. This is something completely different. > > > * a working Burning app for Fedora Gnome desktop > > > Put any new user in front of fresh Fedora 7 desktop and ask them to > > > burn some files to CD or DVD - any watch them as they wiggle > > > unpleasantly as they can't find any burning app under gnome desktop. > > > Puting a link for nautils burner under "Places / CD - DVD Recoder" > > > doesn't help. > > > > Really? I have been installing computers with fedora for a while now > > and > > giving them to my customers. _No_one_ has ever asked me how to burn > > CDs/DVDs. > > Do they burn discs? Do they even have burners? Do they even know they > have a burning option? Erm, I guess if I sell them a computer with DVD burner but without the necessary software to burn I would have heard _lots_ of complainants. ;) > Have you asked your customer to burn a CD or a DVD and see what he/she > does? Today a customer handed over his laptop to me in order to upgrade it to F7. "Don't worry about the files," he said "I have backed up everything onto DVD." So I guess my customers know that they have the ability to burn discs. > Or you have had to teach them to use rhythmbox and gnome burning > tool because they didn't know how to use it by them selves? No, I did not have to teach them but only tell them to launch rhythmbox. > > I have to admit that starting rhythmbox to burn audio discs is > > not really intuitive but it works. > > And that is what I'm talking about! It has to be intuitive or it doesn't > float. I remember the "shiny desktop" thread where you said that we should learn from Apple. By default the only way to burn an audio disc in MacOS is to use iTunes. Same in Windows with it's Mediaplayer BTW. As I said before: It's not really intuitive for audio, but if there is one lesson we should learn from other OSes it IMHO is: No duplicate functionality in the base install. > > So IMO we shouldn't add duplicate > > functionality to the default install. > > There is no duplication if you add only a shortcut for gnome burner > "burn:///" under gnome "Applications" menu instead of being only in > "Places" menue - which is really not intuitive. For most of my customers it is. Everything they see in nautilus first of all is a "place" for them but not an "application" (of course nautilus itself is an app, too). Chris [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031#c26 From debarshi.ray at gmail.com Wed Jul 4 17:17:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 4 Jul 2007 22:47:03 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <20070704165742.GE10550@psilocybe.teonanacatl.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <3170f42f0707030921r16ce9192u7a899610a0fb578@mail.gmail.com> <468A7A1B.1060602@fedoraproject.org> <200707040030.58814.alain.portal@free.fr> <3170f42f0707040941r56316244s98c8778750fe4a37@mail.gmail.com> <20070704165742.GE10550@psilocybe.teonanacatl.org> Message-ID: <3170f42f0707041017k1596f8dqf35713a4c38ade81@mail.gmail.com> > No, it mustn't. If it rocked, it would have properly included the > CC's. If you see them in gmail, then it's showing you things that are > not there. :) >From what I can see, and I can only see the mail header at my end, it did include the CCs. I already gave you the mail headers. :-) Moreover it seems from Thomas Canniot's reply, which he sent to me privately that he actually got the mail. I am not an expert in email protocols, but I suspect that the CC worked. In case you want to investigate I can send you all the headers offlist. :-) Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From frosario777 at gmail.com Wed Jul 4 17:18:14 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Wed, 4 Jul 2007 10:18:14 -0700 Subject: Parallel Booting In-Reply-To: References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> Message-ID: Speaking on the subject of parallel booting... has anyone tried init-ng? I had it installed in Fedora Core 6 using a P4 Hyper-Threading CPU and it cut my boot time in half. One drawback is that you manually have to set up most of your startup scripts as many services are not setup right out of the box. Maybe this changed in Fedora 7? On 7/3/07, Bojan Smojver wrote: > > Bill Nottingham redhat.com> writes: > > > So, for all this work, we get a 0.6%-1.1% speedup. Oh, and we get > > 62 AVCs from SELinux in the process. What's the point of this again? > > Yeah, not very useful it would seem... > > What happened to this? > > http://fedoraproject.org/wiki/FCNewInit/xdm > > Is it being worked on? (Yeah, I know - I should probably not ask > questions, but > submit patches :-) > > >From a desktop users' point of view, the "magic" thing is the login > screen. By > the time they type in/pick the username and password, other stuff would > have > already started in the background, but the "boot time" would appear > shorter. > Isn't that the trick used on Windaz boxes as well? > > -- > Bojan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- --Freddie -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Wed Jul 4 17:21:32 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jul 2007 10:21:32 -0700 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: <1183568158.2806.22.camel@kennedy> References: <1183568158.2806.22.camel@kennedy> Message-ID: <1183569692.3628.30.camel@localhost.localdomain> On Wed, 2007-07-04 at 12:55 -0400, Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- Feature Policy Draft - > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-meeting -- Statically link libuu (uulib-static) into > klibido -- tibbs -- > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 > > /topic FESCo meeting -- Free discussion around Fedora releng wants us to decide whether perl-devel can be removed from the default buildroot. Jesse should probably drive that discussion, though. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjan at infradead.org Wed Jul 4 17:19:16 2007 From: arjan at infradead.org (Arjan van de Ven) Date: Wed, 04 Jul 2007 10:19:16 -0700 Subject: [Fwd: F7: Howto monitoring a Hardware sata raid controller] In-Reply-To: <1183543723.5223.29.camel@lesca.home.solinos.it> References: <1183543723.5223.29.camel@lesca.home.solinos.it> Message-ID: <1183569556.2633.1.camel@laptopd505.fenrus.org> On Wed, 2007-07-04 at 12:08 +0200, Dario Lesca wrote: > Hi, why I have not obtained answers to my message? > > I have perhaps offend someone? > I have formulate the question bad? (my english is bad, sorry) > It is OT for this list? > In this ML none know about my question? > > This problem is a lot important for me ... > > Please someone can tell to me somethings ? > > Many thanks! ok first of all you have a software raid controller; all the raid is done in software. "dmraid" is the component that does the raid, and I think it has some form of monitoring, but I don't know all that much about it, I hope that at least it's a start for you to look for more info... From tmus at tmus.dk Wed Jul 4 17:23:17 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 04 Jul 2007 15:23:17 -0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183557943.5484.126.camel@fedora> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: Valent Turkovic wrote: > > Are your hands completely tied? > > I live and work by the moto "Where there is will there is a way." > Meaning that when you want to do something you find a way to do so. > The thing is, that the purpose of the Fedora distribution is to be as clean as possible, when it comes to things like this. Even if means that a few things won't "work" straight out of the box, it's better than "contaminating" the distribution with potentially problematic stuff. So in most cases (if not all), you'll find that these things are excluded on purpose and cannot be included without violating the Fedora policy. I, for one, applaud the exclusion of these things. /Thomas From bpepple at fedoraproject.org Wed Jul 4 17:32:12 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jul 2007 13:32:12 -0400 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: <1183569692.3628.30.camel@localhost.localdomain> References: <1183568158.2806.22.camel@kennedy> <1183569692.3628.30.camel@localhost.localdomain> Message-ID: <1183570332.2806.25.camel@kennedy> On Wed, 2007-07-04 at 10:21 -0700, Toshio Kuratomi wrote: > releng wants us to decide whether perl-devel can be removed from the > default buildroot. Jesse should probably drive that discussion, though. I'll add it to the schedule. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 tibbs at math.uh.edu Wed Jul 4 17:36:43 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jul 2007 12:36:43 -0500 Subject: [Fwd: F7: Howto monitoring a Hardware sata raid controller] In-Reply-To: <1183569556.2633.1.camel@laptopd505.fenrus.org> References: <1183543723.5223.29.camel@lesca.home.solinos.it> <1183569556.2633.1.camel@laptopd505.fenrus.org> Message-ID: >>>>> "AvdV" == Arjan van de Ven writes: AvdV> "dmraid" is the component that does the raid, and I think it has AvdV> some form of monitoring, but I don't know all that much about AvdV> it, I hope that at least it's a start for you to look for more AvdV> info... dmraid will alert you if the RAID set becomes incomplete or experiences an error. smartd will alert you if the disks themselves experience errors (even ones that are remapped by the drive, in my experience). I don't know if there's any sort of functionality like the drive scrubbing that 3ware cards have. (They periodically read, reconstruct if necessary and rewrite all of the sectors on all of the drives, which prevents sectors from going bad silently.) You can run a cron job that asks the drives in your RAID set to do online self fests; smartd may even support doing that automatically. - J< From markg85 at gmail.com Wed Jul 4 17:40:41 2007 From: markg85 at gmail.com (Mark) Date: Wed, 4 Jul 2007 19:40:41 +0200 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <1183568740.3628.21.camel@localhost.localdomain> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <468BA5B7.90007@linux-kernel.at> <6e24a8e80707040657o2eb7d341mefe3a4bc60eda5d4@mail.gmail.com> <200707041605.17602.opensource@till.name> <6e24a8e80707040718q744f6bf5w6d0467454f18cd63@mail.gmail.com> <6e24a8e80707040728i45d5e787h14a1a76dfe9cf3b@mail.gmail.com> <1183562260.3628.16.camel@localhost.localdomain> <6e24a8e80707040852g7b7c223cr4ae13237da8c9610@mail.gmail.com> <1183568740.3628.21.camel@localhost.localdomain> Message-ID: <6e24a8e80707041040o17fa2fa0w2827468fb24b1419@mail.gmail.com> oke, so that's how it should be done. i'm compiling the kernel at this moment.... should take a while. now lets hope that wifi support has been made better and that suspend is working how it should :) But why isn't rpmbuild compiling all kernel rpm's if you leave out the --target? than it makes the kernel-headers rpm and a .src.rpm but nothing more. 2007/7/4, Toshio Kuratomi : > > On Wed, 2007-07-04 at 17:52 +0200, Mark wrote: > > Thanx for the reply but i'm stuck after step 10. > > after step 10 it says: "You may then proceed as usual." > > and what is that? is that make rpm? or rpmbuild in some special > location? > > > > the notice below step 10 says: "Normally, kernels for Fedora are built > > using the rpmbuild utility and a specfile. Your results may vary if > > you use the kernel's built-in make rpm target." but that doesn't > > answer the question.to me it indicates that both make rpm and rpmbuild > > are possible.. but than again.. where can i do rpmbuild on the kernel? > > > > That documentation should be expanded with the full guide for making a > rpm. > > > It depends on what you want to do. Your question seemed to be: How do I > get "rpmbuild -ba kernel-2.6.spec" to produce kernel rpms. The answer > is: > rpmbuild -ba --target $(uname -m) kernel-2.6.spec > > I should have made it clearer in my original reply that the > "--target...." was the only thing you needed to get from that page. > > If you want to make modifications to the kernel spec file, then the rest > of that page becomes relevant. > > -Toshio > > > 2007/7/4, Toshio Kuratomi : > > > On Wed, 2007-07-04 at 16:28 +0200, Mark wrote: > > > > oke.. now i'm having a little more complex question also about the > kernel. > > > > when i do: "rpmbuild -ba kernel-2.6.spec" i get this output within > > > > about a minute: > > > > > > > > Wrote: /usr/src/redhat/SRPMS/kernel-2.6.21-1.3228.fc7.src.rpm > > > > Wrote: /usr/src/redhat/RPMS/i386/kernel- > headers-2.6.21-1.3228.fc7.i386.rpm > > > > > > > > (this was tested with the F7 kernel source but i also tested it with > > > > the F8 kernel source. both have the same result as above.. just > > > > another version) > > > > > > > > and more but that's what i want to know. now when running the > rpmbuild > > > > line i expected the full kernel to be compiled.. not just the > headers > > > > and the source rpm. so the question is: how do i compile the kernel > > > > the fedora way? > > > > > > > > or is this the way how it should be done: > > > > http://www.howtoforge.com/kernel_compilation_fedora if that's the > case > > > > i will just follow that tutorial. but this (couldn't find it on the > > > > wiki) is important information to get in the fedora wiki. > > > > > > > > And the reason why i want to have this new kernel is mainly because > > > > iwl (whatever the name was) just the wireless drivers that should be > > > > alot more stable in this kernel than in 2.6.21 > > > > > > > > > > This will help you:: > > > http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Kernel.html > > > > > > In your specific case you're missing the --target $(uname -m) > > > > > > -Toshio > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayvd at bludgeon.org Wed Jul 4 17:50:50 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 4 Jul 2007 10:50:50 -0700 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468B74E5.10207@nicubunu.ro> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> <468B74E5.10207@nicubunu.ro> Message-ID: <20070704175050.GA476@bludgeon.org> On Wed, Jul 04, 2007 at 01:22:29PM +0300, Nicu Buculei wrote: > Valent Turkovic wrote: > > Starting a default browser app is like a roulet - you see an icon but > > you place bets before clicking it and then see what app starts after you > > Not at all, after a default install the icon will start Firefox and this > does not change until you go to change the default manually (or unistall > Firefox, if that was possible, but isn't) > > > click it. It should be unambiguous which apps starts from just looking > > at the icon. If it is firefox it should be firefox icon, if it is other > > It is unambiguous: the default web browser is launched. This is a > task-oriented philosophy instead of application-oriented. > In the same vein, the menu option titled "Word Processor" will launch OOo > Writer and Movie Player will launch Totem, it is not a discrimination > against Firefox. > > > some other browser that the icon should be also changer to it's default > > icon. Perhaps the htmlview icon could somehow be "symlinked" to the icon for whichever browser is default. So the user sees the Firefox icon .. or Mozilla, or whichever they have configured as default. Ray From a.badger at gmail.com Wed Jul 4 17:54:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Jul 2007 10:54:37 -0700 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: <1183570332.2806.25.camel@kennedy> References: <1183568158.2806.22.camel@kennedy> <1183569692.3628.30.camel@localhost.localdomain> <1183570332.2806.25.camel@kennedy> Message-ID: <1183571677.3628.33.camel@localhost.localdomain> We should vote to change the voting method to Approval Voting for the upcoming election as well:: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02822.html -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 bpepple at fedoraproject.org Wed Jul 4 18:08:37 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jul 2007 14:08:37 -0400 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: <1183571677.3628.33.camel@localhost.localdomain> References: <1183568158.2806.22.camel@kennedy> <1183569692.3628.30.camel@localhost.localdomain> <1183570332.2806.25.camel@kennedy> <1183571677.3628.33.camel@localhost.localdomain> Message-ID: <1183572517.2806.27.camel@kennedy> On Wed, 2007-07-04 at 10:54 -0700, Toshio Kuratomi wrote: > We should vote to change the voting method to Approval Voting for the > upcoming election as well:: > > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02822.html Added to the schedule. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 kwhiskerz at yahoo.ca Wed Jul 4 18:20:19 2007 From: kwhiskerz at yahoo.ca (kwhiskerz) Date: Wed, 4 Jul 2007 12:20:19 -0600 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 Message-ID: <200707041220.19120.kwhiskerz@yahoo.ca> The bottom line is: Beagle serves no useful purpose (ever heard of directory hierarchies to keep information so that you can easily find it?), it takes up a lot of disk space, it uses processor time - loads of it, and it archives and collects information that poses a risk of breach of personal privacy. Furthermore, why would I want to index stuff on the web, even if I did want to index the material on my own computer? Google already does that. No, no no! From fedora at leemhuis.info Wed Jul 4 18:21:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jul 2007 20:21:24 +0200 Subject: EPEL branching if Fedora maintainer does not react (was: Re: Plan for tomorrows (20070705) FESCO meeting) In-Reply-To: <1183568158.2806.22.camel@kennedy> References: <1183568158.2806.22.camel@kennedy> Message-ID: <468BE524.9020604@leemhuis.info> On 04.07.2007 18:55, Brian Pepple wrote: > [...] > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule [...] Just a heads up -- the EPEL Steering Committee today decided this: ---- EPEL branching if Fedora maintainer does not react If an EPEL maintainer wants to get a Fedora package into EPEL he should first check if he the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus . If the Fedora maintainer of the package has indicated there a desire not to participate in EPEL then the EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently). The EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. If it's unclear if the Fedora maintainer of the package participates in EPEL then the EPEL maintainer should mail the Fedora maintainer and ask about their plans for EPEL in general and the package at hand. If there is no answer within seven days the EPEL maintainer is free to request the EPEL branch (CC the Fedora maintainer here as well). If the Fedora maintainer later wants to participate in EPEL in general and maintain this package, then the EPEL maintainer of the package should hand primary per release maintainership back to the Fedora maintainer (and become comaintainer, if interested). ---- If that's not okay for FESCo or those reading this mail please speak up now before EPEL maintainers start acting according to it (note that I send a variant of this text this this list one week ago as RFC; no replies). CU thl From bpepple at fedoraproject.org Wed Jul 4 18:32:27 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Jul 2007 14:32:27 -0400 Subject: EPEL branching if Fedora maintainer does not react (was: Re: Plan for tomorrows (20070705) FESCO meeting) In-Reply-To: <468BE524.9020604@leemhuis.info> References: <1183568158.2806.22.camel@kennedy> <468BE524.9020604@leemhuis.info> Message-ID: <1183573947.2806.29.camel@kennedy> On Wed, 2007-07-04 at 20:21 +0200, Thorsten Leemhuis wrote: > > Just a heads up -- the EPEL Steering Committee today decided this: > > ---- > > EPEL branching if Fedora maintainer does not react > > If an EPEL maintainer wants to get a Fedora package into EPEL he should > first check if he the ContributorStatus document, located in the wiki at > http://fedoraproject.org/wiki/EPEL/ContributorStatus . > > If the Fedora maintainer of the package has indicated there a desire not > to participate in EPEL then the EPEL maintainer can request the branch > directly via the standard procedures (e.g. via bugzilla currently). The > EPEL maintainer should CC the Fedora maintainer on the branch request, > so the Fedora maintainer knows that the package is maintained in EPEL as > well. > > If it's unclear if the Fedora maintainer of the package participates in > EPEL then the EPEL maintainer should mail the Fedora maintainer and ask > about their plans for EPEL in general and the package at hand. If there > is no answer within seven days the EPEL maintainer is free to request > the EPEL branch (CC the Fedora maintainer here as well). If the Fedora > maintainer later wants to participate in EPEL in general and maintain > this package, then the EPEL maintainer of the package should hand > primary per release maintainership back to the Fedora maintainer (and > become comaintainer, if interested). > > ---- > > If that's not okay for FESCo or those reading this mail please speak up > now before EPEL maintainers start acting according to it (note that I > send a variant of this text this this list one week ago as RFC; no > replies). I've got no problem with it. Seems like a reasonable policy. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 linux_4ever at yahoo.com Wed Jul 4 19:29:02 2007 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 4 Jul 2007 12:29:02 -0700 (PDT) Subject: rsyslog in f8? In-Reply-To: <468BA4BE.7020100@fedoraproject.org> Message-ID: <847233.73537.qm@web51511.mail.re2.yahoo.com> >Would be better to push this into Fedora 7 too I think. Makes it easier >to transition to a newer version. The config file format is backwards compatible. So, its not strictly necessary to change your config or adapt to it. We have the spec files set to obsolete sysklogd. So, that would have to be different for F7. In a way, I think its best to put rsyslog in rawhide targeted for f8, and deprecate sysklogd at the same time. IOW F7 is the end of the line for sysklogd. -Steve ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From linux_4ever at yahoo.com Wed Jul 4 19:32:11 2007 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 4 Jul 2007 12:32:11 -0700 (PDT) Subject: rsyslog in f8? In-Reply-To: <1183500744.5894.2.camel@sb-home> Message-ID: <893665.49864.qm@web51505.mail.re2.yahoo.com> >Does rsyslog support store and forward logging? Not that I know of. However, its under active development and you could probably ask the upstream mail list if this is on their roadmap. :) -Steve ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From linux_4ever at yahoo.com Wed Jul 4 19:36:27 2007 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 4 Jul 2007 12:36:27 -0700 (PDT) Subject: rsyslog in f8? In-Reply-To: <200707031446.09235.jkeating@redhat.com> Message-ID: <20070704193627.84988.qmail@web51508.mail.re2.yahoo.com> >Instead of looking at this as a 'new default logger', perhaps it would be >better to look at this as a 'rsyslogd is obsoleting sysklogd'. Exactly. We don't need to maintain a new and deprecated syslogger. > Think of it purely within the scope of one package is replacing the other, due > to things like sysklogd being dead upstream. In that context, we can do the > replacement now and be happy. I think we would like to make the switch as soon as possible to maximize the amount of testing it will get before everyone depends on it. We are losing testing everyday that goes by. -Steve ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From Axel.Thimm at ATrpms.net Wed Jul 4 19:47:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 4 Jul 2007 21:47:06 +0200 Subject: Plan for tomorrows (20070705) FESCO meeting In-Reply-To: <1183568158.2806.22.camel@kennedy> References: <1183568158.2806.22.camel@kennedy> Message-ID: <20070704194706.GA11183@puariko.nirvana> On Wed, Jul 04, 2007 at 12:55:58PM -0400, Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- Feature Policy Draft - > http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft > > /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-meeting -- Statically link libuu (uulib-static) into > klibido -- tibbs -- > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218599 > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). Early discuss mass rebuilds? > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > Thanks, > /B -- 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 nicolas.mailhot at laposte.net Wed Jul 4 20:11:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Jul 2007 22:11:00 +0200 Subject: [Fwd: F7: Howto monitoring a Hardware sata raid controller] In-Reply-To: References: <1183543723.5223.29.camel@lesca.home.solinos.it> <1183569556.2633.1.camel@laptopd505.fenrus.org> Message-ID: <1183579860.3774.1.camel@rousalka.dyndns.org> Le mercredi 04 juillet 2007 ? 12:36 -0500, Jason L Tibbitts III a ?crit : > I don't know if there's any sort of functionality like the drive > scrubbing that 3ware cards have. If you are using md (not dm) software raid: # system/data every 10 days at 02:30 30 2 */10 * * root echo check >> /sys/block/md1/md/sync_action -- 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 debarshi.ray at gmail.com Wed Jul 4 20:20:21 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 5 Jul 2007 01:50:21 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: <468BD3BB.6080508@fedoraproject.org> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> <468BD3BB.6080508@fedoraproject.org> Message-ID: <3170f42f0707041320x415a7407v9697daefe58db727@mail.gmail.com> > Rum (The original one, not Debarshi's) did have easy command line > arguments for disabling/enabling repositories in a persistent manner. > They probably have custom code to do this but you might want to take a > look at that. Thanks for the pointer. The RUM (original one) code looks much more cleaner to me than Yumex's and is smaller in size too. Let me see if I can integrate this into the YUM API. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From giallu at gmail.com Wed Jul 4 22:19:43 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 5 Jul 2007 00:19:43 +0200 Subject: package files marked as documentation Message-ID: Hi, I am striving to understand why in the mantis package (a php application) most files are marked as documentation [1] though they are not. I am quite sure there isa stupid mistake in the spec file[1], but I'm not able to locate it. Any help appreciated. [1] or ,at least, that's what "rpm -q --docfiles mantis" reports. [2] http://cvs.fedora.redhat.com/viewcvs/devel/mantis/mantis.spec?rev=1.16&view=log From christoph.wickert at nurfuerspam.de Wed Jul 4 22:38:58 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Thu, 05 Jul 2007 00:38:58 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183558378.23976.400.camel@mccallum.corsepiu.local> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> <1183558378.23976.400.camel@mccallum.corsepiu.local> Message-ID: <1183588738.3433.95.camel@wicktop.localdomain> Am Mittwoch, den 04.07.2007, 16:12 +0200 schrieb Ralf Corsepius: > You mean, you know, somebody who sells heroine or plutonium, so you're > going to package it for Fedora? ;) Can somebody please make this the new topic for #fedora-devel ;) Chris From hawat.thufir at gmail.com Wed Jul 4 22:48:42 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 4 Jul 2007 22:48:42 +0000 (UTC) Subject: a legal way to include 3rd party repositories in fedora? References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: On Wed, 04 Jul 2007 15:23:17 -0200, Thomas M Steenholdt wrote: > The thing is, that the purpose of the Fedora distribution is to be as > clean as possible, when it comes to things like this. Even if means that > a few things won't "work" straight out of the box, it's better than > "contaminating" the distribution with potentially problematic stuff. > > So in most cases (if not all), you'll find that these things are > excluded on purpose and cannot be included without violating the Fedora > policy. I, for one, applaud the exclusion of these things. However, the question is: can't it be made easier to add those potentially contaminated third party repos? Is this a legal issue or a policy? -Thufir From christoph.wickert at nurfuerspam.de Wed Jul 4 22:53:58 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Thu, 05 Jul 2007 00:53:58 +0200 Subject: Realtek 8185 wireless card In-Reply-To: <1183531973.13139.3.camel@T7.Linux> References: <1183531973.13139.3.camel@T7.Linux> Message-ID: <1183589638.3433.101.camel@wicktop.localdomain> Am Mittwoch, den 04.07.2007, 07:52 +0100 schrieb Paul: > Hi, > > Is there an out the box driver for the realtek 8185 wireless chipset > available under rawhide or do I need to use ndiswrapper and some other > magic to get it working? AFAIK it's not supported in rawhide, but there is a GPL'ed linux driver available from http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=1&PFid=1&Level=6&Conn=5&DownTypeID=3&GetDown=false&Downloads=true#352 Chris From hawat.thufir at gmail.com Wed Jul 4 22:53:45 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 4 Jul 2007 22:53:45 +0000 (UTC) Subject: Here are some of my ideas for Fedora 8 and Fedora 9 References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> Message-ID: On Wed, 04 Jul 2007 12:13:47 +0200, Valent Turkovic wrote: > Starting a default browser app is like a roulet - you see an icon but > you place bets before clicking it and then see what app starts after you > click it. It should be unambiguous which apps starts from just looking > at the icon. this is a taste issue. I prefer firefox, but others may have a different preference. I also prefer to not make things a hassle for those with different preferences. Not everything can be one click automagical. Having firefox as the default is an improvement, but why lock it down for others? -Thufir From hawat.thufir at gmail.com Wed Jul 4 22:58:49 2007 From: hawat.thufir at gmail.com (Thufir) Date: Wed, 4 Jul 2007 22:58:49 +0000 (UTC) Subject: Here are some of my ideas for Fedora 8 and Fedora 9 References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183553384.3677.47.camel@wicktop.localdomain> Message-ID: On Wed, 04 Jul 2007 14:49:44 +0200, Christoph Wickert wrote: > Although this is a good idea I'm not sure how to achieve this > technically: Yes, there is an IRC url scheme [1], but I'm not sure if > all desktops are able to open IRC links. Other questions are: What > application should be used to open this link and how to we make sure > this application really is installed? I would really like this for a rescue situation, so that I don't have to register nick's and muck around trying to remember my nick and password. For total newbies, it'd be good too. I imagine that it wouldn't that significant of a burden. Over on the user list, the OP mentioned Sabayon doing this. Pidgin is in the live cd and would work fine for this, to my knowledge. It would have to be something in the live cd. I see it more as a live-cd thing rather than necessary on an actual install. -Thufir From tibbs at math.uh.edu Wed Jul 4 23:06:00 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jul 2007 18:06:00 -0500 Subject: package files marked as documentation In-Reply-To: References: Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> Hi, I am striving to understand why in the mantis package (a php GS> application) most files are marked as documentation [1] though GS> they are not. Funny. Note how "/usr/share/mantis" looks a lot like "/usr/share/man". GS> I am quite sure there isa stupid mistake in the spec file[1], but GS> I'm not able to locate it. Nope, looks like an RPM bug. - J< From sundaram at fedoraproject.org Wed Jul 4 23:06:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Jul 2007 04:36:46 +0530 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <1183547065.23976.382.camel@mccallum.corsepiu.local> <1183557943.5484.126.camel@fedora> Message-ID: <468C2806.3000705@fedoraproject.org> Thufir wrote: > > However, the question is: can't it be made easier to add those > potentially contaminated third party repos? Is this a legal issue or a > policy? If you mean by easier, a direct reference to a third party repository, then it both a potential legal issue and a matter of policy. I would suggest that folks curious about all these refer to list archives because we have gone through this dozens of times before. There has been some things that we are pursuing to look at what we could potentially change from time to time though but this is a pretty complicated issue that involves a nice mix of Fedora policies that are in favor of Free and open source software and potential issues with copyright and patent laws. Rahul From jkeating at redhat.com Thu Jul 5 02:08:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 4 Jul 2007 22:08:12 -0400 Subject: Thursday releases (was Re: Fedora Rel-Eng Meeting Recap 2007-JUL-02) In-Reply-To: <468B2615.2010603@leemhuis.info> References: <468A790F.7050204@redhat.com> <468B2615.2010603@leemhuis.info> Message-ID: <200707042208.17200.jkeating@redhat.com> On Wednesday 04 July 2007 00:46:13 Thorsten Leemhuis wrote: > Just wondering: Why target a Thursday as release date? With the "Don't > release on Fridays, Weekends and Mondays" approach that we had in the > past (and likely still have?) we would have to slip five days if there > is a important bug found in the last minute that requires to respin and > slip one day. Thursday is the target. We thought of Tuesday, but more often than not we're not ready by Tuesday and would slip to Thursday anyway. If we get done earlier, we just give mirrors more time to sync up. -- 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 Jul 5 02:12:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 4 Jul 2007 22:12:27 -0400 Subject: Where did the Fedora 8 CVS go to? In-Reply-To: <200707041545.00111.opensource@till.name> References: <6e24a8e80707040619t6291bafeo5714d2ed46391655@mail.gmail.com> <2294.192.54.193.51.1183556243.squirrel@rousalka.dyndns.org> <200707041545.00111.opensource@till.name> Message-ID: <200707042212.27652.jkeating@redhat.com> On Wednesday 04 July 2007 09:44:55 Till Maas wrote: > No, no, no, everything is in pkgs now. To which 'extras' is a symlink to (: -- 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 pmatilai at laiskiainen.org Thu Jul 5 06:46:43 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 5 Jul 2007 09:46:43 +0300 (EEST) Subject: package files marked as documentation In-Reply-To: References: Message-ID: On Thu, 4 Jul 2007, Jason L Tibbitts III wrote: >>>>>> "GS" == Gianluca Sforna writes: > > GS> Hi, I am striving to understand why in the mantis package (a php > GS> application) most files are marked as documentation [1] though > GS> they are not. > > Funny. Note how "/usr/share/mantis" looks a lot like "/usr/share/man". > > GS> I am quite sure there isa stupid mistake in the spec file[1], but > GS> I'm not able to locate it. > > Nope, looks like an RPM bug. Indeed. Please bugzilla this. - Panu - From pmatilai at laiskiainen.org Thu Jul 5 06:51:20 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 5 Jul 2007 09:51:20 +0300 (EEST) Subject: Massive size increases in certain packages In-Reply-To: <468B537E.8000101@hhs.nl> References: <464CBCA2.8050500@cora.nwra.com> <464D607E.1050307@hhs.nl> <464DD1E2.5080900@cora.nwra.com> <464DE424.6080407@hhs.nl> <1179514701.26613.35.camel@localhost.localdomain> <1179762016.3547.91.camel@enki.eridu> <1179763650.3547.92.camel@enki.eridu> <468B537E.8000101@hhs.nl> Message-ID: On Wed, 4 Jul 2007, Hans de Goede wrote: > Paul Nasrat wrote: >> On Mon, 2007-05-21 at 18:00 +0200, Goede, J.W.R. de wrote: >> >>> Well, >>> >>> I can confirm that this does NOT work properly on a recent >>> rawhide system. >>> >>> Maybe the problem is that I exclude dirs, and that the size >>> calculation still dives into the dir, and doesn't see the >>> files in there as excluded? >> >> Yeah that seems to be the case, can you come up with a simple test spec >> reproducer and file in bugzilla please. >> >> Paul > > Hi Paul, > > Sometime ago we had the above discussion, should I still BZ this, ifso in > which BZ, RH or rpm.org? Paul's on vacation but yeah, please bugzilla. rpm.org doesn't at the moment have it's own bug tracking so just use RH BZ. - Panu - From sundaram at fedoraproject.org Thu Jul 5 07:46:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Jul 2007 13:16:57 +0530 Subject: Suggestion: Disk Druid changes In-Reply-To: <468A556D.7030102@verizon.net> References: <468A556D.7030102@verizon.net> Message-ID: <468CA1F1.4060009@fedoraproject.org> Gerry Reno wrote: > Hi all, > As I mentioned in another post, I have been using a technique that at > least for me greatly simplifies moving to and from RAID-1 on any > system. I do this by installing the system on a degraded RAID-1 array > and then later it is very simple to make the system true RAID by just > adding the missing drive/partitions. > > From the other Fedora 8/9 wishlist post: > Another thing in Disk Druid that I would like to see is the ability to > install on a degraded RAID-1 array where I declare RAID-1 but then the > second mirror is missing. I install this way all the time on systems > and then when I add the second hard drive later and place it into the > array, it just syncs. Want to go back to just a single drive - no > problem. Just fault the device and remove it. No complicated > remounting filesystems or anything - very smooth. This way you're > always on an md device. I would like to see this actually become the > default. It makes it very easy to convert a system to RAID-1 later on > if the user would like to do so without any complicated procedures > necessary. You might want to file RFE's in http://bugzilla.redhat.com. Rahul From drago01 at gmail.com Thu Jul 5 07:47:07 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 05 Jul 2007 09:47:07 +0200 Subject: rsyslog in f8? In-Reply-To: <20070704193627.84988.qmail@web51508.mail.re2.yahoo.com> References: <20070704193627.84988.qmail@web51508.mail.re2.yahoo.com> Message-ID: <468CA1FB.2030202@gmail.com> Steve G wrote: > I think we would like to make the switch as soon as possible to > maximize the > amount of testing it will get before everyone depends on it. We are losing > testing everyday that goes by. > +1 just go ahead and do it. From sundaram at fedoraproject.org Thu Jul 5 07:49:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Jul 2007 13:19:27 +0530 Subject: EPEL branching if Fedora maintainer does not react In-Reply-To: <468BE524.9020604@leemhuis.info> References: <1183568158.2806.22.camel@kennedy> <468BE524.9020604@leemhuis.info> Message-ID: <468CA287.9060008@fedoraproject.org> Thorsten Leemhuis wrote: . If the Fedora > maintainer later wants to participate in EPEL in general and maintain > this package, then the EPEL maintainer of the package should hand > primary per release maintainership back to the Fedora maintainer (and > become comaintainer, if interested). This in essence would mean that the Fedora maintainer can essentally take over the EPEL branch even if there are long term contributors who have taken a good interest and contribute well to EPEL. Why is that desirable? Rahul From giallu at gmail.com Thu Jul 5 07:59:34 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 5 Jul 2007 09:59:34 +0200 Subject: package files marked as documentation In-Reply-To: References: Message-ID: On 7/5/07, Panu Matilainen wrote: > > GS> I am quite sure there isa stupid mistake in the spec file[1], but > > GS> I'm not able to locate it. > > > > Nope, looks like an RPM bug. > > Indeed. Please bugzilla this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246819 thanks for your help. From fedora at leemhuis.info Thu Jul 5 08:06:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Jul 2007 10:06:43 +0200 Subject: EPEL branching if Fedora maintainer does not react In-Reply-To: <468CA287.9060008@fedoraproject.org> References: <1183568158.2806.22.camel@kennedy> <468BE524.9020604@leemhuis.info> <468CA287.9060008@fedoraproject.org> Message-ID: <468CA693.8020508@leemhuis.info> On 05.07.2007 09:49, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > . If the Fedora >> maintainer later wants to participate in EPEL in general and maintain >> this package, then the EPEL maintainer of the package should hand >> primary per release maintainership back to the Fedora maintainer (and >> become comaintainer, if interested). > This in essence would mean that the Fedora maintainer can essentally > take over the EPEL branch even if there are long term contributors who > have taken a good interest and contribute well to EPEL. Why is that > desirable? It's not. There was a "within some weeks want to participate in EPEL" in one of the drafts, but seems I deleted it myself accidentally. I'll bring that up in a EPEL SIG meeting soon, but for now this will become policy. CU thl From kanarip at kanarip.com Thu Jul 5 09:04:02 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 05 Jul 2007 11:04:02 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183537704.5484.53.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> <468A5B41.4040106@kanarip.com> <1183537704.5484.53.camel@fedora> Message-ID: <468CB402.7070704@kanarip.com> Valent Turkovic wrote: > On Tue, 2007-07-03 at 16:20 +0200, Jeroen van Meeuwen wrote: >> Turning evil on your (potential) userbase doesn't help anybody either. > > I'm just a fedora user, I don't have a userbase, yet :) > I'm not a beagle devel, just one concerned fedora desktop user. > As an advocate for beagle you pretty much have a user base (maybe it's a language barrier on my side and I should have said 'an audience'). Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Thu Jul 5 09:06:58 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 05 Jul 2007 11:06:58 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <20070704085212.GA11680@orient.maison.lan> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> Message-ID: <468CB4B2.9030802@kanarip.com> Emmanuel Seyman wrote: > * Valent Turkovic [04/07/2007 10:45] : >>> * Firefox to have it's original icon in gnome panel >>> >>> I can only guess this is a licensing issue a-la-iceweasel. >> Nope. Firefox icon is present on firefox shortcut in gnome menu. > > The Firefox icon in the menu launches firefox. > > The Web browser icon in the gnome panel lauches htmlview which in turn > launches whatever your favourite web browser is (the default is firefox > but that's easily changed) so I'm not sure changing the icon is justified. > I'm sure it's not, but the point was (I think), to have the icon change under certain circumstances: 1) there is only one browser installed 2) preferences are changed This way, the icon-change makes sense to me. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Thu Jul 5 09:23:16 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 05 Jul 2007 11:23:16 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183543721.5484.64.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5ABF.1050801@kanarip.com> <468A5FE8.3070707@kanarip.com> <1183543721.5484.64.camel@fedora> Message-ID: <468CB884.9030006@kanarip.com> Valent Turkovic wrote: > On Tue, 2007-07-03 at 16:40 +0200, Jeroen van Meeuwen wrote: >> Replying to myself, I see my ~/rpmbuild (which I /happily/ use as an >> archive) is being indexed with: >> >> /usr/lib/rpm/rpmq -q --package --queryformat [%{*:xml}?] /path/to/rpm >> >> Apparently it's threaded, because this one happily consuming 100% CPU, >> happily locking up my funky beryl desktop. Then it seems beagle-helper >> catches some output because it gets too excited and happily consumes >> like 20% CPU next to the 100-20% CPU being consumed by the other happy >> process. >> >> Thanks for the reminder, sometime in the future I'll try again. > > Please look at this video: > http://www.youtube.com/watch?v=b8P_X8UK2fQ > No. > is the use-case you are having really a bug? Yes. If not a bug, it's a feature that makes me not use beagle. Beagle has to index files > in order to make desktop search possible. Every process that actually > does something uses 100% of the cpu - only issue is how well it plays > with the desktiop. Beagle should be running a high NICE so it shouldn't > impact your desktop experience while it indexes files... > To me your experience with beagle just shows that beagle is working and > it doesn't show that beagle is buggy and kills your system. > Fine. We have different opinions. If beagle is unable to nice/renice the child processes it launches then that is a blocker for me. If it's installed I'll remove it. Regardless of whether one of us thinks it's either a bug or a feature: You requested someone to show you how beagle doesn't work for anyone. I've given you my use case. Knock yourself out. EOF Kind regards, Jeroen van Meeuwen -kanarip From andy at warmcat.com Thu Jul 5 09:23:25 2007 From: andy at warmcat.com (Andy Green) Date: Thu, 05 Jul 2007 10:23:25 +0100 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <200707041315.51788@rineau.tsetse> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <468A5FE8.3070707@kanarip.com> <1183543721.5484.64.camel@fedora> <200707041315.51788@rineau.tsetse> Message-ID: <468CB88D.3030800@warmcat.com> Laurent Rineau wrote: >> is the use-case you are having really a bug? Beagle has to index files >> in order to make desktop search possible. Every process that actually >> does something uses 100% of the cpu - only issue is how well it plays > Exhibiting one case where does things nicely is not a justification. Yes... how many billions of CPU cycles should it take to strip some plain text out of a PDF? Maybe the fault isn't with Beagle but a child process but the result in front of the user is the same. Besides the even bigger problem with Beagle is it pulls in Mono, you need a new language to index files now? -Andy From buildsys at redhat.com Thu Jul 5 10:37:58 2007 From: buildsys at redhat.com (Build System) Date: Thu, 5 Jul 2007 06:37:58 -0400 Subject: rawhide report: 20070705 changes Message-ID: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> New package c2070 Converts bitcmyk data to Lexmark 2070 printer language New package cjet Converts PCL data to Canon CaPSL III printer language New package drawtiming A command line tool for generating timing diagrams New package pbm2l2030 Converts PBM stream to Lexmark 2030 printer language New package perl-Text-Markdown A text-to-HTML filter New package stardict-dic-ja Japanese(ja) dictionaries for StarDict New package stardict-dic-ru Russian(ru) dictionaries for StarDict New package stardict-dic-zh_CN Simplified Chinese(zh_CN) dictionaries for StarDict New package stardict-dic-zh_TW Traditional Chinese(zh_TW) dictionaries for StarDict New package tailor A tool to migrate changesets between several version control systems New package xzgv A GTK+/Imlib-based picture viewer for X Updated Packages: Pound-2.4-0.1.c.fc8 ------------------- * Mon Jun 04 2007 Ruben Kerkhof 2.4.0-1c - Upstream released new version TeXmacs-1.0.6.10-3.fc8 ---------------------- * Fri Jun 29 2007 Gerard Milmeister - 1.0.6.10-3 - ps generation fix abcm2ps-5.4.4-1.fc8 ------------------- * Wed Jul 04 2007 Gerard Milmeister - 5.4.4-1 - new version 5.4.4 at-3.1.10-13.fc8 ---------------- * Tue Jul 03 2007 Marcela Maslanova - 3.1.10-13 - Resolves: rhbz#243064 balsa-2.3.17-1.fc8 ------------------ * Wed Jul 04 2007 Pawel Salek - 2.3.17-1 - update to upstream 2.3.17. bash-3.2-10.fc8 --------------- * Wed Jul 04 2007 Tim Waugh 3.2-10 - Clarification in the ulimit man page (bug #220657). claws-mail-plugins-2.10.0-1.fc8 ------------------------------- * Tue Jul 03 2007 Andreas Bierfert - 2.10.0-1 - version upgrade coreutils-6.9-4.fc8 ------------------- * Wed Jul 04 2007 Tim Waugh 6.9-4 - Use hard links instead of symbolic links for LC_TIME files (bug #246729). cups-1:1.2.11-4.fc8 ------------------- * Wed Jul 04 2007 Tim Waugh 1:1.2.11-4 - Better paper-out detection patch still (bug #246222). dar-2.3.4-1.fc8 --------------- * Tue Jul 03 2007 Chris Petersen 2.3.4-1 - Update to 2.3.4 exim-4.67-2.fc8 --------------- * Wed Jun 27 2007 David Woodhouse 4.67-2 - Fix typo in config (#246799) exim-doc-4.67-1.fc8 ------------------- * Wed Jul 04 2007 David Woodhouse 4.67-1 - Update to 4.67 fedora-logos-6.0.98-5.fc8 ------------------------- * Wed Jul 04 2007 Florian La Roche 6.0.98-5 - require coreutils for the %post script file-4.21-2.fc8 --------------- * Wed Jul 04 2007 Martin Bacovsky - 4.21-2 - resolves: #246700: RPM description isn't related to product - resolves: #238789: file-devel depends on 4.21 but not on 4.21-2.fc8 - resolves: #235267: for core files, file doesn't display the executable name * Tue May 29 2007 Martin Bacovsky - 4.21-1 - upgrade to new upstream 4.21 - resolves: #241034: CVE-2007-2799 file integer overflow * Wed Mar 07 2007 Martin Bacovsky - 4.20-1 - upgrade to new upstream 4.20 gcc-4.1.2-15 ------------ * Wed Jul 04 2007 Jakub Jelinek 4.1.2-15 - update from gcc-4_1-branch (-r126008:126302) - PRs boehm-gc/21940, boehm-gc/21942, target/28307, target/32506, tree-optimization/31966, tree-optimization/32533 - merge in redhat/gcc-4_1-jdwp-merge-branch - JDWP support (Keith Seitz) - fix OpenMP handling of Fortran POINTER non-array vars (PR fortran/32550) gnokii-0.6.17-1.fc8 ------------------- * Wed Jul 04 2007 - Bastien Nocera - 0.6.17-1 - New upstream release kernel-2.6.22-0.9.rc7.git3.fc8 ------------------------------ * Wed Jul 04 2007 Dave Jones - 2.6.22-rc7-git3 * Wed Jul 04 2007 Dave Jones - x86-64 tickless support. lib765-0.4.0-1.fc8 ------------------ * Thu Jul 05 2007 Ian Chapman 0.4.0-1.fc8 - Upgrade to 0.4.0 - 'Escaped' several macros in the changelogs - Corrected summary for devel package libdsk-1.1.12-1.fc8 ------------------- * Wed Jul 04 2007 Ian Chapman 1.1.12-1.fc8 - Upgrade to 1.1.12 - Removed some extraneous 'docs' - Moved some docs to the devel sub package lightning-1.2-8.fc8 ------------------- * Wed Jul 04 2007 Jochen Schmitt 1.2-8 - Fix ppc execstack issue (#246732) * Wed Jul 04 2007 Jochen Schmitt 1.2-7 - Exclude ppc architecture (#246732) logwatch-7.3.6-3.fc8 -------------------- * Wed Jul 04 2007 Ivana Varekova 7.3.6-3 - add named, pam_unix and audit service patches lx-20030328-1.fc8 ----------------- rpm-4.4.2.1-0.4.rc2 ------------------- * Wed Jul 04 2007 Panu Matilainen 4.4.2.1-0.4.rc2 - 4.4.2.1-rc2 * Thu Jun 28 2007 Panu Matilainen 4.4.2.1-0.3.rc1 - don't hang because of leftover query iterators (#246044) * Tue Jun 26 2007 Panu Matilainen 4.4.2.1-0.2.rc1 - patch popt version to 1.10.2.1 for clean upgrade path - popt release follows main package release again tpb-0.6.4-8.fc8 --------------- * Tue Jul 03 2007 Kevin Fenzi - 0.6.4-8 - Remove obsolete 90-tpb.nodes file (fixes #245963) xchat-1:2.8.4-1.fc8 ------------------- * Wed Jul 04 2007 Kevin Kofler - 1:2.8.4-1 - update to 2.8.4 - drop xc282-fixtrayzombies.diff (already in 2.8.4) - rebase redhat-desktop and tray-icon patches Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kernel - 2.6.22-0.9.rc7.git3.fc8.i686 requires mkinitrd >= 0:6.0.9-7.1 kernel-PAE - 2.6.22-0.9.rc7.git3.fc8.i686 requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-Bit-Vector - 6.4-3.fc8.i386 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.i386 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.i386 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.2-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kernel - 2.6.22-0.9.rc7.git3.fc8.x86_64 requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Bit-Vector - 6.4-3.fc8.x86_64 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.x86_64 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.x86_64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.2-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kernel - 2.6.22-0.9.rc7.git3.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel - 2.6.22-0.9.rc7.git3.fc8.ppc requires mkinitrd >= 0:6.0.9-7.1 kernel-kdump - 2.6.22-0.9.rc7.git3.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel-smp - 2.6.22-0.9.rc7.git3.fc8.ppc requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Bit-Vector - 6.4-3.fc8.ppc requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.ppc requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.ppc requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kernel - 2.6.22-0.9.rc7.git3.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kernel-kdump - 2.6.22-0.9.rc7.git3.fc8.ppc64 requires mkinitrd >= 0:6.0.9-7.1 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) perl-Bit-Vector - 6.4-3.fc8.ppc64 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.ppc64 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) rpy - 0.4.6-16.fc7.ppc64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From nicolas.mailhot at laposte.net Thu Jul 5 11:16:38 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 5 Jul 2007 13:16:38 +0200 (CEST) Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468CB88D.3030800@warmcat.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <468A5FE8.3070707@kanarip.com> <1183543721.5484.64.camel@fedora> <200707041315.51788@rineau.tsetse> <468CB88D.3030800@warmcat.com> Message-ID: <20427.192.54.193.51.1183634198.squirrel@rousalka.dyndns.org> Le Jeu 5 juillet 2007 11:23, Andy Green a ?crit : > Yes... how many billions of CPU cycles should it take to strip some > plain text out of a PDF? Indexers such as beagle often have pathological behaviour when processing documents like .pdfs, because they do not write their own text strippers but reuse filters designed to preserve document structure & formatting. -- Nicolas Mailhot From Christian.Iseli at licr.org Thu Jul 5 13:08:55 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 5 Jul 2007 15:08:55 +0200 Subject: Fedora Package Status of Jul 4, 2007 Message-ID: <20070705150855.66c324ad@ludwig-alpha.unil.ch> Hi folks, This week's update. Changes from last week: - 50 more packages in owners.list - 20 less packages in NEW review requests - 96 more open BZ bug tickets I'm guessing we can start looking at closing or rejuvenating the fc5 BZ tickets. Any volunteers ? I'm also wondering a bit about the EPEL- and OLPC-only packages that are also listed in the Fedora owners.list: is it really the proper way to do things ? Enjoy, C Fedora Package Status of Jul 4, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4687 packages - 7688 binary rpms in devel - 108 orphans - 74 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtkdata Axel dot Thimm at ATrpms dot net vtk afb at users dot sourceforge dot net slim andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue andreas at bawue dot net perl-NetAddr-IP arozansk at redhat dot com edac-utils bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago bugs dot michael at gmx dot net audacious-plugin-fc cgoorah at yahoo dot com dot au drawtiming cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym dan at danny dot cz tailor dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask devrim at commandprompt dot com postgis foolish at guezz dot net perl-Net-Packet foolish at guezz dot net perl-SQLite-Simple gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils i at stingr dot net roundup icon at fedoraproject dot org mod_evasive jafo at tummy dot com python-mechanoid jafo at tummy dot com python-memcached jeff at ocjtech dot us perl-Text-Markdown jeff at ocjtech dot us sofsip-cli jeremy at hinegardner dot org libtomcrypt jeremy at hinegardner dot org libtommath jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client lkundrak at redhat dot com c2070 lkundrak at redhat dot com cjet lkundrak at redhat dot com pbm2l2030 lkundrak at redhat dot com lx lxtnow at gmail dot com gshutdown mastahnke at gmail dot com epel-release mmahut at redhat dot com sub2srt mpg at redhat dot com olpc-hardware-manager mpg at redhat dot com sugar mpg at redhat dot com sugar-presence-service mpg at redhat dot com xulrunner mpg at redhat dot com sugar-artwork mpg at redhat dot com sugar-datastore mpg at redhat dot com hulahop mpg at redhat dot com xapian-core mpg at redhat dot com pyxapian mpg at redhat dot com xapian-bindings mwringe at redhat dot com jrexx opensource at till dot name fcgi paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman pvrabec at redhat dot com rsyslog qspencer at ieee dot org suitesparse rpm at greysector dot net ekg2 rvokal at redhat dot com gaim-guifications silfreed at silfreed dot net qgis splinux at fedoraproject dot org drapes steve at silug dot org perl-Test-Output sundaram at redhat dot com olpc-utils terjeros at phys dot ntnu dot no xzgv vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wjhns174 at hardakers dot net perl-Crypt-OpenSSL-DSA xgl-maint at redhat dot com xorg-x11-drv-vermilion yufanyufan at gmail dot com audacious-plugins-docklet zhu at redhat dot com stardict-dic-zh_TW zhu at redhat dot com stardict-dic-ja zhu at redhat dot com stardict-dic-zh_CN zhu at redhat dot com stardict-dic-ru - 3 packages not available in devel but present in release caolanm at redhat dot com hunspell-he jorton at redhat dot com newt-perl notting at redhat dot com g-wrap - 6 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=222191,231861,244523 eclipse bkonrath at redhat.com cyrus-imapd tjanouse at redhat.com ddrescue splinux25 at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221717,224458,245649 agg caolanm at redhat.com libsilc wtogami at redhat.com gnome-password-generator debarshi.ray at gmail.com - 5 packages present in the development repo which have no owners entry audacious-docklet s390utils stardict-dic ufsparse ws-commons-util - 19 orphaned packages, yet available in devel docbook-dtds docbook-simple docbook-slides docbook-style-dsssl docbook-style-xsl docbook-utils driftnet gnome-bluetooth gob2 libbtctl libedit linuxdoc-tools luks-tools openjade opensp pam_usb udftools xmltex xmlto FE-ACCEPT packages stats: - 2790 accepted, closed package reviews - 46 accepted, closed package reviews not in repo - 7 accepted, closed package reviews not in owners - 92 accepted, open package reviews older than 4 weeks; - 109 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 223 open tickets - 77 tickets with no activity in eight weeks - 35 tickets with no activity in four weeks - 22 closed tickets FE-NEW packages stats: - 916 open tickets - 707 tickets with no activity in eight weeks - 49 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 50 open tickets - 5 tickets with no activity in eight weeks - 3 tickets with no activity in four weeks FE-LEGAL packages stats: - 2 open tickets - 1 tickets with no activity in eight weeks OPEN-BUGS packages stats: - 8188 open tickets - 5251 tickets with no activity in eight weeks - 971 tickets with no activity in four weeks CVS stats: - 4691 packages with a devel directory - 1 packages with no owners entry tdma - 203 packages were dropped from Fedora Maintainers stats: - 393 maintainers - 2 inactive maintainers with open bugs - 3 inactive maintainers Dropped Fedora packages: - 6 packages were dropped since Fedora 7 Comps.xml files stats: - 2409 packages in comps-f8 file - 1009 packages missing from comps-f8 file - 25 packages in comps-f8 but not in repo - 2389 packages in comps-f7 file - 992 packages missing from comps-f7 file - 30 packages in comps-f7 but not in repo From che666 at gmail.com Thu Jul 5 13:53:32 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 5 Jul 2007 15:53:32 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <1183425031.4113.4.camel@lt21223.campus.dmacc.edu> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> Message-ID: 2007/7/3, Valent Turkovic : > > There was a recent discussion on this topic and the decision was to > > remove Beagle from the default install because for too many users Beagle > > would suck up 100% CPU and leave the machine virtually unusable. See the > > archives for details. Once Beagle matures some more and causes fewer > > problems like this having Beagle in the default install can be > > reconsidered. > > > > Jeff > > > > The beagle was disabled (I'm on bugzilla for that beagle bug and also > I was active in discussions on mailing lists when that happened) but > IMHO the reasoning that was for it to not be installed by default > would make Fedora 7 look like Fedora Core 3 if it was applied to > fedora as a whole and not only to beagle. > > I have substantially tested beagle on 7 different desktops and had > ZERO problems. Also the bug in bugzilla is really vague. I have much > more problems with other features in Fedora 7; like user switcher > which, if you haven't used it, causes data losses and time losses. > When other user logs in then after some time first X session just > crashes taking all apps and all the work that has been going on there > down with it! This is a MUCH more severe bug that beagle can produce > and it is still installed by default on all Fedora 7 desktops. This is > inconsistent. Either don't include any of new fetures that aren't > rock-solid in Fedora 7, 8, 9, etc, or give us these great apps and > iron the bugs out along the was. Fedora team should have left beagle > installed an on by default and hunt down and squashed that bug. > > I contacted beagle maintainers for fedora and offered them my hand in > testing if beagle is now good enough for prime time. > here is the bugzilla link: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217031 > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241 > Skype: valent.turkovic > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > grab a dualcore laptop with 2gb of ram and a 100gb sata drive do svn checkouts until you have atleast a basic fedora system and 80gb full (around 50gb sourcecode) enable beagle then and tell me what happens if it starts to reindex... for me the system becomes then unusable for you. regards, Rudolf Kastl From greno at verizon.net Thu Jul 5 14:16:04 2007 From: greno at verizon.net (Gerry Reno) Date: Thu, 05 Jul 2007 10:16:04 -0400 Subject: Suggestion: Disk Druid changes In-Reply-To: <468CA1F1.4060009@fedoraproject.org> References: <468A556D.7030102@verizon.net> <468CA1F1.4060009@fedoraproject.org> Message-ID: <468CFD24.2070901@verizon.net> Rahul Sundaram wrote: > Gerry Reno wrote: >> Hi all, >> As I mentioned in another post, I have been using a technique that >> at least for me greatly simplifies moving to and from RAID-1 on any >> system. I do this by installing the system on a degraded RAID-1 >> array and then later it is very simple to make the system true RAID >> by just adding the missing drive/partitions. >> >> From the other Fedora 8/9 wishlist post: >> Another thing in Disk Druid that I would like to see is the ability >> to install on a degraded RAID-1 array where I declare RAID-1 but then >> the second mirror is missing. I install this way all the time on >> systems and then when I add the second hard drive later and place it >> into the array, it just syncs. Want to go back to just a single >> drive - no problem. Just fault the device and remove it. No >> complicated remounting filesystems or anything - very smooth. This >> way you're always on an md device. I would like to see this actually >> become the default. It makes it very easy to convert a system to >> RAID-1 later on if the user would like to do so without any >> complicated procedures necessary. > > You might want to file RFE's in http://bugzilla.redhat.com. > > Rahul > Rahul, Will do. Just wanted to see what kind of take up there was for the idea. Gerry From drago01 at gmail.com Thu Jul 5 14:32:30 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 5 Jul 2007 16:32:30 +0200 Subject: rawhide report: 20070705 changes In-Reply-To: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> References: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> Message-ID: On 7/5/07, Build System wrote: > > > kernel-2.6.22-0.9.rc7.git3.fc8 > ------------------------------ > * Wed Jul 04 2007 Dave Jones > - 2.6.22-rc7-git3 > > * Wed Jul 04 2007 Dave Jones > - x86-64 tickless support. > > I tested this one on my laptop (still uses f7) and it hangs at boot. after "Booting the kernel" no more errors, no panic it just don't continue to boot. Its a Zepto 6615WD with a Core 2 Duo T7400, ICH7 chipset running on x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Thu Jul 5 14:41:00 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 5 Jul 2007 16:41:00 +0200 Subject: rawhide report: 20070705 changes In-Reply-To: References: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> Message-ID: On 7/5/07, dragoran wrote: > > > > On 7/5/07, Build System wrote: > > > > > > kernel-2.6.22-0.9.rc7.git3.fc8 > > ------------------------------ > > * Wed Jul 04 2007 Dave Jones > > - 2.6.22-rc7-git3 > > > > * Wed Jul 04 2007 Dave Jones < davej at redhat.com> > > - x86-64 tickless support. > > > > > > I tested this one on my laptop (still uses f7) and it hangs at boot. after > "Booting the kernel" no more errors, no panic it just don't continue to > boot. > Its a Zepto 6615WD with a Core 2 Duo T7400, ICH7 chipset running on x86_64 > added CC, any idea how to get a message from the kernel to see whats going on? -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Thu Jul 5 14:50:54 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 5 Jul 2007 16:50:54 +0200 Subject: rawhide report: 20070705 changes In-Reply-To: References: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> Message-ID: On 7/5/07, dragoran wrote: > > > > On 7/5/07, dragoran wrote: > > > > > > > > On 7/5/07, Build System < buildsys at redhat.com> wrote: > > > > > > > > > kernel-2.6.22-0.9.rc7.git3.fc8 > > > ------------------------------ > > > * Wed Jul 04 2007 Dave Jones > > > - 2.6.22-rc7-git3 > > > > > > * Wed Jul 04 2007 Dave Jones < davej at redhat.com> > > > - x86-64 tickless support. > > > > > > > > > > I tested this one on my laptop (still uses f7) and it hangs at boot. > > after "Booting the kernel" no more errors, no panic it just don't continue > > to boot. > > Its a Zepto 6615WD with a Core 2 Duo T7400, ICH7 chipset running on > > x86_64 > > > > added CC, any idea how to get a message from the kernel to see whats going > on? > it boots when I pass "nohpet" to it. dmesg is attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dmesg.txt URL: From jkeating at redhat.com Thu Jul 5 15:11:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 11:11:53 -0400 Subject: init script bugs and changes Message-ID: <200707051111.53422.jkeating@redhat.com> Harald, I appreciate your dillagence in filing all these bugs, however I think a change like this needs to go through the Fedora Packaging Committee. You're asking folks to change content in init scripts when there hasn't been much / any discussion on the topic. If we're going to make this policy going forward, it really needs to be in the packaging guidelines, and approved by FESCo. -- 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 Jul 5 15:12:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 11:12:59 -0400 Subject: init script bugs and changes In-Reply-To: <200707051111.53422.jkeating@redhat.com> References: <200707051111.53422.jkeating@redhat.com> Message-ID: <200707051113.00021.jkeating@redhat.com> On Thursday 05 July 2007 11:11:53 Jesse Keating wrote: > I appreciate your dillagence That should be 'diligence'. -- 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 Thu Jul 5 15:38:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 05 Jul 2007 17:38:29 +0200 Subject: init script bugs and changes In-Reply-To: <200707051111.53422.jkeating@redhat.com> References: <200707051111.53422.jkeating@redhat.com> Message-ID: <468D1075.8010408@hhs.nl> Jesse Keating wrote: > Harald, I appreciate your dillagence in filing all these bugs, however I think > a change like this needs to go through the Fedora Packaging Committee. > You're asking folks to change content in init scripts when there hasn't been > much / any discussion on the topic. If we're going to make this policy going > forward, it really needs to be in the packaging guidelines, and approved by > FESCo. > > So where does that leave the receivers of said bugs, I assume we should wait until this has been discussed? Leave the bugs open in the mean time? Regards, Hans From jkeating at redhat.com Thu Jul 5 15:47:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 11:47:40 -0400 Subject: init script bugs and changes In-Reply-To: <468D1075.8010408@hhs.nl> References: <200707051111.53422.jkeating@redhat.com> <468D1075.8010408@hhs.nl> Message-ID: <200707051147.40376.jkeating@redhat.com> On Thursday 05 July 2007 11:38:29 Hans de Goede wrote: > So where does that leave the receivers of said bugs, I assume we should > wait until this has been discussed? Leave the bugs open in the mean time? Yes, I would recommend leaving the bugs open and untouched for the time being until this is sorted out. -- 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 pertusus at free.fr Thu Jul 5 16:06:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 5 Jul 2007 18:06:51 +0200 Subject: init script bugs and changes In-Reply-To: <200707051111.53422.jkeating@redhat.com> References: <200707051111.53422.jkeating@redhat.com> Message-ID: <20070705160651.GG22240@free.fr> On Thu, Jul 05, 2007 at 11:11:53AM -0400, Jesse Keating wrote: > Harald, I appreciate your dillagence in filing all these bugs, however I think > a change like this needs to go through the Fedora Packaging Committee. > You're asking folks to change content in init scripts when there hasn't been > much / any discussion on the topic. If we're going to make this policy going > forward, it really needs to be in the packaging guidelines, and approved by > FESCo. Having LSB compliant init scripts seems to me to be a good thing in most cases, even though it should certainly not be mandatory, so why not let maintainers act on the bugreports? And keep it open for those who don't want to do anything without a policy. -- Pat From d.lesca at solinos.it Thu Jul 5 16:30:20 2007 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 05 Jul 2007 18:30:20 +0200 Subject: [Fwd: F7: Howto monitoring a Hardware sata raid controller] In-Reply-To: <1183543723.5223.29.camel@lesca.home.solinos.it> References: <1183543723.5223.29.camel@lesca.home.solinos.it> Message-ID: <1183653020.3797.36.camel@lesca.home.solinos.it> Il giorno mer, 04/07/2007 alle 12.08 +0200, Dario Lesca ha scritto: > Please someone can tell to me somethings ? Thanks for all your reply! But now I 'm a little bit confuse.... RAID md..... (mdadm, /proc/mdstat, init.d/mdmonitor, mdadm.conf, ecc) RAID dm..... (dmraid, dmraid.static, /dev/dm-0, /dev/dm-1, ecc) My kind of RAID is a Software Raid or hardare? MD: When I install Fc6 on this system, I must create a software raid on 2 disk. The system when boot see the raid device like /dev/md0 ecc (md..). I can use the mdadm tools for manage the raid, and I have a service for monitoring the raid state (mdmonitor) witch send to me a mail, and open/close many time the cdrom, and print on all printers the problem, and play some .ogg files, and ...... DM: When I install F7 I see in anaconda the RAID done and I not see 2 disk but one RAID. The system when boot see the raid whit /dev/mapper/ddf1_raid1p1 device. I can use the dmraid tools for monitoring the raid state. .... And the service for monitoring some kind of problem? there is or not? I must build some shell to put in crontab or inittab? SMART: Smart monitoring the disk state, and not the RAID state ... right? Then: How I can do for receive some type of warning when problems are manifested on the RAID? Many thanks to all... -- Dario Lesca From linux_4ever at yahoo.com Thu Jul 5 16:33:17 2007 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 5 Jul 2007 09:33:17 -0700 (PDT) Subject: konqueror backtraces Message-ID: <550155.99686.qm@web51504.mail.re2.yahoo.com> Hi, I'm trying to chase down some KDE bugs in rawhide and installed the debuginfo packages. But I constantly get this message on my x86_64 machine when konqueror crashes on malformed html: "This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash." Is KDE built wrong? -Steve ____________________________________________________________________________________ Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php From rc040203 at freenet.de Thu Jul 5 16:35:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Jul 2007 18:35:18 +0200 Subject: owners owners.list,1.3233,1.3234 In-Reply-To: <200707040603.l6463wfr006143@cvs-int.fedora.redhat.com> References: <200707040603.l6463wfr006143@cvs-int.fedora.redhat.com> Message-ID: <1183653318.22644.22.camel@mccallum.corsepiu.local> Kevin, On Wed, 2007-07-04 at 02:03 -0400, Kevin Fenzi wrote: > Author: kevin > > Update of /cvs/pkgs/owners > In directory cvs-int.fedora.redhat.com:/home/fedora/kevin/owners > > Modified Files: > owners.list > Log Message: > Add perl-Text-Markdown > > > > Index: owners.list > =================================================================== > RCS file: /cvs/pkgs/owners/owners.list,v > retrieving revision 1.3233 > retrieving revision 1.3234 > diff -u -r1.3233 -r1.3234 > --- owners.list 4 Jul 2007 02:40:54 -0000 1.3233 > +++ owners.list 4 Jul 2007 06:03:28 -0000 1.3234 > +Fedora|perl-Text-Markdown|A text-to-HTML filter|jeff at ocjtech dot us|extras-qa at fedoraproject dot org| FE once had the convention to have an InitialCC to fedora-perl-devel-list at redhat dot com for all perl-modules. Has this convention been dropped or is this an oversight? Ralf From mclasen at redhat.com Thu Jul 5 16:39:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 05 Jul 2007 12:39:35 -0400 Subject: init script bugs and changes In-Reply-To: <468D1075.8010408@hhs.nl> References: <200707051111.53422.jkeating@redhat.com> <468D1075.8010408@hhs.nl> Message-ID: <1183653575.7283.2.camel@localhost.localdomain> On Thu, 2007-07-05 at 17:38 +0200, Hans de Goede wrote: > Jesse Keating wrote: > > Harald, I appreciate your dillagence in filing all these bugs, however I think > > a change like this needs to go through the Fedora Packaging Committee. > > You're asking folks to change content in init scripts when there hasn't been > > much / any discussion on the topic. If we're going to make this policy going > > forward, it really needs to be in the packaging guidelines, and approved by > > FESCo. > > > > > > So where does that leave the receivers of said bugs, I assume we should wait > until this has been discussed? Leave the bugs open in the mean time? I don't think making init scripts lsb compliant has to wait until some higher body gives you a thumbs up. Not that it will help much in terms of boot speed, but the lsb compliance itself is not something that is controversial or anything, so you could just do it and forget about the bug... From katzj at redhat.com Thu Jul 5 16:51:46 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 05 Jul 2007 12:51:46 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> Message-ID: <1183654307.18575.13.camel@erebor.boston.redhat.com> On Thu, 2007-07-05 at 01:02 +0800, Hikaru Amano wrote: > On 7/5/07, Debarshi 'Rishi' Ray wrote: > > Just a moment. I am getting lost on this. > > > > > +1 to a single tool for managing repos globally, rather than every > > > apps have its own repo control, which is , IMHO, make stuff feels more > > > complicated .. > > > > The YUM API already has a way to enable and disable repositories. The > > --enablerepo and --disablerepo flags directly use this. > > > > What seems to be lacking is a way to alter yum.conf and the .repo > > files so that the changes become persistent. Once this is available in > > the YUM API, all that an application needs to do is make calls to this > > API component to do the necessary configuration. > > > > yup .. I'm looking for a way to alter yum.conf and the .repo file to > become persistent .. I have set up a LAN repo for newbies in my uni > and was trying to make a one click installation script for it ... I > dont want to tell them to manually edit all the .repo files one by one > to disable the official repos and enable my repos... FWIW, the best way to actually do this now is to set yourself up as a private mirror in mirror manager (https://admin.fedoraproject.org/mirrormanager) with an IP range set. Then, clients connecting and asking for the mirror list from your IP range will get back the local mirror. Then the users don't have to do anything and it Just Works (tm) Jeremy From jam at zoidtechnologies.com Thu Jul 5 16:59:09 2007 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Thu, 5 Jul 2007 12:59:09 -0400 Subject: init script bugs and changes In-Reply-To: <1183653575.7283.2.camel@localhost.localdomain> References: <200707051111.53422.jkeating@redhat.com> <468D1075.8010408@hhs.nl> <1183653575.7283.2.camel@localhost.localdomain> Message-ID: <200707051259.10092.jam@zoidtechnologies.com> On Thursday 05 July 2007 12:39 pm, Matthias Clasen wrote: > I don't think making init scripts lsb compliant has to wait until some > higher body gives you a thumbs up. Not that it will help much in terms > of boot speed, but the lsb compliance itself is not something that is > controversial or anything, so you could just do it and forget about the > bug... I might agree with you there ("just do it"), but *please* update BZ to note that the issue is being discussed on fedora-devel so that in the future when somebody needs to look it up they can at least see that *some* progress is being made towards resolution and get an idea of where to look. regards, -- Jeff MacDonald, Zoid Technologies "Web Applications That Suck Less" From jkeating at redhat.com Thu Jul 5 16:57:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 12:57:39 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200706281352.57015.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> Message-ID: <200707051257.43480.jkeating@redhat.com> On Thursday 28 June 2007 13:52:56 Jesse Keating wrote: > The comps change can be made at any time, however changes to mock need to > be coordinated with the maintainer for redhat-rpm-config. ?I'd also like to > move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the > packages already being pulled into the buildroot (redhat-rpm-config > perhaps, since it will be referencing it?), and thus we'll need to > coordinate with the rpmdevtools maintainer. To date: comps change made. 'yum groupinfo buildsys-build' on rawhide for details. buildroot check scripts now included in upstream rpm, also in rawhide. mock changes created in http://people.redhat.com/jkeating/git/mock-nogrouprepo.git , RFE filed. redhat-rpm-config changes created in http://people.redhat.com/jkeating/git/redhat-rpm-config.git , upstream maintainer notified. Once the redhat-rpm-config and mock changes go through, we'll be done with this little change. -- 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 jaroslav at aster.pl Thu Jul 5 17:15:56 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Thu, 5 Jul 2007 19:15:56 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183534305.5484.9.camel@fedora> References: <200707031343.54452.kwhiskerz@yahoo.ca> <1183534305.5484.9.camel@fedora> Message-ID: <200707051916.03317.jaroslav@aster.pl> Hi, Wednesday 04 of July 2007 09:31:45 Valent Turkovic napisa?(a): > On Tue, 2007-07-03 at 13:43 -0600, kwhiskerz wrote: > > I am definitely opposed to the inclusion of such nuisance programs > > like Beagle > > (...) > > No, no, no! > > Yes, yes, yes! My 2 cents - "default" should be as small as possible. And, besides, there are serious performance issues with this application. so, definitely: NO, NO, NO ;) -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tibbs at math.uh.edu Thu Jul 5 17:16:17 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jul 2007 12:16:17 -0500 Subject: owners owners.list,1.3233,1.3234 In-Reply-To: <1183653318.22644.22.camel@mccallum.corsepiu.local> References: <200707040603.l6463wfr006143@cvs-int.fedora.redhat.com> <1183653318.22644.22.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> FE once had the convention to have an InitialCC to RC> fedora-perl-devel-list at redhat dot com for all perl-modules. RC> Has this convention been dropped or is this an oversight? I imagine that it simply wasn't requested. I had added it to the few Perl-related CVS requests I did, but there's no policy anywhere that mandates it. It should be easy to fix if indeed that's what's wanted. - J< From kevin at scrye.com Thu Jul 5 17:26:03 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 5 Jul 2007 11:26:03 -0600 Subject: owners owners.list,1.3233,1.3234 In-Reply-To: References: <200707040603.l6463wfr006143@cvs-int.fedora.redhat.com> <1183653318.22644.22.camel@mccallum.corsepiu.local> Message-ID: <20070705112603.1f1cfb46@ghistelwchlohm.scrye.com> On 05 Jul 2007 12:16:17 -0500 tibbs at math.uh.edu (Jason L Tibbitts III) wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> FE once had the convention to have an InitialCC to > RC> fedora-perl-devel-list at redhat dot com for all perl-modules. > > RC> Has this convention been dropped or is this an oversight? > > I imagine that it simply wasn't requested. Correct. Is there a global policy/convention that we should add that CC even if it's not requested? > > I had added it to the few Perl-related CVS requests I did, but there's > no policy anywhere that mandates it. Yeah. > It should be easy to fix if indeed that's what's wanted. Indeed. > - J< kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Jul 5 17:32:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Jul 2007 13:32:28 -0400 Subject: init script bugs and changes In-Reply-To: <20070705160651.GG22240@free.fr> References: <200707051111.53422.jkeating@redhat.com> <20070705160651.GG22240@free.fr> Message-ID: <20070705173228.GD14882@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > Having LSB compliant init scripts seems to me to be a good thing in most > cases, even though it should certainly not be mandatory, so why not let > maintainers act on the bugreports? And keep it open for those who don't > want to do anything without a policy. Note that *any* addition of Required-Start, Required-Stop etc. lines to init scripts is going to change their bootup/shutdown order. Ergo, be careful. Bill From ruben at rubenkerkhof.com Thu Jul 5 17:36:03 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Thu, 5 Jul 2007 19:36:03 +0200 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <20070705150855.66c324ad@ludwig-alpha.unil.ch> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> Message-ID: On 5-jul-2007, at 15:08, Christian Iseli wrote: > Hi folks, > > This week's update. Changes from last week: > - 50 more packages in owners.list > - 20 less packages in NEW review requests > - 96 more open BZ bug tickets Hi Chris, The report shows petitboot (#235409) as not available in the development repo, but it is. Ruben From mclasen at redhat.com Thu Jul 5 17:35:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 05 Jul 2007 13:35:23 -0400 Subject: init script bugs and changes In-Reply-To: <20070705173228.GD14882@nostromo.devel.redhat.com> References: <200707051111.53422.jkeating@redhat.com> <20070705160651.GG22240@free.fr> <20070705173228.GD14882@nostromo.devel.redhat.com> Message-ID: <1183656923.7283.4.camel@localhost.localdomain> On Thu, 2007-07-05 at 13:32 -0400, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > Having LSB compliant init scripts seems to me to be a good thing in most > > cases, even though it should certainly not be mandatory, so why not let > > maintainers act on the bugreports? And keep it open for those who don't > > want to do anything without a policy. > > Note that *any* addition of Required-Start, Required-Stop etc. lines to > init scripts is going to change their bootup/shutdown order. Ergo, be > careful. only for those using prcsys though, right ? From ville.skytta at iki.fi Thu Jul 5 18:02:47 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 5 Jul 2007 21:02:47 +0300 Subject: init script bugs and changes In-Reply-To: <200707051111.53422.jkeating@redhat.com> References: <200707051111.53422.jkeating@redhat.com> Message-ID: <200707052102.48274.ville.skytta@iki.fi> On Thursday 05 July 2007, Jesse Keating wrote: > Harald, I appreciate your dillagence in filing all these bugs, however I > think a change like this needs to go through the Fedora Packaging > Committee. You're asking folks to change content in init scripts when there > hasn't been much / any discussion on the topic. If we're going to make > this policy going forward, it really needs to be in the packaging > guidelines, and approved by FESCo. Some questions, I'm sure there are more: Starting an already running service and stopping an already stopped one should return with 0, fair enough. Should the init script output something in these cases? Are there default values for Default-Start/Default-Stop? If I specify "Default-Start: 2 3 4 5", do I also need to specify "Default-Stop: 0 1 6" or can I leave the latter out? What happens if I do leave it out? If there's no Default-Start, is Default-Stop needed? Is "Default-Stop: 0 1 2 3 4 5 6" the same as leaving Default-Stop out? Does chkconfig (when invoked as chkconfig, not the LSB tool symlinks) process Default-Start and Default-Stop lines? If both the usual chkconfig: line and Default-Start/Default-Stop are specified and their information differs, which one prevails? Is "Default-Start: 2 3 4 5" semantically equivalent to "chkconfig: 2345 xx yy" ie. it means that the service is enabled by default? Which keywords are required? None/all/subset? Note that rpmlint currently gives most likely wrong advice about the keywords, more discussion at http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/71 From ville.skytta at iki.fi Thu Jul 5 18:16:25 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 5 Jul 2007 21:16:25 +0300 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200707051257.43480.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <200707051257.43480.jkeating@redhat.com> Message-ID: <200707052116.26093.ville.skytta@iki.fi> On Thursday 05 July 2007, Jesse Keating wrote: > redhat-rpm-config changes created in > http://people.redhat.com/jkeating/git/redhat-rpm-config.git , upstream > maintainer notified. I see only /usr/lib/rpm/check-buildroot is enabled in %__arch_install_post. I'm fine with not enabling /usr/lib/rpm/check-rpaths in redhat-rpm-config, that's how it is in current Fedora build roots too AFAIU. On the other hand, I wouldn't personally mind enabling check-rpaths too - but it will generate many build failures that didn't occur before, most of which will be /usr/lib64 rpaths on x86_64 which are a relatively minor concern (but should be fixed anyway). But the upside is that it could reveal some really harmful rpaths that are security issues (not only in Fedora proper, but also in 3rd party packages). rpmdev-setuptree has traditionally written both the rpath check and the buildroot check in ~/.rpmmacros. If both aren't enabled in the new redhat-rpm-config, I'll probably leave it as is in rpmdevtools. OTOH if both are enabled in it, I could get rid of that stuff altogether. From notting at redhat.com Thu Jul 5 18:15:58 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Jul 2007 14:15:58 -0400 Subject: init script bugs and changes In-Reply-To: <1183656923.7283.4.camel@localhost.localdomain> References: <200707051111.53422.jkeating@redhat.com> <20070705160651.GG22240@free.fr> <20070705173228.GD14882@nostromo.devel.redhat.com> <1183656923.7283.4.camel@localhost.localdomain> Message-ID: <20070705181558.GA17196@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > > Note that *any* addition of Required-Start, Required-Stop etc. lines to > > init scripts is going to change their bootup/shutdown order. Ergo, be > > careful. > > only for those using prcsys though, right ? No. chkconfig reads those lines to determine priorities. Bill From notting at redhat.com Thu Jul 5 18:17:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Jul 2007 14:17:52 -0400 Subject: init script bugs and changes In-Reply-To: <200707052102.48274.ville.skytta@iki.fi> References: <200707051111.53422.jkeating@redhat.com> <200707052102.48274.ville.skytta@iki.fi> Message-ID: <20070705181752.GB17196@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > Does chkconfig (when invoked as chkconfig, not the LSB tool symlinks) process > Default-Start and Default-Stop lines? Yes. > If both the usual chkconfig: line and > Default-Start/Default-Stop are specified and their information differs, which > one prevails? LSB. > Is "Default-Start: 2 3 4 5" semantically equivalent > to "chkconfig: 2345 xx yy" ie. it means that the service is enabled by > default? Yes. Bill From jkeating at redhat.com Thu Jul 5 18:19:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 14:19:04 -0400 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200707052116.26093.ville.skytta@iki.fi> References: <200706281352.57015.jkeating@redhat.com> <200707051257.43480.jkeating@redhat.com> <200707052116.26093.ville.skytta@iki.fi> Message-ID: <200707051419.04646.jkeating@redhat.com> On Thursday 05 July 2007 14:16:25 Ville Skytt? wrote: > I see only /usr/lib/rpm/check-buildroot is enabled in %__arch_install_post. > ? I'm fine with not enabling /usr/lib/rpm/check-rpaths in > redhat-rpm-config, that's how it is in current Fedora build roots too > AFAIU. Yeah, changing that will need more than just me making it happen, it'll need FESCo approval and all that stuff. Too late for this week, can discuss next week. -- 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 rnorwood at redhat.com Thu Jul 5 18:40:18 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 05 Jul 2007 14:40:18 -0400 Subject: perl-devel will be removed from the f8 buildroots In-Reply-To: (Robin Norwood's message of "Thu, 28 Jun 2007 12:07:21 -0400") References: Message-ID: Robin Norwood writes: > Hi, > > On Monday, perl-devel will be removed from the f8 buildroots. This > means that if you try to build a perl-* package that uses the perl build > tools, you will need to add those tools to the BuildRequires for the > package. The most common will be: > > BuildRequires: perl(ExtUtils::MakeMaker) > > But you should also watch the build output to make sure tests aren't > being skipped due to other missing modules. FESCo voted on this issue today and passed the following proposal: Remove perl-devel from default buildroot. Assist others with proper spec fixups. Alert time of removal is 1 week. So, what we'll be doing is: o Various people have volunteered to help convert packages to use the specific Buildrequires tags. If anyone wants to ask for assistance with their packages, do so here, and we'll take care of them for you. o There will soon be a 'perl-core' metapackage, that will Require everything that has been split from the main 'perl' package - essentially everything in the upstream tarball, except for suidperl. It is stronly encouraged that package maintainers BuildRequire the specific perl modules their package needs to build instead of this package. o Next Thursday (the 12th of July), the buildroots will be changed to remove the 'devel' bits This means that any packages that haven't been fixed yet will not build. But of course we can easily fix them on a one-off basis. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From kagesenshi.87 at gmail.com Thu Jul 5 18:52:16 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 6 Jul 2007 02:52:16 +0800 Subject: Pirut: Edit -> Repositories In-Reply-To: <1183654307.18575.13.camel@erebor.boston.redhat.com> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> <1183654307.18575.13.camel@erebor.boston.redhat.com> Message-ID: On 7/6/07, Jeremy Katz wrote: > > yup .. I'm looking for a way to alter yum.conf and the .repo file to > > become persistent .. I have set up a LAN repo for newbies in my uni > > and was trying to make a one click installation script for it ... I > > dont want to tell them to manually edit all the .repo files one by one > > to disable the official repos and enable my repos... > > FWIW, the best way to actually do this now is to set yourself up as a > private mirror in mirror manager > (https://admin.fedoraproject.org/mirrormanager) with an IP range set. > Then, clients connecting and asking for the mirror list from your IP > range will get back the local mirror. Then the users don't have to do > anything and it Just Works (tm) > > Jeremy I know about mirrormanager .. but no matter how much I would love to use it , I couldnt .. :( the network in my college is set up like a very paranoid network .. where theres 6 separated networks that couldnt connect to each other , and 1 central network that become the center of all 7 networks. theres a proxy farm in the central network that allows connection between the 6 networks , however, it have a crazy limitation. port 80 POST/GET with 2MB size limit and port 443 TCP/CONNECT .. and no other protocols allowed .. this limitation also applies to normal internet connection.. I managed to get around that and mirrored Fedora's repository locally for others who dont know how to sneak through the network. considering yum doesnt support https, I had to write a set of automated scripts complete with init to start a tunneling application (prtunnel), and create a CONNECT tunnel to my http server running on port 443 through the proxy. I even wrote a simple yum plugin to make sure the tunnel is running before yum'ing. all of that are packaged into a rpm which will handle all the dirty work for them. The only problem I have now is a way to easily switch between using Fedora's official repository or my mirrored+tunneled repository on localhost. My current approach of enabling/disabling repos is very ugly where i renames the .repo files accordingly .. I know my case is >= 0.1% of the entire population of Fedora users, so I try not to demand big stuff like https + https_proxy support in yum (which will solves not only this problem .. but some of my other small problems too), rather than some little help in getting something to work.. Everything else , I will manage to do it .... somehow ...... -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From skvidal at linux.duke.edu Thu Jul 5 18:57:22 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 05 Jul 2007 14:57:22 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <1183387321.10801.17.camel@aglarond.local> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> <1183654307.18575.13.camel@erebor.boston.redhat.com> Message-ID: <1183661842.31613.163.camel@cutter> On Fri, 2007-07-06 at 02:52 +0800, Hikaru Amano wrote: > considering yum doesnt support https, I had to write a set of yes, yum supports https just fine. -sv From jima at beer.tclug.org Thu Jul 5 19:02:16 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 5 Jul 2007 14:02:16 -0500 (CDT) Subject: init script bugs and changes In-Reply-To: <20070705181752.GB17196@nostromo.devel.redhat.com> References: <200707051111.53422.jkeating@redhat.com> <200707052102.48274.ville.skytta@iki.fi> <20070705181752.GB17196@nostromo.devel.redhat.com> Message-ID: On Thu, 5 Jul 2007, Bill Nottingham wrote: > Ville Skytt? (ville.skytta at iki.fi) said: >> Is "Default-Start: 2 3 4 5" semantically equivalent >> to "chkconfig: 2345 xx yy" ie. it means that the service is enabled by >> default? > > Yes. Conversely, what's the proper way to say "not enabled by default?" "Default-Start: -"? "Default-Start: "? Leaving Default-Start out? The documentation didn't seem to cover that. Jima From buildsys at redhat.com Thu Jul 5 19:03:27 2007 From: buildsys at redhat.com (Build System) Date: Thu, 5 Jul 2007 15:03:27 -0400 Subject: rawhide report: 20070628 changes Message-ID: <200707051903.l65J3Rn7002916@porkchop.devel.redhat.com> From debarshi.ray at gmail.com Thu Jul 5 19:05:03 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 6 Jul 2007 00:35:03 +0530 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <46893808.7090405@rasmil.dk> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> <1183654307.18575.13.camel@erebor.boston.redhat.com> Message-ID: <3170f42f0707051205x4a5a863cy4c1f2e41268fbfda@mail.gmail.com> > the network in my college is set up like a very paranoid network .. > where theres 6 separated networks that couldnt connect to each other , > and 1 central network that become the center of all 7 networks. theres > a proxy farm in the central network that allows connection between the > 6 networks , however, it have a crazy limitation. port 80 POST/GET > with 2MB size limit and port 443 TCP/CONNECT .. and no other protocols > allowed .. this limitation also applies to normal internet > connection.. I managed to get around that and mirrored Fedora's > repository locally for others who dont know how to sneak through the > network. I had a very similar set-up in my university too. We did not have the 2MB size limit though. :-) Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jkeating at redhat.com Thu Jul 5 19:41:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Jul 2007 15:41:17 -0400 Subject: rawhide report: 20070628 changes In-Reply-To: <200707051903.l65J3Rn7002916@porkchop.devel.redhat.com> References: <200707051903.l65J3Rn7002916@porkchop.devel.redhat.com> Message-ID: <200707051541.20787.jkeating@redhat.com> On Thursday 05 July 2007 15:03:27 Build System wrote: > rawhide report: 20070628 changes Hee, this was an old processthat got killed, not a slip in the space/time continuum. -- 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 ville.skytta at iki.fi Thu Jul 5 19:46:42 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 5 Jul 2007 22:46:42 +0300 Subject: init script bugs and changes In-Reply-To: References: <200707051111.53422.jkeating@redhat.com> <20070705181752.GB17196@nostromo.devel.redhat.com> Message-ID: <200707052246.43023.ville.skytta@iki.fi> On Thursday 05 July 2007, Jima wrote: > On Thu, 5 Jul 2007, Bill Nottingham wrote: > > Ville Skytt? (ville.skytta at iki.fi) said: > >> Is "Default-Start: 2 3 4 5" semantically equivalent > >> to "chkconfig: 2345 xx yy" ie. it means that the service is enabled by > >> default? > > > > Yes. > > Conversely, what's the proper way to say "not enabled by default?" > "Default-Start: -"? I don't think this would be valid. > "Default-Start: "? Leaving Default-Start out? The > documentation didn't seem to cover that. Either will probably do, but I'd still like to know whether "Default-Stop: 0 1 2 3 4 5 6" should be added in this case. FWIW, Debian appears to be encouraging including keywords with empty values: http://lintian.debian.org/reports/Tinit.d-script-missing-lsb-keyword.html From jwboyer at jdub.homelinux.org Thu Jul 5 21:11:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 05 Jul 2007 16:11:08 -0500 Subject: rawhide report: 20070628 changes In-Reply-To: <200707051541.20787.jkeating@redhat.com> References: <200707051903.l65J3Rn7002916@porkchop.devel.redhat.com> <200707051541.20787.jkeating@redhat.com> Message-ID: <1183669868.11695.2.camel@vader.jdub.homelinux.org> On Thu, 2007-07-05 at 15:41 -0400, Jesse Keating wrote: > On Thursday 05 July 2007 15:03:27 Build System wrote: > > rawhide report: 20070628 changes > > Hee, this was an old processthat got killed, not a slip in the space/time > continuum. Damn. And here I thought it was my birthday again. josh From Christian.Iseli at licr.org Thu Jul 5 22:33:07 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 6 Jul 2007 00:33:07 +0200 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> Message-ID: <20070706003307.465b4fe2@ludwig-alpha.unil.ch> On Thu, 5 Jul 2007 19:36:03 +0200, Ruben Kerkhof wrote: > The report shows petitboot (#235409) as not available in the > development repo, but it is. Yes, the script failed to parse the Summary field of the ticket because there was no space after the colon of "Review Request:"... Fixed now. Thanks, C From david at lovesunix.net Thu Jul 5 23:00:01 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 06 Jul 2007 01:00:01 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183537591.5484.51.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030709wed94e3la9fe497da4e40a9b@mail.gmail.com> <1183476038.3063.20.camel@dawkins> <1183537591.5484.51.camel@fedora> Message-ID: <1183676401.3093.37.camel@dawkins> ons, 04 07 2007 kl. 10:26 +0200, skrev Valent Turkovic: > Can you please explain how would that work in a little more detail? I > get great benefit from beagle searching my mail, web pages and local > documents... how would I benefit from beagle integration to amarok or > audacious or some other player I use? I don't see what beagle would do > there so please explain. Okay imagine you down.. acquire a new album, with beagle indexing this it would automatically be added to your library, you could move the files around and the library would not break. Okay, lemme give you an example, I recently ripped some The Smashing Pumpkins albums, I did so outside of my media player and I forgot to double check that the metadata was correct. Then I imported the resulting flac files into Banshee and notice that some of the albums were labelled as "Smashing Pumpkins" so I corrected that but the files weren't moved into the same directory. So I moved them manually.. and voila Banshee now looks for the files in the wrong dir. With an indexed solution this would be a non issue, I could move my files around like I wanted and have my library be consistent. This is just a simple use case for an index, you can do a lot of fun and useful things with this type of technology that are more advanced. The problem is that currently the technology isn't at the stage where any applications are really relying on an index. Right now that means that Beagle is basically a very handy way to search my massive archive of mail, considering the current downsides one has to wonder if it's worth enabling by default. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From kagesenshi.87 at gmail.com Thu Jul 5 23:40:35 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 6 Jul 2007 07:40:35 +0800 Subject: Pirut: Edit -> Repositories In-Reply-To: <1183661842.31613.163.camel@cutter> References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> <1183654307.18575.13.camel@erebor.boston.redhat.com> <1183661842.31613.163.camel@cutter> Message-ID: On 7/6/07, seth vidal wrote: > On Fri, 2007-07-06 at 02:52 +0800, Hikaru Amano wrote: > > > considering yum doesnt support https, I had to write a set of > > > yes, yum supports https just fine. is it? ... since when?. .. the last time I tried (around FC5/early FC6) ... iirc, that time, https doesnt work .. (or was it .. https doesnt work through https_proxy?? .. ) .. I tried several times and still couldnt connect to the server .. thus .. lead me to derive the auto tunneling scripts etc to get around it .. > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From kevin.kofler at chello.at Fri Jul 6 01:37:55 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 6 Jul 2007 01:37:55 +0000 (UTC) Subject: Unpushing broken or obsolete updates from testing Message-ID: Why are updates lingering in updates-testing for weeks when: * they are known broken and/or * they have already been replaced by a new version, which is already in stable? IMHO, that's really what the "unpush" option is for. For example, do we really need to have that obsolete Thunderbird RC sitting in testing forever when the actual release is already out in the stable updates? This also makes it harder to track down the legitimate updates which have been sitting in testing for way too long. Kevin Kofler From skvidal at linux.duke.edu Fri Jul 6 02:29:14 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 05 Jul 2007 22:29:14 -0400 Subject: Pirut: Edit -> Repositories In-Reply-To: References: <3170f42f0707020257p2e32b2dxa0abfa39c7bde956@mail.gmail.com> <468A5BEF.40309@fedoraproject.org> <468B2766.5000908@rasmil.dk> <468B6856.4090007@gmail.com> <3170f42f0707040939yc032a80pf2e556ae94ed83ae@mail.gmail.com> <1183654307.18575.13.camel@erebor.boston.redhat.com> <1183661842.31613.163.camel@cutter> Message-ID: <1183688954.31613.174.camel@cutter> On Fri, 2007-07-06 at 07:40 +0800, Hikaru Amano wrote: > On 7/6/07, seth vidal wrote: > > On Fri, 2007-07-06 at 02:52 +0800, Hikaru Amano wrote: > > > > > considering yum doesnt support https, I had to write a set of > > > > > > yes, yum supports https just fine. > > is it? ... since when?. .. the last time I tried (around FC5/early > FC6) ... iirc, that time, https doesnt work .. (or was it .. https > doesnt work through https_proxy?? .. ) .. I tried several times and > still couldnt connect to the server .. thus .. lead me to derive the > auto tunneling scripts etc to get around it .. > https definitely works and the last time I checked the proxy worked, too. If you've got a bug, file it and let's take a look, okay b/c it _should_ work. -sv From jeff at ocjtech.us Fri Jul 6 06:32:56 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 06 Jul 2007 01:32:56 -0500 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <20070704163753.GA4850@jadzia.bu.edu> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <20070704163753.GA4850@jadzia.bu.edu> Message-ID: <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> On Wed, 2007-07-04 at 12:37 -0400, Matthew Miller wrote: > On Wed, Jul 04, 2007 at 12:41:09PM +0200, Valent Turkovic wrote: > > Also I understand that directly linking from Fedora or an official > > Fedora website to http://rpm.livna.org is considered "contributory > > infingement" > > *Could* be contributory infringement. An important distinction -- I don't > think we admit any such thing, but are rather erroring on the side of > caution. Even if it wasn't contributory infringement, Fedora isn't about building a great OS using whatever software happens to work, Fedora is about building a great OS with free and open source software. Making it easier to install non-FOSS sofware is contrary to that goal. 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 sean.bruno at dsl-only.net Fri Jul 6 06:43:05 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 05 Jul 2007 23:43:05 -0700 Subject: dmraid failure/test cases [fc5-7] Message-ID: <1183704185.3591.14.camel@home-desk> I spent some time trying to arm wrestle my machines fake raid controllers(ck804, sil 3118) and a pci board I had lying around(adaptec 1210sa), and came to the conclusion that dmraid was causing me serious grief. First off, I could _not_ get dmraid to go away during the install on x86_64. Even the nodmraid kernel option failed me. Each time I booted up with two disks connected to any controller, the only drive I had at my disposal was /dev/mapper/mapper0. I did notice that there was a 'disable dmraid' toggle in the advanced setup button in the installer, however this option was grayed out in all situations that I could come up with. Second, all three of the SATA raid controllers I tested failed in similar, yet different ways during the install process. They mainly failed during file system creation, but there was some variances in behavior that were interesting. For example, some would cause anaconda to dump and crash, others would simply cause the installer to abort and reboot the machine. Third, and the most annoying, was that I couldn't install a plain s/w raid configuration with 2 drives connected. There was just no way to keep the system from assuming that I meant to use /dev/mapper/mapper0 even after I ensured that the superblock metadata was wiped out with a quick call to 'dmraid -Er /dev/sdX' to be sure that it was really gone. In a related note, it would be nice if the installer would allow you to create a broken raid 1 in the installer, anaconda should definitely warn you and tell you that what you are doing is loopy, but there should be a way to just say, "go ahead if you really wanna". I was unable to find this magic, and had to install on a single drive. I guess I'll have to migrate to s/w raid after the install is finished. I am more than interested now in diagnosing and fixing the issues I've spewed forth here. I've even gone so far as to start some bugzilla goodness on tkt:246817 Any takers in dev land want to give me a hand with this one? Sean From valent.turkovic at gmail.com Fri Jul 6 07:08:47 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:08:47 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <20070704175050.GA476@bludgeon.org> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> <468B74E5.10207@nicubunu.ro> <20070704175050.GA476@bludgeon.org> Message-ID: <1183705727.23127.0.camel@fedora> On Wed, 2007-07-04 at 10:50 -0700, Ray Van Dolson wrote: > Perhaps the htmlview icon could somehow be "symlinked" to the icon for > whichever browser is default. So the user sees the Firefox icon .. or > Mozilla, or whichever they have configured as default. > > Ray > Yes, a simple thing to do. Please consider this proposal. From valent.turkovic at gmail.com Fri Jul 6 07:11:30 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:11:30 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> Message-ID: <1183705890.23127.4.camel@fedora> On Wed, 2007-07-04 at 22:53 +0000, Thufir wrote: > this is a taste issue. I prefer firefox, but others may have a > different > preference. I also prefer to not make things a hassle for those with > different preferences. I'm not even suggesting anything like that. > Not everything can be one click automagical. > > Having firefox as the default is an improvement, but why lock it down > for > others? > > -Thufir I'm not saying that. If htmlview is launcher when you click on "Internet Browser" and it checks which is the default browser than htmlview icon should also change as you change preference in your browsers. That is only thing I suggested. What do you think about that? From valent.turkovic at gmail.com Fri Jul 6 07:12:50 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:12:50 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468CB4B2.9030802@kanarip.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <468CB4B2.9030802@kanarip.com> Message-ID: <1183705970.23127.6.camel@fedora> On Thu, 2007-07-05 at 11:06 +0200, Jeroen van Meeuwen wrote: > I'm sure it's not, but the point was (I think), to have the icon > change > under certain circumstances: > > 1) there is only one browser installed > > 2) preferences are changed > > This way, the icon-change makes sense to me. Yes, thank you. That was the meaning. Can this be done? I believe it is a simple thing but a logical one to do. From valent.turkovic at gmail.com Fri Jul 6 07:18:12 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:18:12 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468CB884.9030006@kanarip.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5ABF.1050801@kanarip.com> <468A5FE8.3070707@kanarip.com> <1183543721.5484.64.camel@fedora> <468CB884.9030006@kanarip.com> Message-ID: <1183706292.23127.10.camel@fedora> On Thu, 2007-07-05 at 11:23 +0200, Jeroen van Meeuwen wrote: > Fine. We have different opinions. > > If beagle is unable to nice/renice the child processes it launches > then > that is a blocker for me. If it's installed I'll remove it. > > Regardless of whether one of us thinks it's either a bug or a feature: > You requested someone to show you how beagle doesn't work for anyone. > I've given you my use case. Knock yourself out. Thank you all for your input. Because this thread got mostly talked about beagle I'll start a new one. But a really short one. And I'll need the precious info and your usage cases. Thank you Jeroen and all of you. From emmanuel.seyman at club-internet.fr Fri Jul 6 07:30:58 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 6 Jul 2007 09:30:58 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183705890.23127.4.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> <1183705890.23127.4.camel@fedora> Message-ID: <20070706073058.GA26430@orient.maison.lan> * Valent Turkovic [06/07/2007 09:25] : > > If htmlview is launcher when you click on "Internet Browser" and it > checks which is the default browser than htmlview icon should also > change as you change preference in your browsers. That is only thing I > suggested. > > What do you think about that? I'm more in favour of the icon staying constant regardless of changes in the user's choice, to be honest. I can easily see a user changing his choice to test other browers and then not being able to find the icon again because he has no idea what it looks like now. Emmanuel From valent.turkovic at gmail.com Fri Jul 6 07:44:44 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:44:44 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <20070706073058.GA26430@orient.maison.lan> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> <1183705890.23127.4.camel@fedora> <20070706073058.GA26430@orient.maison.lan> Message-ID: <1183707884.23127.33.camel@fedora> On Fri, 2007-07-06 at 09:30 +0200, Emmanuel Seyman wrote: > I'm more in favour of the icon staying constant regardless of changes > in > the user's choice, to be honest. I can easily see a user changing his > choice > to test other browers and then not being able to find the icon again > because > he has no idea what it looks like now. People would probaly spot the only icon that has changed... From valent.turkovic at gmail.com Fri Jul 6 07:48:57 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:48:57 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468B9CCE.2010509@gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5FF6.6030108@gmail.com> <1183543346.5484.56.camel@fedora> <468B9CCE.2010509@gmail.com> Message-ID: <1183708137.23127.37.camel@fedora> On Wed, 2007-07-04 at 15:12 +0200, Alphonse Van Assche wrote: > Sorry but your test is absolutely not correct. I have say *some* big > pdf > and the only pdf that you test is a text only pdf. In the real live > many > pdf contain images too. Another think that I have never understand is > why beagle re-index always files that are already indexed. Can you please provide a link for a really big pdf so I can to some testing. Thank you. Valent. From valent.turkovic at gmail.com Fri Jul 6 07:50:08 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 09:50:08 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468B9CCE.2010509@gmail.com> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5FF6.6030108@gmail.com> <1183543346.5484.56.camel@fedora> <468B9CCE.2010509@gmail.com> Message-ID: <1183708208.23127.39.camel@fedora> On Wed, 2007-07-04 at 15:12 +0200, Alphonse Van Assche wrote: > with Thunderbird and coding in Eclipse on the other hand when beagle > take 100% of the CPU I can difficultly open a gnome-terminal to kill > him. why not issue beagle-shutdown? From jdogalt at yahoo.com Fri Jul 6 08:59:53 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Fri, 6 Jul 2007 01:59:53 -0700 (PDT) Subject: dmraid failure/test cases [fc5-7] In-Reply-To: <1183704185.3591.14.camel@home-desk> Message-ID: <944847.33315.qm@web56907.mail.re3.yahoo.com> --- Sean Bruno wrote: > In a related note, it would be nice if the installer would allow you > to > create a broken raid 1 in the installer, anaconda should definitely > warn > you and tell you that what you are doing is loopy, but there should > be a > way to just say, "go ahead if you really wanna". I thought it was going to be loopy too... http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html I might just have to post a 7 line patch tomorrow that implements the above... without using so much as a single loop device ;) -dmc/jdog ____________________________________________________________________________________ Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz From alcapcom at gmail.com Fri Jul 6 09:24:01 2007 From: alcapcom at gmail.com (Alphonse Van Assche) Date: Fri, 06 Jul 2007 11:24:01 +0200 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183708208.23127.39.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <64b14b300707030540m1410fbady6a24206baa4e5312@mail.gmail.com> <468A52B3.4090501@verizon.net> <200707031548.42818@rineau.tsetse> <64b14b300707030706t4e6bae70w74ac119db90b625c@mail.gmail.com> <468A5FF6.6030108@gmail.com> <1183543346.5484.56.camel@fedora> <468B9CCE.2010509@gmail.com> <1183708208.23127.39.camel@fedora> Message-ID: <468E0A31.2030707@gmail.com> Valent Turkovic a ?crit : > On Wed, 2007-07-04 at 15:12 +0200, Alphonse Van Assche wrote: >> with Thunderbird and coding in Eclipse on the other hand when beagle >> take 100% of the CPU I can difficultly open a gnome-terminal to kill >> him. > > why not issue beagle-shutdown? > Kill vs shutdown, why... same result ;-). The problem is that beagle is too "possessive" with the CPU and dislike to share him... not nice even with a renice :-). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From buildsys at redhat.com Fri Jul 6 09:37:52 2007 From: buildsys at redhat.com (Build System) Date: Fri, 6 Jul 2007 05:37:52 -0400 Subject: rawhide report: 20070706 changes Message-ID: <200707060937.l669bqOT005852@porkchop.devel.redhat.com> New package audacious-plugin-fc Future Composer input plugin for Audacious New package ndesk-dbus Managed C# implementation of DBus New package perl-Crypt-OpenSSL-DSA Perl interface to OpenSSL for DSA New package perl-Test-Output Utilities to test STDOUT and STDERR messages New package postgis Geographic Information Systems Extensions to PostgreSQL New package ppl The Parma Polyhedra Library: a library of numerical abstractions New package qgis A user friendly Open Source Geographic Information System New package trac-git-plugin GIT version control plugin for Trac New package trac-mercurial-plugin Mercurial plugin for Trac Updated Packages: R-hdf5-1.6.6-1.fc8 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 1.6.6-1 - bump to 1.6.6 avahi-0.6.20-4.fc8 ------------------ * Thu Jul 05 2007 Dan Williams - 0.6.20-4 - Add Requires(pre): shadow-utils for avahi-autoipd package bash-3.2-11.fc8 --------------- * Thu Jul 05 2007 Tim Waugh 3.2-11 - Patchlevel 17 (bug #241647). * Wed Jul 04 2007 Tim Waugh 3.2-10 - Clarification in the ulimit man page (bug #220657). * Mon Feb 12 2007 Tim Waugh 3.2-9 - Rebuild to link with libtinfo instead of libncurses. cronolog-1.6.2-5.fc8 -------------------- * Thu Jul 05 2007 Sean Reifschneider 1.6.2-5 - Included patch for LARGEFILE support, fix provided by Arenas Belon, Carlo Marcelo. cups-1:1.2.11-5.fc8 ------------------- * Thu Jul 05 2007 Tim Waugh 1:1.2.11-5 - Support for page-ranges and accounting in the textonly filter (bug #244979). dialog-1.1-1.20070704.fc8 ------------------------- * Thu Jul 05 2007 Harald Hoyer - 1.1-1.20070704 - version 1.1-20070704 * Wed Jun 27 2007 Harald Hoyer - 1.1-1.20070604 - dialog-1.1-20070604 * Wed Feb 28 2007 Harald Hoyer - 1.1-1.20070227svn - version 1.1-20070227 - added devel subpackage - specfile fixes (bug#225693) - Resolves: rhbz#225693 emacs-nxml-mode-0.20041004-6.fc8 -------------------------------- * Thu Jul 05 2007 Tim Waugh . gdb-6.6-19.fc8 -------------- * Thu Jul 05 2007 Jan Kratochvil - 6.6-19 - Link with libreadline provided by the operating system. glom-1.4.4-1.fc7 ---------------- * Tue Jun 19 2007 Denis Leroy - 1.4.4-1 - Update to 1.4.4 - Excluding ppc64 until gdamm is available * Thu Apr 05 2007 Denis Leroy - 1.4.3-1 - Update to 1.4.3 gmp-4.1.4-13 ------------ * Thu Jul 05 2007 Florian La Roche 4.1.4-13 - don't fail scripts to e.g. allow excludedocs installs * Tue Apr 24 2007 Karsten Hopp 4.1.4-12.3 - fix library permissions * Wed Mar 14 2007 Karsten Hopp 4.1.4-12.2 - fix typo gnome-games-1:2.19.4-2.fc8 -------------------------- * Thu Jul 05 2007 Ray Strode - 1:2.19.4-2 - Add glchess back (bug 234127) gqview-2.0.4-2 -------------- * Thu Jul 05 2007 Michael Schwendt - 2.0.4-2 - temporarily patch print.c to setup PageSize and a few more parameters gutenprint-5.0.1-3.fc8 ---------------------- * Mon Jul 02 2007 Tim Waugh 5.0.1-3 - The foomatic package requires system-config-printer-libs for the update script (bug #246865). gxemul-0.4.6-1.fc8 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 0.4.6-1 - bump to 0.4.6 irqbalance-2:0.55-3.fc8 ----------------------- * Thu Jul 05 2007 Neil Horman - 0.55.3 - Fixing LSB requirements (bz 246959) jpackage-utils-0:1.7.3-1jpp.3.fc8 --------------------------------- * Wed Jun 20 2007 Thomas Fitzsimmons - 0:1.7.3-1jpp.3 - Add 1.7.0 directories. * Thu Jan 11 2007 Thomas Fitzsimmons - 0:1.7.3-1jpp.2 - Add 1.6.0 directories missed in merge. - Resolves: rhbz#221262 * Mon Dec 11 2006 Thomas Fitzsimmons - 0:1.7.3-1jpp.1 - Import version 0:1.7.3-1jpp from jpackage.org. - Change release numbering format to Xjpp.Y.fc7. - Resolves: rhbz#218936 kernel-2.6.22-0.12.rc7.git4.fc8 ------------------------------- * Thu Jul 05 2007 Dave Jones - Further tickless improvements to ondemand cpufreq governor. * Thu Jul 05 2007 Dave Jones - 2.6.22-rc7-git4 * Thu Jul 05 2007 Dave Jones - Lower mkinitrd requires: to match what's in rawhide. kexec-tools-1.101-72.fc8 ------------------------ * Thu Jul 05 2007 Neil Horman - 1.101-72.fc8 - Fixing up initscript for LSB (bz 246967) libdap-3.7.8-1.fc8.1 -------------------- * Thu Jul 05 2007 Patrice Dumas 3.7.8-1.1 - update to 3.7.8 libgii-1.0.2-3.fc8 ------------------ * Fri Jul 06 2007 kwizart < kwizart at gmail.com > - 1.0.2-3 - Use the full package name for sub-packages. libifp-1.0.0.2-5.fc8 -------------------- * Thu Jul 05 2007 Aurelien Bompard 1.0.0.2-5 - update udev rules to newer syntax (bug 246844) libreadline-java-0.8.0-18.fc8 ----------------------------- * Thu Jul 05 2007 Thomas Fitzsimmons - 0.8.0-18 - Specify full path to libedit backing library. - Default to libedit backing library. - Satisfy termcap requirements with ncurses. - Resolves: rhbz#231209 lightning-1.2-9.fc8 ------------------- * Thu Jul 05 2007 Jochen Schmitt 1.2-9 - Add prelink as a BR man-pages-ja-20070615-1 ----------------------- * Thu Jul 05 2007 Akira TAGOH - 20070615-1 - updates to 20070615. - man-pages-ja-20051115-libaio.patch: removed. - man-pages-ja-20060815-204664-write.2.patch: removed. * Thu Apr 26 2007 Akira TAGOH - 20070415-1 - updates to 20070415. metacity-2.19.21-2.fc8 ---------------------- * Thu Jul 05 2007 Matthias Clasen - 2.19.21-2 - Fix keybindings pam_keyring-0.0.9-1.fc7 ----------------------- * Fri Jun 15 2007 Denis Leroy - 0.0.9-1 - Update to 0.0.9 version (bug 238741) perl-Class-DBI-Loader-Relationship-1.3-4.fc8.1 ---------------------------------------------- * Thu Jul 05 2007 Tom "spot" Callaway 1.3-4.1 - missing BR for devel (Test::More) * Thu Jul 05 2007 Tom "spot" Callaway 1.3-4 - fix false provide (Class::DBI::Loader::Generic) perl-DateTime-1:0.38-2.fc8 -------------------------- * Thu Jul 05 2007 Steven Pritchard 1:0.38-2 - BR Test::Output. * Mon Jul 02 2007 Steven Pritchard 1:0.38-1 - Update to DateTime 0.38. - Update to DateTime::TimeZone 0.6602. - BR Test::Pod::Coverage. * Mon Apr 02 2007 Steven Pritchard 1:0.37-3 - Drop BR DateTime::Format::* to avoid circular build deps. perl-Email-MIME-Creator-1.453-2.fc8 ----------------------------------- * Thu Jul 05 2007 Tom "spot" Callaway - 1.453-2 - fix false provide (Email::MIME) perl-Email-Simple-Creator-1.420-3.fc8 ------------------------------------- powertop-1.7-2.fc8 ------------------ * Thu Jul 05 2007 Adam Jackson 1.7-2 - Don't suggest disabling g-p-m. Any additional power consumption is more than offset by the ability to suspend. qt4-4.3.0-8.fc8 --------------- * Thu Jul 05 2007 Rex Dieter 4.3.0-8 - fix %_qt4_prefix/doc symlink * Thu Jun 28 2007 Rex Dieter 4.3.0-7 - prepare for possible rename qt4 -> qt (+Provides: qt4) - make _qt4_* macro usage consistent (with %check's) redhat-rpm-config-9.0.1-1.fc8 ----------------------------- * Thu Jul 05 2007 Jesse Keating - 9.0.1-1 - Remove dist defines, fedora-release does that now - Enable post-build buildroot checking by default rpmdevtools-6.0-1.fc8 --------------------- * Thu Jul 05 2007 Ville Skytt?? - 6.0-1 - Remove check-{buildroot,rpaths*}, now included in rpm-build >= 4.4.2.1. - Drop explicit dependency on patch, pulled in by recent rpm-build. - Add cmake and scons to default devel package list in rpmdev-rmdevelrpms. - Add LSB comment block to init script template. * Wed Jun 27 2007 Ville Skytt?? - Add 2-argument form for comparing EVR strings to rpmdev-vercmp (available only if rpmUtils.miscutils is available). * Sat Jun 16 2007 Ville Skytt?? - Include rpmsodiff and dependencies (rpmargs, rpmelfsym, rpmfile, rpmpeek, rpmsoname) from ALT Linux's qa-robot package. - Include rpmls (#213778). sane-backends-1.0.18-8.fc8 -------------------------- * Thu Jul 05 2007 Nils Philippsen - 1.0.18-8 - tweak udev rules to conform with new udev syntax (#246849) skencil-0.6.17-14.20070606svn.fc8 --------------------------------- * Wed Jun 06 2007 Gerard Milmeister - 0.6.17-14.20070606svn - update to svn 20070606 system-config-language-1.2.5-1.fc8 ---------------------------------- * Thu Jul 05 2007 Lingning Zhang - 1.2.5 - fix bug241746. system-switch-java-1.1.0-2.fc8 ------------------------------ * Thu Jul 05 2007 Thomas Fitzsimmons - 1.1.0-2 - Bump release number. units-1.86-6.fc8 ---------------- * Thu Jul 05 2007 Florian La Roche - fix preun script to properly remove the info file * Fri Mar 23 2007 Harald Hoyer - 1.86-5.fc8 - more specfile cleanups * Tue Mar 20 2007 Harald Hoyer - 1.86-4.fc8 - added readline build requirement - changed BUILDROOT wordpress-2.2.1-1.fc7 --------------------- * Wed Jul 04 2007 John Berninger - 2.2.1-1 - update to upstream 2.2.1 to fix various vulnerabilities * Mon Apr 16 2007 John Berninger - 2.1.3-1 - update to 2.1.3 final - bz235912 * Mon Mar 26 2007 John Berninger - 2.1.3-rc2 - update to 2.1.3rc2 for bz 233703 xfsprogs-2.8.21-1.fc8 --------------------- * Fri Jul 06 2007 Eric Sandeen 2.8.21-1 - Upgrade to xfsprogs 2.8.21, lazy sb counters enabled, xfs_quota fix (#236746) xmms-modplug-2.05-9.fc8 ----------------------- * Thu Jul 05 2007 Ville Skytt?? - 2.05-9 - Rebuild to fix symbol lookup failures on i386 (#247146). yap-5.1.1-5.fc8 --------------- * Thu Jul 05 2007 Gerard Milmeister - 5.1.1-5 - also build libYap.so * Fri May 11 2007 Gerard Milmeister - 5.1.1-3 - remove -fstack-protector from optflags in order to enable loading of .so modules * Mon Aug 28 2006 Gerard Milmeister - 5.1.1-2 - Rebuild for FE6 Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-Bit-Vector - 6.4-3.fc8.i386 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.i386 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.i386 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Bit-Vector - 6.4-3.fc8.x86_64 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.x86_64 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.x86_64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 giggle - 0.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Bit-Vector - 6.4-3.fc8.ppc requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.ppc requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 rpy - 0.4.6-16.fc7.ppc requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) giggle - 0.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) perl-Bit-Vector - 6.4-3.fc8.ppc64 requires perl(Bit::Vector) perl-Date-Calc - 5.4-1.2.2.1.ppc64 requires perl(Bit::Vector) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) rpy - 0.4.6-16.fc7.ppc64 requires R = 0:2.5.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From caolanm at redhat.com Fri Jul 6 11:18:33 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 06 Jul 2007 12:18:33 +0100 Subject: Two competing (?) Swedish hunspell (openoffice.org) dictionaries Message-ID: <1183720713.3105.8.camel@Nom> I guess I need a native Swedish speaker to take a look at two apparently competing hunspell/openoffice.org dictionaries, and decide between... http://sv.speling.org/, i.e http://sv.speling.org/filer/myspell-sv-1.3.8-6b.tar.gz and http://dsso.se/, i.e. http://hem.bredband.net/dsso1/sv_SE.zip as to which one we want, currently we use the speling.org one. Is there a relationship between the two, is one a successor to the other ? If both are active which one do we want ? C. From valent.turkovic at gmail.com Fri Jul 6 11:08:38 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 13:08:38 +0200 Subject: Amarok 2.0 - has anybody tried it? Message-ID: <1183720118.31708.12.camel@fedora> I have tried building Amarok 2.0 from source on FC6 and F7 and after wasting the whole day I didn't succeed :( I tried going with this howto: http://amarok.kde.org/wiki/2.0_Development_HowTo Did anybody try to build it? If you succeeded please post Fedora specific howto or provide rpms, that would be really appreciated. Are there some devels up to the challenge? ;) Valent. From drago01 at gmail.com Fri Jul 6 11:16:16 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 06 Jul 2007 13:16:16 +0200 Subject: Amarok 2.0 - has anybody tried it? In-Reply-To: <1183720118.31708.12.camel@fedora> References: <1183720118.31708.12.camel@fedora> Message-ID: <468E2480.9020001@gmail.com> Valent Turkovic wrote: > I have tried building Amarok 2.0 from source on FC6 and F7 and after > wasting the whole day I didn't succeed :( > > I tried going with this howto: > http://amarok.kde.org/wiki/2.0_Development_HowTo > > Did anybody try to build it? If you succeeded please post Fedora > specific howto or provide rpms, that would be really appreciated. > > Are there some devels up to the challenge? ;) > > "Amarok 2.0 will require KDE4. Tarballs of KDE4 are periodically released, but the plan is to work off of KDE trunk. It is not known whether alpha1 works with Amarok 2.0 or not." From drago01 at gmail.com Fri Jul 6 11:20:47 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 06 Jul 2007 13:20:47 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <20070704163753.GA4850@jadzia.bu.edu> <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> Message-ID: <468E258F.4090107@gmail.com> Jeffrey C. Ollie wrote: > On Wed, 2007-07-04 at 12:37 -0400, Matthew Miller wrote: > >> On Wed, Jul 04, 2007 at 12:41:09PM +0200, Valent Turkovic wrote: >> >>> Also I understand that directly linking from Fedora or an official >>> Fedora website to http://rpm.livna.org is considered "contributory >>> infingement" >>> >> *Could* be contributory infringement. An important distinction -- I don't >> think we admit any such thing, but are rather erroring on the side of >> caution. >> > > Even if it wasn't contributory infringement, Fedora isn't about building > a great OS using whatever software happens to work, Fedora is about > building a great OS with free and open source software. Making it > easier to install non-FOSS sofware is contrary to that goal. > > its not about non-FOSS software but about FOSS software that can't be shipped due to patents. From rdieter at math.unl.edu Fri Jul 6 12:20:58 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 06 Jul 2007 07:20:58 -0500 Subject: Amarok 2.0 - has anybody tried it? References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> Message-ID: dragoran wrote: > Valent Turkovic wrote: >> I have tried building Amarok 2.0 from source on FC6 and F7 and after >> wasting the whole day I didn't succeed :( ... >> Did anybody try to build it? If you succeeded please post Fedora >> specific howto or provide rpms, that would be really appreciated. >> >> Are there some devels up to the challenge? ;) > "Amarok 2.0 will require KDE4. Tarballs of KDE4 are periodically > released, but the plan is to work off of KDE trunk. It is not known > whether alpha1 works with Amarok 2.0 or not." fyi, kde4 packages are in the works. *Very* rough ones are available the kde-redhat/unstable repo, these currently install into /opt/kde4 we'll hopefully get something based on these into rawhide in the coming weeks. -- Rex From valent.turkovic at gmail.com Fri Jul 6 12:39:38 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 14:39:38 +0200 Subject: Amarok 2.0 - has anybody tried it? In-Reply-To: <468E2480.9020001@gmail.com> References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> Message-ID: <1183725578.2227.10.camel@fedora> On Fri, 2007-07-06 at 13:16 +0200, dragoran wrote: > "Amarok 2.0 will require KDE4. Tarballs of KDE4 are periodically > released, but the plan is to work off of KDE trunk. It is not known > whether alpha1 works with Amarok 2.0 or not." Yup, KDE4 packages are needed, but not all. I downloaded source for KDE4 and started compiling using this guide: http://techbase.kde.org/Getting_Started/Build/Unstable_Version but I didn't succeed ;( From valent.turkovic at gmail.com Fri Jul 6 12:42:02 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 06 Jul 2007 14:42:02 +0200 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <468E258F.4090107@gmail.com> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <20070704163753.GA4850@jadzia.bu.edu> <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> <468E258F.4090107@gmail.com> Message-ID: <1183725722.2227.13.camel@fedora> On Fri, 2007-07-06 at 13:20 +0200, dragoran wrote: > its not about non-FOSS software but about FOSS software that can't be > shipped due to patents. I started this thread ONLY about software that would install 3rd party yum repositories. This way no patented software would ship with Fedora. How did you draw that conclusion? If I was not clear accept my apologies. From per at erinet.se Fri Jul 6 13:07:30 2007 From: per at erinet.se (Per Eriksson) Date: Fri, 06 Jul 2007 15:07:30 +0200 Subject: Two competing (?) Swedish hunspell (openoffice.org) dictionaries Message-ID: <1183727250.5326.44.camel@dhcppc1> Dear Caolan McNamara, Thank you for bringing up this issue. I am working with the marketing effort for the Swedish market in the OpenOffice.org community, and cannot garuantee that everything i mention is 100% true (as this is not what I normally work with). The domain speling.org is driven by Sk?ne Sj?lland Linux User Group and has been a central meeting point for linguistic efforts for the nordic countries. The effort for the different languages there has been alittle different. Much emailing has been used, with a "digest review" kind of way. On the Swedish side, there is no development done on speling.org. DSSO, The big swedish dictionary is a dictionary based on a large list of words by Tom Westerberg, that did not contain any information about the words, it's type, inflection, compound information etc. The DSSO has used that information as a base to work with. DSSO is today using an intelligent web-based interface to work with, using a file format called eXtensible Dictionary and has been developed by the DSSO owner in Perl for the DSSO purpose. --The source-- The source available in the XD format. http://hem.bredband.net/dsso1/dsso-1.22.txt Contains the source from DSSO, updated manually once a month. http://dsso.se/dsso-unstable.txt.gz Is updated automatically every 15 minutes from the web interface. -- Dictionaries -- These are converted versions from XD to hunspell http://hem.bredband.net/dsso1/sv_SE.zip Source code used for conversion: http://dsso.se/kallkod.tgz (Needs Hunspell's munch) -- Older -- http://sv.speling.org/filer/ These files are Aspell, Ispell and Myspell converted files, based on the sol-1.3.8 (tar.gz) and (zip) files. These are old copies, and I can't tell if they are updated or not. (Confused by Apaches version number being present) Hope this helps. If not, please contact off-list and I'll help. _______________________________________________________ Best Regards Per Eriksson Marketing Contact Sweden OpenOffice.org Phone: 0046 (0)70 560 10 33 Web: http://sv.openoffice.org/ E-mail: pereriksson at openoffice.org 2007-07-06 12:18:33 +0100 Caolan McNamara wrote: > I guess I need a native Swedish speaker to take a look at two > apparently > competing hunspell/openoffice.org dictionaries, and decide between... > > http://sv.speling.org/, i.e > http://sv.speling.org/filer/myspell-sv-1.3.8-6b.tar.gz > and > http://dsso.se/, i.e. > http://hem.bredband.net/dsso1/sv_SE.zip > > as to which one we want, currently we use the speling.org one. > > Is there a relationship between the two, is one a successor to the > other ? If both are active which one do we want ? > > C. From ajackson at redhat.com Fri Jul 6 13:37:06 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 06 Jul 2007 09:37:06 -0400 Subject: koji weirdness In-Reply-To: <1181046262.8453.89.camel@localhost.localdomain> References: <465A8F08.90708@hhs.nl> <200705280941.51943.jkeating@redhat.com> <465BDE48.9010606@hhs.nl> <200705290633.56160.jkeating@redhat.com> <1180639944.21359.14.camel@burren.boston.redhat.com> <1180965403.8453.14.camel@localhost.localdomain> <1181046262.8453.89.camel@localhost.localdomain> Message-ID: <1183729026.10197.92.camel@localhost.localdomain> On Tue, 2007-06-05 at 08:24 -0400, Adam Jackson wrote: > On Mon, 2007-06-04 at 09:56 -0400, Adam Jackson wrote: > > > This appears to stick a : between every target in the CHAIN, which means > > the build system will stall between every one. Would it be possible to > > get like a 'make expert-chain' that lets you specify the stall points > > explicitly? > > In fact, rather than just ask for it, here's a patch that does what I > want. This patch doesn't seem to have made it's way into Makefile.common. Should I file a bug? - ajax From rdieter at math.unl.edu Fri Jul 6 14:12:40 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 06 Jul 2007 09:12:40 -0500 Subject: Amarok 2.0 - has anybody tried it? References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> <1183725578.2227.10.camel@fedora> Message-ID: Valent Turkovic wrote: > On Fri, 2007-07-06 at 13:16 +0200, dragoran wrote: >> "Amarok 2.0 will require KDE4. Tarballs of KDE4 are periodically >> released, but the plan is to work off of KDE trunk. It is not known >> whether alpha1 works with Amarok 2.0 or not." > > Yup, KDE4 packages are needed, but not all. I downloaded source for KDE4 > and started compiling using this guide: > http://techbase.kde.org/Getting_Started/Build/Unstable_Version > > but I didn't succeed ;( Fedora is (still) missing a few needed deps... redland is one. quick-n-dirty srpms are available from: http://kdeforge.unl.edu/apt/kde-redhat/all/unstable/SRPMS/ they also require/use qt4 rpm macros, that have been fixed only in 4.3.0-5 and newer (only built for devel/ branch for now). -- Rex -- Rex From greno at verizon.net Fri Jul 6 14:29:20 2007 From: greno at verizon.net (Gerry Reno) Date: Fri, 06 Jul 2007 10:29:20 -0400 Subject: Suggestion: Disk Druid changes In-Reply-To: <468CFD24.2070901@verizon.net> References: <468A556D.7030102@verizon.net> <468CA1F1.4060009@fedoraproject.org> <468CFD24.2070901@verizon.net> Message-ID: <468E51C0.6020701@verizon.net> Gerry Reno wrote: > Rahul Sundaram wrote: >> Gerry Reno wrote: >>> Hi all, >>> As I mentioned in another post, I have been using a technique that >>> at least for me greatly simplifies moving to and from RAID-1 on any >>> system. I do this by installing the system on a degraded RAID-1 >>> array and then later it is very simple to make the system true RAID >>> by just adding the missing drive/partitions. >>> >>> From the other Fedora 8/9 wishlist post: >>> Another thing in Disk Druid that I would like to see is the ability >>> to install on a degraded RAID-1 array where I declare RAID-1 but >>> then the second mirror is missing. I install this way all the time >>> on systems and then when I add the second hard drive later and place >>> it into the array, it just syncs. Want to go back to just a single >>> drive - no problem. Just fault the device and remove it. No >>> complicated remounting filesystems or anything - very smooth. This >>> way you're always on an md device. I would like to see this >>> actually become the default. It makes it very easy to convert a >>> system to RAID-1 later on if the user would like to do so without >>> any complicated procedures necessary. >> >> You might want to file RFE's in http://bugzilla.redhat.com. >> >> Rahul >> > Rahul, > Will do. Just wanted to see what kind of take up there was for the > idea. > > Gerry > Not sure if this is how you file RFE but here it is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247119 Gerry From mattdm at mattdm.org Fri Jul 6 14:39:12 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 6 Jul 2007 10:39:12 -0400 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <20070704163753.GA4850@jadzia.bu.edu> <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> Message-ID: <20070706143912.GA4474@jadzia.bu.edu> On Fri, Jul 06, 2007 at 01:32:56AM -0500, Jeffrey C. Ollie wrote: > Even if it wasn't contributory infringement, Fedora isn't about building > a great OS using whatever software happens to work, Fedora is about > building a great OS with free and open source software. Making it > easier to install non-FOSS sofware is contrary to that goal. And that's why we bend over backwards to provide multilib. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Fri Jul 6 14:50:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Jul 2007 10:50:45 -0400 Subject: koji weirdness In-Reply-To: <1181046262.8453.89.camel@localhost.localdomain> References: <465A8F08.90708@hhs.nl> <1180965403.8453.14.camel@localhost.localdomain> <1181046262.8453.89.camel@localhost.localdomain> Message-ID: <200707061050.48864.jkeating@redhat.com> On Tuesday 05 June 2007 08:24:22 Adam Jackson wrote: > On Mon, 2007-06-04 at 09:56 -0400, Adam Jackson wrote: > > This appears to stick a : between every target in the CHAIN, which means > > the build system will stall between every one. Would it be possible to > > get like a 'make expert-chain' that lets you specify the stall points > > explicitly? > > In fact, rather than just ask for it, here's a patch that does what I > want. > > - ajax Couple things. Should there be a .PHONY target for chain-build-expert? Can you add a section in the help for this new target? -- 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 bruno at wolff.to Fri Jul 6 15:16:09 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 6 Jul 2007 10:16:09 -0500 Subject: dmraid failure/test cases [fc5-7] In-Reply-To: <944847.33315.qm@web56907.mail.re3.yahoo.com> References: <1183704185.3591.14.camel@home-desk> <944847.33315.qm@web56907.mail.re3.yahoo.com> Message-ID: <20070706151609.GA20638@wolff.to> On Fri, Jul 06, 2007 at 01:59:53 -0700, Jane Dogalt wrote: > > --- Sean Bruno wrote: > > > In a related note, it would be nice if the installer would allow you > > to > > create a broken raid 1 in the installer, anaconda should definitely > > warn > > you and tell you that what you are doing is loopy, but there should > > be a > > way to just say, "go ahead if you really wanna". > > I thought it was going to be loopy too... > > http://www.redhat.com/archives/fedora-livecd-list/2006-August/msg00000.html > > I might just have to post a 7 line patch tomorrow that implements the > above... without using so much as a single loop device ;) I wouldn't let it create a 'broken' (e.g. in degraded mode) raid 1 device. You can create raid 1 arrays with only one device rather than with two devices and one of them missing. It isn't hard to add other devices to a raid 1 array later. Letting the installer *use* a degraded array is a grayer area. I think it would be better to require the admin to modify the array first otherwise you can have unexpected things happen when people split arrays by failing a drive, but end up having the failed device get used when the array is restarted later, instead of the intended device. I have asked for anaconda to be changed to allow 1 element raid 1 arrays to be used in the past (188314) and have been turned down. From caolanm at redhat.com Fri Jul 6 16:39:55 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 06 Jul 2007 17:39:55 +0100 Subject: Two competing (?) Swedish hunspell (openoffice.org) dictionaries In-Reply-To: <1183727250.5326.44.camel@dhcppc1> References: <1183727250.5326.44.camel@dhcppc1> Message-ID: <1183739995.3105.33.camel@Nom> On Fri, 2007-07-06 at 15:07 +0200, Per Eriksson wrote: > --The source-- > The source available in the XD format. > http://hem.bredband.net/dsso1/dsso-1.22.txt > Contains the source from DSSO, updated manually once a month. Hmm, wget -S says: Last-Modified: Thu, 07 Dec 2006 09:36:37 GMT, perhaps updated once a year or something ? > > http://dsso.se/dsso-unstable.txt.gz > Is updated automatically every 15 minutes from the web interface. wget -S says: Date: Fri, 06 Jul 2007 13:27:54 GMT Last-Modified: Thu, 05 Jul 2007 10:40:44 GMT This one seems to be updated very frequently alright. > -- Dictionaries -- > These are converted versions from XD to hunspell > http://hem.bredband.net/dsso1/sv_SE.zip > > Source code used for conversion: > http://dsso.se/kallkod.tgz > (Needs Hunspell's munch) Ah, excellent. Couldn't read the text to figure out that page :-) > -- Older -- > http://sv.speling.org/filer/ > These files are Aspell, Ispell and Myspell converted files, based on the > sol-1.3.8 (tar.gz) and (zip) files. These are old copies, and I can't > tell if they are updated or not. (Confused by Apaches version number > being present) This one was updated on 05-Jul-2007 (after a long time of being not updated) to http://sv.speling.org/filer/myspell-sv-1.3.8-6b.tar.gz which triggered me looking at it again. Anyhow.. I like the sound of the dsso one, it seems like the contemporary content developing project. Unless there are any objections I think I'll point the hunspell-sv at that dictionary. Perhaps someone Swedish should drop a line to both parties and merge the efforts, if even to just pointing the myspell-sv/hunspell-sv seeking user from speling towards dsso. C. From buildsys at fedoraproject.org Fri Jul 6 15:55:38 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 06 Jul 2007 15:55:38 -0000 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 Message-ID: <20070706155538.21202.861@extras64.linux.duke.edu> ====================================================================== The results in this summary consider unreleased updates in the build-system's needsign-queue! ====================================================================== Summary of broken packages (by owner): caillon AT redhat.com banshee - 0.10.12-4.fc6.i386 banshee - 0.10.12-4.fc6.ppc banshee - 0.10.12-4.fc6.x86_64 davidz AT redhat.com livecd-tools - 008-1.fc6.noarch (62 days) livecd-tools - 008-1.fc6.noarch (62 days) devrim AT commandprompt.com postgis-jdbc - 1.2.0-4.fc6.i386 postgis-jdbc - 1.2.0-4.fc6.ppc postgis-jdbc - 1.2.0-4.fc6.x86_64 jamatos AT fc.up.pt rpy - 0.4.6-16.fc6.i386 (3 days) rpy - 0.4.6-16.fc6.ppc (3 days) rpy - 0.4.6-16.fc6.x86_64 (3 days) ====================================================================== Broken packages in fedora-extras-6-i386: banshee-0.10.12-4.fc6.i386 requires mono(dbus-sharp) = 0:0.60.0.0 postgis-jdbc-1.2.0-4.fc6.i386 requires postgis = 0:1.2.0-4.fc6 rpy-0.4.6-16.fc6.i386 requires R = 0:2.5.0 ====================================================================== Broken packages in fedora-extras-6-ppc: banshee-0.10.12-4.fc6.ppc requires mono(dbus-sharp) = 0:0.60.0.0 postgis-jdbc-1.2.0-4.fc6.ppc requires postgis = 0:1.2.0-4.fc6 rpy-0.4.6-16.fc6.ppc requires R = 0:2.5.0 ====================================================================== Broken packages in fedora-extras-6-x86_64: banshee-0.10.12-4.fc6.x86_64 requires mono(dbus-sharp) = 0:0.60.0.0 postgis-jdbc-1.2.0-4.fc6.x86_64 requires postgis = 0:1.2.0-4.fc6 rpy-0.4.6-16.fc6.x86_64 requires R = 0:2.5.0 ====================================================================== Broken packages in fedora-extras-needsign-6-i386: livecd-tools-008-1.fc6.noarch requires dosfstools >= 0:2.11-8 ====================================================================== Broken packages in fedora-extras-needsign-6-x86_64: livecd-tools-008-1.fc6.noarch requires dosfstools >= 0:2.11-8 From mschwendt.tmp0701.nospam at arcor.de Fri Jul 6 16:09:40 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 6 Jul 2007 18:09:40 +0200 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 In-Reply-To: <20070706155538.21202.861@extras64.linux.duke.edu> References: <20070706155538.21202.861@extras64.linux.duke.edu> Message-ID: <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> Plus these for i386/ppc/x86_64 -- I haven't examined what update breaks these and the pkgs in Extras 6: source rpm: dbus-sharp-0.63-6.fc6.src.rpm package: dbus-sharp-devel - 0.63-6.fc6.i386 from fedora-core-6-i386 unresolved deps: dbus-sharp = 0:0.63-6.fc6 source rpm: f-spot-0.2.1-1.fc6.src.rpm package: f-spot - 0.2.1-1.fc6.i386 from fedora-core-6-i386 unresolved deps: mono(dbus-sharp) = 0:0.60.0.0 From harald at redhat.com Fri Jul 6 16:18:04 2007 From: harald at redhat.com (Harald Hoyer) Date: Fri, 06 Jul 2007 18:18:04 +0200 Subject: Parallel Booting In-Reply-To: <20070704010938.GA9335@nostromo.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> Message-ID: <468E6B3C.6070100@redhat.com> Bill Nottingham schrieb: > Bill Nottingham (notting at redhat.com) said: >> - where are the benchmarks? What's the actual gain? > > Not seeing any other benchmarks, I decided to test this. > > Fairly standard box - P4, ata_piix, 1G memory. Stock desktop install, fully > up to date with updates and updates-testing as of this afternoon. > > A 'normal' boot to gdm is about 56.9 seconds. I installed > prcsys, and edited the startup scripts to add LSB dependencies > as attached. > > I then booted with prcsys and parallel init. The new boot time was... > 56.3 and 56.6 seconds. With: S12syslog S13ip6tables S13iptables S14network S25netfs S26auditd S26messagebus S27setroubleshoot S55sshd S98haldaemon S99local /etc/rc.d/rc takes: 8.5s in normal mode 6s in parallel startup > > So, for all this work, we get a 0.6%-1.1% speedup. so for me thats 140% speedup :) > Oh, and we get > 62 AVCs from SELinux in the process. What's the point of this again? for that, I now have a fix. > >> - how would this be useful for the case where facilities that are provided >> are determined at runtime (say, NetworkManager providing $network instead >> of /etc/init.d/network, or $remote_fs being provided by either rc.sysinit >> or /etc/init.d/netfs, depending on configuration). yep, tbd >> Similarly, you may >> want a meta-dependency for 'authorization available', which would be >> at different times depending on whether or not you're using local >> passwords, KRB5, etc. yep, tbd >> - does this work with dbus system activation? yep, tbd > > I also don't see how it handles either of these. > > Bill > Which system does fullfill all of these requirements yet? Harald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From clydekunkel7734 at cox.net Fri Jul 6 16:27:10 2007 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Fri, 06 Jul 2007 12:27:10 -0400 Subject: dmraid failure/test cases [fc5-7] In-Reply-To: <1183704185.3591.14.camel@home-desk> References: <1183704185.3591.14.camel@home-desk> Message-ID: <468E6D5E.2010400@cox.net> Sean Bruno wrote: > > Third, and the most annoying, was that I couldn't install a plain s/w > raid configuration with 2 drives connected. There was just no way to > keep the system from assuming that I meant to use /dev/mapper/mapper0 > even after I ensured that the superblock metadata was wiped out with a > quick call to 'dmraid -Er /dev/sdX' to be sure that it was really gone. > Sean > On my x86 box, I used the "nompath" parameter during install to prevent /dev/mapper/mapper0 from being used and then could see all disks properly, including pre-existing software raid arrays. Seems that even if you are not using the bios raid capability of a SATA setup, anaconda thinks you want to. Must be a way to check the bios to see if the setup is for raid or not. -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From fedora at leemhuis.info Fri Jul 6 16:39:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Jul 2007 18:39:26 +0200 Subject: x86_64 devel kernel boot only with nohpet (was: Re: rawhide report: 20070705 changes) In-Reply-To: References: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> Message-ID: <468E703E.4080605@leemhuis.info> On 05.07.2007 16:50, dragoran wrote: > On 7/5/07, *dragoran* > wrote: > On 7/5/07, *dragoran* < drago01 at gmail.com > > wrote: > On 7/5/07, *Build System* < buildsys at redhat.com > > wrote: > kernel-2.6.22-0.9.rc7.git3.fc8 > ------------------------------ > * Wed Jul 04 2007 Dave Jones > > - 2.6.22-rc7-git3 > > * Wed Jul 04 2007 Dave Jones < davej at redhat.com > > > - x86-64 tickless support. > I tested this one on my laptop (still uses f7) and it hangs at > boot. after "Booting the kernel" no more errors, no panic it > just don't continue to boot. > Its a Zepto 6615WD with a Core 2 Duo T7400, ICH7 chipset running > on x86_64 > added CC, any idea how to get a message from the kernel to see whats > going on? > it boots when I pass "nohpet" to it. > dmesg is attached. Same problem here as well -- same workaround works :-) Dell D630 (Santa Rosa with GM965). http://leemhuis.info/files/fedorarpms/MISC.fdr/dmesg-d630 dragoran, did you file a bug somewhere? I could not find one. Cu thl From dominik at greysector.net Fri Jul 6 16:55:07 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 6 Jul 2007 18:55:07 +0200 Subject: Unpushing broken or obsolete updates from testing In-Reply-To: References: Message-ID: <20070706165507.GA19599@ryvius.pekin.waw.pl> On Friday, 06 July 2007 at 03:37, Kevin Kofler wrote: > Why are updates lingering in updates-testing for weeks when: > * they are known broken and/or > * they have already been replaced by a new version, which is already in > stable? > IMHO, that's really what the "unpush" option is for. For example, do we > really need to have that obsolete Thunderbird RC sitting in testing > forever when the actual release is already out in the stable updates? > This also makes it harder to track down the legitimate updates which have > been sitting in testing for way too long. This is exactly the kind of thing that should be automated, i.e. run a script once a week that'd check if there are any obsolete updates in testing and delete them (notifying the owner perhaps). Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rhally at mindspring.com Fri Jul 6 17:53:06 2007 From: rhally at mindspring.com (Richard Hally) Date: Fri, 06 Jul 2007 13:53:06 -0400 Subject: rawhide report: 20070706 changes In-Reply-To: <200707060937.l669bqOT005852@porkchop.devel.redhat.com> References: <200707060937.l669bqOT005852@porkchop.devel.redhat.com> Message-ID: <468E8182.2050709@mindspring.com> Build System wrote: > > kernel-2.6.22-0.12.rc7.git4.fc8 > ------------------------------- > * Thu Jul 05 2007 Dave Jones > - Further tickless improvements to ondemand cpufreq governor. > > * Thu Jul 05 2007 Dave Jones > - 2.6.22-rc7-git4 > > * Thu Jul 05 2007 Dave Jones > - Lower mkinitrd requires: to match what's in rawhide. > It looks like all of this stuff did not get pushed to the download servers. Or is it the repodata? or both? Richard From jkeating at redhat.com Fri Jul 6 17:48:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Jul 2007 13:48:13 -0400 Subject: rawhide report: 20070706 changes In-Reply-To: <468E8182.2050709@mindspring.com> References: <200707060937.l669bqOT005852@porkchop.devel.redhat.com> <468E8182.2050709@mindspring.com> Message-ID: <200707061348.13909.jkeating@redhat.com> On Friday 06 July 2007 13:53:06 Richard Hally wrote: > It looks like all of this stuff did not get pushed to the download servers. > Or is it the repodata? or both? Both. Fixing it as we speak. -- 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 rhally at mindspring.com Fri Jul 6 18:15:17 2007 From: rhally at mindspring.com (Richard Hally) Date: Fri, 06 Jul 2007 14:15:17 -0400 Subject: rawhide report: 20070706 changes In-Reply-To: <200707061348.13909.jkeating@redhat.com> References: <200707060937.l669bqOT005852@porkchop.devel.redhat.com> <468E8182.2050709@mindspring.com> <200707061348.13909.jkeating@redhat.com> Message-ID: <468E86B5.1000700@mindspring.com> Jesse Keating wrote: > On Friday 06 July 2007 13:53:06 Richard Hally wrote: >> It looks like all of this stuff did not get pushed to the download servers. >> Or is it the repodata? or both? > > Both. Fixing it as we speak. > Thanks Jesse ! From davej at redhat.com Fri Jul 6 18:25:20 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 6 Jul 2007 14:25:20 -0400 Subject: Parallel Booting In-Reply-To: <468E6B3C.6070100@redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <468E6B3C.6070100@redhat.com> Message-ID: <20070706182520.GB25869@redhat.com> On Fri, Jul 06, 2007 at 06:18:04PM +0200, Harald Hoyer wrote: > With: > > S12syslog > S13ip6tables > S13iptables > S14network > S25netfs > S26auditd > S26messagebus > S27setroubleshoot > S55sshd > S98haldaemon > S99local > > /etc/rc.d/rc takes: > 8.5s in normal mode > 6s in parallel startup This seems suspicious to me. A lot of the above isn't really parallelisable (or shouldn't be). network->ip[6]tables-> sshd|netfs should be serialised. Also afaik, haldaemon can't start until messagebus has run setroubleshoot is also serialising on auditd iirc. So what's actually causing that 2s difference? Is it possible that you just got a dhcp reply quicker the second time? Dave -- http://www.codemonkey.org.uk From mmcgrath at redhat.com Fri Jul 6 15:45:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 06 Jul 2007 10:45:23 -0500 Subject: New Infrastructure Ticketing System Message-ID: <468E6393.7000301@redhat.com> The Infrastructure Team has decided to change ticketing systems. The new system is available at: https://hosted.fedoraproject.org/projects/fedora-infrastructure/report We'll be continuing to set that site up but tickets can now be filed there. The previous ticketing system (at https://admin.fedoraproject.org/tickets/) turned out to be a bit to heavy for our teams needs. Using a Trac system feels more natural to us and we suspect it will feel more natural to the community as well. -Mike _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From buildsys at fedoraproject.org Fri Jul 6 20:09:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Jul 2007 16:09:50 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-06 Message-ID: <20070706200950.EF493152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 45 abcm2ps-5.4.4-1.fc6 NEW astyle-1.21-5.fc6 : Source code formatter for C-like programming languages NEW atanks-2.4-1.fc6 : Remake of a classic DOS game "Scorched Earth" balsa-2.3.17-1.fc6 cegui-0.5.0b-4.fc6 chess-1.0-6.fc6 dar-2.3.4-1.fc6 NEW drawtiming-0.6.2-1.fc6 : A command line tool for generating timing diagrams fcron-3.0.3-1.fc6 gnupg2-2.0.4-1.fc6 NEW gpsdrive-2.09-3.fc6 : A GPS based navigation tool gxemul-0.4.6-1.fc6 gxine-0.5.11-5.fc6 ktorrent-2.2-2.fc6 NEW ldapvi-1.7-1.fc6 : An interactive LDAP client lib765-0.4.0-1.fc6 libdsk-1.1.12-1.fc6 NEW mrxvt-0.5.2-9.fc6 : A lightweight multi-tabbed terminal emulator for X NEW msmtp-1.4.12-7.fc6 : SMTP client nexuiz-2.3-1.fc6 nexuiz-data-2.3-2.fc6 ogre-1.4.2-1.fc6 NEW ois-1.0-1.fc6 : Open Input System, OO gaming input library perl-Class-DBI-Loader-Relationship-1.3-4.fc6 perl-Email-MIME-Creator-1.453-2.fc6 perl-Email-Simple-Creator-1.420-3.fc6 NEW perl-Text-Markdown-1.0.3-3.fc6 : A text-to-HTML filter perl-version-0.7203-1.fc6 NEW php-spyc-0.2.5-1.fc6 : A simple php yaml class NEW presto-utils-0.2.0-1.fc6 : Tools for creating presto repositories NEW qgis-0.8.1-10.fc6 : A user friendly Open Source Geographic Information System R-hdf5-1.6.6-1.fc6 roundcubemail-0.1-0.6rc1.1.fc6 NEW sofia-sip-1.12.6-8.fc6 : Sofia SIP User-Agent library spandsp-0.0.4-0.1.pre3.fc6 TeXmacs-1.0.6.10-3.fc6 NEW trac-git-plugin-0.0.1-3.20070705svn1536.fc6 : GIT version control plugin for Trac NEW trac-mercurial-plugin-0.10.0.2-3.20070705svn5798.fc6 : Mercurial plugin for Trac ushare-1.0-1.fc6 wammu-0.19-3.fc6 wordpress-2.2.1-1.fc6 xemacs-21.5.28-3.fc6 xmoto-edit-0.2.4-8.fc6 NEW xzgv-0.8-5.fc6 : A GTK+/Imlib-based picture viewer for X yap-5.1.1-5.fc6 Changes in Fedora Extras 6: abcm2ps-5.4.4-1.fc6 ------------------- * Wed Jul 04 2007 Gerard Milmeister - 5.4.4-1 - new version 5.4.4 astyle-1.21-5.fc6 ----------------- * Mon Jul 02 2007 Adam M. Dutko 1.21-5 - Fixed sourceforge Source0 link. - Updated to 1.21. * Tue Jun 19 2007 Adam M. Dutko 1.20.2-4 - Removed macros from changelog - Formatted changelog from 1.20.2-2 * Tue Jun 19 2007 Adam M. Dutko 1.20.2-3 - Changed licensing to LGPL from GPL - Removed execute bit from src/* - Used bindir/install instead of /usr/bin/install * Thu Jun 14 2007 Mary Ellen Foster 1.20.2-2 - Modifications from Ralf Corsepius (thanks!): - Eliminated use of build/Makefile; just compile and install directly - Use bindir rather than /usr/bin atanks-2.4-1.fc6 ---------------- * Mon Jul 02 2007 Konstantin Ryabitsev - 2.4-1 - Importing into Fedora CVS and building. * Fri Jun 29 2007 Konstantin Ryabitsev - 2.4-0.1 - Initial packaging for Fedora. balsa-2.3.17-1.fc6 ------------------ * Wed Jul 04 2007 Pawel Salek - 2.3.17-1 - update to upstream 2.3.17. cegui-0.5.0b-4.fc6 ------------------ * Sat Jun 30 2007 Ian Chapman 0.5.0b-4.fc6 - release bump * Sun Jun 17 2007 Ian Chapman 0.5.0b-3.fc6 - rpath fixes for x86_64 * Sun Jun 10 2007 Ian Chapman 0.5.0b-2.fc6 - Added patch to fix undefined-non-weak-symbol warnings * Wed May 30 2007 Ian Chapman 0.5.0b-1.fc6 - Upgrade to 0.5.0b - Added patch from Gentoo to compile with lua 5.1 - Updated the patch to use versioned .so for dlopen() - Dropped several patches as they are no longer needed - Dropped useless provides. Nothing used them anyway - Added support for the SILLY image codec - Added support for xerces-c chess-1.0-6.fc6 --------------- * Sun Jul 01 2007 Hans de Goede 1.0-6 - Port to Ogre 1.4.x + OIS * Fri Feb 16 2007 Hans de Goede 1.0-5 - Rebuild for new ogre * Fri Oct 27 2006 Hans de Goede 1.0-4 - Rebuild for new ogre dar-2.3.4-1.fc6 --------------- * Tue Jul 03 2007 Chris Petersen 2.3.4-1 - Update to 2.3.4 drawtiming-0.6.2-1.fc6 ---------------------- * Thu Jun 28 2007 Chitlesh Goorah - 0.6.2-1 - Initial Package fcron-3.0.3-1.fc6 ----------------- * Thu Jul 05 2007 Alain Portal 3.0.3-1 - New upstream version - Update patch0 - Remove patch1 & patch2, no more needed * Thu Apr 12 2007 Alain Portal 3.0.2-2 - Replace "smtpdaemon" by "/usr/sbin/sendmail" in Requires and BuildRequires statements. Fix #235601. * Wed Feb 07 2007 Alain Portal 3.0.2-1 - New upstream version - Update patch3 - Remove patch4 now applied by upstream gnupg2-2.0.4-1.fc6 ------------------ * Fri May 18 2007 Rex Dieter 2.0.4-1 - gnupg-2.0.4 * Thu Mar 08 2007 Rex Dieter 2.0.3-1 - gnupg-2.0.3 * Fri Feb 02 2007 Rex Dieter 2.0.2-1 - gnupg-2.0.2 * Wed Dec 06 2006 Rex Dieter 2.0.1-2 - CVE-2006-6235 (#219934) gpsdrive-2.09-3.fc6 ------------------- * Mon May 21 2007 Kevin Fenzi - 2.09-3 - Do not ship useless INSTALL file. - Fix incorrect greek translation. gxemul-0.4.6-1.fc6 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 0.4.6-1 - bump to 0.4.6 gxine-0.5.11-5.fc6 ------------------ * Fri Jul 06 2007 Martin Sourada - 0.5.11-5 - Change the name displayed in menu to GXine Video Player * Wed May 16 2007 Martin Sourada - 0.5.11-4 - rebuild to include ppc64 arch ktorrent-2.2-2.fc6 ------------------ * Fri Jul 06 2007 Roland Wolters 2.2-2 - spec-file fixes re-included * Tue Jul 03 2007 Roland Wolters 2.2-1 - update to upstream 2.2: - cleaner UI - - New file selection dialog - Statistics plugin with pretty graphs - Possibility to open as many tabs as you want - Diskspace monitoring and stopping of downloads when the diskspace drops below a certain value - Individual torrent speed limits - Full disk preallocation to avoid fragmentation * Wed Jun 13 2007 Roland Wolters 2.2rc1-1 - update to upstream 2.2rc1 ldapvi-1.7-1.fc6 ---------------- * Thu Jul 05 2007 Gavin Henry - 1.7-1 - Initial version lib765-0.4.0-1.fc6 ------------------ * Thu Jul 05 2007 Ian Chapman 0.4.0-1.fc6 - Upgrade to 0.4.0 - 'Escaped' several macros in the changelogs - Corrected summary for devel package libdsk-1.1.12-1.fc6 ------------------- * Wed Jul 04 2007 Ian Chapman 1.1.12-1.fc6 - Upgrade to 1.1.12 - Removed some extraneous 'docs' - Moved some docs to the devel sub package mrxvt-0.5.2-9.fc6 ----------------- * Mon Jun 18 2007 Adam M. Dutko - 0.5.2-9 - Removed extraneous build comments. - Modified "end-of-line" fix to fit one line after patch1. - Fixed comment for 0.5.2-6 * Mon Jun 18 2007 Mamoru Tasaka - 0.5.2-8 - Clean up %prep stage * Sat Jun 16 2007 Adam M. Dutko - 0.5.2-7 - Removed Version entry from desktop file. * Sun Jun 10 2007 Adam M. Dutko - 0.5.2-6 - Fixed "end-of-line" encoding error with sed replacement - Fixed release tag msmtp-1.4.12-7.fc6 ------------------ * Sat Jun 30 2007 Nikolay Vladimirov - 1.4.12-7 - timestamps fix * Sat Jun 30 2007 Nikolay Vladimirov - 1.4.12-6 - minor spec fixes * Thu Jun 28 2007 Nikolay Vladimirov - 1.4.12-5 - removed provides for sendmail - added BuildRequires for libgsasl * Fri Jun 22 2007 Nikolay Vladimirov - 1.4.12-4 - not using alternatives * Wed Jun 20 2007 Nikolay Vladimirov - 1.4.12-3 - now using alternatives - added provides for sendmail - edited description * Tue Jun 19 2007 Nikolay Vladimirov - 1.4.12-2 - fixed source0 - removed openssl-devel from BuildRequires - added BuildRequires for gettext - added more doc files * Tue Jun 19 2007 Nikolay Vladimirov - 1.4.12-1 - new version - changed Summary and description * Mon Jun 11 2007 Nikolay Vladimirov - 1.4.11-2 - fixed URL, Summary and description * Mon Jun 11 2007 Nikolay Vladimirov - 1.4.11-1 - initial release nexuiz-2.3-1.fc6 ---------------- * Tue Jun 19 2007 Jon Ciesla - 2.3-1 - Updated to 2.3 nexuiz-data-2.3-2.fc6 --------------------- * Mon Jul 02 2007 Jon Ciesla - 2.3-2 - Added disttag. * Tue Jun 19 2007 Jon Ciesla - 2.3-1 - Updated to 2.3 ogre-1.4.2-1.fc6 ---------------- * Sat Jun 30 2007 Hans de Goede 1.4.2-1 - New upstream release 1.4.2 - Warning as always with a new upstream ogre release this breaks the ABI and changes the soname! - Warning this release also breaks the API! * Thu May 24 2007 Hans de Goede 1.2.5-2 - Fix building on ppc64 * Fri Feb 16 2007 Hans de Goede 1.2.5-1 - New upstream release 1.2.5 * Fri Jan 19 2007 Hans de Goede 1.2.3-2 - Rebuild for new cairomm - Added a samples sub-package (suggested by Xavier Decoret) * Fri Oct 27 2006 Hans de Goede 1.2.3-1 - New upstream release 1.2.3 - Warning as always with a new upstream ogre release this breaks the ABI and changes the soname! ois-1.0-1.fc6 ------------- * Sun Jul 01 2007 Hans de Goede 1.0-1 - Initial Fedora package perl-Class-DBI-Loader-Relationship-1.3-4.fc6 -------------------------------------------- * Thu Jul 05 2007 Tom "spot" Callaway 1.3-4 - fix false provide (Class::DBI::Loader::Generic) perl-Email-MIME-Creator-1.453-2.fc6 ----------------------------------- * Thu Jul 05 2007 Tom "spot" Callaway - 1.453-2 - fix false provide (Email::MIME) perl-Email-Simple-Creator-1.420-3.fc6 ------------------------------------- * Thu Jul 05 2007 Tom "spot" Callaway - 1.420-3 - fix false provide of Email::Simple perl-Text-Markdown-1.0.3-3.fc6 ------------------------------ * Tue Jul 03 2007 Jeffrey C. Ollie - 1.0.3-3 - Fix license field. * Sat Jun 30 2007 Jeffrey C. Ollie - 1.0.3-2 - BR some modules for tests perl-version-0.7203-1.fc6 ------------------------- * Tue Jul 03 2007 Tom "spot" Callaway 1:0.7203-1 - i love perl versioning. bumping to 0.7203 php-spyc-0.2.5-1.fc6 -------------------- * Wed Jun 20 2007 Michael Stahnke - 0.2.5-1 - Initial packaging presto-utils-0.2.0-1.fc6 ------------------------ * Tue Jun 19 2007 Jonathan Dieter - 0.2.0-1 - Initial release qgis-0.8.1-10.fc6 ----------------- * Thu Jul 05 2007 Douglas E. Warner 0.8.1-10 - updated lib64 patch for core and grass libraries * Thu Jul 05 2007 Douglas E. Warner 0.8.1-9 - updated lib64 patch * Thu Jul 05 2007 Douglas E. Warner 0.8.1-8 - adding ExcludeArch: ppc64 for bug#247152 (lrelease segfault) * Thu Jul 05 2007 Douglas E. Warner 0.8.1-7 - adding patch for lib64 support through lib_suffix * Thu Jun 28 2007 Douglas E. Warner 0.8.1-6 - fixed date of changelog entry for 0.8.1-5 from Wed Jun 27 2007 to Thu Jun 28 2007 - linking icon to included png instead of packaging it again * Thu Jun 28 2007 Douglas E. Warner 0.8.1-5 - adding comment on why grass is required in addition to grass-devel for BR - fixing typo * Wed Jun 27 2007 Douglas E. Warner 0.8.1-4 - adding contributors to doc - adding desktop file and icon * Mon Jun 25 2007 Douglas E. Warner 0.8.1-3 - updating detection of grass libraries to not use RPM call - disabling building of -devel package due to shared libraries not being versioned and having no other packages that compile against qgis (see bug #241403) - removing chmod of test_export.py due to lack of python requirement - removing msexport and share/python directory due to removal of python * Fri Jun 22 2007 Douglas E. Warner 0.8.1-2 - added BuildRequires: cmake - updated build to use cmake macro and make verbose * Tue Jun 19 2007 Douglas E. Warner 0.8.1-1 - updating version - removed BuildRequires: python-devel due to lack of PyQt4 bindings - updated build for use of cmake instead of autotools - added patch for setting WORKDIR in settings.pro file - added patch for fixing install path of man pages - updated library names R-hdf5-1.6.6-1.fc6 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 1.6.6-1 - bump to 1.6.6 roundcubemail-0.1-0.6rc1.1.fc6 ------------------------------ * Tue Jul 03 2007 Jon Ciesla = 0.1-0.6rc1.1 - New upstream release, all GPL, all current languages included. sofia-sip-1.12.6-8.fc6 ---------------------- * Tue Jul 03 2007 Jeffrey C. Ollie - 1.12.6-8 - Disable checks for now, they all pass in local mock builds but fail when built with plague. * Tue Jul 03 2007 Jeffrey C. Ollie - 1.12.6-7 - Enable more debugging output from "make check" * Tue Jul 03 2007 Jeffrey C. Ollie - 1.12.6-6 - Block building on ppc64 * Mon Jul 02 2007 Jeffrey C. Ollie - 1.12.6-5 - Update description. * Fri Jun 29 2007 Jeffrey C. Ollie - 1.12.6-4 - Get rid of .h.in files. * Fri Jun 29 2007 Jeffrey C. Ollie - 1.12.6-3 - Link glib library with main library. * Tue Jun 26 2007 Jeffrey C. Ollie - 1.12.6-2 - Re-run libtoolize and auto* to fix rpath issues. - Add --disable-rpath to the configure line. - The devel packages need to BR pkgconfig. spandsp-0.0.4-0.1.pre3.fc6 -------------------------- * Mon Jun 11 2007 Jeffrey C. Ollie - 0.0.4-0.1.pre3 - Update to 0.0.4pre3 TeXmacs-1.0.6.10-3.fc6 ---------------------- * Fri Jun 29 2007 Gerard Milmeister - 1.0.6.10-3 - ps generation fix trac-git-plugin-0.0.1-3.20070705svn1536.fc6 ------------------------------------------- * Thu Jul 05 2007 Jesse Keating - 0.0.1-3.20070705svn1536 - Require trac and python-setuptools as well * Thu Jul 05 2007 Jesse Keating - 0.0.1-2.20070705svn1536 - Require git-core * Thu Jul 05 2007 Jesse Keating - 0.0.1-1.20070705svn1536 - Initial build trac-mercurial-plugin-0.10.0.2-3.20070705svn5798.fc6 ---------------------------------------------------- * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-3.20070705svn5798 - Require trac, python-setuptools as well * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-2.20070705svn5798 - Require mercurial * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-1.20070705svn5798 - Initial build ushare-1.0-1.fc6 ---------------- * Fri Jul 06 2007 Eric Tanguy - 1.0-1 - Update to 1.0 * Tue Jun 26 2007 Eric Tanguy - 0.9.10-4 - Rebuild wammu-0.19-3.fc6 ---------------- * Tue Jul 03 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.19-3 - Added additional Requires. wordpress-2.2.1-1.fc6 --------------------- * Wed Jul 04 2007 John Berninger - 2.2.1-1 - update to upstream 2.2.1 to fix various vulnerabilities xemacs-21.5.28-3.fc6 -------------------- * Sun Jun 24 2007 Ville Skytt? - 21.5.28-3 - Apply upstream fix for #245017. xmoto-edit-0.2.4-8.fc6 ---------------------- * Tue Jul 03 2007 Jon Ciesla 0.2.4-8 - Fixed BZ 246572. xzgv-0.8-5.fc6 -------------- * Wed Jul 04 2007 Terje Rosten - 0.8-5 - importing, fix tag problem * Tue Jul 03 2007 Terje Rosten - 0.8-4 - add gnome-icon-theme to req * Sun Jul 01 2007 Terje Rosten - 0.8-3 - really add AUTHORS and NEWS to %doc - use image-viewer.png from gnome-icon-theme as icon - help system need xterm * Wed Jun 20 2007 Terje Rosten - 0.8-2 - add AUTHORS and NEWS to %doc - fix scriplets - add buildreq: desktop-file-utils - add smp_mflags macro - remove app categori from desktop file - switch icon to eog * Mon Jun 18 2007 Terje Rosten - 0.8-1 - 0.8 - add integer overflow patch - cleanup description - add correct buildrequires - desktop file - add req for post, preun yap-5.1.1-5.fc6 --------------- * Thu Jul 05 2007 Gerard Milmeister - 5.1.1-5 - also build libYap.so For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From drago01 at gmail.com Fri Jul 6 20:30:27 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 6 Jul 2007 22:30:27 +0200 Subject: x86_64 devel kernel boot only with nohpet (was: Re: rawhide report: 20070705 changes) In-Reply-To: <468E703E.4080605@leemhuis.info> References: <200707051037.l65Abw9r012771@porkchop.devel.redhat.com> <468E703E.4080605@leemhuis.info> Message-ID: On 7/6/07, Thorsten Leemhuis wrote: > > On 05.07.2007 16:50, dragoran wrote: > > On 7/5/07, *dragoran* > > wrote: > > On 7/5/07, *dragoran* < drago01 at gmail.com > > > wrote: > > On 7/5/07, *Build System* < buildsys at redhat.com > > > wrote: > > kernel-2.6.22-0.9.rc7.git3.fc8 > > ------------------------------ > > * Wed Jul 04 2007 Dave Jones > > > > - 2.6.22-rc7-git3 > > > > * Wed Jul 04 2007 Dave Jones < davej at redhat.com > > > > > - x86-64 tickless support. > > I tested this one on my laptop (still uses f7) and it hangs at > > boot. after "Booting the kernel" no more errors, no panic it > > just don't continue to boot. > > Its a Zepto 6615WD with a Core 2 Duo T7400, ICH7 chipset running > > on x86_64 > > added CC, any idea how to get a message from the kernel to see whats > > going on? > > it boots when I pass "nohpet" to it. > > dmesg is attached. > > Same problem here as well -- same workaround works :-) > > Dell D630 (Santa Rosa with GM965). > http://leemhuis.info/files/fedorarpms/MISC.fdr/dmesg-d630 > > dragoran, did you file a bug somewhere? I could not find one. no, just wrote this mail. fell free to open a bug and cc me, but dave already knows about it and the next kernel should have a workaround (remove the force hpet patch) until the upstream developer gets back from vocation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Fri Jul 6 20:43:58 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 6 Jul 2007 20:43:58 +0000 (UTC) Subject: Amarok 2.0 - has anybody tried it? References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> <1183725578.2227.10.camel@fedora> Message-ID: Rex Dieter math.unl.edu> writes: > Fedora is (still) missing a few needed deps... redland is one. 3.91.0 will also build without redland, you'll not get the Nepomuk stuff though. I don't know if Amarok 2 works without Nepomuk. Redland alone isn't enough, by the way, we also need Soprano, a Qt binding for Redland: http://soprano.sourceforge.net/ By the way, I've updated Thomas Vander Stichele's redland specfile to 1.0.5: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195647 The current version is 1.0.6, but that needs updates of raptor and rasqal too. Kevin Kofler From walters at redhat.com Fri Jul 6 20:55:47 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 06 Jul 2007 16:55:47 -0400 Subject: Parallel Booting In-Reply-To: References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> Message-ID: <1183755347.15795.5.camel@neutron.verbum.private> On Wed, 2007-07-04 at 02:32 +0000, Bojan Smojver wrote: > Isn't that the trick used on Windaz boxes as well? Possibly, but I think the biggest speedup by far is the disk caching/reorganization that both Windows and OS X do: http://www.kernelthread.com/mac/apme/optimizations/ At this rate though, we might all be using solid state drives before the kernel developers stop pointing at userspace as the problem and implement it for Linux. From tibbs at math.uh.edu Fri Jul 6 21:03:09 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jul 2007 16:03:09 -0500 Subject: Parallel Booting In-Reply-To: <1183755347.15795.5.camel@neutron.verbum.private> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> Message-ID: >>>>> "CW" == Colin Walters writes: CW> At this rate though, we might all be using solid state drives CW> before the kernel developers stop pointing at userspace as the CW> problem and implement it for Linux. Well, I have a machine running entirely from SSDs (two 32GB PATA Samsungs, /boot is mirrored and the rest is striped). It still doesn't boot all that quickly (stock F-7); if someone has tests for me to run I'll be happy to try them. (Actually I'm only getting 57MB/s reads from the striped volumes, so I think there's some tuning to do as that looks like the single-drive speed.) - J< From alan at redhat.com Fri Jul 6 21:31:38 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 6 Jul 2007 17:31:38 -0400 Subject: Parallel Booting In-Reply-To: <1183755347.15795.5.camel@neutron.verbum.private> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> Message-ID: <20070706213138.GA8245@devserv.devel.redhat.com> On Fri, Jul 06, 2007 at 04:55:47PM -0400, Colin Walters wrote: > Possibly, but I think the biggest speedup by far is the disk > caching/reorganization that both Windows and OS X do: > http://www.kernelthread.com/mac/apme/optimizations/ > > At this rate though, we might all be using solid state drives before the > kernel developers stop pointing at userspace as the problem and > implement it for Linux. We already lay stuff out very carefully and precache. Unfortunately most of the mess *is* userspace and some of the userspace authors are in complete denial. Just profile the number of file opens of different files done in a gnome startup and when you've finished laughing you can weep. Years ago I sent the gnome team a library that could load and linearlly map the entire theme in about 3 syscalls coming out nicely on disk. They never used it. That isn't to say the kernel is perfect and there is a ton of optimising work still going on, different scheduling algorithms and the like but most of the slowness is from user space - some from tools, some from combinations of tools and kernel (eg linker and paging patterns) and a lot of it from sheer stupid clueless design of applications and especially of GUI libraries. Alan From alan at redhat.com Fri Jul 6 21:33:26 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 6 Jul 2007 17:33:26 -0400 Subject: Parallel Booting In-Reply-To: References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> Message-ID: <20070706213326.GB8245@devserv.devel.redhat.com> On Fri, Jul 06, 2007 at 04:03:09PM -0500, Jason L Tibbitts III wrote: > Well, I have a machine running entirely from SSDs (two 32GB PATA > Samsungs, /boot is mirrored and the rest is striped). It still If you run the system entirely from a giant RAM disk (eg a gigabyte i-RAM) you'll rapidly discover that the disk isn't the biggest bottleneck > to run I'll be happy to try them. (Actually I'm only getting 57MB/s > reads from the striped volumes, so I think there's some tuning to do > as that looks like the single-drive speed.) Disk performance is usually quantified in ops/second. If you read linear data you'll get 57MB/sec. Go to true random access and performance is way way lower and hasn't improved much in the past ten years. Alan From darrellpf at gmail.com Fri Jul 6 21:45:39 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 6 Jul 2007 14:45:39 -0700 Subject: Parallel Booting In-Reply-To: <20070706213138.GA8245@devserv.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213138.GA8245@devserv.devel.redhat.com> Message-ID: On 7/6/07, Alan Cox wrote: > On Fri, Jul 06, 2007 at 04:55:47PM -0400, Colin Walters wrote: > > Possibly, but I think the biggest speedup by far is the disk > > caching/reorganization that both Windows and OS X do: > > http://www.kernelthread.com/mac/apme/optimizations/ > > > > At this rate though, we might all be using solid state drives before the > > kernel developers stop pointing at userspace as the problem and > > implement it for Linux. > > We already lay stuff out very carefully and precache. Unfortunately most > of the mess *is* userspace and some of the userspace authors are in > complete denial. Just profile the number of file opens of different files > done in a gnome startup and when you've finished laughing you can weep. > > Years ago I sent the gnome team a library that could load and linearlly > map the entire theme in about 3 syscalls coming out nicely on disk. They > never used it. > > That isn't to say the kernel is perfect and there is a ton of optimising > work still going on, different scheduling algorithms and the like but > most of the slowness is from user space - some from tools, some from > combinations of tools and kernel (eg linker and paging patterns) and a lot > of it from sheer stupid clueless design of applications and especially > of GUI libraries. > Speaking from my many days as a performance analyst, Pfeifer's first rule of performance says "The only good I/O is one you don't do". I'll second Alan here. The OS can mitigate the effects of I/O but userspace has the onus to be reasonable. darrell From walters at redhat.com Fri Jul 6 21:56:35 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 06 Jul 2007 17:56:35 -0400 Subject: Parallel Booting In-Reply-To: <20070706213138.GA8245@devserv.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213138.GA8245@devserv.devel.redhat.com> Message-ID: <1183758995.15795.21.camel@neutron.verbum.private> On Fri, 2007-07-06 at 17:31 -0400, Alan Cox wrote: > On Fri, Jul 06, 2007 at 04:55:47PM -0400, Colin Walters wrote: > > Possibly, but I think the biggest speedup by far is the disk > > caching/reorganization that both Windows and OS X do: > > http://www.kernelthread.com/mac/apme/optimizations/ > > > > At this rate though, we might all be using solid state drives before the > > kernel developers stop pointing at userspace as the problem and > > implement it for Linux. > > We already lay stuff out very carefully and precache. What precaching? Ok, I just googled and found a really good thread: http://kerneltrap.org/node/2157 It's unclear to me though how much of this is actually running now. The MacOS X page I linked to claimed that when they disabled the filesystem boot cache, it almost doubled boot time (in other words, the cache halved boot time). That says to me that either 1) Our precaching isn't as good as their implementation 2) MacOS X is fundamentally different I think it's more likely to be 1. I could be wrong though. > Years ago I sent the gnome team a library that could load and > linearlly > map the entire theme in about 3 syscalls coming out nicely on disk. > They > never used it. I believe the icon cache is currently mmap'd: /usr/share/icons/hicolor/icon-theme.cache Whether it's your actual code or not I don't know. > Unfortunately most > of the mess *is* userspace Right. That doesn't change the fact that some kernel work seems very likely to speed things up quite a bit. > and some of the userspace authors are in > complete denial. Just profile the number of file opens of different files > done in a gnome startup and when you've finished laughing you can weep. Work continues on improving userspace: http://primates.ximian.com/%7Efederico/news-2007-06.html#26 From david at lovesunix.net Fri Jul 6 22:12:19 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 07 Jul 2007 00:12:19 +0200 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 In-Reply-To: <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> References: <20070706155538.21202.861@extras64.linux.duke.edu> <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1183759939.3355.28.camel@dawkins> fre, 06 07 2007 kl. 18:09 +0200, skrev Michael Schwendt: > Plus these for i386/ppc/x86_64 -- I haven't examined what update breaks > these and the pkgs in Extras 6: > > source rpm: dbus-sharp-0.63-6.fc6.src.rpm > package: dbus-sharp-devel - 0.63-6.fc6.i386 from fedora-core-6-i386 > unresolved deps: > dbus-sharp = 0:0.63-6.fc6 > > source rpm: f-spot-0.2.1-1.fc6.src.rpm > package: f-spot - 0.2.1-1.fc6.i386 from fedora-core-6-i386 > unresolved deps: > mono(dbus-sharp) = 0:0.60.0.0 Upsie.. I'm correcting this. I'm currently importing the ndesk-dbus package which is a replacement for the obsolete dbus-sharp, sadly this problem was not caught in the review. Sorry, should go away soon. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From alan at redhat.com Fri Jul 6 22:17:08 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 6 Jul 2007 18:17:08 -0400 Subject: Parallel Booting In-Reply-To: <1183758995.15795.21.camel@neutron.verbum.private> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213138.GA8245@devserv.devel.redhat.com> <1183758995.15795.21.camel@neutron.verbum.private> Message-ID: <20070706221708.GA10220@devserv.devel.redhat.com> On Fri, Jul 06, 2007 at 05:56:35PM -0400, Colin Walters wrote: > Ok, I just googled and found a really good thread: > http://kerneltrap.org/node/2157 > > It's unclear to me though how much of this is actually running now. Quite a bit in terms of the disk layer. We readahead and writebehind, we preallocate data so that trickling writes don't end up smeared around the disk > 1) Our precaching isn't as good as their implementation > 2) MacOS X is fundamentally different > > I think it's more likely to be 1. I could be wrong though. Try running FC7 off a Gigabyte i-RAM (you'll need the approved RAM and a recent firmware for it to be reliable). You can then seperate the disk and non-disk load > I believe the icon cache is currently > mmap'd: /usr/share/icons/hicolor/icon-theme.cache > Whether it's your actual code or not I don't know. Hooray, and I hope mapped shared across all users. > > Unfortunately most > > of the mess *is* userspace > > Right. That doesn't change the fact that some kernel work seems very > likely to speed things up quite a bit. Yes. There are things we can do such as better predicting what I/O is coming and what data not to write yet (and when to defer writing for reading). There are things we can't do like make the old gconf one key per file implementation not suck. > > complete denial. Just profile the number of file opens of different files > > done in a gnome startup and when you've finished laughing you can weep. > > Work continues on improving userspace: > http://primates.ximian.com/%7Efederico/news-2007-06.html#26 Which is good. One area that probably could do with more work (although openoffice has forced many improvements ;)) is the linker and ELF loader side, both from the user space point of view for performance, and the kernel point of view to reduce page fault counts and between the two of them to load data in a sane order when doing demand paging (actually for large systems I question these days how useful demand paging is for most apps) From mschwendt.tmp0701.nospam at arcor.de Fri Jul 6 22:48:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 7 Jul 2007 00:48:15 +0200 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 In-Reply-To: <1183759939.3355.28.camel@dawkins> References: <20070706155538.21202.861@extras64.linux.duke.edu> <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> <1183759939.3355.28.camel@dawkins> Message-ID: <20070707004815.33d2c691.mschwendt.tmp0701.nospam@arcor.de> On Sat, 07 Jul 2007 00:12:19 +0200, David Nielsen wrote: > fre, 06 07 2007 kl. 18:09 +0200, skrev Michael Schwendt: > > Plus these for i386/ppc/x86_64 -- I haven't examined what update breaks > > these and the pkgs in Extras 6: > > > > source rpm: dbus-sharp-0.63-6.fc6.src.rpm > > package: dbus-sharp-devel - 0.63-6.fc6.i386 from fedora-core-6-i386 > > unresolved deps: > > dbus-sharp = 0:0.63-6.fc6 > > > > source rpm: f-spot-0.2.1-1.fc6.src.rpm > > package: f-spot - 0.2.1-1.fc6.i386 from fedora-core-6-i386 > > unresolved deps: > > mono(dbus-sharp) = 0:0.60.0.0 > > Upsie.. I'm correcting this. I'm currently importing the ndesk-dbus > package which is a replacement for the obsolete dbus-sharp, sadly this > problem was not caught in the review. > > Sorry, should go away soon. For Fedora 6 there is no problem yet, since the build is blocked in needsign for now. But your fix in CVS # Replaces old unmanaged DBus-sharp implementation Provides: dbus-sharp = 0.64 -Provides: mono(dbus-sharp) +Provides: mono(dbus-sharp) = 0.64 Obsoletes: dbus-sharp < 0.64 won't suffice, since nothing obsoletes dbus-sharp-devel yet, and f-spot in Core and banshee in Extras would still need a rebuild because they require a different EVR. From mschwendt.tmp0701.nospam at arcor.de Fri Jul 6 22:59:42 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 7 Jul 2007 00:59:42 +0200 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 In-Reply-To: <20070707004815.33d2c691.mschwendt.tmp0701.nospam@arcor.de> References: <20070706155538.21202.861@extras64.linux.duke.edu> <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> <1183759939.3355.28.camel@dawkins> <20070707004815.33d2c691.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070707005942.6a10543c.mschwendt.tmp0701.nospam@arcor.de> On Sat, 7 Jul 2007 00:48:15 +0200, Michael Schwendt wrote: > On Sat, 07 Jul 2007 00:12:19 +0200, David Nielsen wrote: > > > fre, 06 07 2007 kl. 18:09 +0200, skrev Michael Schwendt: > > > Plus these for i386/ppc/x86_64 -- I haven't examined what update breaks > > > these and the pkgs in Extras 6: > > > > > > source rpm: dbus-sharp-0.63-6.fc6.src.rpm > > > package: dbus-sharp-devel - 0.63-6.fc6.i386 from fedora-core-6-i386 > > > unresolved deps: > > > dbus-sharp = 0:0.63-6.fc6 > > > > > > source rpm: f-spot-0.2.1-1.fc6.src.rpm > > > package: f-spot - 0.2.1-1.fc6.i386 from fedora-core-6-i386 > > > unresolved deps: > > > mono(dbus-sharp) = 0:0.60.0.0 > > > > Upsie.. I'm correcting this. I'm currently importing the ndesk-dbus > > package which is a replacement for the obsolete dbus-sharp, sadly this > > problem was not caught in the review. > > > > Sorry, should go away soon. > > For Fedora 6 there is no problem yet, since the build is blocked in > needsign for now. But your fix in CVS > > # Replaces old unmanaged DBus-sharp implementation > Provides: dbus-sharp = 0.64 > -Provides: mono(dbus-sharp) > +Provides: mono(dbus-sharp) = 0.64 > Obsoletes: dbus-sharp < 0.64 > > won't suffice, since nothing obsoletes dbus-sharp-devel yet, and f-spot in > Core and banshee in Extras would still need a rebuild because they require > a different EVR. And since this is '6' not '7', Core cannot build against Extras, so, this thing needs more work. From walters at redhat.com Fri Jul 6 23:16:41 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 06 Jul 2007 19:16:41 -0400 Subject: Parallel Booting In-Reply-To: <20070706221708.GA10220@devserv.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213138.GA8245@devserv.devel.redhat.com> <1183758995.15795.21.camel@neutron.verbum.private> <20070706221708.GA10220@devserv.devel.redhat.com> Message-ID: <1183763802.15795.52.camel@neutron.verbum.private> On Fri, 2007-07-06 at 18:17 -0400, Alan Cox wrote: > On Fri, Jul 06, 2007 at 05:56:35PM -0400, Colin Walters wrote: > > Ok, I just googled and found a really good thread: > > http://kerneltrap.org/node/2157 > > > > It's unclear to me though how much of this is actually running now. > > Quite a bit in terms of the disk layer. We readahead and writebehind, As I understand the readahead, it is simply requesting further blocks inside a single file before the read() requests come in for them. The Hot File Clustering system on that page actually moves the files into a special area of the disk and and ensures they're contiguous (thus avoiding seeks, which plain readahead doesn't really solve). Both OS X and Windows include systems which watch the startup and continually optimize. Looking at Fedora, we have the "readahead" package, but as far as I can tell it's static in the sense that we ship some definitions with the package; it's never rerun. Has anyone run a current version of http://bootchart.org/ on Fedora? From david at lovesunix.net Fri Jul 6 23:33:03 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 07 Jul 2007 01:33:03 +0200 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 In-Reply-To: <20070707005942.6a10543c.mschwendt.tmp0701.nospam@arcor.de> References: <20070706155538.21202.861@extras64.linux.duke.edu> <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> <1183759939.3355.28.camel@dawkins> <20070707004815.33d2c691.mschwendt.tmp0701.nospam@arcor.de> <20070707005942.6a10543c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1183764783.3355.44.camel@dawkins> l?r, 07 07 2007 kl. 00:59 +0200, skrev Michael Schwendt: > On Sat, 7 Jul 2007 00:48:15 +0200, Michael Schwendt wrote: > > > On Sat, 07 Jul 2007 00:12:19 +0200, David Nielsen wrote: > > > > > fre, 06 07 2007 kl. 18:09 +0200, skrev Michael Schwendt: > > > > Plus these for i386/ppc/x86_64 -- I haven't examined what update breaks > > > > these and the pkgs in Extras 6: > > > > > > > > source rpm: dbus-sharp-0.63-6.fc6.src.rpm > > > > package: dbus-sharp-devel - 0.63-6.fc6.i386 from fedora-core-6-i386 > > > > unresolved deps: > > > > dbus-sharp = 0:0.63-6.fc6 > > > > > > > > source rpm: f-spot-0.2.1-1.fc6.src.rpm > > > > package: f-spot - 0.2.1-1.fc6.i386 from fedora-core-6-i386 > > > > unresolved deps: > > > > mono(dbus-sharp) = 0:0.60.0.0 > > > > > > Upsie.. I'm correcting this. I'm currently importing the ndesk-dbus > > > package which is a replacement for the obsolete dbus-sharp, sadly this > > > problem was not caught in the review. > > > > > > Sorry, should go away soon. > > > > For Fedora 6 there is no problem yet, since the build is blocked in > > needsign for now. But your fix in CVS > > > > # Replaces old unmanaged DBus-sharp implementation > > Provides: dbus-sharp = 0.64 > > -Provides: mono(dbus-sharp) > > +Provides: mono(dbus-sharp) = 0.64 > > Obsoletes: dbus-sharp < 0.64 > > > > won't suffice, since nothing obsoletes dbus-sharp-devel yet, and f-spot in > > Core and banshee in Extras would still need a rebuild because they require > > a different EVR. > > And since this is '6' not '7', Core cannot build against Extras, > so, this thing needs more work. What would you propose, sadly the timing is really bad as I'm leaving to go to a wedding and will likely be out of reach till after Monday. Clearly you are right with regards to FC-6, I'd love to replace it with ndesk-dbus across the board but that is not going to happen it seems. How about retracting for FC-6? For F-7 and above it's my understanding that most applications should not depend on the unmaintained dbus-sharp anyways as they generally rely on bundled copies of ndesk-dbus, banshee' dbus-sharp dep e.g. is totally unneeded because of this. So the sane solution seems to be pushing ndesk-dbus and ndesk-dbus-glib along with recompiles of banshee and friends. Again I apologize for the breakage. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From david at lovesunix.net Fri Jul 6 23:44:22 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 07 Jul 2007 01:44:22 +0200 Subject: Please remove ndesk-dbus Message-ID: <1183765462.3355.50.camel@dawkins> This has turned out to be a bit premature, it would likely serve us best to remove the package pending a bit more planning for it eventually replacing the unmaintained and rather problematic dbus-sharp. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From tibbs at math.uh.edu Sat Jul 7 01:26:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jul 2007 20:26:07 -0500 Subject: Parallel Booting In-Reply-To: <20070706213326.GB8245@devserv.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213326.GB8245@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: AC> Disk performance is usually quantified in ops/second. If you read AC> linear data you'll get 57MB/sec. Go to true random access and AC> performance is way way lower and hasn't improved much in the past AC> ten years. Well, these aren't disks (essentially zero seek time), so I'd expect random access read performance to be extremely fast. Random writes, on the other hand, should be terrible. I didn't have a lot of time to benchmark this before heading home so I just ran bonnie++ but I left off some options and the second line of results was entirely filled with plusses. But anyway, I was merely responding to the comment about SSDs rendering this discussion moot. Obviously disk access speed is a factor in startup time, but I don't think it's anything close to the dominating factor. - J< From sean.bruno at dsl-only.net Sat Jul 7 02:11:41 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri, 06 Jul 2007 19:11:41 -0700 Subject: dmraid failure/test cases [fc5-7] In-Reply-To: <468E6D5E.2010400@cox.net> References: <1183704185.3591.14.camel@home-desk> <468E6D5E.2010400@cox.net> Message-ID: <1183774301.2991.0.camel@home-desk> On Fri, 2007-07-06 at 12:27 -0400, Clyde E. Kunkel wrote: > Sean Bruno wrote: > > > > Third, and the most annoying, was that I couldn't install a plain s/w > > raid configuration with 2 drives connected. There was just no way to > > keep the system from assuming that I meant to use /dev/mapper/mapper0 > > even after I ensured that the superblock metadata was wiped out with a > > quick call to 'dmraid -Er /dev/sdX' to be sure that it was really gone. > > > Sean > > > > On my x86 box, I used the "nompath" parameter during install to prevent > /dev/mapper/mapper0 from being used and then could see all disks > properly, including pre-existing software raid arrays. Seems that even > if you are not using the bios raid capability of a SATA setup, anaconda > thinks you want to. Must be a way to check the bios to see if the setup > is for raid or not. That didn't work for me. I am still presented with the /dev/mapper/mapper0 device as my only install target. Sean From sean.bruno at dsl-only.net Sat Jul 7 02:13:45 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri, 06 Jul 2007 19:13:45 -0700 Subject: NEEDINFO changes into what exactly? Message-ID: <1183774425.2991.3.camel@home-desk> I've noticed that tickets when placed in the NEEDINFO status field need to be changed to 'something' else to get attention. What status should they be changed to when the item or information requested is posted to a ticket in response to a NEEDINFO request? Sean From roopesh.majeti at gmail.com Sat Jul 7 02:51:27 2007 From: roopesh.majeti at gmail.com (roopesh majeti) Date: Sat, 7 Jul 2007 08:21:27 +0530 Subject: NEEDINFO changes into what exactly? In-Reply-To: <1183774425.2991.3.camel@home-desk> References: <1183774425.2991.3.camel@home-desk> Message-ID: <599059470707061951t73bb9f5pdb8aa90209025321@mail.gmail.com> I have seen two systems about ticket tracking mechanism. In one system, once the required information is placed back in the ticket in response to NEEDINFO request, the status will be changed to ASSIGNED back to the person who is working on the ticket/requested the info. But in another system, i saw the status as INFOPROVIDED. Roopesh. On 7/7/07, Sean Bruno wrote: > > I've noticed that tickets when placed in the NEEDINFO status field need > to be changed to 'something' else to get attention. > > What status should they be changed to when the item or information > requested is posted to a ticket in response to a NEEDINFO request? > > Sean > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spng.yang at gmail.com Sat Jul 7 02:59:41 2007 From: spng.yang at gmail.com (Ken YANG) Date: Sat, 07 Jul 2007 10:59:41 +0800 Subject: about theme install Message-ID: <468F019D.1000501@gmail.com> i am running F8 Rawhide, there is a problem existing for a period. i want to install some theme i favorite, but the theme manager always complains "the file format is invalid", i try "tar.gz" and "tar.bz2", the error was still there. i remember "tar.gz" is ok, is there something i missing? From mclasen at redhat.com Sat Jul 7 03:07:52 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 06 Jul 2007 23:07:52 -0400 Subject: about theme install In-Reply-To: <468F019D.1000501@gmail.com> References: <468F019D.1000501@gmail.com> Message-ID: <1183777672.23009.0.camel@localhost.localdomain> On Sat, 2007-07-07 at 10:59 +0800, Ken YANG wrote: > i am running F8 Rawhide, there is a problem existing for a period. > > i want to install some theme i favorite, but the theme manager always > complains "the file format is invalid", i try "tar.gz" and "tar.bz2", > the error was still there. > > i remember "tar.gz" is ok, is there something i missing? > The theme capplet is being reworked currently, and some parts of the functionality have not been put together again yet. From frosario777 at gmail.com Sat Jul 7 03:18:11 2007 From: frosario777 at gmail.com (Freddie Rosario) Date: Fri, 6 Jul 2007 20:18:11 -0700 Subject: a legal way to include 3rd party repositories in fedora? In-Reply-To: <20070706143912.GA4474@jadzia.bu.edu> References: <64b14b300707040341h25e6e5f5gd1a5bd165574d9d0@mail.gmail.com> <20070704163753.GA4850@jadzia.bu.edu> <1183703576.18790.22.camel@lt21223.campus.dmacc.edu> <20070706143912.GA4474@jadzia.bu.edu> Message-ID: "I started this thread ONLY about software that would install 3rd party yum repositories. This way no patented software would ship with Fedora. How did you draw that conclusion? If I was not clear accept my apologies." There are rpm's that easily enable 3rd party repos provided by those same 3rd parties. Here is an example: http://rpm.livna.org/rlowiki/ That may be the solution you were looking for. If there is non FOSS software that you are looking to install, you can always do a Google search for terms such as " fc7 .rpm" That usually turns up what you are looking for and the third party repo hosting that package. Does that answer your question Valent? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgl at redhat.com Sat Jul 7 03:31:12 2007 From: tgl at redhat.com (Tom Lane) Date: Fri, 06 Jul 2007 23:31:12 -0400 Subject: NEEDINFO changes into what exactly? In-Reply-To: <1183774425.2991.3.camel@home-desk> References: <1183774425.2991.3.camel@home-desk> Message-ID: <13421.1183779072@sss.pgh.pa.us> Sean Bruno writes: > I've noticed that tickets when placed in the NEEDINFO status field need > to be changed to 'something' else to get attention. > What status should they be changed to when the item or information > requested is posted to a ticket in response to a NEEDINFO request? AFAIK, Red Hat's bugzilla automatically changes the state to ASSIGNED when the reporter replies to a NEEDINFO state. regards, tom lane From sean.bruno at dsl-only.net Sat Jul 7 05:08:38 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri, 06 Jul 2007 22:08:38 -0700 Subject: NEEDINFO changes into what exactly? In-Reply-To: <13421.1183779072@sss.pgh.pa.us> References: <1183774425.2991.3.camel@home-desk> <13421.1183779072@sss.pgh.pa.us> Message-ID: <1183784918.2991.8.camel@home-desk> On Fri, 2007-07-06 at 23:31 -0400, Tom Lane wrote: > Sean Bruno writes: > > I've noticed that tickets when placed in the NEEDINFO status field need > > to be changed to 'something' else to get attention. > > What status should they be changed to when the item or information > > requested is posted to a ticket in response to a NEEDINFO request? > > AFAIK, Red Hat's bugzilla automatically changes the state to ASSIGNED > when the reporter replies to a NEEDINFO state. > Well, that's not what has been happening when I respond to my tickets. I had responded to a NEEDINFO on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244332. It looks like the NEEDINFO changed ownership? Very confusing... I don't seem to be able to change the ticket status to anything that is meaningful to myself. What should it be I wonder? Sean From sean.bruno at dsl-only.net Sat Jul 7 07:14:28 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sat, 07 Jul 2007 00:14:28 -0700 Subject: Dependency Hell[F7-x86_64] Message-ID: <1183792468.3161.8.camel@home-desk> I was going to rip NetworkManager out of my machine just now, and yum went in and found some really nifty dependencies that made me sit up and take notice. I can't believe that pidgin and evolution really use NM libs. Is this for real? [sean at home-desk ~]$ sudo yum -y remove 'NetworkManager*' Loading "installonlyn" plugin Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package NetworkManager-glib.x86_64 1:0.6.5-7.fc7 set to be erased ---> Package NetworkManager.i386 1:0.6.5-7.fc7 set to be erased ---> Package NetworkManager-gnome.x86_64 1:0.6.5-7.fc7 set to be erased ---> Package NetworkManager-openvpn.x86_64 0:0.3.2-7.fc6 set to be erased ---> Package NetworkManager.x86_64 1:0.6.5-7.fc7 set to be erased ---> Package NetworkManager-glib.i386 1:0.6.5-7.fc7 set to be erased --> Processing Dependency: libnm_glib.so.0 for package: evolution --> Processing Dependency: libnm_glib.so.0()(64bit) for package: libpurple --> Processing Dependency: libnm_glib.so.0()(64bit) for package: pidgin --> Processing Dependency: libnm_glib.so.0()(64bit) for package: evolution --> Processing Dependency: libnm_glib.so.0()(64bit) for package: krb5-auth-dialog --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package NetworkManager-glib.x86_64 1:0.6.5-7.fc7 set to be erased ---> Package evolution.x86_64 0:2.10.2-3.fc7 set to be erased ---> Package evolution.i386 0:2.10.2-3.fc7 set to be erased ---> Package pidgin.x86_64 0:2.0.2-3.fc7 set to be erased ---> Package NetworkManager-glib.i386 1:0.6.5-7.fc7 set to be erased ---> Package krb5-auth-dialog.x86_64 0:0.7-2 set to be erased ---> Package libpurple.x86_64 0:2.0.2-3.fc7 set to be erased --> Processing Dependency: libpurple.so.0()(64bit) for package: nautilus-sendto --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package nautilus-sendto.x86_64 0:0.10-4.fc7 set to be erased ---> Package libpurple.x86_64 0:2.0.2-3.fc7 set to be erased Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: NetworkManager i386 1:0.6.5-7.fc7 installed 1.8 M NetworkManager x86_64 1:0.6.5-7.fc7 installed 1.8 M NetworkManager-glib x86_64 1:0.6.5-7.fc7 installed 24 k NetworkManager-glib i386 1:0.6.5-7.fc7 installed 18 k NetworkManager-gnome x86_64 1:0.6.5-7.fc7 installed 430 k NetworkManager-openvpn x86_64 0.3.2-7.fc6 installed 208 k Removing for dependencies: evolution x86_64 2.10.2-3.fc7 installed 59 M evolution i386 2.10.2-3.fc7 installed 59 M krb5-auth-dialog x86_64 0.7-2 installed 56 k libpurple x86_64 2.0.2-3.fc7 installed 17 M nautilus-sendto x86_64 0.10-4.fc7 installed 237 k pidgin x86_64 2.0.2-3.fc7 installed 16 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 12 Package(s) From sundaram at fedoraproject.org Sat Jul 7 07:37:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Jul 2007 13:07:01 +0530 Subject: Dependency Hell[F7-x86_64] In-Reply-To: <1183792468.3161.8.camel@home-desk> References: <1183792468.3161.8.camel@home-desk> Message-ID: <468F429D.4020107@fedoraproject.org> Sean Bruno wrote: > I was going to rip NetworkManager out of my machine just now, and yum > went in and found some really nifty dependencies that made me sit up and > take notice. I can't believe that pidgin and evolution really use NM > libs. Is this for real? > > [sean at home-desk ~]$ sudo yum -y remove 'NetworkManager*' Try # yum remove NetworkManager and avoid using -y if you don't know the dependency set. Pidgin and Evolution depends on NetworkManager-glib to check network connectivity and automatically go offline and things like that. Rahul From lightsolphoenix at gmail.com Sat Jul 7 07:47:13 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 7 Jul 2007 03:47:13 -0400 Subject: Dependency Hell[F7-x86_64] In-Reply-To: <1183792468.3161.8.camel@home-desk> References: <1183792468.3161.8.camel@home-desk> Message-ID: <200707070347.13967.lightsolphoenix@gmail.com> On Saturday, July 07, 2007 3:14 am Sean Bruno wrote: > I was going to rip NetworkManager out of my machine just now, and yum > went in and found some really nifty dependencies that made me sit up and > take notice. I can't believe that pidgin and evolution really use NM > libs. Is this for real? Yes, I've heard this one before. I don't fully understand why huge sections of Gnome rely on NetworkManager. Could it be the same reason Gnome is starting to have a HUGE dependency on Mono to function? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From sundaram at fedoraproject.org Sat Jul 7 07:51:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Jul 2007 13:21:28 +0530 Subject: Dependency Hell[F7-x86_64] In-Reply-To: <200707070347.13967.lightsolphoenix@gmail.com> References: <1183792468.3161.8.camel@home-desk> <200707070347.13967.lightsolphoenix@gmail.com> Message-ID: <468F4600.4030107@fedoraproject.org> Kelly wrote: > On Saturday, July 07, 2007 3:14 am Sean Bruno wrote: >> I was going to rip NetworkManager out of my machine just now, and yum >> went in and found some really nifty dependencies that made me sit up and >> take notice. I can't believe that pidgin and evolution really use NM >> libs. Is this for real? > > Yes, I've heard this one before. I don't fully understand why huge sections > of Gnome rely on NetworkManager. Could it be the same reason Gnome is > starting to have a HUGE dependency on Mono to function? I don't have mono or Network Manager (it's a desktop) installed and I can easily continue using GNOME. Can you be more specific on what you consider "HUGE dependency"? Rahul From sundaram at fedoraproject.org Sat Jul 7 07:56:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Jul 2007 13:26:32 +0530 Subject: Suggestion: Disk Druid changes In-Reply-To: <468E51C0.6020701@verizon.net> References: <468A556D.7030102@verizon.net> <468CA1F1.4060009@fedoraproject.org> <468CFD24.2070901@verizon.net> <468E51C0.6020701@verizon.net> Message-ID: <468F4730.1040800@fedoraproject.org> Gerry Reno wrote: = > > Not sure if this is how you file RFE but here it is: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247119 > Yes. This is fine. Rahul From spng.yang at gmail.com Sat Jul 7 09:28:39 2007 From: spng.yang at gmail.com (Ken YANG) Date: Sat, 07 Jul 2007 17:28:39 +0800 Subject: xchm crash in F8 rawhide Message-ID: <468F5CC7.7020204@gmail.com> hi all, this problem had existed for more than a month. when i click "font" button in xchm, the xchm will crash: -(:17:11:$)-> xchm ***MEMORY-WARNING***: [1693]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... *** glibc detected *** xchm: double free or corruption (out): 0x092e1bb0 *** ======= Backtrace: ========= /lib/libc.so.6[0x4cef3f41] /lib/libc.so.6(cfree+0x90)[0x4cef7580] /lib/libglib-2.0.so.0(g_free+0x31)[0x44f3d821] /usr/lib/libwx_gtk2u_core-2.8.so.0[0x4a0ef3fa] /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxButton10SetDefaultEv+0xdb)[0x4a0efa6b] xchm[0x8071f9e] xchm[0x806657f] /usr/lib/libwx_baseu-2.8.so.0(_ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_+0x35)[0x49cf7045] /usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent+0x8f)[0x49d9f78f] /usr/lib/libwx_baseu-2.8.so.0(_ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler+0x7d)[0x49d9f8dd] /usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0xc6)[0x49d9fa46] /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN12wxWindowBase9TryParentER7wxEvent+0x6b)[0x4a1ca04b] /usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0x7b)[0x49d9f9fb] /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN13wxToolBarBase11OnLeftClickEib+0x62)[0x4a1bf562] /usr/lib/libwx_gtk2u_core-2.8.so.0[0x4a12c760] /lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0x450a48c9] /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x45096eb3] /lib/libgobject-2.0.so.0[0x450a89ed] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x823)[0x450a9e53] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x450aa0f9] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x57)[0x497d7587] /usr/lib/libgtk-x11-2.0.so.0[0x497d96fe] /lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0x450a48c9] /lib/libgobject-2.0.so.0[0x450956a9] /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x45096eb3] /lib/libgobject-2.0.so.0[0x450a8e7a] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x823)[0x450a9e53] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x450aa0f9] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x57)[0x497d7617] /usr/lib/libgtk-x11-2.0.so.0[0x497d7692] /usr/lib/libgtk-x11-2.0.so.0[0x498cad72] /lib/libgobject-2.0.so.0[0x450956a9] /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x45096eb3] /lib/libgobject-2.0.so.0[0x450a9033] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x6d6)[0x450a9d06] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x450aa0f9] /usr/lib/libgtk-x11-2.0.so.0[0x49a03bb8] /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x1ae)[0x498c2c7e] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3c2)[0x498c4052] /usr/lib/libgdk-x11-2.0.so.0[0x496cf59a] /lib/libglib-2.0.so.0(g_main_context_dispatch+0x17c)[0x44f360ec] /lib/libglib-2.0.so.0[0x44f3952f] /lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0x44f398d9] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0x498c44e4] /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN11wxEventLoop3RunEv+0x5c)[0x4a09b3ec] /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN9wxAppBase8MainLoopEv+0x4c)[0x4a13859c] /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN9wxAppBase5OnRunEv+0x21)[0x4a137bb1] /usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x6a)[0x49d342fa] /usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPc+0x37)[0x49d343b7] xchm[0x8058f90] /lib/libc.so.6(__libc_start_main+0xe0)[0x4cea1f70] xchm(_ZN19wxTopLevelWindowGTK14OnInternalIdleEv+0xb5)[0x8058e61] ======= Memory map: ======== 00110000-0017d000 r-xp 00000000 08:07 3258046 /usr/lib/libgnomeprint-2-2.so.0.1.0 0017d000-0017f000 rwxp 0006c000 08:07 3258046 /usr/lib/libgnomeprint-2-2.so.0.1.0 0017f000-001c0000 r-xp 00000000 08:07 3258824 /usr/lib/libgnomeprintui-2-2.so.0.1.0 001c0000-001c2000 rwxp 00040000 08:07 3258824 /usr/lib/libgnomeprintui-2-2.so.0.1.0 001c2000-001ee000 r-xp 00000000 08:07 3257818 /usr/lib/libgnomecanvas-2.so.0.1400.0 001ee000-001ef000 rwxp 0002b000 08:07 3257818 /usr/lib/libgnomecanvas-2.so.0.1400.0 001ef000-001f6000 r-xp 00000000 08:07 3257861 /usr/lib/libpopt.so.0.0.0 001f6000-001f7000 rwxp 00006000 08:07 3257861 /usr/lib/libpopt.so.0.0.0 001f7000-00205000 r-xp 00000000 08:07 3259270 /usr/lib/libgnomecups-1.0.so.1.0.0 00205000-00206000 rwxp 0000e000 08:07 3259270 /usr/lib/libgnomecups-1.0.so.1.0.0 00206000-00239000 r-xp 00000000 08:07 3258220 /usr/lib/librsvg-2.so.2.16.1 00239000-0023a000 rwxp 00032000 08:07 3258220 /usr/lib/librsvg-2.so.2.16.1 0023a000-0029a000 r-xp 00000000 08:07 3257859 /usr/lib/libgnomevfs-2.so.0.1900.2 0029a000-0029d000 rwxp 0005f000 08:07 3257859 /usr/lib/libgnomevfs-2.so.0.1900.2 0029d000-002de000 r-xp 00000000 08:07 1855759 /lib/libssl.so.0.9.8b 002de000-002e2000 rwxp 00040000 08:07 1855759 /lib/libssl.so.0.9.8b 002ea000-0031f000 r-xp 00000000 08:07 3256140 /usr/lib/libcups.so.2 0031f000-00321000 rwxp 00034000 08:07 3256140 /usr/lib/libcups.so.2 00321000-0033a000 r-xp 00000000 08:07 1855758 /lib/libselinux.so.1 0033a000-0033c000 rwxp 00018000 08:07 1855758 /lib/libselinux.so.1 0033c000-00369000 r-xp 00000000 08:07 3257844 /usr/lib/libgssapi_krb5.so.2.2 00369000-0036a000 rwxp 0002d000 08:07 3257844 /usr/lib/libgssapi_krb5.so.2.2 0036a000-00372000 r-xp 00000000 08:07 3257831 /usr/lib/libkrb5support.so.0.1 00372000-00373000 rwxp 00007000 08:07 3257831 /usr/lib/libkrb5support.so.0.1 003cf000-003d0000 r-xp 00000000 08:07 3518832 /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so 003d0000-003d1000 rwxp 00001000 08:07 3518832 /usr/lib/gtk-2.0/2.10.0/loaders/svgAborted From buildsys at redhat.com Sat Jul 7 09:37:45 2007 From: buildsys at redhat.com (Build System) Date: Sat, 7 Jul 2007 05:37:45 -0400 Subject: rawhide report: 20070707 changes Message-ID: <200707070937.l679bjjC012602@porkchop.devel.redhat.com> New package jrexx Automaton based regluar expression API for Java New package ldapvi An interactive LDAP client New package libtextcat Text Categorization Library New package loki-lib Loki C++ Library of design patterns and idioms New package ocaml-lablgl LablGL is an OpenGL interface for Objective Caml New package prcsys Parallel rc with LSB dependency resolver Updated Packages: ConsoleKit-0.2.1-3.fc8 ---------------------- * Fri Jul 06 2007 Matthias Clasen - 0.2.1-3 - Add LSB header to init script (#246894) R-2.5.1-2.fc8 ------------- * Thu Jul 05 2007 Tom "spot" Callaway 2.5.1-2 - add rpm helper macros, script * Mon Jul 02 2007 Tom "spot" Callaway 2.5.1-1 - drop patch, upstream fixed - bump to 2.5.1 * Mon Apr 30 2007 Tom "spot" Callaway 2.5.0-2 - patch from Martyn Plummer fixes .pc files - add new BR: gcc-objc audacious-1.3.2-1.fc8 --------------------- compat-flex-2.5.4a-2.fc8 ------------------------ control-center-1:2.19.4-7.fc8 ----------------------------- * Wed Jun 27 2007 Matthias Clasen - 2.19.4-7 - Don't ship old unused cursor fonts * Wed Jun 27 2007 Matthias Clasen - 2.19.4-6 - Remove some questionable a11y autostart files, too - Add a filesystem subpackage dbus-1.1.1-3.fc8 ---------------- * Fri Jul 06 2007 Matthias Clasen - 1.1.1-3 - Add LSB header to init script (#246902) * Thu Jun 28 2007 Ray Strode - 1.1.1-2 - include session.d directory in package manifest * Thu Jun 28 2007 Ray Strode - 1.1.1-1 - Update to 1.1.1 eog-2.19.3-2.fc8 ---------------- * Fri Jul 06 2007 Matthias Clasen - 2.19.3-2 - Fix a directory ownership issue fcron-3.0.3-1.fc8 ----------------- * Thu Jul 05 2007 Alain Portal 3.0.3-1 - New upstream version - Update patch0 - Remove patch1 & patch2, no more needed fwbuilder-2.1.12-1.fc8 ---------------------- * Fri Jul 06 2007 Ralf Ertzinger 2.1.12-1.fc8 - Update to 2.1.12 gengetopt-2.20-1.fc8 -------------------- * Tue Jun 12 2007 Debarshi Ray - 2.20-1 - Version bump to 2.20. giggle-0.3-2.fc8 ---------------- * Fri Jul 06 2007 Jeremy Katz - 0.3-2 - fix to build against gtksourceview2 gnome-applets-1:2.18.0-12.fc8 ----------------------------- * Fri Jul 06 2007 Matthias Clasen - 1:2.18.0-12 - Fix a directory ownership issue gnome-power-manager-2.19.5-1.fc8 -------------------------------- * Fri Jul 06 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gnome-session-2.19.4-3.fc8 -------------------------- * Fri Jul 06 2007 Matthias Clasen - 2.19.4-3 - Move /usr/share/gnome/wm-properties to control-center-filesystem gnome-utils-1:2.18.1-2.fc8 -------------------------- * Fri Jul 06 2007 Matthias Clasen - 2.18.1-2 - Fix tempdir handling in gnome-screenshot (#246687) gnupg2-2.0.5-2.fc8 ------------------ * Fri Jul 06 2007 Rex Dieter 2.0.5-2 - gnupg-2.0.5 - gpg-agent not restarted after kde session crash/killed (#196327) - BR: libassuan-devel > 1.0.2, libksba-devel > 1.0.2 gthumb-2.10.5-2.fc8 ------------------- * Fri Jul 06 2007 Matthias Clasen - 2.10.5-2 - Fix a directory ownership issue gxine-0.5.11-5.fc8 ------------------ * Fri Jul 06 2007 Martin Sourada - 0.5.11-5 - Change the name displayed in menu to GXine Video Player hplip-2.7.6-2.fc8 ----------------- * Fri Jul 06 2007 Tim Waugh 2.7.6-2 - Main package requires python-reportlab for hp-sendfax (bug #189030). - Explicitly enable scanning. - Main package requires python-imaging for hp-scan (bug #247210). * Mon Jul 02 2007 Tim Waugh - Updated selinux-policy conflict for bug #246257. hunspell-sv-1.22-1.fc8 ---------------------- kernel-2.6.22-0.21.rc7.git5.fc8 ------------------------------- * Fri Jul 06 2007 Dave Jones - Update CFS to v19. * Fri Jul 06 2007 Jeremy Katz - Add minimal patch from markmc for ICH9 support in e1000 while the new driver works itself out upstream * Fri Jul 06 2007 Chuck Ebbert - add Intel ICH8M (Santa Rosa) PCI ID to ata_piix driver kover-3-1 --------- * Fri Jul 06 2007 Adrian Reber - 3-1 - updated to 3 - handle icons and mimetype - added libcdio-devel and libcddb-devel as BR * Thu Oct 05 2006 Christian Iseli 2.9.6-8 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 * Mon Sep 18 2006 Adrian Reber - 2.9.6-7 - rebuilt ktorrent-2.2-2.fc8 ------------------ * Fri Jul 06 2007 Roland Wolters 2.2-2 - spec-file fixes re-included libassuan-1.0.2-1.fc8 --------------------- * Fri Jul 06 2007 Rex Dieter - 1.0.2-1 - libassuan-1.0.2 - rename -static -> -devel libfwbuilder-2.1.12-1.fc8 ------------------------- * Fri Jul 06 2007 Ralf Ertzinger 2.1.12-1.fc8 - Update to 2.1.12 libksba-1.0.2-1.fc8 ------------------- * Fri Jul 06 2007 Rex Dieter 1.0.2-1 - libksba-1.0.2 mdadm-2.6.2-3.fc8 ----------------- * Fri Jul 06 2007 Doug Ledford - 2.6.2-3 - Oops, had to update the file leak patch, missed one thing - Minor tweak to return codes in init script and add LSB header - Resolves: bz244582, bz246980 monotone-0.35-4.fc8 ------------------- * Fri Jul 06 2007 Florian La Roche - 0.35-4 - add more requires nautilus-2.19.4-2.fc8 --------------------- * Fri Jul 06 2007 Matthias Clasen - 2.19.4-2 - Fix directory ownership issues * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 * Tue Jun 05 2007 Matthias Clasen - 2.19.3-1 - Update to 2.19.3 ndesk-dbus-0.5.2-9.fc8 ---------------------- * Sat Jul 07 2007 David Nielsen - 0.5.2-9 - And let's not be stupid and add the EVR for that provides * Fri Jul 06 2007 David Nielsen - 0.5.2-8 - Provide mono(dbus-sharp) nspr-4.6.7-2.fc8 ---------------- * Fri Jul 06 2007 Kai Engert - 4.6.7-2 - Update to 4.6.7 * Fri Jul 06 2007 Kai Engert - 4.6.6-2 - Update thread-cleanup patch to latest upstream version - Add upstream patch to support PR_STATIC_ASSERT orage-4.4.1-2.fc8 ----------------- * Wed Jul 04 2007 Kevin Fenzi - 4.4.1-2 - Fix category in desktop file (fixes #243601) * Wed Apr 11 2007 Kevin Fenzi - 4.4.1-1 - Update to 4.4.1 perl-Bit-Vector-6.4-4.fc8 ------------------------- * Fri Jul 06 2007 Robin Norwood 6.4-4 - Resolves: rhbz#247212 - Fix broken perl_provides script - it was removing both the versioned and unversioned Provides: perl(Bit::Vector) policycoreutils-2.0.22-4.fc8 ---------------------------- * Sat Jul 07 2007 Dan Walsh 2.0.22-4 - Fix checking for conflicting directory specification in genhomedircon ppl-0.9-13.fc8 -------------- * Fri Jul 06 2007 Roberto Bagnara 0.9-13 - Bug 246815 had been fixed: YAP support enabled again. pybluez-0.9.2-1.fc7 ------------------- * Wed Jun 20 2007 - Will Woods - 0.9.2-1 - Update to 0.9.2, which should fix bug #240536 repoview-0.5.2-2.fc7 -------------------- * Fri Jun 29 2007 Konstantin Ryabitsev - 0.5.2-2 - Backport patches from trunk to fix repoview on F7 (#232590) rpy-0.4.6-17.fc8 ---------------- * Fri Jul 06 2007 Tom "spot" Callaway - 0.4.6-17 - Rebuild to link with R 2.5.1 selinux-policy-3.0.2-3.fc8 -------------------------- * Fri Jul 06 2007 Dan Walsh 3.0.2-3 - Fix root login to include system_r * Fri Jul 06 2007 Dan Walsh 3.0.2-2 - Allow prelink to read kernel sysctls ushare-1.0-1.fc8 ---------------- * Fri Jul 06 2007 Eric Tanguy - 1.0-1 - Update to 1.0 * Tue Jun 26 2007 Eric Tanguy - 0.9.10-4 - Rebuild Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DocType) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::EncodingDetect) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::XMLDecl) perl-XML-SAX - 0.16-1.fc8.noarch requires perl(XML::SAX::PurePerl::DTDDecls) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 From david at lovesunix.net Sat Jul 7 09:48:16 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 07 Jul 2007 11:48:16 +0200 Subject: xchm crash in F8 rawhide In-Reply-To: <468F5CC7.7020204@gmail.com> References: <468F5CC7.7020204@gmail.com> Message-ID: <1183801696.3270.14.camel@dawkins> l?r, 07 07 2007 kl. 17:28 +0800, skrev Ken YANG: > > hi all, > > > this problem had existed for more than a month. > > when i click "font" button in xchm, the xchm will crash: > > -(:17:11:$)-> xchm > > ***MEMORY-WARNING***: [1693]: GSlice: g_thread_init() must be called > before all other GLib functions; memory corruption due to late > invocation of g_thread_init() has been detected; this program is likely > to crash, leak or unexpectedly abort soon... > *** glibc detected *** xchm: double free or corruption (out): 0x092e1bb0 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x4cef3f41] > /lib/libc.so.6(cfree+0x90)[0x4cef7580] > /lib/libglib-2.0.so.0(g_free+0x31)[0x44f3d821] > /usr/lib/libwx_gtk2u_core-2.8.so.0[0x4a0ef3fa] > /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxButton10SetDefaultEv+0xdb)[0x4a0efa6b] > xchm[0x8071f9e] > xchm[0x806657f] > /usr/lib/libwx_baseu-2.8.so.0(_ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_+0x35)[0x49cf7045] > /usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent+0x8f)[0x49d9f78f] > /usr/lib/libwx_baseu-2.8.so.0(_ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler+0x7d)[0x49d9f8dd] > /usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0xc6)[0x49d9fa46] > /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN12wxWindowBase9TryParentER7wxEvent+0x6b)[0x4a1ca04b] > /usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0x7b)[0x49d9f9fb] > /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN13wxToolBarBase11OnLeftClickEib+0x62)[0x4a1bf562] > /usr/lib/libwx_gtk2u_core-2.8.so.0[0x4a12c760] > /lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0x450a48c9] > /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x45096eb3] > /lib/libgobject-2.0.so.0[0x450a89ed] > /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x823)[0x450a9e53] > /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x450aa0f9] > /usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x57)[0x497d7587] > /usr/lib/libgtk-x11-2.0.so.0[0x497d96fe] > /lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0x450a48c9] > /lib/libgobject-2.0.so.0[0x450956a9] > /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x45096eb3] > /lib/libgobject-2.0.so.0[0x450a8e7a] > /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x823)[0x450a9e53] > /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x450aa0f9] > /usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x57)[0x497d7617] > /usr/lib/libgtk-x11-2.0.so.0[0x497d7692] > /usr/lib/libgtk-x11-2.0.so.0[0x498cad72] > /lib/libgobject-2.0.so.0[0x450956a9] > /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x45096eb3] > /lib/libgobject-2.0.so.0[0x450a9033] > /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x6d6)[0x450a9d06] > /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x450aa0f9] > /usr/lib/libgtk-x11-2.0.so.0[0x49a03bb8] > /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x1ae)[0x498c2c7e] > /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x3c2)[0x498c4052] > /usr/lib/libgdk-x11-2.0.so.0[0x496cf59a] > /lib/libglib-2.0.so.0(g_main_context_dispatch+0x17c)[0x44f360ec] > /lib/libglib-2.0.so.0[0x44f3952f] > /lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0x44f398d9] > /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0x498c44e4] > /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN11wxEventLoop3RunEv+0x5c)[0x4a09b3ec] > /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN9wxAppBase8MainLoopEv+0x4c)[0x4a13859c] > /usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN9wxAppBase5OnRunEv+0x21)[0x4a137bb1] > /usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x6a)[0x49d342fa] > /usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPc+0x37)[0x49d343b7] > xchm[0x8058f90] > /lib/libc.so.6(__libc_start_main+0xe0)[0x4cea1f70] > xchm(_ZN19wxTopLevelWindowGTK14OnInternalIdleEv+0xb5)[0x8058e61] > ======= Memory map: ======== > 00110000-0017d000 r-xp 00000000 08:07 3258046 > /usr/lib/libgnomeprint-2-2.so.0.1.0 > 0017d000-0017f000 rwxp 0006c000 08:07 3258046 > /usr/lib/libgnomeprint-2-2.so.0.1.0 > 0017f000-001c0000 r-xp 00000000 08:07 3258824 > /usr/lib/libgnomeprintui-2-2.so.0.1.0 > 001c0000-001c2000 rwxp 00040000 08:07 3258824 > /usr/lib/libgnomeprintui-2-2.so.0.1.0 > 001c2000-001ee000 r-xp 00000000 08:07 3257818 > /usr/lib/libgnomecanvas-2.so.0.1400.0 > 001ee000-001ef000 rwxp 0002b000 08:07 3257818 > /usr/lib/libgnomecanvas-2.so.0.1400.0 > 001ef000-001f6000 r-xp 00000000 08:07 3257861 /usr/lib/libpopt.so.0.0.0 > 001f6000-001f7000 rwxp 00006000 08:07 3257861 /usr/lib/libpopt.so.0.0.0 > 001f7000-00205000 r-xp 00000000 08:07 3259270 > /usr/lib/libgnomecups-1.0.so.1.0.0 > 00205000-00206000 rwxp 0000e000 08:07 3259270 > /usr/lib/libgnomecups-1.0.so.1.0.0 > 00206000-00239000 r-xp 00000000 08:07 3258220 > /usr/lib/librsvg-2.so.2.16.1 > 00239000-0023a000 rwxp 00032000 08:07 3258220 > /usr/lib/librsvg-2.so.2.16.1 > 0023a000-0029a000 r-xp 00000000 08:07 3257859 > /usr/lib/libgnomevfs-2.so.0.1900.2 > 0029a000-0029d000 rwxp 0005f000 08:07 3257859 > /usr/lib/libgnomevfs-2.so.0.1900.2 > 0029d000-002de000 r-xp 00000000 08:07 1855759 /lib/libssl.so.0.9.8b > 002de000-002e2000 rwxp 00040000 08:07 1855759 /lib/libssl.so.0.9.8b > 002ea000-0031f000 r-xp 00000000 08:07 3256140 /usr/lib/libcups.so.2 > 0031f000-00321000 rwxp 00034000 08:07 3256140 /usr/lib/libcups.so.2 > 00321000-0033a000 r-xp 00000000 08:07 1855758 /lib/libselinux.so.1 > 0033a000-0033c000 rwxp 00018000 08:07 1855758 /lib/libselinux.so.1 > 0033c000-00369000 r-xp 00000000 08:07 3257844 > /usr/lib/libgssapi_krb5.so.2.2 > 00369000-0036a000 rwxp 0002d000 08:07 3257844 > /usr/lib/libgssapi_krb5.so.2.2 > 0036a000-00372000 r-xp 00000000 08:07 3257831 > /usr/lib/libkrb5support.so.0.1 > 00372000-00373000 rwxp 00007000 08:07 3257831 > /usr/lib/libkrb5support.so.0.1 > 003cf000-003d0000 r-xp 00000000 08:07 3518832 > /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so > 003d0000-003d1000 rwxp 00001000 08:07 3518832 > /usr/lib/gtk-2.0/2.10.0/loaders/svgAborted Can you please file a bug on this so it doesn't get lost. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From peter at thecodergeek.com Sat Jul 7 09:54:14 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 07 Jul 2007 02:54:14 -0700 Subject: xchm crash in F8 rawhide In-Reply-To: <1183801696.3270.14.camel@dawkins> References: <468F5CC7.7020204@gmail.com> <1183801696.3270.14.camel@dawkins> Message-ID: <1183802054.10483.4.camel@tuxhugs> On Sat, 2007-07-07 at 11:48 +0200, David Nielsen wrote: > Can you please file a bug on this so it doesn't get lost. Ken, If/when you do, please file it against wxGTK and add me (this email address) as a CC on the bug. I've seen similar backtraces from other wxGTK-using applications (including code::blocks and Audacity). Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jul 7 10:01:42 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 07 Jul 2007 19:01:42 +0900 Subject: xchm crash in F8 rawhide In-Reply-To: <1183802054.10483.4.camel@tuxhugs> References: <468F5CC7.7020204@gmail.com> <1183801696.3270.14.camel@dawkins> <1183802054.10483.4.camel@tuxhugs> Message-ID: <468F6486.6080606@ioa.s.u-tokyo.ac.jp> Peter Gordon wrote, at 07/07/2007 06:54 PM +9:00: > On Sat, 2007-07-07 at 11:48 +0200, David Nielsen wrote: >> Can you please file a bug on this so it doesn't get lost. > > Ken, > > If/when you do, please file it against wxGTK and add me (this email > address) as a CC on the bug. I've seen similar backtraces from other > wxGTK-using applications (including code::blocks and Audacity). > > Thanks. > It seems that this is similar with: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245485#c10 Mamoru From sundaram at fedoraproject.org Sat Jul 7 10:39:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 07 Jul 2007 16:09:32 +0530 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <20070705150855.66c324ad@ludwig-alpha.unil.ch> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> Message-ID: <468F6D64.9010209@fedoraproject.org> Christian Iseli wrote: > Hi folks, > > This week's update. Changes from last week: > - 50 more packages in owners.list > - 20 less packages in NEW review requests > - 96 more open BZ bug tickets > Rum is listed in the potential problems section but the review request was closed because upstream lost interest in maintaining it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205504 > sundaram at redhat dot com olpc-utils This package has not been pushed into devel after talking to J5. Not sure what the plan is. Rahul From drago01 at gmail.com Sat Jul 7 10:43:20 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 07 Jul 2007 12:43:20 +0200 Subject: Parallel Booting In-Reply-To: <1183763802.15795.52.camel@neutron.verbum.private> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213138.GA8245@devserv.devel.redhat.com> <1183758995.15795.21.camel@neutron.verbum.private> <20070706221708.GA10220@devserv.devel.redhat.com> <1183763802.15795.52.camel@neutron.verbum.private> Message-ID: <468F6E48.9060400@gmail.com> Colin Walters wrote: > On Fri, 2007-07-06 at 18:17 -0400, Alan Cox wrote: > >> On Fri, Jul 06, 2007 at 05:56:35PM -0400, Colin Walters wrote: >> >>> Ok, I just googled and found a really good thread: >>> http://kerneltrap.org/node/2157 >>> >>> It's unclear to me though how much of this is actually running now. >>> >> Quite a bit in terms of the disk layer. We readahead and writebehind, >> > > As I understand the readahead, it is simply requesting further blocks > inside a single file before the read() requests come in for them. > > The Hot File Clustering system on that page actually moves the files > into a special area of the disk and and ensures they're contiguous (thus > avoiding seeks, which plain readahead doesn't really solve). > > Both OS X and Windows include systems which watch the startup and > continually optimize. Looking at Fedora, we have the "readahead" > package, but as far as I can tell it's static in the sense that we ship > some definitions with the package; it's never rerun. > > you can boot with "init=/sbin/readahead-collector" but for me this ended up in readahead to many files... which caused a high diskload during boot which results into a longer boot time. From darrellpf at gmail.com Sat Jul 7 13:45:09 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Sat, 7 Jul 2007 06:45:09 -0700 Subject: rawhide report: 20070707 changes In-Reply-To: <200707070937.l679bjjC012602@porkchop.devel.redhat.com> References: <200707070937.l679bjjC012602@porkchop.devel.redhat.com> Message-ID: > hplip-2.7.6-2.fc8 > ----------------- > * Fri Jul 06 2007 Tim Waugh 2.7.6-2 > - Main package requires python-reportlab for hp-sendfax (bug #189030). > - Explicitly enable scanning. > - Main package requires python-imaging for hp-scan (bug #247210). > > * Mon Jul 02 2007 Tim Waugh > - Updated selinux-policy conflict for bug #246257. > error: %pre(hplip-2.7.6-2.fc8.i386) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping hplip-2.7.6-2.fc8 Filed as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247349 From mschwendt.tmp0701.nospam at arcor.de Sat Jul 7 14:12:58 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 7 Jul 2007 16:12:58 +0200 Subject: Summary - Broken dependencies in Fedora 6 - 2007-07-06 In-Reply-To: <1183764783.3355.44.camel@dawkins> References: <20070706155538.21202.861@extras64.linux.duke.edu> <20070706180940.5d59a26d.mschwendt.tmp0701.nospam@arcor.de> <1183759939.3355.28.camel@dawkins> <20070707004815.33d2c691.mschwendt.tmp0701.nospam@arcor.de> <20070707005942.6a10543c.mschwendt.tmp0701.nospam@arcor.de> <1183764783.3355.44.camel@dawkins> Message-ID: <20070707161258.f7471125.mschwendt.tmp0701.nospam@arcor.de> On Sat, 07 Jul 2007 01:33:03 +0200, David Nielsen wrote: > > > For Fedora 6 there is no problem yet, since the build is blocked in > > > needsign for now. But your fix in CVS > > > > > > # Replaces old unmanaged DBus-sharp implementation > > > Provides: dbus-sharp = 0.64 > > > -Provides: mono(dbus-sharp) > > > +Provides: mono(dbus-sharp) = 0.64 > > > Obsoletes: dbus-sharp < 0.64 > > > > > > won't suffice, since nothing obsoletes dbus-sharp-devel yet, and f-spot in > > > Core and banshee in Extras would still need a rebuild because they require > > > a different EVR. > > > > And since this is '6' not '7', Core cannot build against Extras, > > so, this thing needs more work. > > What would you propose, sadly the timing is really bad as I'm leaving to > go to a wedding and will likely be out of reach till after Monday. What I propose is: focus on F7 and/or F8 and treat F6 as a stable distribution. If ndesk-dbus* serves as a bug-fix upgrade for F6, prepare the full set of updates and talk to authoritative Fedora people, i.e. FESCo, on how to proceed. Because a package in Extras would obsolete Core (a MUSTNOT), and a package in Core that is broken in the process would need a fix or a rebuild (the latter is a CANTFIX unless f-spot were moved into Extras). > Clearly you are right with regards to FC-6, I'd love to replace it with > ndesk-dbus across the board but that is not going to happen it seems. > How about retracting for FC-6? ndesk-dbus for F6 has not been released from needsign yet. ;) From Christian.Iseli at licr.org Sat Jul 7 14:58:43 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sat, 7 Jul 2007 16:58:43 +0200 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <468F6D64.9010209@fedoraproject.org> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <468F6D64.9010209@fedoraproject.org> Message-ID: <20070707165843.1b7346cd@ludwig-alpha.unil.ch> On Sat, 07 Jul 2007 16:09:32 +0530, Rahul Sundaram wrote: > Rum is listed in the potential problems section but the review request > was closed because upstream lost interest in maintaining it. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205504 I see 3 options (given the package has been approved already): 1. find a maintainer willing to own it (maybe the person who reviewed) 2. mark it dead in CVS 3. drop the FE-ACCEPT blocker (and lose the reviewing work...) Any takers ? > > sundaram at redhat dot com olpc-utils > > This package has not been pushed into devel after talking to J5. Not > sure what the plan is. Yea, I'm still unsure how to handle EPEL and OLPC only packages. Should they be listed in owners.list ? pro: they are part of the Fedora project con: they do not appear in the Fedora package collection itself Thoughts ? Christian From d.jacobfeuerborn at conversis.de Sat Jul 7 16:19:10 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 07 Jul 2007 18:19:10 +0200 Subject: Amarok 2.0 - has anybody tried it? In-Reply-To: References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> <1183725578.2227.10.camel@fedora> Message-ID: <468FBCFE.3030104@conversis.de> Rex Dieter wrote: > Valent Turkovic wrote: > >> On Fri, 2007-07-06 at 13:16 +0200, dragoran wrote: >>> "Amarok 2.0 will require KDE4. Tarballs of KDE4 are periodically >>> released, but the plan is to work off of KDE trunk. It is not known >>> whether alpha1 works with Amarok 2.0 or not." >> Yup, KDE4 packages are needed, but not all. I downloaded source for KDE4 >> and started compiling using this guide: >> http://techbase.kde.org/Getting_Started/Build/Unstable_Version >> >> but I didn't succeed ;( > > Fedora is (still) missing a few needed deps... redland is one. > > quick-n-dirty srpms are available from: > http://kdeforge.unl.edu/apt/kde-redhat/all/unstable/SRPMS/ > I've tried building kdelibs from that directory but I get a ton of these errors: ERROR 0002: file '/opt/kde4/bin/ksvgtopng' contains an invalid rpath '/usr/local/lib' in [/opt/kde4/lib:/usr/local/lib] Is there any option I need to set in order to get past that? The compile itself looks fine. Regards, Dennis From rdieter at math.unl.edu Sat Jul 7 18:08:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 07 Jul 2007 13:08:29 -0500 Subject: Amarok 2.0 - has anybody tried it? References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> <1183725578.2227.10.camel@fedora> <468FBCFE.3030104@conversis.de> Message-ID: Dennis Jacobfeuerborn wrote: > Rex Dieter wrote: >> quick-n-dirty srpms are available from: >> http://kdeforge.unl.edu/apt/kde-redhat/all/unstable/SRPMS/ > I've tried building kdelibs from that directory but I get a ton of these > errors: WORKSFORME (built in mock), though this isn't too surprising. pre-built rpms are available in the kde-redhat/repo (using yum) or grab 'em yourself: http://kdeforge.unl.edu/apt/kde-redhat/fedora/7/i386/unstable/RPMS/ -- Rex From lightsolphoenix at gmail.com Sat Jul 7 18:13:59 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 7 Jul 2007 14:13:59 -0400 Subject: Dependency Hell[F7-x86_64] In-Reply-To: <468F4600.4030107@fedoraproject.org> References: <1183792468.3161.8.camel@home-desk> <200707070347.13967.lightsolphoenix@gmail.com> <468F4600.4030107@fedoraproject.org> Message-ID: <200707071414.00007.lightsolphoenix@gmail.com> On Saturday, July 07, 2007 3:51 am Rahul Sundaram wrote: > I don't have mono or Network Manager (it's a desktop) installed and I > can easily continue using GNOME. Can you be more specific on what you > consider "HUGE dependency"? > > Rahul I dunno. My head hurts really badly right now; maybe I have the dependency chain upside down... -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From debarshi.ray at gmail.com Sat Jul 7 19:37:43 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 8 Jul 2007 01:07:43 +0530 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <20070705150855.66c324ad@ludwig-alpha.unil.ch> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> Message-ID: <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> > Owners file stats: > - 4687 packages > - 7688 binary rpms in devel > - 108 orphans > - 74 packages not available in devel or release > ... > ... > andreas at bawue dot net ddrescue > - 6 packages which have not yet been FE-ACCEPT'd... > ... > ... > ddrescue splinux25 at gmail.com Why two 'ddrescue's out there? There is a package called 'dd_rescue' already in Rawhide: Name : dd_rescue Arch : i386 Version: 1.12 Release: 6.fc7 Size : 37 k Repo : development Summary: Fault tolerant "dd" utility for rescuing data from bad media Description: ddrescue is a utility similar to the system utility "dd" which copies data from a file or block device to another. ddrescue does however not abort on errors in the input file. This makes it suitable for rescuing data from media with errors, e.g. a disk with bad sectors. This package includes dd_rhelp, a wrapper script facilating data recovery. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Sat Jul 7 20:00:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Jul 2007 01:30:46 +0530 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> Message-ID: <468FF0EE.8000807@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> Owners file stats: >> - 4687 packages >> - 7688 binary rpms in devel >> - 108 orphans >> - 74 packages not available in devel or release >> ... >> ... >> andreas at bawue dot net ddrescue > >> - 6 packages which have not yet been FE-ACCEPT'd... >> ... >> ... >> ddrescue splinux25 at gmail.com > > Why two 'ddrescue's out there? > > There is a package called 'dd_rescue' already in Rawhide: dd_rescue is not ddrescue. Look that up. Rahul From jamatos at fc.up.pt Sat Jul 7 20:15:26 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 7 Jul 2007 21:15:26 +0100 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <468FF0EE.8000807@fedoraproject.org> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> <468FF0EE.8000807@fedoraproject.org> Message-ID: <200707072115.26625.jamatos@fc.up.pt> On Saturday 07 July 2007 21:00:46 Rahul Sundaram wrote: > dd_rescue is not ddrescue. Look that up. > > Rahul And this same issue was discussed in this list (or fedora-extras) several times before. (I remember more or less 5 times). -- Jos? Ab?lio From sundaram at fedoraproject.org Sat Jul 7 20:43:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Jul 2007 02:13:10 +0530 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <1183705727.23127.0.camel@fedora> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> <468B74E5.10207@nicubunu.ro> <20070704175050.GA476@bludgeon.org> <1183705727.23127.0.camel@fedora> Message-ID: <468FFADE.9090607@fedoraproject.org> Valent Turkovic wrote: > On Wed, 2007-07-04 at 10:50 -0700, Ray Van Dolson wrote: >> Perhaps the htmlview icon could somehow be "symlinked" to the icon for >> whichever browser is default. So the user sees the Firefox icon .. or >> Mozilla, or whichever they have configured as default. >> >> Ray >> > > Yes, a simple thing to do. Please consider this proposal. You got to file enhancements in bugzilla.redhat.com. A long mail with multiple points is likely to be lost with no action taken even you post to many lists and forums unnecessarily. Rahul From mclasen at redhat.com Sat Jul 7 20:37:47 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 07 Jul 2007 16:37:47 -0400 Subject: Here are some of my ideas for Fedora 8 and Fedora 9 In-Reply-To: <468FFADE.9090607@fedoraproject.org> References: <64b14b300707021423p7b11adc4u9d628a2bf44671ea@mail.gmail.com> <364d303b0707030805p61720899mb51cdfc7ae484aec@mail.gmail.com> <1183536734.5484.44.camel@fedora> <20070704085212.GA11680@orient.maison.lan> <1183544027.5484.67.camel@fedora> <468B74E5.10207@nicubunu.ro> <20070704175050.GA476@bludgeon.org> <1183705727.23127.0.camel@fedora> <468FFADE.9090607@fedoraproject.org> Message-ID: <1183840667.3289.5.camel@localhost.localdomain> On Sun, 2007-07-08 at 02:13 +0530, Rahul Sundaram wrote: > Valent Turkovic wrote: > > On Wed, 2007-07-04 at 10:50 -0700, Ray Van Dolson wrote: > >> Perhaps the htmlview icon could somehow be "symlinked" to the icon for > >> whichever browser is default. So the user sees the Firefox icon .. or > >> Mozilla, or whichever they have configured as default. > >> > >> Ray > >> > > > > Yes, a simple thing to do. Please consider this proposal. > > You got to file enhancements in bugzilla.redhat.com. A long mail with > multiple points is likely to be lost with no action taken even you post > to many lists and forums unnecessarily. And when you work on the patch to implement this you'll likely find that it is not quite as simple as you think. From d.jacobfeuerborn at conversis.de Sat Jul 7 20:45:53 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 07 Jul 2007 22:45:53 +0200 Subject: Amarok 2.0 - has anybody tried it? In-Reply-To: References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> <1183725578.2227.10.camel@fedora> <468FBCFE.3030104@conversis.de> Message-ID: <468FFB81.9070502@conversis.de> Rex Dieter wrote: > Dennis Jacobfeuerborn wrote: > >> Rex Dieter wrote: > >>> quick-n-dirty srpms are available from: >>> http://kdeforge.unl.edu/apt/kde-redhat/all/unstable/SRPMS/ > >> I've tried building kdelibs from that directory but I get a ton of these >> errors: > > WORKSFORME (built in mock), though this isn't too surprising. > > pre-built rpms are available in the kde-redhat/repo (using yum) or grab 'em > yourself: > http://kdeforge.unl.edu/apt/kde-redhat/fedora/7/i386/unstable/RPMS/ Thanks, I will try these packages instead. Regards, Dennis From kevin.kofler at chello.at Sat Jul 7 20:53:40 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 7 Jul 2007 20:53:40 +0000 (UTC) Subject: Amarok 2.0 - has anybody tried it? References: <1183720118.31708.12.camel@fedora> <468E2480.9020001@gmail.com> <1183725578.2227.10.camel@fedora> <468FBCFE.3030104@conversis.de> Message-ID: Dennis Jacobfeuerborn conversis.de> writes: > ERROR 0002: file '/opt/kde4/bin/ksvgtopng' contains an invalid rpath > '/usr/local/lib' in [/opt/kde4/lib:/usr/local/lib] You need to disable the RPATH checks for now. There's 2 problems there: * rpaths in cmake/KDE are all or nothing, if they put in /opt/kde4 ones, they also put in standard ones, * the rpath checks don't accept rpaths to paths outside of /usr, which IMHO is just broken. This should not be a problem anymore when we can install KDE 4 to /usr (in Fedora 8). Kevin Kofler From jaroslav at aster.pl Sat Jul 7 21:39:26 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Sat, 7 Jul 2007 23:39:26 +0200 Subject: emacs-22.x - comments highlighting is "wrong" Message-ID: <200707072339.37806.jaroslav@aster.pl> Hi, I've recently upgraded FC6 -> F7 and I've noticed that in emacs comments are being highlighted very different than in 21.x versions. I've checked it in {C,Python,Shell}-modes. In 21.x if you put a comment mark at the beginning of the line or comment a region with "/*" and "*/", _all_ the text that is commented changes its color to "comment_font_color" (please forgive this arbitrary and non-technical term). In 22.x _only_ the comment characters color is "comment_font_color" and the whole commented text is "plain_text_font_color" Is it a bug or a feature? ;) Is there a way to change this behaviour? In my opinion it's far worse solution - definitely less readable. thanks and regards, -- Jaroslaw Gorny -------------- next part -------------- A non-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 Sat Jul 7 22:43:28 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 7 Jul 2007 18:43:28 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-07 Message-ID: <20070707224328.EDA32152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 4 clamav-0.88.7-3.fc6 NEW loki-lib-0.1.6-4.fc6 : Loki C++ Library of design patterns and idioms R-2.5.1-2.fc6 rpy-0.4.6-17.fc6 Changes in Fedora Extras 6: clamav-0.88.7-3.fc6 ------------------- * Thu May 31 2007 Enrico Scholz - 0.88.7-3 - [SECURITY] fixed CVE-2007-2650 (OLE2 list loop) and Clamav bug #515 (broken OOM handling) loki-lib-0.1.6-4.fc6 -------------------- * Thu Jul 05 2007 Sergio Pascual 0.1.6-4 - Installing libraries in _libdir instead of prefix/lib * Tue Jul 03 2007 Sergio Pascual 0.1.6-3 - Header files in directory loki * Sun Jul 01 2007 Sergio Pascual 0.1.6-2 - Disabled test suite, does not work in x86_64 - Added requires for -devel package * Tue Jun 26 2007 Sergio Pascual 0.1.6-1 - fixed installation of .h files - fixed version number * Mon Jun 11 2007 Sergio Pascual 0.1.6-0.3 - Removed the unused dependency to libm in the dynamic library * Mon Jun 11 2007 Sergio Pascual 0.1.6-0.2 - Removed the unused dependency to libpthread in the dynamic library * Thu Jun 07 2007 Sergio Pascual 0.1.6-0.1 - Initial fedora rpm release R-2.5.1-2.fc6 ------------- * Thu Jul 05 2007 Tom "spot" Callaway 2.5.1-2 - add rpm helper macros, script * Mon Jul 02 2007 Tom "spot" Callaway 2.5.1-1 - drop patch, upstream fixed - bump to 2.5.1 rpy-0.4.6-17.fc6 ---------------- * Fri Jul 06 2007 Tom "spot" Callaway - 0.4.6-17 - Rebuild to link with R 2.5.1 * Thu Apr 26 2007 Jos? Matos - 0.4.6-16 - Rebuild to link with R 2.5.0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From debarshi.ray at gmail.com Sun Jul 8 04:41:01 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 8 Jul 2007 10:11:01 +0530 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <468FF0EE.8000807@fedoraproject.org> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> <468FF0EE.8000807@fedoraproject.org> Message-ID: <3170f42f0707072141j4c8eefbfx73500218bbc55dc9@mail.gmail.com> > > There is a package called 'dd_rescue' already in Rawhide: > dd_rescue is not ddrescue. Look that up. Maybe, but there is scarce little in the description field to clarify the difference. The 'dd_rescue' package talks about 'ddrecue' in its description, which is misleading since end-users would not be searching the Web and archives to make out the difference. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Sun Jul 8 06:18:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Jul 2007 11:48:14 +0530 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <3170f42f0707072141j4c8eefbfx73500218bbc55dc9@mail.gmail.com> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> <468FF0EE.8000807@fedoraproject.org> <3170f42f0707072141j4c8eefbfx73500218bbc55dc9@mail.gmail.com> Message-ID: <469081A6.1020005@fedoraproject.org> Debarshi 'Rishi' Ray wrote: >> > There is a package called 'dd_rescue' already in Rawhide: > >> dd_rescue is not ddrescue. Look that up. > > Maybe, but there is scarce little in the description field to clarify > the difference. The 'dd_rescue' package talks about 'ddrecue' in its > description, which is misleading since end-users would not be > searching the Web and archives to make out the difference. You can file a bug report with a better description. Rahul From ruben at rubenkerkhof.com Sun Jul 8 08:34:44 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sun, 8 Jul 2007 10:34:44 +0200 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: <468FF0EE.8000807@fedoraproject.org> References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> <468FF0EE.8000807@fedoraproject.org> Message-ID: On 7-jul-2007, at 22:00, Rahul Sundaram wrote: > dd_rescue is not ddrescue. Look that up. Ok, [ruben at odin fedora-packaging]$ grep rescue owners/owners.list Fedora|dd_rescue|Fault tolerant "dd" utility for rescuing data from bad media|andreas at bawue.net|extras-qa at fedoraproject.org| Fedora|ddrescue|Fault tolerant "dd" utility for rescuing data from bad media|andreas at bawue.net|extras-qa at fedoraproject.org| This is confusing :-) Ruben From mschwendt.tmp0701.nospam at arcor.de Sun Jul 8 09:16:46 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 8 Jul 2007 11:16:46 +0200 Subject: Fedora Package Status of Jul 4, 2007 In-Reply-To: References: <20070705150855.66c324ad@ludwig-alpha.unil.ch> <3170f42f0707071237m5c8bdf97g1d58d366b0f17944@mail.gmail.com> <468FF0EE.8000807@fedoraproject.org> Message-ID: <20070708111646.c9feec58.mschwendt.tmp0701.nospam@arcor.de> On Sun, 8 Jul 2007 10:34:44 +0200, Ruben Kerkhof wrote: > > On 7-jul-2007, at 22:00, Rahul Sundaram wrote: > > > dd_rescue is not ddrescue. Look that up. > > Ok, > [ruben at odin fedora-packaging]$ grep rescue owners/owners.list > Fedora|dd_rescue|Fault tolerant "dd" utility for rescuing data from > bad media|andreas at bawue.net|extras-qa at fedoraproject.org| > Fedora|ddrescue|Fault tolerant "dd" utility for rescuing data from > bad media|andreas at bawue.net|extras-qa at fedoraproject.org| > > This is confusing :-) Even more confusing because there are multiple versions of ddrescue -- one in the review queue -- and dd_rescue in Fedora obsoletes ddrescue. ;o) At least the spec file ought to contain a comment to explain this. From mschwendt.tmp0701.nospam at arcor.de Sun Jul 8 09:24:42 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 8 Jul 2007 11:24:42 +0200 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> Message-ID: <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> On Sat, 7 Jul 2007 19:57:56 -0400, Chitlesh GOORAH (chitlesh) wrote: > Author: chitlesh > > Update of /cvs/extras/rpms/kmenu-gnome/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv20306/FC-6 > > Modified Files: > kmenu-gnome.spec > Log Message: > -Release: 2%{?dist} > +Release: 3%{?dist} > Summary: K Menu with Gnome directory > > License: GPL/LGPL > @@ -16,7 +16,7 @@ > Requires: kdebase >= 6:3.5.1 > > %description > -K Menu with Gnome folder and extra icons for Fedora Core 5 or later. > +K Menu with Gnome folder and extra icons. > > %prep > > @@ -71,6 +71,9 @@ > %doc ChangeLog COPYING GPL LGPL README > > %Changelog > +* Sun Jul 08 2007 Chitlesh Goorah - 0.6.5-3 > +- fixed %%description #247365 > + Our users shake their heads in disbelief, when new builds are published as updates just for a changed description like in this case. From chris.stone at gmail.com Sun Jul 8 09:23:22 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 8 Jul 2007 02:23:22 -0700 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On 7/8/07, Michael Schwendt wrote: > On Sat, 7 Jul 2007 19:57:56 -0400, Chitlesh GOORAH (chitlesh) wrote: > > > Author: chitlesh > > > > Update of /cvs/extras/rpms/kmenu-gnome/FC-6 > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv20306/FC-6 > > > > Modified Files: > > kmenu-gnome.spec > > Log Message: > > > > -Release: 2%{?dist} > > +Release: 3%{?dist} > > Summary: K Menu with Gnome directory > > > > License: GPL/LGPL > > @@ -16,7 +16,7 @@ > > Requires: kdebase >= 6:3.5.1 > > > > %description > > -K Menu with Gnome folder and extra icons for Fedora Core 5 or later. > > +K Menu with Gnome folder and extra icons. > > > > %prep > > > > @@ -71,6 +71,9 @@ > > %doc ChangeLog COPYING GPL LGPL README > > > > %Changelog > > +* Sun Jul 08 2007 Chitlesh Goorah - 0.6.5-3 > > +- fixed %%description #247365 > > + > > Our users shake their heads in disbelief, when new builds are published > as updates just for a changed description like in this case. Actually, to be quite honest, I'm shaking my head in disbelief that someone actually cares about downloading a few kilobytes. Even less if you use delta rpms which you probably should be doing by now anyway.... LOL, Thanks for the morning humor. From buildsys at redhat.com Sun Jul 8 09:29:23 2007 From: buildsys at redhat.com (Build System) Date: Sun, 8 Jul 2007 05:29:23 -0400 Subject: rawhide report: 20070708 changes Message-ID: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> New package astyle Source code formatter for C-like programming languages New package ocaml-lablgtk Objective Caml interface to gtk+ Updated Packages: ORBit2-2.14.7-4.fc8 ------------------- * Sat Jul 07 2007 Matthias Clasen - 2.14.7-4 - Fix directory ownership issues bluez-gnome-0.8-2.fc8 --------------------- * Sat Jul 07 2007 - Bastien Nocera - 0.8-2 - Only install and uninstall our own schema file (#247330) colordiff-1.0.6a-2.fc8 ---------------------- * Sat Jul 07 2007 Ville Skytt?? - 1.0.6a-2 - Convert docs to UTF-8. * Sat May 12 2007 Ville Skytt?? - 1.0.6a-1 - 1.0.6a. cpuspeed-1:1.2.1-2.fc8 ---------------------- * Sat Jul 07 2007 Jarod Wilson - Account for the cpuidle feature in rawhide kernels, slated for release in kernel 2.6.23 (#247352) fuse-emulator-0.8.0.1-1.fc8 --------------------------- * Sat Jun 30 2007 Ian Chapman 0.8.0.1-1.fc8 - Upgrade to 0.8.0.1 - Various cleanups to the SPEC including conforming to new guidelines * Thu Feb 09 2006 Paul F. Johnson - 0.7.0-6 - Removed pre and post as they were empty - Fixed the "fuse-emulator" problem * Wed Oct 26 2005 Paul F. Johnson - 0.7.0-5 - Altered package name to fuse-emulator (macro) - Removed BR: zlib-devel and BR: glibc-devel and both Requires - Included comment regarding the SRPM not containing the ROMS - Added README.z88sdk file to the archive - Made the source of the tarball a valid one! - Removed a comma from after xml2-devel fuse-emulator-utils-0.8.0.1-1.fc8 --------------------------------- * Sat Jul 07 2007 Ian Chapman 0.8.0.1-1.fc8 - Upgrade to 0.8.0.1 - Various cleanups to the SPEC including conforming to new guidelines gail-1.19.3-2.fc8 ----------------- * Sat Jul 07 2007 Matthias Clasen - 1.19.3-2 - fix directory ownership issues gnome-applets-1:2.18.0-13.fc8 ----------------------------- * Sat Jul 07 2007 Matthias Clasen - 1:2.18.0-13 - Another directory ownership fix gnome-panel-2.19.4-2.fc8 ------------------------ * Sat Jul 07 2007 Matthias Clasen - 2.19.4-2 - Fix directory ownership issues gnome-python2-2.19.1-1.fc8 -------------------------- * Sat Jul 07 2007 Matthew Barnes -2.19.1-1.fc8 - Update to 2.19.1 - Update versions of required packages. - Remove the zvt subpackage, which was removed upstream long ago. hplip-2.7.6-3.fc8 ----------------- * Sat Jul 07 2007 Tim Waugh 2.7.6-3 - Fixed pre scriptlet (bug #247349, bug #247322). hunspell-1.1.7-1.fc8 -------------------- * Sat Jul 07 2007 Caolan McNamara - 1.1.7-1 - latest version - drop integrated hunspell-1.1.5.freem.patch kmenu-gnome-0.6.5-3.fc8 ----------------------- * Sun Jul 08 2007 Chitlesh Goorah - 0.6.5-3 - fixed %description #247365 libXcursor-1.1.8-3 ------------------ * Sat Jul 07 2007 Matthias Clasen 1.1.8-3 - Don't own /usr/share/icons - Require pkgconfig in -devel * Sat Apr 21 2007 Matthias Clasen 1.1.8-2 - Don't install INSTALL libbonoboui-2.19.4-2.fc8 ------------------------ * Sat Jul 07 2007 Matthias Clasen - 2.19.4-2 - Fix directory ownership libgail-gnome-1.18.0-3.fc8 -------------------------- * Sat Jul 07 2007 Matthias Clasen - 1.18.0-3 - Fix directory ownership issues libgnome-2.19.0-2.fc8 --------------------- * Sat Jul 07 2007 Matthias Clasen - 2.19.0-2 - Fix directory ownership issues * Mon Jun 18 2007 Matthias Clasen - 2.19.0-1 - Update to 2.19.0 - Drop upstreamed patch * Thu Apr 19 2007 Matthias Clasen - 2.18.0-4 - Change the default icon theme to Fedora libspectrum-0.3.0.1-2.fc8 ------------------------- * Sat Jun 30 2007 Ian Chapman 0.3.0.1-2.fc8 - Release bump * Sat Jun 30 2007 Ian Chapman 0.3.0.1-1.fc8 - Upgrade to 0.3.0.1 - Changes to spec due to new guidelines perl-Test-Base-0.54-2.fc8 ------------------------- * Sat Jul 07 2007 Steven Pritchard 0.54-2 - BR Test::More. * Mon Jul 02 2007 Steven Pritchard 0.54-1 - Update to 0.54. perl-XML-SAX-0.16-2.fc8 ----------------------- * Sat Jul 07 2007 Robin Norwood - 0.16-2 - Resolves: rhbz#247213 - Fix provides and requires scripts. pygobject2-2.13.2-1.fc8 ----------------------- * Sat Jul 07 2007 Matthew Barnes - 2.13.2-1.fc8 - Update to 2.13.2 tsclient-0.150-2.fc8 -------------------- * Sat Jul 07 2007 Matthias Clasen - 0.150-2 - Fix a directory ownership issue tuxpaint-1:0.9.17-1.fc8 ----------------------- * Sat Jul 07 2007 Steven Pritchard 1:0.9.17-1 - Update to 0.9.17. - BR librsvg2-devel and libpaper-devel. - Add include path for glibconfig.h to CFLAGS. tuxpaint-stamps-2007.07.01-1.fc8 -------------------------------- yumex-1.9.10-1.0.fc8 -------------------- * Sat Jul 07 2007 Tim Lauridsen - 1.9.10-1.0 - Development Release 1.9.10-1.0 Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From Lam at Lam.pl Sun Jul 8 09:38:10 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 08 Jul 2007 11:38:10 +0200 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1183887490.3756.6.camel@pensja.lam.pl> Dnia 08-07-2007, N o godzinie 02:23 -0700, Christopher Stone napisa?(a): > Actually, to be quite honest, I'm shaking my head in disbelief that > someone actually cares about downloading a few kilobytes. Even less > if you use delta rpms which you probably should be doing by now > anyway.... Actually, it's quite a few megabytes of metadata to download because someone changes something (in this case, a perfectly correct description, FC6 is still Core+Extras), and in case of deltarpms, please, teach me, how to use them at this time without setting up my own mirrors. 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 j.w.r.degoede at hhs.nl Sun Jul 8 09:57:20 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 08 Jul 2007 11:57:20 +0200 Subject: rawhide report: 20070708 changes In-Reply-To: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> Message-ID: <4690B500.7070504@hhs.nl> Build System wrote: > Broken deps for i386 > ---------------------------------------------------------- > ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 > ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 > anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 > conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 > drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 > eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 > gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 > glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 > gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 > gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 > gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 > kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 > kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 > kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE > kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 > kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE > lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 > lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 > lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 > libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 > lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 > maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 > nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 > openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > osgal - 20060903-3.fc7.i386 requires libosg.so.1 > osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 > ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 > scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 > setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 > setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 > syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 > syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 > syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 > syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 > tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 > xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 > I've noticed that quite a few of these have been in here for a while now, as Games SIG member I've filed bugs for the games related ones, but I wonder, maybe bugs should get autofiled if a package stays in here for > 1 week? Regards, Hans From mschwendt.tmp0701.nospam at arcor.de Sun Jul 8 10:11:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 8 Jul 2007 12:11:01 +0200 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <1183887490.3756.6.camel@pensja.lam.pl> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> <1183887490.3756.6.camel@pensja.lam.pl> Message-ID: <20070708121101.78a0d07b.mschwendt.tmp0701.nospam@arcor.de> On Sun, 08 Jul 2007 11:38:10 +0200, Leszek Matok wrote: > Actually, it's quite a few megabytes of metadata to download because > someone changes something (in this case, a perfectly correct > description, FC6 is still Core+Extras), Often, it's N times a few megabytes of metadata to download, because mirrors are out-of-sync and offer files that don't pass the checksum check, and Yum proceeds through the mirror-list until it succeeds or fails finally. On top of that the wasted time when this blocks access to the repositories for a normal pirut/yum install. And to Christopher, yes, you're right, it is worse for larger packages to release updates for ridiculous changes like this one. From Lam at Lam.pl Sun Jul 8 10:40:18 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 08 Jul 2007 12:40:18 +0200 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <20070708121101.78a0d07b.mschwendt.tmp0701.nospam@arcor.de> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> <1183887490.3756.6.camel@pensja.lam.pl> <20070708121101.78a0d07b.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1183891218.3260.19.camel@pensja.lam.pl> Dnia 08-07-2007, N o godzinie 12:11 +0200, Michael Schwendt napisa?(a): > Often, it's N times a few megabytes of metadata to download, because > mirrors are out-of-sync and offer files that don't pass the checksum > check, and Yum proceeds through the mirror-list until it succeeds or fails > finally. As I already have written here, there are many very simple solutions, like: - not using downloaded repomd.xml if we already have a newer version (Seth replied to me that using a temporary 2 KiB file instead of instantly overwriting the previous one is a waste of resources, ha ha), now it happens to download old repomd.xml, when most mirrors host newer primary.*. - using versioned file names, like primary--.xml.gz and keeping them a week or two back. This way, if we need current primary-fc7-124.xml.gz, we'd never download anything from servers not synced yet (they'd just give us a 404 instead of useless 2,5 MiB .xml.gz or 4 MiB .sqlite.bz2) and if we need older primary-fc7-120.xml.gz, probably first mirror tried would provide that to us. Both changes are trivial and don't break any compatibility (first one is in yum itself, and the second is only a change in , which affects only the publishing system, not yum nor any other depsolving updater). > On top of that the wasted time when this blocks access to the > repositories for a normal pirut/yum install. Try to tell that to them, the proud Americans with their gigabit links and always in-sync mirrors. Maybe they'll send you a respin CD or tell you to leave the computer on for a nightly update. Yes, I'm aware that this comment isn't very helpful, but these are my feelings based on reading this list and I want to express them. Thanks for patience, 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 chitlesh at fedoraproject.org Sun Jul 8 11:03:27 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 8 Jul 2007 13:03:27 +0200 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <13dbfe4f0707080403q5dd40df8w88f10a087d120c4e@mail.gmail.com> On 7/8/07, Michael Schwendt wrote: > Our users shake their heads in disbelief, when new builds are published > as updates just for a changed description like in this case. Yup, may sounds like that. But however, I'll be offline for 2 weeks (vacation) soon, I'm trying to cut down the number of open bugs I have under my name. Chitlesh -- http://clunixchit.blogspot.com From jkeating at redhat.com Sun Jul 8 11:16:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 8 Jul 2007 07:16:55 -0400 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <13dbfe4f0707080403q5dd40df8w88f10a087d120c4e@mail.gmail.com> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> <13dbfe4f0707080403q5dd40df8w88f10a087d120c4e@mail.gmail.com> Message-ID: <200707080716.59062.jkeating@redhat.com> On Sunday 08 July 2007 07:03:27 Chitlesh GOORAH wrote: > Yup, may sounds like that. But however, I'll be offline for 2 weeks > (vacation) soon, I'm trying to cut down the number of open bugs I have > under my name. Make the change, close it NEXTRELEASE. Then the next time you have a real reason to update the package the change will already be in 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 jkeating at redhat.com Sun Jul 8 11:18:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 8 Jul 2007 07:18:35 -0400 Subject: rawhide report: 20070708 changes In-Reply-To: <4690B500.7070504@hhs.nl> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> <4690B500.7070504@hhs.nl> Message-ID: <200707080718.35905.jkeating@redhat.com> On Sunday 08 July 2007 05:57:20 Hans de Goede wrote: > I've noticed that quite a few of these have been in here for a while now, > as Games SIG member I've filed bugs for the games related ones, but I > wonder, maybe bugs should get autofiled if a package stays in here for > 1 > week? maybe. Next week I really need to get the individual mail part working if it isn't already. Not only do we put the list in these reports, but we're supposed to be mailing the owners directly with their individual breakages. If they ignore those, they'll most likely ignore a bug too. Rel-eng has decided that a week before the freeze we'll start really really hounding these people and/or fixing them ourselves. -- 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 drago01 at gmail.com Sun Jul 8 11:31:25 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 08 Jul 2007 13:31:25 +0200 Subject: rawhide report: 20070708 changes In-Reply-To: <200707080718.35905.jkeating@redhat.com> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> <4690B500.7070504@hhs.nl> <200707080718.35905.jkeating@redhat.com> Message-ID: <4690CB0D.3060805@gmail.com> Jesse Keating wrote > On Sunday 08 July 2007 05:57:20 Hans de Goede wrote: > >> I've noticed that quite a few of these have been in here for a while now, >> as Games SIG member I've filed bugs for the games related ones, but I >> wonder, maybe bugs should get autofiled if a package stays in here for > 1 >> week? >> > > maybe. Next week I really need to get the individual mail part working if it > isn't already. Not only do we put the list in these reports, but we're > supposed to be mailing the owners directly with their individual breakages. > If they ignore those, they'll most likely ignore a bug too. > > Rel-eng has decided that a week before the freeze we'll start really really > hounding these people and/or fixing them ourselves. > > most of them would be fixed by a simple rebuild. From mschwendt.tmp0701.nospam at arcor.de Sun Jul 8 12:26:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 8 Jul 2007 14:26:26 +0200 Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 In-Reply-To: <200707080716.59062.jkeating@redhat.com> References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> <13dbfe4f0707080403q5dd40df8w88f10a087d120c4e@mail.gmail.com> <200707080716.59062.jkeating@redhat.com> Message-ID: <20070708142626.08f4a5ba.mschwendt.tmp0701.nospam@arcor.de> On Sun, 8 Jul 2007 07:16:55 -0400, Jesse Keating wrote: > On Sunday 08 July 2007 07:03:27 Chitlesh GOORAH wrote: > > Yup, may sounds like that. But however, I'll be offline for 2 weeks > > (vacation) soon, I'm trying to cut down the number of open bugs I have > > under my name. > > Make the change, close it NEXTRELEASE. Then the next time you have a real > reason to update the package the change will already be in there. The bug report (by Rahul, #247365) was about 'devel', not about an older branch. So, CLOSED/RAWHIDE as always. From tcallawa at redhat.com Sun Jul 8 13:31:30 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 08 Jul 2007 08:31:30 -0500 Subject: rawhide report: 20070708 changes In-Reply-To: <200707080718.35905.jkeating@redhat.com> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> <4690B500.7070504@hhs.nl> <200707080718.35905.jkeating@redhat.com> Message-ID: <1183901490.3489.48.camel@localhost.localdomain> On Sun, 2007-07-08 at 07:18 -0400, Jesse Keating wrote: > maybe. Next week I really need to get the individual mail part > working if it > isn't already. Not only do we put the list in these reports, but > we're > supposed to be mailing the owners directly with their individual > breakages. > If they ignore those, they'll most likely ignore a bug too. Pretty sure this is not working, as Hans's bug was the first I'd heard of an issue with one of my packages. ~spot From ville.skytta at iki.fi Sun Jul 8 14:04:08 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 8 Jul 2007 17:04:08 +0300 Subject: LSB init scripts and NETWORKING=no && exit 0 Message-ID: <200707081704.09237.ville.skytta@iki.fi> One more question related to LSB init scripts: A commonly found current approach in init scripts for services that require networking to be up is: # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ "$NETWORKING" = "no" ] && exit 0 Silently exiting with 0 no matter which action was requested does not look like something expected of LSB compliant init scripts. Actually, all of 1) silent exit and 2) the zero exit value and 3) the way "is networking up?" is checked seem questionable to me. Anyone have ideas for better approaches to this? From debarshi.ray at gmail.com Sun Jul 8 15:38:25 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 8 Jul 2007 21:08:25 +0530 Subject: Pirut: Edit -> Repositories mock-up. Message-ID: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> http://debarshiray.multiply.com/journal/item/82 I have finished designing the Edit -> Repositories dialog. Although the primary objective was to use it for my offline updating tool (https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay), I am also keen to contribute this to Pirut. Do you like it? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From sundaram at fedoraproject.org Sun Jul 8 15:53:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Jul 2007 21:23:34 +0530 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> Message-ID: <4691087E.60109@fedoraproject.org> Debarshi 'Rishi' Ray wrote: > http://debarshiray.multiply.com/journal/item/82 > You should get your blog in Fedora Planet. See http://fedoraproject.org/wiki/Planet. Wiki link to Pirut is incorrect btw. Good work but I don't understand many details here: * Can you explain the use case for making changes to repository configuration but not saving them? * What happens when you click on edit? Shouldn't it be disabled if you haven't selected a specific repository? * Add Cdrom (Shouldn't this be capitalized) seems to be a lone option there. Can I point to a DVD repository? If so, it should probably say add CDROM/DVD or add media instead. Media support should probably go to a Yum API which the GUI takes advantage of (along with a command line) rather than being Pirut specific. * There is no convenient interface to exclude packages to point to the base url instead of the mirror list. Rahul From drago01 at gmail.com Sun Jul 8 15:56:24 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 8 Jul 2007 17:56:24 +0200 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <4691087E.60109@fedoraproject.org> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <4691087E.60109@fedoraproject.org> Message-ID: On 7/8/07, Rahul Sundaram wrote: > > Debarshi 'Rishi' Ray wrote: > > http://debarshiray.multiply.com/journal/item/82 > > > > You should get your blog in Fedora Planet. See > http://fedoraproject.org/wiki/Planet. Wiki link to Pirut is incorrect btw. > > Good work but I don't understand many details here: > > * Can you explain the use case for making changes to repository > configuration but not saving them? same as running yum with --enablerepo=... or --disablerepo=... -------------- next part -------------- An HTML attachment was scrubbed... URL: From otto_rey at yahoo.com.ar Sun Jul 8 16:12:57 2007 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Sun, 8 Jul 2007 09:12:57 -0700 (PDT) Subject: Where to file bugs against FUS? Message-ID: <434780.16590.qm@web52401.mail.re2.yahoo.com> Please people, help me with this: i have some bugs to report to Fast User Switch functionality. What component should i use? Currently im using fast-user-switch-applet, but looks like nobody working in this. Thanks Otto Rey BTW: Im working on new email cliente (GPL - OpenJDK) to have an alternative to buggy Evolution in Micro$oft Exchange accounts. Sooner i will upload files to sourceforge and call for volunteers. For more (???) information go to http://sourceforge.net/projects/jpvmailerx, http://jpvmailer.com.ar and http://openjdk.java.net __________________________________________________ Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). ?Probalo ya! http://www.yahoo.com.ar/respuestas From steve at silug.org Sun Jul 8 19:52:39 2007 From: steve at silug.org (Steven Pritchard) Date: Sun, 8 Jul 2007 14:52:39 -0500 Subject: LSB init scripts and NETWORKING=no && exit 0 In-Reply-To: <200707081704.09237.ville.skytta@iki.fi> References: <200707081704.09237.ville.skytta@iki.fi> Message-ID: <20070708195239.GA22763@osiris.silug.org> On Sun, Jul 08, 2007 at 05:04:08PM +0300, Ville Skytt? wrote: > Actually, all of 1) silent exit and 2) the zero exit value and 3) the way "is > networking up?" is checked seem questionable to me. Anyone have ideas for > better approaches to this? Isn't that just supposed to be checking if networking is enabled at all? If that is "no", presumably we don't even have the loopback interface up. 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 ville.skytta at iki.fi Sun Jul 8 20:15:55 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 8 Jul 2007 23:15:55 +0300 Subject: LSB init scripts and NETWORKING=no && exit 0 In-Reply-To: <20070708195239.GA22763@osiris.silug.org> References: <200707081704.09237.ville.skytta@iki.fi> <20070708195239.GA22763@osiris.silug.org> Message-ID: <200707082315.56113.ville.skytta@iki.fi> On Sunday 08 July 2007, Steven Pritchard wrote: > On Sun, Jul 08, 2007 at 05:04:08PM +0300, Ville Skytt? wrote: > > Actually, all of 1) silent exit and 2) the zero exit value and 3) the way > > "is networking up?" is checked seem questionable to me. Anyone have > > ideas for better approaches to this? > > Isn't that just supposed to be checking if networking is enabled at > all? If that is "no", presumably we don't even have the loopback > interface up. Hard to tell, but that's just one bit of the puzzle. To elaborate on the issues: a) Why doesn't it output an error message saying that the service requires networking but networking doesn't seem to be available? b) Why is the exit status 0, indicating success? c) Why is the check done before doing anything else instead of being done eg. only in the start (and restart, reload and friends if they're not implemented using start) action? That and b) will result in eg. the status action returning 0, indicating in LSB terms "program is running or service is OK" which it most likely is not if it requires networking and networking isn't up. d) Why does it just read something from a config file instead of actually checking whether networking is up? Not sure if that check is necessary in the first place - could just let the service fail. Maybe it's used/useful for optimization purposes and/or to provide a hook for a more descriptive error message than what the failing service would output. From kevin.kofler at chello.at Sun Jul 8 22:00:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 8 Jul 2007 22:00:41 +0000 (UTC) Subject: rpms/kmenu-gnome/FC-6 kmenu-gnome.spec,1.9,1.10 References: <200707072357.l67NvutH020398@cvs-int.fedora.redhat.com> <20070708112442.2dce717d.mschwendt.tmp0701.nospam@arcor.de> <1183887490.3756.6.camel@pensja.lam.pl> <20070708121101.78a0d07b.mschwendt.tmp0701.nospam@arcor.de> <1183891218.3260.19.camel@pensja.lam.pl> Message-ID: Leszek Matok Lam.pl> writes: > As I already have written here, there are many very simple solutions, > like: [snip] > Try to tell that to them, the proud Americans with their gigabit links > and always in-sync mirrors. First of all, I'm not an American and I don't have a gigabit link. ;-) (Quite possibly still a faster connection than you though.) I've found the mirrorlist feature to be entirely useless. I always hardcode a mirror I know to be reasonably in sync (almost always) and very fast (able to saturate my connection). That way the date check on the repomd is entirely unneeded, because metadata doesn't get older on the same mirror. ;-) (Or if it does, pick a better one. ;-) ) Not to mention that my favorite depsolver (apt-rpm) doesn't support mirrorlists anyway. Hint: There's a certain country between Austria and Poland which has fast and up-to-date mirrors. ;-) I hope this helps, Kevin Kofler From sean.bruno at dsl-only.net Sun Jul 8 22:28:26 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 08 Jul 2007 15:28:26 -0700 Subject: dmraid status, regressions Message-ID: <1183933706.3161.18.camel@home-desk> I quickly browsed through bugzilla to see if I was the only one having issues with dmraid. It looks like there are a few tickets, but not as many as I would have thought. A quick search shows only ten or so tickets: https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora&component=dmraid&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= However, they are being masked as installer failures in anaconda. I went through the first page or so and came up with these: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=155979 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242252 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156161 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=157773 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=128766 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234719 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227186 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217291 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213738 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139765 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175586 There's even one or two that I have commented on and one or two that completely duplicate my issues. I have three dmraid compatible controllers at my disposal and all three fail to install(anaconda barfs). Anyone want to suggest a troubleshooting methodology? Should I be contacting the upstream dmraid maintainers for the failures? Sean From emmanuel.seyman at club-internet.fr Sun Jul 8 22:37:42 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 9 Jul 2007 00:37:42 +0200 Subject: LSB init scripts and NETWORKING=no && exit 0 In-Reply-To: <20070708195239.GA22763@osiris.silug.org> References: <200707081704.09237.ville.skytta@iki.fi> <20070708195239.GA22763@osiris.silug.org> Message-ID: <20070708223742.GA16578@orient.maison.lan> * Steven Pritchard [08/07/2007 22:09] : > > Isn't that just supposed to be checking if networking is enabled at > all? If that is "no", presumably we don't even have the loopback > interface up. It's sourced from /etc/sysconfig/network so the question being answered is "Does the box sysadmin want networking to be started on boot ?". Seems a bit redundant with "chkconfig network off" to me but checking it to see if network-related services should be started on boot sounds OK. Probably best to check with "/etc/init.d/network status", though. Emmanuel From seandarcy2 at gmail.com Mon Jul 9 00:16:50 2007 From: seandarcy2 at gmail.com (sean) Date: Sun, 08 Jul 2007 20:16:50 -0400 Subject: rawhide report: 20070708 changes In-Reply-To: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> Message-ID: Something here broke the window manager in gnome. No window frame, can't resize,etc. kde and xfce work. I don't even know what to file against - it all looks harmless. Anybody else?? sean From darrellpf at gmail.com Mon Jul 9 02:36:34 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Sun, 8 Jul 2007 19:36:34 -0700 Subject: rawhide report: 20070708 changes In-Reply-To: References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> Message-ID: On 7/8/07, sean wrote: > Something here broke the window manager in gnome. No window > frame, can't resize,etc. > > kde and xfce work. > > I don't even know what to file against - it all looks harmless. > > Anybody else?? > Are you running with compiz? I get that problem, but as a workaround I turn off desktop effects and then turn them back on again right away. darrell From abartlet at samba.org Mon Jul 9 02:47:37 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 09 Jul 2007 12:47:37 +1000 Subject: Exchange clients (was: Re: Where to file bugs against FUS?) In-Reply-To: <434780.16590.qm@web52401.mail.re2.yahoo.com> References: <434780.16590.qm@web52401.mail.re2.yahoo.com> Message-ID: <1183949257.2838.37.camel@localhost.localdomain> On Sun, 2007-07-08 at 09:12 -0700, Otto Rey wrote: > BTW: Im working on new email cliente (GPL - OpenJDK) to have an > alternative to buggy Evolution in Micro$oft Exchange accounts. Sooner > i will upload files to sourceforge and call for volunteers. For more > (???) information go to http://sourceforge.net/projects/jpvmailerx, > http://jpvmailer.com.ar and http://openjdk.java.net Have you thought about using the OpenChange libraries, to get real exchange server support? They are working to replace the current Exchange connector with one that uses the real exchange protocols. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://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 spng.yang at gmail.com Mon Jul 9 06:14:28 2007 From: spng.yang at gmail.com (Ken YANG) Date: Mon, 09 Jul 2007 14:14:28 +0800 Subject: xchm crash in F8 rawhide In-Reply-To: <1183802054.10483.4.camel@tuxhugs> References: <468F5CC7.7020204@gmail.com> <1183801696.3270.14.camel@dawkins> <1183802054.10483.4.camel@tuxhugs> Message-ID: <4691D244.4080308@gmail.com> Peter Gordon wrote: > On Sat, 2007-07-07 at 11:48 +0200, David Nielsen wrote: >> Can you please file a bug on this so it doesn't get lost. > > Ken, > > If/when you do, please file it against wxGTK and add me (this email > address) as a CC on the bug. I've seen similar backtraces from other > wxGTK-using applications (including code::blocks and Audacity). hi peter, david and mamoru sorry for reply late, i have not network in sunday, i had submitted this as bug 247424: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247414 > > Thanks. > From otto_rey at yahoo.com.ar Mon Jul 9 06:23:23 2007 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Sun, 8 Jul 2007 23:23:23 -0700 (PDT) Subject: Exchange clients (was: Re: Where to file bugs against FUS?) Message-ID: <614254.38061.qm@web52405.mail.re2.yahoo.com> Wow!! This is really good for us (Exchange Servers are for everywhere :( ). Thanks for data Andrew. ----- Mensaje original ---- De: Andrew Bartlett Para: Development discussions related to Fedora Core Enviado: domingo 8 de julio de 2007, 23:47:37 Asunto: Exchange clients (was: Re: Where to file bugs against FUS?) On Sun, 2007-07-08 at 09:12 -0700, Otto Rey wrote: > BTW: Im working on new email cliente (GPL - OpenJDK) to have an > alternative to buggy Evolution in Micro$oft Exchange accounts. Sooner > i will upload files to sourceforge and call for volunteers. For more > (???) information go to http://sourceforge.net/projects/jpvmailerx, > http://jpvmailer.com.ar and http://openjdk.java.net Have you thought about using the OpenChange libraries, to get real exchange server support? They are working to replace the current Exchange connector with one that uses the real exchange protocols. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). ?Probalo ya! http://www.yahoo.com.ar/respuestas From otto_rey at yahoo.com.ar Mon Jul 9 06:37:59 2007 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Sun, 8 Jul 2007 23:37:59 -0700 (PDT) Subject: Virtualization things. Message-ID: <698534.53803.qm@web52401.mail.re2.yahoo.com> - Is somebody working on Virtualization (KVM + QEMU) Performance? Maybe Upstream? Some time ago kqemu (qemu accelerator) was released under GPL 2 license. Any plans to include in fedora? Or it is already included/merged under qemu name? - It is posible to include VirtualBox OSE (Open Source Edition - GPL v2) in Fedora repo's? Any problem with Legal Stuff? Thanks a lot Otto Rey __________________________________________________ Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). ?Probalo ya! http://www.yahoo.com.ar/respuestas From valent.turkovic at gmail.com Mon Jul 9 07:20:47 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jul 2007 09:20:47 +0200 Subject: Fedora Frog - does this actually works or it is me? Message-ID: <64b14b300707090020n77b91290xecf4fca5a2641ae1@mail.gmail.com> http://www.linux.com/articles/114132?tid=47 Have you tried this? I installed it and I don't get it how it should work. Fedora Helper works ok on Fedora Core 6 and even on Fedora 7 if you change the script a bit. http://www.brandonhutchinson.com/Fedora_Helper.html I looked into the rpm and saw only "frog.user" as executable file. When I start it I get only this on my Fedora Core 6: [valentt at fedora ~]$ frog.user ################################################################################ Do you want to configure Num Lock to turn on at startup? ################################################################################ yes/no/quit (ynq) n [valentt at fedora ~]$ frog.user ################################################################################ Do you want to configure Num Lock to turn on at startup? ################################################################################ yes/no/quit (ynq) q Program terminated at user request. [valentt at fedora ~]$ frog.user ################################################################################ Do you want to configure Num Lock to turn on at startup? ################################################################################ yes/no/quit (ynq) y NumlockX has been configured to turn on when you login. [valentt at fedora ~]$ frog.user ################################################################################ Do you want to configure Num Lock to turn on at startup? ################################################################################ yes/no/quit (ynq) n [valentt at fedora ~]$ Does Fedora Frog actually work or is it me? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From buildsys at redhat.com Mon Jul 9 08:49:28 2007 From: buildsys at redhat.com (Build System) Date: Mon, 9 Jul 2007 04:49:28 -0400 Subject: rawhide report: 20070709 changes Message-ID: <200707090849.l698nSKw003485@porkchop.devel.redhat.com> New package coco-coq Coco Coq in Grostesteing's base, an AGI adventure game New package roundup Simple and flexible issue-tracking system Updated Packages: amavisd-new-2.5.2-1.fc8 ----------------------- * Sun Jul 08 2007 Steven Pritchard 2.5.2-1 - Update to 2.5.2. apt-0.5.15lorg3.92-1.fc8 ------------------------ * Sun Jul 08 2007 Panu Matilainen - 0.5.15lorg3.92-1 - update to 0.5.15lorg3.92 - drop broken GPG keys, they belong to the config package anyway - buildrequire sqlite-devel for repomd sqlite extension support - add changelog to docs compat-wxGTK26-2.6.3-4 ---------------------- * Sun Jul 08 2007 Michael Schwendt - 2.6.3-4 - Call g_thread_init early (#244542). * Sun Jul 08 2007 Michael Schwendt - 2.6.3-3 - Avoid g_free related crashes in gtk. freedroid-1.0.2-7.fc8 --------------------- * Sun Jul 08 2007 Ville Skytt?? - 1.0.2-7 - Apply partial CPU hogging fix from upstream CVS. - Desktop entry improvements. * Tue Aug 29 2006 Ville Skytt?? - 1.0.2-6 - Move data files from %{_datadir}/games/freedroid to %{_datadir}/freedroid. * Tue Feb 21 2006 Ville Skytt?? - 1.0.2-5 - Fix crash when the config file cannot be read/written to (#182280). - Install icon to %{_datadir}/icons/hicolor, update GTK icon cache at post(un)install time. - Build with dependency tracking disabled. - List installed files explicitly. fwbackups-1.43.0-1.fc8 ---------------------- * Sun Jul 08 2007 Stewart Adam 1.43.0-1 - Add BuildRequires python 2.4, gettext - Add Requires python 2.4, notify-python - No longer requires redhat-artwork and usermode - New description - Update to 1.43.0 (see CHANGELOG file for details on version changes) * Sat Apr 14 2007 Stewart Adam 1.43.0-0.1.beta3 - Update to 1.43.0 Beta3 * Mon Mar 26 2007 Stewart Adam 1.43.0-0.1.beta2 - Update to 1.43.0 Beta2 gcalctool-5.19.5-1.fc8 ---------------------- * Sun Jul 08 2007 Matthias Clasen - 5.19.5-1 - Update to 5.19.5 gdb-6.6-20.fc8 -------------- * Sun Jul 08 2007 Jan Kratochvil - 6.6-20 - Do not hang on exit of a thread group leader (BZ 247354). - New test for upstream fix of VDSO decoding while attaching to an i386 process. - Fixed BZ # 232014 -> 232015. * Thu Jul 05 2007 Jan Kratochvil - 6.6-19 - Link with libreadline provided by the operating system. * Tue Jun 26 2007 Jan Kratochvil - 6.6-18 - Fix PPC software watchpoints active while stepping atomic instr. (BZ 237572). gmime-2.2.9-3.fc8 ----------------- * Sun Jul 08 2007 Thorsten Leemhuis - 2.2.9-3 - there is no mono for ppc64 as well * Fri Jul 06 2007 Thorsten Leemhuis - 2.2.9-2 - build stuff depending on mono on all archs except those where we know there is no mono (fixes alpha, #246437) gnome-desktop-2.19.5-1.fc8 -------------------------- * Sun Jul 08 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gnome-menus-2.19.5-1.fc8 ------------------------ * Sun Jul 08 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gnome-session-2.19.5-1.fc8 -------------------------- * Sun Jul 08 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gtk2-2.11.5-3.fc8 ----------------- * Sun Jul 08 2007 Matthias Clasen - 2.11.5-3 - Own /usr/lib/gtk-2.0/modules * Mon Jul 02 2007 Matthias Clasen - 2.11.5-1 - Update to 2.11.5 * Tue Jun 19 2007 Matthias Clasen - 2.11.4-1 - Update to 2.11.4 libgnomeprint22-2.18.0-3.fc8 ---------------------------- * Sun Jul 08 2007 Matthias Clasen - 2.18.0-3 - Fix a directory ownership issue * Sat Apr 21 2007 Matthias Clasen - 2.18.0-2 - Don't ship .la files - Require pkgconfig in the -devel package libwnck-2.19.5-1.fc8 -------------------- * Sun Jul 08 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 magic-7.4.35-5.fc8 ------------------ * Sun Jul 08 2007 Chitlesh Goorah - 7.4.35-5 - patching properly * Sun Jul 08 2007 Chitlesh Goorah - 7.4.35-4 - patching properly * Sun Jul 08 2007 Chitlesh Goorah - 7.4.35-3 - fix for 64 bit with respect to a hardcoded autopath - fix for %post and %postun - #246778 perl-Pugs-Compiler-Rule-0.24-1.fc8 ---------------------------------- perl-XML-Twig-3.29-4.fc8 ------------------------ * Sun Jul 08 2007 Robin Norwood - 3.29-4 - Resolves: rhbz#247247 - Remove bogus Provides: perl(XML::XPathEngine::NodeSet), and move Requires filter into spec file. python-paste-1.4-1.fc8 ---------------------- * Sun Jul 08 2007 Luke Macken - 1.4-1 - 1.4 * Sat Mar 03 2007 Luke Macken - 1.2.1-1 - 1.2.1 * Sat Dec 09 2006 Luke Macken - 1.0-2 - Add python-devel to BuildRequires - 1.0 python-paste-deploy-1.3.1-1.fc8 ------------------------------- * Sun Jul 08 2007 Luke Macken - 1.3.1-1 - 1.3.1 python-paste-script-1.3.5-1.fc8 ------------------------------- * Sun Jul 08 2007 Luke Macken - 1.3.5-1 - 1.3.5 python-simplejson-1.7.1-1.fc8 ----------------------------- * Sun Jul 08 2007 Luke Macken - 1.7.1-1 - 1.7.1 revisor-2.0.4.1-1rc2.fc8 ------------------------ * Sun Jul 01 2007 Jeroen van Meeuwen 2.0.4.1-1rc2 - Adding cobbler support for CLI mode - Fixing pkgorder issue - Fixing inefficient pkgorder - Adding Enterprise Linux configuration files - Moving some packages to be suggested instead of required - Fixed progress bar during ISO creation - Fixed SHA1SUM file not having all ISOs - Adding full support for installation tree and cleanup yumex-1.9.10-2.0.fc8 -------------------- * Sun Jul 08 2007 Tim Lauridsen - 1.9.10-2.0 - Development Release 1.9.10-2.0 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 lincity-ng - 1.1.0-1.fc7.i386 requires libSDL_gfx.so.13 lincity-ng - 1.1.0-1.fc7.x86_64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 synaptic - 0.57.2-8.fc8.i386 requires libapt-pkg-libc6.6-6.so.2 synaptic - 0.57.2-8.fc8.x86_64 requires libapt-pkg-libc6.6-6.so.2()(64bit) syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc requires libSDL_gfx.so.13 lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 synaptic - 0.57.2-8.fc8.ppc64 requires libapt-pkg-libc6.6-6.so.2()(64bit) synaptic - 0.57.2-8.fc8.ppc requires libapt-pkg-libc6.6-6.so.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) lincity-ng - 1.1.0-1.fc7.ppc64 requires libSDL_gfx.so.13()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 synaptic - 0.57.2-8.fc8.ppc64 requires libapt-pkg-libc6.6-6.so.2()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From alan at redhat.com Mon Jul 9 10:26:49 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Jul 2007 06:26:49 -0400 Subject: Parallel Booting In-Reply-To: References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213326.GB8245@devserv.devel.redhat.com> Message-ID: <20070709102649.GA6716@devserv.devel.redhat.com> On Fri, Jul 06, 2007 at 08:26:07PM -0500, Jason L Tibbitts III wrote: > But anyway, I was merely responding to the comment about SSDs > rendering this discussion moot. Obviously disk access speed is a > factor in startup time, but I don't think it's anything close to the > dominating factor. >From testing with an i-RAM I would concur with this statement. There are cases it does appear to be significant like big software builds but booting is other load From jbowes at redhat.com Mon Jul 9 12:02:36 2007 From: jbowes at redhat.com (James Bowes) Date: Mon, 9 Jul 2007 08:02:36 -0400 Subject: Virtualization things. In-Reply-To: <698534.53803.qm@web52401.mail.re2.yahoo.com> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> Message-ID: <20070709120235.GA7371@crux.rdu.redhat.com> Hi, On Sun, Jul 08, 2007 at 11:37:59PM -0700, Otto Rey wrote: > - Is somebody working on Virtualization (KVM + QEMU) Performance? Maybe Upstream? Some time ago kqemu (qemu accelerator) was released under GPL 2 license. Any plans to include in fedora? Or it is already included/merged under qemu name? kqemu was discussed previously on the list: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/57636 > - It is posible to include VirtualBox OSE (Open Source Edition - GPL v2) in Fedora repo's? Any problem with Legal Stuff? As was VirtualBox: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/53189 -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pvrabec at redhat.com Mon Jul 9 12:17:52 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Mon, 09 Jul 2007 14:17:52 +0200 Subject: rsyslog in f8? In-Reply-To: <1183500744.5894.2.camel@sb-home> References: <20070703124100.2e704168@ghistelwchlohm.scrye.com> <1183500744.5894.2.camel@sb-home> Message-ID: <46922770.2050504@redhat.com> Hi, > > Does rsyslog support store and forward logging? > > Like a good version of sysklogd's centalised host logging, but with an > unlimited buffer size (i.e. store-to-file until acknowledged or okayed > by central log server, then truncate file). sorry I'm not sure what do you mean? Is it "-h" option? From sundaram at fedoraproject.org Mon Jul 9 13:02:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 09 Jul 2007 18:32:39 +0530 Subject: Fedora Frog - does this actually works or it is me? In-Reply-To: <64b14b300707090020n77b91290xecf4fca5a2641ae1@mail.gmail.com> References: <64b14b300707090020n77b91290xecf4fca5a2641ae1@mail.gmail.com> Message-ID: <469231EF.5050603@fedoraproject.org> Valent Turkovic wrote: > http://www.linux.com/articles/114132?tid=47 > > Have you tried this? I installed it and I don't get it how it should > work. > This is offtopic in this list. Post to fedora-list or http://fedoraforum.org for end user questions. Rahul From jkeating at redhat.com Mon Jul 9 13:44:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Jul 2007 09:44:24 -0400 Subject: Plan for Today's (20070709) Release Engineering meeting Message-ID: <200707090944.25252.jkeating@redhat.com> Below you will find a list of topics that we'd like to go over in the next RelEng meeting that is scheduled for Today, Monday at 1700 UTC in #fedora-meeting on irc.freenode.org: /topic RELENG-Meeting - Fedora Signing Server - JesseKeating /topic RELENG-Meeting - Open Discussion You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Open Discussion" phase. If your name/nick is on above list please update the status on the ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That way all the other RelEng members and interested contributors know whats up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his/her slow typing... -- 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 Mon Jul 9 13:46:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Jul 2007 09:46:28 -0400 Subject: Plan for Today's (20070709) Release Engineering meeting In-Reply-To: <200707090944.25252.jkeating@redhat.com> References: <200707090944.25252.jkeating@redhat.com> Message-ID: <200707090946.28537.jkeating@redhat.com> On Monday 09 July 2007 09:44:24 Jesse Keating wrote: > /topic RELENG-Meeting - Fedora Signing Server - JesseKeating > > /topic RELENG-Meeting - Open Discussion /topic RELENG-Meeting - Composes in the colo - JesseKeating -- 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 katzj at redhat.com Mon Jul 9 14:54:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Jul 2007 10:54:00 -0400 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> Message-ID: <1183992841.12137.25.camel@erebor.boston.redhat.com> (Note: you really don't have to send the mail directly to me. I read basically everything on the list) On Sun, 2007-07-08 at 21:08 +0530, Debarshi 'Rishi' Ray wrote: > http://debarshiray.multiply.com/journal/item/82 > > I have finished designing the Edit -> Repositories dialog. Although > the primary objective was to use it for my offline updating tool > (https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay), I am > also keen to contribute this to Pirut. The problem here is that you've started designing from doing a mock-up, not by looking at the use-cases that you're trying to solve and then going from there. Mockups are helpful, but not necessarily the first step to take. So, trying to brain-storm a little on Monday morning on some of the quick and abbreviated use cases for graphical repo editing... 1) Jim is getting more involved in Fedora and wants to enable the updates-testing repository so that he can be involved in testing updates. Also the disable case here. 2) John has a local mirror that he prefers to use for getting his Fedora updates and would like to point directly at it rather than the mirror list. 3) Sue read about some new software that's available from $vendor and would like to add their repo so that she can install and try it out. 4) $vendor provides a repo file on their website and would like to have it be easy for end-users to add that to their configs 5) Sally is a power-user and likes to micro-manage the details of the repository configuration. 6..X) Probably some more :) Of these, the first three are all things that are going to be pretty sensible and fit in with the target audience of pirut. The fourth really isn't and so it's probably not worth trying to look at Sally's needs. And then from the actual use cases, moving on to prototypes and mockups is reasonable. So, looking at your mockup with the above in mind leads to some questions * As Rahul said, what's the real use case for making changes but not saving them? I think that ends up being a bit more of a power-user thing and probably more confusing than not for pirut * The authentication tab seems likely to be a bit of micro-management. Also, even if there's a good case for the user to want to care, why is it separate and global rather than per-repo? Especially as the gpgkey bits are all generally set on a per-repo basis * What's the difference between Add and Add CDROM? A repo is a repo, and distinguishing between where they come from is going to be a little painful. Especially as a repo can have both URLs and a way to access it via media (add mediaid= to the repo config) * What's a channel? It says it's a repository manager but then seems to be dealing with something that's channels? Jeremy From a.badger at gmail.com Mon Jul 9 15:17:33 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Jul 2007 08:17:33 -0700 Subject: rawhide report: 20070708 changes In-Reply-To: <4690B500.7070504@hhs.nl> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> <4690B500.7070504@hhs.nl> Message-ID: <1183994253.22903.14.camel@localhost.localdomain> On Sun, 2007-07-08 at 11:57 +0200, Hans de Goede wrote: > Build System wrote: > > Broken deps for i386 > > ---------------------------------------------------------- > > anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 > > conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 > > drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 > > gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 > > glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 > > gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 > > gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 > > gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 > > libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 > > nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 > > ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 > > scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 > > > > I've noticed that quite a few of these have been in here for a while now, as > Games SIG member I've filed bugs for the games related ones, but I wonder, > maybe bugs should get autofiled if a package stays in here for > 1 week? > The gtksourceview-1 bugs are known and should be fixed in the next couple days. We're going to be providing both gtksourceview 1.x and 2.x in rawhide but there was a guideline change needed for the second package to be approved. That has happened and we are just waiting the three business days since reporting for FESCo to have a chance to veto the change. -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 mschwendt.tmp0701.nospam at arcor.de Mon Jul 9 16:32:12 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 9 Jul 2007 18:32:12 +0200 Subject: rpms/fortune-firefly/FC-3 fortune-firefly.spec,1.8,1.9 In-Reply-To: <200707091525.l69FPKSf018323@cvs-int.fedora.redhat.com> References: <200707091525.l69FPKSf018323@cvs-int.fedora.redhat.com> Message-ID: <20070709183212.e2340752.mschwendt.tmp0701.nospam@arcor.de> On Mon, 9 Jul 2007 11:25:20 -0400, Karen Rei Pease (meme) wrote: > Author: meme > > Update of /cvs/extras/rpms/fortune-firefly/FC-3 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18206/FC-3 > > Modified Files: > fortune-firefly.spec > Log Message: > > * Syncing builds Pardon? What? ;) FC-3, FC-4 and FC-5 have reached end-of-life. While you can still modify the files in CVS, you cannot build any packages for those dists anymore. "Syncing builds" is not possible. Plus, I believe your F-7 branch is missing. And you've not synced all the changes in 'devel' to the other branches anyway. > -Release: 2%{?dist} > +Release: 3%{?dist} > +* Mon Jul 09 2007 Karen Pease - 2.1.2.3 > +- Upping tag to sync builds. > + > * Mon May 07 2007 Karen Pease - 2.1.2.2 > - Upping tag to sync builds. From tcallawa at redhat.com Mon Jul 9 16:35:03 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Jul 2007 11:35:03 -0500 Subject: Retiring: compat-wxGTK & compat-wxPythonGTK Message-ID: <1183998903.3489.62.camel@localhost.localdomain> As far as I can tell, nothing in rawhide is dependent on either compat-wxGTK or compat-wxPythonGTK. This fact combined with an open bug on compat-wxPythonGTK conflicting with wxPython (247377) leads me to the conclusion that these compat packages should die in rawhide. Anyone opposed to this? Speak up. Quickly. Remember, this is wxGTK and wxPython 2.4. ~spot From kagesenshi.87 at gmail.com Mon Jul 9 16:38:54 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Tue, 10 Jul 2007 00:38:54 +0800 Subject: Compiz Fusion? In-Reply-To: <468A5B17.1060808@gmail.com> References: <2a28d2ab0706290430v479da702j1d261522e58b7173@mail.gmail.com> <46875E58.3030106@gmail.com> <46879684.8080805@gmail.com> <1183319736.3592.6.camel@tuxhugs> <4688C910.2000503@gmail.com> <4689616A.2020908@gmail.com> <468A5B17.1060808@gmail.com> Message-ID: On 7/3/07, Alphonse Van Assche wrote: > Hikaru Amano a ?crit : > > Issit? .. the howto post in opencompositing.org forum states > > /usr/lib/fglrx/libGL.so.1.2.xlibmesa. > > > > http://forums.opencompositing.org/viewtopic.php?f=51&t=758#p6439 > > I have see that there too but on my box LibGL* files don't contain > .xlibmesa extension. To be sure, I have build the RPM packages from the > ATI installer and no trace of this extension there too, so the libGL > with this extension come probably from packages for another distrib. > > rpm -qlp ATI-* | grep -i libgl on the generated package returns: > /usr/lib/fglrx/libGL.so.1 > /usr/lib/fglrx/libGL.so.1.2 > /usr/lib/fglrx/libGL.so > > Alphonse I just sent these packages for review compiz-bcop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247405 libcompizconfig: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247406 compizconfig-python: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247408 and a RFE for compiz https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247409 -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From rhally at mindspring.com Mon Jul 9 17:29:52 2007 From: rhally at mindspring.com (Richard Hally) Date: Mon, 09 Jul 2007 13:29:52 -0400 Subject: rawhide report: 20070709 changes In-Reply-To: <200707090849.l698nSKw003485@porkchop.devel.redhat.com> References: <200707090849.l698nSKw003485@porkchop.devel.redhat.com> Message-ID: <46927090.3000605@mindspring.com> It looks like the repodata for the i386 rawhide repo is missing? Richard From jkeating at redhat.com Mon Jul 9 17:31:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Jul 2007 13:31:53 -0400 Subject: rawhide report: 20070709 changes In-Reply-To: <46927090.3000605@mindspring.com> References: <200707090849.l698nSKw003485@porkchop.devel.redhat.com> <46927090.3000605@mindspring.com> Message-ID: <200707091331.53620.jkeating@redhat.com> On Monday 09 July 2007 13:29:52 Richard Hally wrote: > It looks like the repodata for the i386 rawhide repo is missing? Yes, the mash process failed for unknown reasons. The kernel was busted anyway. -- 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 debarshi.ray at gmail.com Mon Jul 9 17:45:10 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 9 Jul 2007 23:15:10 +0530 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <1183992841.12137.25.camel@erebor.boston.redhat.com> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> Message-ID: <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> > 1) Jim is getting more involved in Fedora and wants to enable the > updates-testing repository so that he can be involved in testing > updates. Also the disable case here. I think this is already taken care of. Click the checkbutton beside every repository. > 2) John has a local mirror that he prefers to use for getting his Fedora > updates and would like to point directly at it rather than the mirror > list. This can be done by either adding a 'New' repository, or by 'Editing' an exiting repository. > 3) Sue read about some new software that's available from $vendor and > would like to add their repo so that she can install and try it out. > 4) $vendor provides a repo file on their website and would like to have > it be easy for end-users to add that to their configs Do you want a way one can select a RPM which offers repository configuration for $vendor, rather than manually entering the relevant information? > Of these, the first three are all things that are going to be pretty > sensible and fit in with the target audience of pirut. The fourth > really isn't and so it's probably not worth trying to look at Sally's > needs. What is the target audience of Pirut? If we can offer most of the functionality of the CLI through the GUI, and at the same time use reasonable default values and ensure that the advanced settings do not clutter the GUI and intimidate the beginners, we would have a good solution. > * As Rahul said, what's the real use case for making changes but not > saving them? I think that ends up being a bit more of a power-user > thing and probably more confusing than not for pirut First of all the checkbutton is set to 'on' by default, which is what most people would want. However a --enablerepo/--disablerepo like thing can be quite useful at times. Say X has temporarily migrated from his network and can not access any of the upstream mirrors. Now he wants to use Pirut to remove package P. Currently Pirut will simply fail to contact any of the configured repositories and fail. Instead we can give him an oppurtunity to turn off all the upstream repositories on a one-off basis, so that he can start Pirut and remove P. True this feature might be a bit advanced, and we can hide it away under some drop-box called "advanced settings", or something like that. > * The authentication tab seems likely to be a bit of micro-management. > Also, even if there's a good case for the user to want to care, why is > it separate and global rather than per-repo? Especially as the gpgkey > bits are all generally set on a per-repo basis Okay. I took this from Synaptic. Do you want to handle the key management from the 'Edit' dialog? eg., user selects a repository and clicks 'Edit', and then gets an oppurtunity to disable gpgcheck or permanently delete the key. > * What's the difference between Add and Add CDROM? A repo is a repo, > and distinguishing between where they come from is going to be a little > painful. Especially as a repo can have both URLs and a way to access it > via media (add mediaid= to the repo config) True, but since we already know the layout of the Fedora DVD, we can relieve an entry level user from entering the details of the DVD manually. Now that you say so we can also provide a feature in the 'Edit' dialog, whereby the user can chose whether to access a repository through a URL or media. However I need to learn about this mediaid= thing. Don't know much about it. :-) > * What's a channel? It says it's a repository manager but then seems to > be dealing with something that's channels? I took most of the strings from Synaptic. Please suggest something else. "Repositories" would be alright? What I want to convey is that although a GUI tool will be most often used by newbies, we can also make it attractive for non-newbies (say intermediate level) users too. eg., Synaptic does provide a wide range of configuration options, which on hearing may sound intimidating. However the GUI is so designed and the default values are such that it simply works out of the box in most cases, making it an attractive tool for newbies and non-newbies alike. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From valent.turkovic at gmail.com Mon Jul 9 18:20:41 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 9 Jul 2007 20:20:41 +0200 Subject: X woes - can't set the correct resolution no matter what... Message-ID: <64b14b300707091120q2098bb3vc5100787c413b6e7@mail.gmail.com> I hope this is the right list to raise this issue... if not point me in the right direction. I have Fedora Core 6 and by default is choose i810 driver for X. With that driver I had no problem with laptop screen - but when I connected external 19" screen all hell broke loose :) to be a bit poetic. or more to the point: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238747 In my comment #8 you can see that I changed to intel driver, but even that still doesn't work like I expect. I need my external monitor running at it's full resolution of 1280x1024 and desktop also at that resolution. I got desktop running with 1280x1024 but only on a 1024x768 screen resolution - I didn't know that that was even possible! So my deskop acts as with beryl with zoom plugin - I can see only portion on the desktop and the desktop pans as I move my mouse from one corner to the other. I was feeling lucky and tried setting up dual screen setup via system-config-display - that turned to be a big mistake. I got config that wouldn't even work everytime. I got 2 video cards configured - one with intel and other with vesa driver ?!? So please give me your insight on how to make X behave properly, just dont rtfm me, thank you. Del.icio.us links, url's and any other piece of info is greatly appreciated. Do you have some concrete info regarding fc6+X+intel driver ? I'll post any info you need about my hardware, logs, etc... just ask. Thank you in advance, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From notting at redhat.com Mon Jul 9 18:21:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Jul 2007 14:21:27 -0400 Subject: rawhide report: 20070708 changes In-Reply-To: <1183901490.3489.48.camel@localhost.localdomain> References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> <4690B500.7070504@hhs.nl> <200707080718.35905.jkeating@redhat.com> <1183901490.3489.48.camel@localhost.localdomain> Message-ID: <20070709182127.GB9219@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > On Sun, 2007-07-08 at 07:18 -0400, Jesse Keating wrote: > > maybe. Next week I really need to get the individual mail part > > working if it > > isn't already. Not only do we put the list in these reports, but > > we're > > supposed to be mailing the owners directly with their individual > > breakages. > > If they ignore those, they'll most likely ignore a bug too. > > Pretty sure this is not working, as Hans's bug was the first I'd heard > of an issue with one of my packages. Mail from the chroot is getting lost, due to vagaries of using the system mailer. spam-o-matic needs patched to be smarter. Bill From notting at redhat.com Mon Jul 9 18:26:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Jul 2007 14:26:14 -0400 Subject: LSB init scripts and NETWORKING=no && exit 0 In-Reply-To: <200707081704.09237.ville.skytta@iki.fi> References: <200707081704.09237.ville.skytta@iki.fi> Message-ID: <20070709182614.GD9219@nostromo.devel.redhat.com> Ville Skytt? (ville.skytta at iki.fi) said: > One more question related to LSB init scripts: > > A commonly found current approach in init scripts for services that require > networking to be up is: > > # Source networking configuration. > . /etc/sysconfig/network > # Check that networking is up. > [ "$NETWORKING" = "no" ] && exit 0 > > Silently exiting with 0 no matter which action was requested does not look > like something expected of LSB compliant init scripts. > > Actually, all of 1) silent exit and 2) the zero exit value and 3) the way "is > networking up?" is checked seem questionable to me. Anyone have ideas for > better approaches to this? NETWORKING=no means 'networking has never been configured on this box'. Frankly, I'd nuke the whole section - it's rather pointless, and will not be set on any normal machine. (The comment is misleading.) Bill From katzj at redhat.com Mon Jul 9 18:31:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Jul 2007 14:31:34 -0400 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> Message-ID: <1184005894.12137.62.camel@erebor.boston.redhat.com> On Mon, 2007-07-09 at 23:15 +0530, Debarshi 'Rishi' Ray wrote: > > 1) Jim is getting more involved in Fedora and wants to enable the > > updates-testing repository so that he can be involved in testing > > updates. Also the disable case here. > > I think this is already taken care of. Click the checkbutton beside > every repository. You're missing my point here... the idea _ISN'T_ "how does the UI mock up match with the use cases". It's more "determine the set of use cases. Based on them, work on the actual interface". You _start_ with the use cases, not the mockup. > > 2) John has a local mirror that he prefers to use for getting his Fedora > > updates and would like to point directly at it rather than the mirror > > list. > > This can be done by either adding a 'New' repository, or by 'Editing' > an exiting repository. Again... > > 3) Sue read about some new software that's available from $vendor and > > would like to add their repo so that she can install and try it out. > > 4) $vendor provides a repo file on their website and would like to have > > it be easy for end-users to add that to their configs > > Do you want a way one can select a RPM which offers repository > configuration for $vendor, rather than manually entering the relevant > information? If the vendor is providing it via an RPM, then the user just installs the RPM. They can even do so right from the browser. This is more the case where they say "the repo is at http://some.site.com/path/to/repo" and you then have to go configure it yourself. > > Of these, the first three are all things that are going to be pretty > > sensible and fit in with the target audience of pirut. The fourth ^^^ erm, the last should be the fifth. And the fourth is valid as well. > > really isn't and so it's probably not worth trying to look at Sally's > > needs. > > What is the target audience of Pirut? If we can offer most of the > functionality of the CLI through the GUI, and at the same time use > reasonable default values and ensure that the advanced settings do not > clutter the GUI and intimidate the beginners, we would have a good > solution. The idea with pirut has never been to provide "the functionality of the CLI wrapped up in a GUI". Rather, we want to expose the things which are good for the majority of users. If you need every bit of functionality of the CLI, then really, you're probably a better target user for the CLI not pirut. > > * As Rahul said, what's the real use case for making changes but not > > saving them? I think that ends up being a bit more of a power-user > > thing and probably more confusing than not for pirut > > First of all the checkbutton is set to 'on' by default, which is what > most people would want. However a --enablerepo/--disablerepo like > thing can be quite useful at times. > > Say X has temporarily migrated from his network and can not access any > of the upstream mirrors. Now he wants to use Pirut to remove package > P. Currently Pirut will simply fail to contact any of the configured > repositories and fail. Instead we can give him an oppurtunity to turn > off all the upstream repositories on a one-off basis, so that he can > start Pirut and remove P. > > True this feature might be a bit advanced, and we can hide it away > under some drop-box called "advanced settings", or something like > that. So, why do this in the repository editor? I'd argue the _better_ way to handle this is: a) Use with what's installed should be fixed to be okay if you don't have any repos set up/accessible. This is pretty straight-forward to do b) If a single repo fails to set up (or multiple, where n < total number of repos), allow a way to do a temporary disable then. _Not_ to shoe-horn it in as something associated with repository editing. > > * The authentication tab seems likely to be a bit of micro-management. > > Also, even if there's a good case for the user to want to care, why is > > it separate and global rather than per-repo? Especially as the gpgkey > > bits are all generally set on a per-repo basis > > Okay. I took this from Synaptic. Do you want to handle the key > management from the 'Edit' dialog? eg., user selects a repository and > clicks 'Edit', and then gets an oppurtunity to disable gpgcheck or > permanently delete the key. I don't know if that's interesting or not. Maybe. Maybe not. Definitely more reasonable that way than as its own high level thing > > * What's the difference between Add and Add CDROM? A repo is a repo, > > and distinguishing between where they come from is going to be a little > > painful. Especially as a repo can have both URLs and a way to access it > > via media (add mediaid= to the repo config) > > True, but since we already know the layout of the Fedora DVD, we can > relieve an entry level user from entering the details of the DVD > manually. But why should it be separate at the top level there? Adding a repository can be an easy thing to do. Hell, the Fedora DVD should be set up _by default_ to be accessed as the core repo, but that requires someone to write some code so that we can do a reasonable job of writing out repos at install time. > Now that you say so we can also provide a feature in the 'Edit' > dialog, whereby the user can chose whether to access a repository > through a URL or media. However I need to learn about this mediaid= > thing. Don't know much about it. :-) It's part of how yum at the API level now can really handle media. > > * What's a channel? It says it's a repository manager but then seems to > > be dealing with something that's channels? > > I took most of the strings from Synaptic. Please suggest something > else. "Repositories" would be alright? Probably. > What I want to convey is that although a GUI tool will be most often > used by newbies, we can also make it attractive for non-newbies (say > intermediate level) users too. eg., Synaptic does provide a wide range > of configuration options, which on hearing may sound intimidating. > However the GUI is so designed and the default values are such that it > simply works out of the box in most cases, making it an attractive > tool for newbies and non-newbies alike. Lots of options is _not_ the answer to making a tool attractive to "non-newbies". Jeremy From debarshi.ray at gmail.com Mon Jul 9 18:57:46 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 10 Jul 2007 00:27:46 +0530 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <1184005894.12137.62.camel@erebor.boston.redhat.com> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> <1184005894.12137.62.camel@erebor.boston.redhat.com> Message-ID: <3170f42f0707091157t7f538a13yd3b43a725e58cf61@mail.gmail.com> > You're missing my point here... the idea _ISN'T_ "how does the UI mock > up match with the use cases". It's more "determine the set of use > cases. Based on them, work on the actual interface". You _start_ with > the use cases, not the mockup. I agree. I was just checking out those use-cases, which have been implemented. By the way would it be better if we listed out the use-cases on some Web page, since a mailing list does not seem to be a very good way to maintain such a document? If yes, should I do it on the Fedora wiki, or my blog is good enough? > If the vendor is providing it via an RPM, then the user just installs > the RPM. They can even do so right from the browser. This is more the > case where they say "the repo is at http://some.site.com/path/to/repo" > and you then have to go configure it yourself. So a 'Add' dialog with: Repo ID: Repo Name: Repo Baseurl: Mirrorlist: ..etc.. ....would be fine? > 4) $vendor provides a repo file on their website and would like to have > it be easy for end-users to add that to their configs This seems to be interesting. I can think of 2 options: a. Provide a way by which the user can simply copy-paste the URL of the RPM published on the site, and the tool automatically handles the rest. b. The user downloads the RPM and there is a way in which one can ask Pirut to do: $ yum localinstall .rpm > So, why do this in the repository editor? I'd argue the _better_ way to > handle this is: > a) Use with what's installed should be fixed to be okay if you don't > have any repos set up/accessible. This is pretty straight-forward to do > b) If a single repo fails to set up (or multiple, where n < total number > of repos), allow a way to do a temporary disable then. Fine enough. Let me see if I can do something about this. :-) > But why should it be separate at the top level there? Adding a > repository can be an easy thing to do. Hell, the Fedora DVD should be > set up _by default_ to be accessed as the core repo, but that requires > someone to write some code so that we can do a reasonable job of writing > out repos at install time. What if someone deletes the configuration file corresponding to the DVD? Wouldn't a single click method to bring it back be better? Or you want the 'Add' dialog to have an option distinguishing between the Fedora DVD and other repositories? >>> * What's a channel? It says it's a repository manager but then seems to >>> be dealing with something that's channels? >> I took most of the strings from Synaptic. Please suggest something >> else. "Repositories" would be alright? > Probably. If no one objects to this, then I am going to replace "Channels" by "Repositories". Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From notting at redhat.com Mon Jul 9 19:00:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Jul 2007 15:00:23 -0400 Subject: Parallel Booting In-Reply-To: <20070706213138.GA8245@devserv.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <1183755347.15795.5.camel@neutron.verbum.private> <20070706213138.GA8245@devserv.devel.redhat.com> Message-ID: <20070709190023.GC10904@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > That isn't to say the kernel is perfect and there is a ton of optimising > work still going on, different scheduling algorithms and the like but > most of the slowness is from user space - some from tools, some from > combinations of tools and kernel (eg linker and paging patterns) and a lot > of it from sheer stupid clueless design of applications and especially > of GUI libraries. Just as a data point, in my 57-second bootup timings, a full 10.5 seconds of that is before init - so there is plenty of places to improve all around. Bill From notting at redhat.com Mon Jul 9 19:03:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Jul 2007 15:03:10 -0400 Subject: Parallel Booting In-Reply-To: <468E6B3C.6070100@redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <468E6B3C.6070100@redhat.com> Message-ID: <20070709190310.GD10904@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > With: > > S12syslog > S13ip6tables > S13iptables > S14network > S25netfs > S26auditd > S26messagebus > S27setroubleshoot > S55sshd > S98haldaemon > S99local > > /etc/rc.d/rc takes: > 8.5s in normal mode > 6s in parallel startup Did you add all the proper dependencies? >> So, for all this work, we get a 0.6%-1.1% speedup. > > so for me thats 140% speedup :) 2.5 seconds is 140%? I can try a more minimal setup, but I think we should be concentrating on the normal case. > > Oh, and we get >> 62 AVCs from SELinux in the process. What's the point of this again? > > for that, I now have a fix. Got code? I'm interested in how much time is lost in the audit/setroubleshoot logger logging the AVCs. >>> - how would this be useful for the case where facilities that are >>> provided >>> are determined at runtime (say, NetworkManager providing $network >>> instead >>> of /etc/init.d/network, or $remote_fs being provided by either >>> rc.sysinit >>> or /etc/init.d/netfs, depending on configuration). > > yep, tbd > > >> Similarly, you may >>> want a meta-dependency for 'authorization available', which would be >>> at different times depending on whether or not you're using local >>> passwords, KRB5, etc. > > yep, tbd > >>> - does this work with dbus system activation? > > yep, tbd > >> I also don't see how it handles either of these. > > Which system does fullfill all of these requirements yet? None, yet. But from looking at the prcsys architecture I'm not sure *how* it would do any of those - it seems to be designed in such a way to make that hard. Bill From marcel at mesa.nl Mon Jul 9 20:05:14 2007 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Mon, 9 Jul 2007 22:05:14 +0200 Subject: kde startup problems Message-ID: <20070709200514.GA15574@joshua.mesa.nl> Hello, since last week i seem to have kde startup problems. I get severel popup windows saying things like: 'Malformed URL file:///home/marcel/Desktop' 'Could not find mime type application/octet-stream' 'no mime types installed' I had to re-add Kmenu to the taskbar because it dissapeared... I reinstalled all kde rpms, but the problem persists, so I don't know where to look to fix this. Can anybody help? Thanks -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From jaroslav at aster.pl Mon Jul 9 20:11:15 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Mon, 9 Jul 2007 22:11:15 +0200 Subject: Parallel Booting In-Reply-To: <468E6B3C.6070100@redhat.com> References: <467BE85E.4070807@redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <468E6B3C.6070100@redhat.com> Message-ID: <200707092211.22925.jaroslav@aster.pl> Hi, Friday 06 of July 2007 18:18:04 Harald Hoyer napisa?(a): >(...) > With: > > S12syslog > (...) > S99local > > /etc/rc.d/rc takes: > 8.5s in normal mode > 6s in parallel startup > > > so for me thats 140% speedup :) > Hmm..... ((8.5-6)/8.5)*100 = 29.4% or am I missing sth? -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From poelstra at redhat.com Mon Jul 9 20:16:53 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 09 Jul 2007 13:16:53 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUL-09 Message-ID: <469297B5.2020700@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-JUL-09 Please make corrections and clarifications to the wiki page. == Composes in the colo == * downsides are that it will: 1. probably take longer to complete the compose 1. certainly take longer to get the compose into the hands of our testing lab in Raleigh 1. take longer to get onto the machines in Westford * other benefits most likely outweigh these issues. * f13 is ''single point of failure'' for doing composes--everything is dependent on him Decision: Releng will continue investigations into composing trees within the colo; potentially composing Test1 there. == Fedora Signing Server == * f13 has not received any feedback since last meeting (some gave it before the meeting)--moving proposal to the ReleaseEngineering/ space as it's new home == Open Discussion == * jwb--have we documented the "you need to email rel-eng to get packages in the buildroot" thing? * jeremy--sounds like something worth adding to the update doc. feel free to add :) * notting--we were going to switch that based on bodhi changes with an alert for packages built against unpushed things * f13--but until we switch it, we need it documented somewhere. Once bodhi can prevent an update from going out that was built against an unreleased update, we can make the buildroot selfupdate. * jeremy--note that may need to be overridable, otherwise, I have a _great_ way to keep security updates from being able to go out :) *f13--we do need to be able to override it. Decision: No decision made From jaroslav at aster.pl Mon Jul 9 20:18:21 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Mon, 9 Jul 2007 22:18:21 +0200 Subject: kde startup problems In-Reply-To: <20070709200514.GA15574@joshua.mesa.nl> References: <20070709200514.GA15574@joshua.mesa.nl> Message-ID: <200707092218.21278.jaroslav@aster.pl> Monday 09 of July 2007 22:05:14 Marcel J.E. Mol napisa?(a): > Hello, > since last week i seem to have kde startup problems. > I get severel popup windows saying things like: > > 'Malformed URL file:///home/marcel/Desktop' > > 'Could not find mime type application/octet-stream' > > 'no mime types installed' > > I had to re-add Kmenu to the taskbar because it dissapeared... > > I reinstalled all kde rpms, but the problem persists, so I don't > know where to look to fix this. > > Can anybody help? > Have You tried starting KDE as other user? Or alternatively - temporarily renaming ~/.kdrc file and ~/.kde/ dir? -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Mon Jul 9 21:03:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Jul 2007 16:03:48 -0500 Subject: Please Read: Need help in replacing music in Fedora package Message-ID: <1184015028.3490.19.camel@localhost.localdomain> Hello interweb. I need help. (This is going out to a few places, as to hopefully have it picked up) One of my Fedora packages (rocksndiamonds) has a slight problem. Turns out that some of its audio files are straight copies of music which was used without permission. Full details are here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245435 Rather than pull the game out of Fedora entirely, (it is pretty fun, and the music is the only real blocker) I'd like to replace the music with freely distributable music. So, this could be your big chance! Are you a musician? Is someone you know a musician? Would you be willing to give us some music under a Creative Commons license (Attribution or Attribution-ShareAlike only)? The music we need replacement for is: "Alchemy" by Ian Boddy, from "Drive" (emailed Ian) "Czardasz" by Robert Pieculewicz, from "Czardasz" (emailed Robert, now known as "Steve Allen") "The Chase" by Propaganda, from "A Secret Wish" (could not find contact info for Propaganda) "Twilight Painter" by Tangerine Dream, from "Heartbreakers" (emailed Eastgate Music & Media LTD, Management for Tangerine Dream) "21st Century Common Man" by Tangerine Dream, from "Tyger" (emailed Eastgate Music & Media LTD, Management for Tangerine Dream) "Voyager" by The Alan Parsons Project, from "Pyramid" (emailed permissions at the-alan-parsons-project.com) "Network 23" by Tangerine Dream, from "Exit" (emailed Eastgate Music & Media LTD, Management for Tangerine Dream) I've emailed the contact points for the artists (when I could find them), but I do not expect that they will be willing to permit the sound sample use. We don't need whole songs, just short sound samples that will endlessly loop while the game plays. The clips do not need to be long, the longest one in the above list is 14 seconds. The format needed is .wav. If you're willing to help, please email me (tcallawa at redhat.com). Without replacing this music, we'll have to remove this game from the Fedora package collection. Thanks in advance, ~spot From marcel at mesa.nl Mon Jul 9 21:10:05 2007 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Mon, 9 Jul 2007 23:10:05 +0200 Subject: kde startup problems In-Reply-To: <200707092218.21278.jaroslav@aster.pl> References: <20070709200514.GA15574@joshua.mesa.nl> <200707092218.21278.jaroslav@aster.pl> Message-ID: <20070709211005.GB15574@joshua.mesa.nl> On Mon, Jul 09, 2007 at 10:18:21PM +0200, Jaroslaw Gorny wrote: > Monday 09 of July 2007 22:05:14 Marcel J.E. Mol napisa?(a): > > Hello, > > since last week i seem to have kde startup problems. > > I get severel popup windows saying things like: > > > > 'Malformed URL file:///home/marcel/Desktop' > > > > 'Could not find mime type application/octet-stream' > > > > 'no mime types installed' > > > > I had to re-add Kmenu to the taskbar because it dissapeared... > > > > I reinstalled all kde rpms, but the problem persists, so I don't > > know where to look to fix this. > > > > Can anybody help? > > > > Have You tried starting KDE as other user? Or alternatively - temporarily > renaming ~/.kdrc file and ~/.kde/ dir? I did rename .kde but it did not help. I also removed ~/.mailcap en ~/.mimetypes. I did not rename the .kdrc but it only contains font definitions. -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From opensource at till.name Tue Jul 10 00:55:47 2007 From: opensource at till.name (Till Maas) Date: Tue, 10 Jul 2007 02:55:47 +0200 Subject: Parallel Booting In-Reply-To: <200707092211.22925.jaroslav@aster.pl> References: <467BE85E.4070807@redhat.com> <468E6B3C.6070100@redhat.com> <200707092211.22925.jaroslav@aster.pl> Message-ID: <200707100255.57096.opensource@till.name> On Mo Juli 9 2007, Jaroslaw Gorny wrote: > Friday 06 of July 2007 18:18:04 Harald Hoyer napisa?(a): > >(...) > > With: > > > > S12syslog > > (...) > > S99local > > > > /etc/rc.d/rc takes: > > 8.5s in normal mode > > 6s in parallel startup > > > > > > so for me thats 140% speedup :) > > Hmm..... > ((8.5-6)/8.5)*100 = 29.4% You calculated the the reduction of boottime. I would calculate the speedup this way: Bootspeed = 1/(Time to boot) normal speed = 10/85 parralel startup speed = 10/60 Speedup in percent: 10/60 / 10/85 * 100 = 141.67 % Regards, Till From seandarcy2 at gmail.com Mon Jul 9 23:53:19 2007 From: seandarcy2 at gmail.com (sean) Date: Mon, 09 Jul 2007 19:53:19 -0400 Subject: rawhide report: 20070708 changes In-Reply-To: References: <200707080929.l689TNJ0016217@porkchop.devel.redhat.com> Message-ID: darrell pfeifer wrote: > On 7/8/07, sean wrote: >> Something here broke the window manager in gnome. No window >> frame, can't resize,etc. >> >> kde and xfce work. >> >> I don't even know what to file against - it all looks harmless. >> >> Anybody else?? >> > > Are you running with compiz? I get that problem, but as a workaround I > turn off desktop effects and then turn them back on again right away. > > darrell Nope. Just X. Worked just fine until yesterday. sean From tmus at tmus.dk Tue Jul 10 02:33:28 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 10 Jul 2007 00:33:28 -0200 Subject: LSB init scripts and NETWORKING=no && exit 0 In-Reply-To: <200707082315.56113.ville.skytta@iki.fi> References: <200707081704.09237.ville.skytta@iki.fi> <20070708195239.GA22763@osiris.silug.org> <200707082315.56113.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > On Sunday 08 July 2007, Steven Pritchard wrote: >> On Sun, Jul 08, 2007 at 05:04:08PM +0300, Ville Skytt? wrote: >>> Actually, all of 1) silent exit and 2) the zero exit value and 3) the way >>> "is networking up?" is checked seem questionable to me. Anyone have >>> ideas for better approaches to this? >> Isn't that just supposed to be checking if networking is enabled at >> all? If that is "no", presumably we don't even have the loopback >> interface up. > > Hard to tell, but that's just one bit of the puzzle. To elaborate on the > issues: > > a) Why doesn't it output an error message saying that the service requires > networking but networking doesn't seem to be available? > > b) Why is the exit status 0, indicating success? > > c) Why is the check done before doing anything else instead of being done eg. > only in the start (and restart, reload and friends if they're not implemented > using start) action? That and b) will result in eg. the status action > returning 0, indicating in LSB terms "program is running or service is OK" > which it most likely is not if it requires networking and networking isn't > up. > > d) Why does it just read something from a config file instead of actually > checking whether networking is up? Not sure if that check is necessary in > the first place - could just let the service fail. Maybe it's used/useful > for optimization purposes and/or to provide a hook for a more descriptive > error message than what the failing service would output. > It might be a good idea to start looking at a nice way to handle network service deps. This could easily be cleaned at the same time. /Thomas From buildsys at redhat.com Tue Jul 10 04:30:18 2007 From: buildsys at redhat.com (Build System) Date: Tue, 10 Jul 2007 00:30:18 -0400 Subject: rawhide report: 20070710 changes Message-ID: <200707100430.l6A4UILR019053@porkchop.devel.redhat.com> From tla at rasmil.dk Tue Jul 10 07:30:24 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 10 Jul 2007 09:30:24 +0200 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <3170f42f0707091157t7f538a13yd3b43a725e58cf61@mail.gmail.com> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> <1184005894.12137.62.camel@erebor.boston.redhat.com> <3170f42f0707091157t7f538a13yd3b43a725e58cf61@mail.gmail.com> Message-ID: <46933590.2040407@rasmil.dk> Debarshi 'Rishi' Ray wrote: >> You're missing my point here... the idea _ISN'T_ "how does the UI mock >> up match with the use cases". It's more "determine the set of use >> cases. Based on them, work on the actual interface". You _start_ with >> the use cases, not the mockup. > > I agree. I was just checking out those use-cases, which have been > implemented. > > By the way would it be better if we listed out the use-cases on some > Web page, since a mailing list does not seem to be a very good way to > maintain such a document? If yes, should I do it on the Fedora wiki, > or my blog is good enough? A wiki page would be a good idea. 1. List use cases. A) Jim is getting more involved in Fedora and wants to enable the updates-testing repository so that he can be involved in testing updates. Also the disable case here. 2. Categorize the use cases (novice, power users) A) novice. 3. Map cases to features. A) Enable/disable repositories. 4. Select the target audience for the application (Novice ?, Power User? or both) 5. Select the features to implement based on target audience. 6. Do a mockup 7. Code the tool. > >> If the vendor is providing it via an RPM, then the user just installs >> the RPM. They can even do so right from the browser. This is more the >> case where they say "the repo is at http://some.site.com/path/to/repo" >> and you then have to go configure it yourself. > > So a 'Add' dialog with: > Repo ID: > Repo Name: > Repo Baseurl: > Mirrorlist: > ..etc.. > ....would be fine? > >> 4) $vendor provides a repo file on their website and would like to have >> it be easy for end-users to add that to their configs > > This seems to be interesting. I can think of 2 options: > a. Provide a way by which the user can simply copy-paste the URL of > the RPM published on the site, and the tool automatically handles the > rest. > b. The user downloads the RPM and there is a way in which one can ask > Pirut to do: > $ yum localinstall .rpm In system-config-repo i have implemented a feature where you can paste and url to to repository rpm or a repo file and then it is getting downloaded and installed after doing some checks and prints some warnings, because the is some security issues by adding new repos. Tim From pvrabec at redhat.com Tue Jul 10 08:32:39 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Tue, 10 Jul 2007 10:32:39 +0200 Subject: rsyslog in f8? In-Reply-To: <200707031446.09235.jkeating@redhat.com> References: <20070703124100.2e704168@ghistelwchlohm.scrye.com> <200707031446.09235.jkeating@redhat.com> Message-ID: <46934427.4070508@redhat.com> Jesse Keating wrote: > On Tuesday 03 July 2007 14:41:00 Kevin Fenzi wrote: >> The rsyslog package has been approved and is ready to enter the >> collection. I just thought I would ask if anyone has any issues or >> concerns with switching to rsyslog for default system logger in f8? >> >> See: >> >> http://fedoraproject.org/wiki/Releases/FeatureRsyslog >> and >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243831 >> >> Would it be helpfull to get it pushed out for f7/devel without any >> Obsoletes first so folks can test it? Or should we just replace >> sysklogd in devel right off? > > Instead of looking at this as a 'new default logger', perhaps it would be > better to look at this as a 'rsyslogd is obsoleting sysklogd'. Think of it > purely within the scope of one package is replacing the other, due to things > like sysklogd being dead upstream. In that context, we can do the replacement > now and be happy. > > It's a different subject as to if we want to "switch the default logger" or > perhaps "switch to different logging options by default", and that could use > some discussion with various folks. However that is an aside to the pure > technical thing of rsyslogd is replacing sysklogd. Jesse, does it mean that init,conf,logrot. and sysconf file should be named same? > > From debarshi.ray at gmail.com Tue Jul 10 08:37:05 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 10 Jul 2007 14:07:05 +0530 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: <46933590.2040407@rasmil.dk> References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> <1184005894.12137.62.camel@erebor.boston.redhat.com> <3170f42f0707091157t7f538a13yd3b43a725e58cf61@mail.gmail.com> <46933590.2040407@rasmil.dk> Message-ID: <3170f42f0707100137q420d0b5j900eaff4842e1a1a@mail.gmail.com> > > By the way would it be better if we listed out the use-cases on some > > Web page, since a mailing list does not seem to be a very good way to > > maintain such a document? If yes, should I do it on the Fedora wiki, > > or my blog is good enough? > A wiki page would be a good idea. Is http://fedoraproject.org/wiki/Usability/Objectives/Pirut a good place to use? If yes, what about the existing content? > > This seems to be interesting. I can think of 2 options: > > a. Provide a way by which the user can simply copy-paste the URL of > > the RPM published on the site, and the tool automatically handles the > > rest. > > b. The user downloads the RPM and there is a way in which one can ask > > Pirut to do: > > $ yum localinstall .rpm > In system-config-repo i have implemented a feature where you can paste > and url to to repository rpm or a repo file > and then it is getting downloaded and installed after doing some checks > and prints some warnings, because the is some security > issues by adding new repos. Nice. I shall have a look into it. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From hughsient at gmail.com Tue Jul 10 09:12:18 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jul 2007 10:12:18 +0100 Subject: Video and Keymap Quirks Message-ID: <1184058738.2249.16.camel@work> You might have heard about the HAL quirk site [1] for suspend and resume quirks before, but now we are collecting keymap quirks to make the special buttons such as multimedia keys and Fn function keys do the right thing. I've blogged about this yesterday[2], but I am asking for patches from the fedora development community. In this way we can make laptop special keys "just work" for Fedora 8. So, if you've ever seen messages like: atkbd.c: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0). atkbd.c: Use 'setkeycodes e017 keycode' to make it known. or you are using a < 2 year old sony or any thinkpad, please read the links and help where you can. The whole process is pretty straightforward, but please email me (off list) if you get stuck and I'll add more explanation where it's needed. With a little help, we can make F8 on a laptop seriously rock [3]. Thanks! Richard Hughes [1] http://people.freedesktop.org/~hughsient/quirk/ [2] http://hughsient.livejournal.com/29730.html [3] http://fedoraproject.org/wiki/Releases/FeatureLaptopImprovements From kevin.kofler at chello.at Tue Jul 10 10:15:23 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 10 Jul 2007 10:15:23 +0000 (UTC) Subject: Pirut: Edit -> Repositories mock-up. References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> <1184005894.12137.62.camel@erebor.boston.redhat.com> Message-ID: Jeremy Katz redhat.com> writes: > You're missing my point here... the idea _ISN'T_ "how does the UI mock > up match with the use cases". It's more "determine the set of use > cases. Based on them, work on the actual interface". You _start_ with > the use cases, not the mockup. Except that the "mockup" is inspired by an existing UI (Synaptic) which has been used successfully for years, and which IMHO is one of the best (if not the best) package management UIs out there. > The idea with pirut has never been to provide "the functionality of the > CLI wrapped up in a GUI". Rather, we want to expose the things which > are good for the majority of users. If you need every bit of > functionality of the CLI, then really, you're probably a better target > user for the CLI not pirut. Why artificially restrict the target user base for Pirut this way? Wouldn't it be better if Pirut was useful for everyone? Right now it really isn't, and Synaptic, Yumex or smart --gui are much better options for experienced users. > Lots of options is _not_ the answer to making a tool attractive to > "non-newbies". I also disagree with the assertion. Configurability is an important feature for power users. This is working well for KDE, Synaptic and many other software packages. Another method of dealing with the different requirements of new and experienced users is to do what Firefox does: present a basic UI by default, but make it extensible by dozens of extensions. The yum CLI also uses this design to some extent. I personally really dislike this though, both because hunting down extensions/plugins is a pain (much more than checking an option somewhere) and because some of the functionality provided by the extensions or plugins should really be on by default (and able to be disabled by experienced users), take yum-skip-broken as an example. But IMHO even this design would be an improvement over the current Pirut. Kevin Kofler From trond.danielsen at gmail.com Tue Jul 10 10:25:46 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Tue, 10 Jul 2007 12:25:46 +0200 Subject: Video and Keymap Quirks In-Reply-To: <1184058738.2249.16.camel@work> References: <1184058738.2249.16.camel@work> Message-ID: <409676c70707100325h486bb37fye2123b794bb3718e@mail.gmail.com> 2007/7/10, Richard Hughes : > You might have heard about the HAL quirk site [1] for suspend and resume > quirks before, but now we are collecting keymap quirks to make the > special buttons such as multimedia keys and Fn function keys do the > right thing. > > I've blogged about this yesterday[2], but I am asking for patches from > the fedora development community. In this way we can make laptop special > keys "just work" for Fedora 8. > > So, if you've ever seen messages like: > > atkbd.c: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0). > atkbd.c: Use 'setkeycodes e017 keycode' to make it known. Hi, the special keys on my laptop (Asus S5A) generates ACPI events, and I wonder if you plan to make the keymap quirks support these too? Regards, -- Trond Danielsen From hughsient at gmail.com Tue Jul 10 10:36:43 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jul 2007 11:36:43 +0100 Subject: Video and Keymap Quirks In-Reply-To: <409676c70707100325h486bb37fye2123b794bb3718e@mail.gmail.com> References: <1184058738.2249.16.camel@work> <409676c70707100325h486bb37fye2123b794bb3718e@mail.gmail.com> Message-ID: <1184063803.2249.34.camel@work> On Tue, 2007-07-10 at 12:25 +0200, Trond Danielsen wrote: > the special keys on my laptop (Asus S5A) generates ACPI events, and I > wonder if you plan to make the keymap quirks support these too? That's the plan. I just need to get my hands on an ASUS laptop so I can do the required infrastructure work. If anyone has some time on IRC and doesn't mind giving me root ssh on a laptop I could do it remotely, but I just takes 10x the time. Richard. From debarshi.ray at gmail.com Tue Jul 10 10:40:50 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 10 Jul 2007 16:10:50 +0530 Subject: Pirut: Edit -> Repositories mock-up. In-Reply-To: References: <3170f42f0707080838m7536b542t3416e4a69e387fd@mail.gmail.com> <1183992841.12137.25.camel@erebor.boston.redhat.com> <3170f42f0707091045j23adc169hcfa716f83046608@mail.gmail.com> <1184005894.12137.62.camel@erebor.boston.redhat.com> Message-ID: <3170f42f0707100340l21debc85hcec27dd71c44ae8c@mail.gmail.com> > Except that the "mockup" is inspired by an existing UI (Synaptic) which has > been used successfully for years, and which IMHO is one of the best (if not the > best) package management UIs out there. I like Synaptic a lot too, but I also agree with some of Jeremy's suggestions. eg., replacing "channels" with "repositories", etc.. > Why artificially restrict the target user base for Pirut this way? Wouldn't it > be better if Pirut was useful for everyone? Right now it really isn't, and > Synaptic, Yumex or smart --gui are much better options for experienced users. Ack. Pirut is also often hard for beginners or intermediate users. There are people who know some of the intricate configuration details, but do not want to use 'vi' or 'emacs' to do the stuff. I feel that the number of such users is much more than the abolute newbies or super geeks. > Another method of dealing with the different requirements of new and > experienced users is to do what Firefox does: present a basic UI by default, > but make it extensible by dozens of extensions. Ack. Use reasonable defaults and provide means to alter them, taking enough care not too clutter the GUI and confuse the end-user (need not be an absolute newbie). eg., the advanced configuration can be hidden in a drop-down box or separate tab, etc.. > This is working well for KDE, Synaptic and many other software packages. Well KDE is often bashed for too much configurability, but Synaptic is used by an enormous number of Ubuntu users on a GNOME desktop including relative newcomers. /me thanks everyone for their feedback Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From rjones at redhat.com Tue Jul 10 10:43:34 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 10 Jul 2007 11:43:34 +0100 Subject: Virtualization things. In-Reply-To: <698534.53803.qm@web52401.mail.re2.yahoo.com> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> Message-ID: <469362D6.60907@redhat.com> Otto Rey wrote: > - Is somebody working on Virtualization (KVM + QEMU) Performance? > Maybe Upstream? Some time ago kqemu (qemu accelerator) was released > under GPL 2 license. Any plans to include in fedora? Or it is > already included/merged under qemu name? I can't find anything about kqemu & its status w.r.t. the upstream Linux kernel. KVM is in the upstream & Fedora kernels, and uses QEMU code to do device emulation. Of course, that requires that your hardware supports virtualization, but that will become increasingly common in the next year or two. For performance issues with KVM you should ask upstream (eg. on kvm-devel mailing list, https://lists.sourceforge.net/lists/listinfo/kvm-devel). > - It is posible to include VirtualBox OSE (Open Source Edition > - GPL v2) in Fedora repo's? Any problem with Legal Stuff? VirtualBox is based on QEMU, right? Can you tell us what features it has that makes it distinctive? (I mean in the free version, not interested in proprietary features). There's a project to abstract away the differences between virtualisation technologies so that, for example, the same command line and graphical tools can be used to manage Xen, QEMU, KVM (so far, others coming later). Website: http://libvirt.org/ Mailing list: http://www.redhat.com/mailman/listinfo/libvir-list Graphical tool: http://virt-manager.et.redhat.com/ Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From opensource at till.name Tue Jul 10 11:02:23 2007 From: opensource at till.name (Till Maas) Date: Tue, 10 Jul 2007 13:02:23 +0200 Subject: Virtualization things. In-Reply-To: <469362D6.60907@redhat.com> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> <469362D6.60907@redhat.com> Message-ID: <200707101302.25470.opensource@till.name> On Di Juli 10 2007, Richard W.M. Jones wrote: > VirtualBox is based on QEMU, right? Can you tell us what features it > has that makes it distinctive? (I mean in the free version, not > interested in proprietary features). it uses Code from QEMU but afaik they use their own approach to virtualization, which may be faster. Also currently the GUI works a lot better than virt-manager for me. It will become more interesting, when it supports a snapshot tree and cloning. Currently it supports only linear snapshots. Also, you can run vmware Images directly with the current version, but maybe QEMU can this, too. If you want to try it, I can provide you a working srpm for the current version. There are also two big disadvantages in VirtualBox, imho. One is they use strange build system, that has no stable releases. And the other is, that there seems to be not "install" target to install it properly in a system. > There's a project to abstract away the differences between > virtualisation technologies so that, for example, the same command line > and graphical tools can be used to manage Xen, QEMU, KVM (so far, others > coming later). > > Website: http://libvirt.org/ > Mailing list: http://www.redhat.com/mailman/listinfo/libvir-list > Graphical tool: http://virt-manager.et.redhat.com/ The idea is imho great, but for me with qemu it does not work properly. Regards, Till From j.w.r.degoede at hhs.nl Tue Jul 10 11:31:08 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Jul 2007 13:31:08 +0200 Subject: Video and Keymap Quirks In-Reply-To: <1184058738.2249.16.camel@work> References: <1184058738.2249.16.camel@work> Message-ID: <46936DFC.4090904@hhs.nl> Richard Hughes wrote: > You might have heard about the HAL quirk site [1] for suspend and resume > quirks before, but now we are collecting keymap quirks to make the > special buttons such as multimedia keys and Fn function keys do the > right thing. > > I've blogged about this yesterday[2], but I am asking for patches from > the fedora development community. In this way we can make laptop special > keys "just work" for Fedora 8. > Hi Hughes, Great that you're working on this and targeting F-8 with it. Unfortunately having only scancode -> keycode mappings in the kernel is not enough to make most keys just work. This also requires mapping to X keysyms and configurations of applications. I've been working on this, but currently I'm stuck on getting my intermediate solution for the generation of XKeysyms for these keys integrated into the xkeyboard-config package. I say intermediate, because in the long run X should switch from the kbd driver to the evdev driver, changing the way keyysyms get generated significantly. My analysis of the problem and proposed solution is described here: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html I would be much obligated if you could add your 2 cents to the patch/bug report about the XKeysym generation here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 I'm hoping that if others vote for the inclusion of this patch too, it will help getting it integrated. Ofcourse its possible to disagree with this patch too, in that case an alternative solution proposal would be very welcome. I've spare time to work on this, but first I need to know where / how to spend my time. Thanks & Regards, Hans From rjones at redhat.com Tue Jul 10 11:31:51 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 10 Jul 2007 12:31:51 +0100 Subject: Virtualization things. In-Reply-To: <200707101302.25470.opensource@till.name> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> <469362D6.60907@redhat.com> <200707101302.25470.opensource@till.name> Message-ID: <46936E27.1090606@redhat.com> Till Maas wrote: > On Di Juli 10 2007, Richard W.M. Jones wrote: > >> VirtualBox is based on QEMU, right? Can you tell us what features it >> has that makes it distinctive? (I mean in the free version, not >> interested in proprietary features). > > it uses Code from QEMU but afaik they use their own approach to > virtualization, which may be faster. Also currently the GUI works a lot > better than virt-manager for me. It will become more interesting, when it > supports a snapshot tree and cloning. Currently it supports only linear > snapshots. Also, you can run vmware Images directly with the current version, > but maybe QEMU can this, too. If you want to try it, I can provide you a > working srpm for the current version. Is this all in the free version? > There are also two big disadvantages in VirtualBox, imho. One is they use > strange build system, that has no stable releases. And the other is, that > there seems to be not "install" target to install it properly in a system. > >> There's a project to abstract away the differences between >> virtualisation technologies so that, for example, the same command line >> and graphical tools can be used to manage Xen, QEMU, KVM (so far, others >> coming later). >> >> Website: http://libvirt.org/ >> Mailing list: http://www.redhat.com/mailman/listinfo/libvir-list >> Graphical tool: http://virt-manager.et.redhat.com/ > > The idea is imho great, but for me with qemu it does not work properly. I'd really like to help out here. Did you get any error messages? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From hughsient at gmail.com Tue Jul 10 11:40:18 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jul 2007 12:40:18 +0100 Subject: Video and Keymap Quirks In-Reply-To: <46936DFC.4090904@hhs.nl> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> Message-ID: <1184067618.2249.84.camel@work> On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: > Great that you're working on this and targeting F-8 with it. Unfortunately > having only scancode -> keycode mappings in the kernel is not enough to make > most keys just work. This also requires mapping to X keysyms and configurations > of applications. Sure, but this is the first part of the jigsaw. For stuff like rfkill-input we need the kernel to _know_ that KEY_FN_F1 is actually KEY_BLUETOOTH. When X switches to evdev (soon?) the keysym problem should be a lot simpler to fix. > I've been working on this, but currently I'm stuck on getting my intermediate > solution for the generation of XKeysyms for these keys integrated into the > xkeyboard-config package. I say intermediate, because in the long run X should > switch from the kbd driver to the evdev driver, changing the way keyysyms get > generated significantly. Sure, that will be done before F8. > My analysis of the problem and proposed solution is described here: > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02236.html > > I would be much obligated if you could add your 2 cents to the patch/bug report > about the XKeysym generation here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245576 Sure, I'll try and do it this afternoon. I'm averaging a new email every 30 seconds at the moment, so I'm a little busy :-) > I'm hoping that if others vote for the inclusion of this patch too, it will > help getting it integrated. Ofcourse its possible to disagree with this patch > too, in that case an alternative solution proposal would be very welcome. I've > spare time to work on this, but first I need to know where / how to spend my time. Sure, I think we have to work together - the laptop key to switch bluetooth off is pretty orthogonal (although related) to mapping one keyboard layout to another. For the likes of desktops, we can't do dmi matching for the keylayout as this would break when we unplugged and replaced the keboard with a different model :-) How does your solution work with the new world of evdev and acpi input drivers? Richard. From opensource at till.name Tue Jul 10 11:50:36 2007 From: opensource at till.name (Till Maas) Date: Tue, 10 Jul 2007 13:50:36 +0200 Subject: Virtualization things. In-Reply-To: <46936E27.1090606@redhat.com> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> <200707101302.25470.opensource@till.name> <46936E27.1090606@redhat.com> Message-ID: <200707101350.37794.opensource@till.name> On Di Juli 10 2007, Richard W.M. Jones wrote: > Till Maas wrote: > > it uses Code from QEMU but afaik they use their own approach to > > virtualization, which may be faster. Also currently the GUI works a lot > > better than virt-manager for me. It will become more interesting, when it > > supports a snapshot tree and cloning. Currently it supports only linear > > snapshots. Also, you can run vmware Images directly with the current > > version, but maybe QEMU can this, too. If you want to try it, I can > > provide you a working srpm for the current version. > > Is this all in the free version? The snapshot tree and cloning has not been developed, yet. But the other stuff is in the free version. I just tried to boot a Monowall VMDK from http://www.xs4all.nl/~brugh/projects.html and it worked. For a normal user, VirtualBox seems to be the best solution in the free software world, so far. It provides more than VMWare Player (except for USB-Support) and a little less than VMWare Workstation. > I'd really like to help out here. Did you get any error messages? I will send you an private e-mail, because I guess it does not belong here. :-) Regards, Till From j.w.r.degoede at hhs.nl Tue Jul 10 12:35:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Jul 2007 14:35:06 +0200 Subject: Video and Keymap Quirks In-Reply-To: <1184067618.2249.84.camel@work> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> Message-ID: <46937CFA.4050808@hhs.nl> Richard Hughes wrote: > On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: >> I've been working on this, but currently I'm stuck on getting my intermediate >> solution for the generation of XKeysyms for these keys integrated into the >> xkeyboard-config package. I say intermediate, because in the long run X should >> switch from the kbd driver to the evdev driver, changing the way keyysyms get >> generated significantly. > > Sure, that will be done before F8. > Will it, is evdev scheduled for F-8, this the first time I've heard this. Also evdev upstream has told me that evdev currently cannot handle chinese/japanese input, so I think a switch atm is very unlikely. >> I'm hoping that if others vote for the inclusion of this patch too, it will >> help getting it integrated. Ofcourse its possible to disagree with this patch >> too, in that case an alternative solution proposal would be very welcome. I've >> spare time to work on this, but first I need to know where / how to spend my time. > > Sure, I think we have to work together - the laptop key to switch > bluetooth off is pretty orthogonal (although related) to mapping one > keyboard layout to another. For the likes of desktops, we can't do dmi > matching for the keylayout as this would break when we unplugged and > replaced the keboard with a different model :-) > > How does your solution work with the new world of evdev and acpi input > drivers? > I'm mainly focusing on normal (ps2/usb keyboards) with extra keys for multimedia and internet stuff. My solution currently assumes that: 1) The kernel generates the correct keycodes for these keys (which is true for all usb keyboards and most ps/2 keyboards) For the few exceptional ps/2 non laptop keyboards manual setkeycodes calls will be necessary, but that will be the case no matter what so for now I'm ignoring this. 2) That F-8 will keep using the kbd driver for Xorg, if F-8 will change to evdev, then my plan needs to be reworked. With this assumptions and the focus of internet / multimedia keys, my simple and short plan is to: 1) Add Linux virtual ps/2 keyboard fake scancode -> keysym translation to the (default) "Generic 104 keys" and "Generic 105 keys (international)" keyboard models. This is what the patch in bug 245576 does. 2) Start patching applications (starting with metacity) to have default keybindings to these keysyms for relevant actions. Currently atleast for metacity the default keybindings for multia media actions are empty. Notice that 2) is something which will also be necessary once switched to evdev, so the only work which will be thrown away because of me choosing in intermediate solution (in order to have something working for F-8) is the (already written) xkb patch Regards, Hans From opensource at till.name Tue Jul 10 12:35:02 2007 From: opensource at till.name (Till Maas) Date: Tue, 10 Jul 2007 14:35:02 +0200 Subject: Virtualization things. In-Reply-To: <698534.53803.qm@web52401.mail.re2.yahoo.com> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> Message-ID: <200707101435.03750.opensource@till.name> On Mo Juli 9 2007, Otto Rey wrote: > - Is somebody working on Virtualization (KVM + QEMU) Performance? Maybe > Upstream? Some time ago kqemu (qemu accelerator) was released under GPL 2 > license. Any plans to include in fedora? Or it is already included/merged > under qemu name? There is a dkms rpm available in an second party repository which works fine for me. > - It is posible to include VirtualBox OSE (Open Source Edition - GPL v2) in > Fedora repo's? Any problem with Legal Stuff? Do you want to (co)maintain or maybe test it? I have written an spec that compiles the 1.4.0 OSE release and provides a dkms for the kernel module. Xavier Lamien has written a spec to create kmod for the additions and the kernel module. But it is imho not clean enough, to submit it to Fedora and I do not have the time to finish it. Regards, Till From hughsient at gmail.com Tue Jul 10 12:41:14 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jul 2007 13:41:14 +0100 Subject: Video and Keymap Quirks In-Reply-To: <46937CFA.4050808@hhs.nl> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> Message-ID: <1184071274.2249.108.camel@work> On Tue, 2007-07-10 at 14:35 +0200, Hans de Goede wrote: > Richard Hughes wrote: > > On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: > > >> I've been working on this, but currently I'm stuck on getting my intermediate > >> solution for the generation of XKeysyms for these keys integrated into the > >> xkeyboard-config package. I say intermediate, because in the long run X should > >> switch from the kbd driver to the evdev driver, changing the way keyysyms get > >> generated significantly. > > > > Sure, that will be done before F8. > > > > Will it, is evdev scheduled for F-8, this the first time I've heard this. Also > evdev upstream has told me that evdev currently cannot handle chinese/japanese > input, so I think a switch atm is very unlikely. Ahh, I didn't know this. Is this a long term problem or just a bug? > I'm mainly focusing on normal (ps2/usb keyboards) with extra keys for > multimedia and internet stuff. My solution currently assumes that: > 1) The kernel generates the correct keycodes for these keys (which is > true for all usb keyboards and most ps/2 keyboards) > For the few exceptional ps/2 non laptop keyboards manual setkeycodes calls > will be necessary, but that will be the case no matter what so for now I'm > ignoring this. Cool. > 2) That F-8 will keep using the kbd driver for Xorg, if F-8 will change to > evdev, then my plan needs to be reworked. Right. Which may or may not be true. > With this assumptions and the focus of internet / multimedia keys, my simple > and short plan is to: > 1) Add Linux virtual ps/2 keyboard fake scancode -> keysym translation to the > (default) "Generic 104 keys" and "Generic 105 keys (international)" keyboard > models. This is what the patch in bug 245576 does. Yes, that seems sane. > 2) Start patching applications (starting with metacity) to have default > keybindings to these keysyms for relevant actions. Currently atleast for > metacity the default keybindings for multia media actions are empty. Sure, also sane. > Notice that 2) is something which will also be necessary once switched to > evdev, so the only work which will be thrown away because of me choosing in > intermediate solution (in order to have something working for F-8) is the > (already written) xkb patch Then why don't we just merge this now? Could it break anything that works already? Richard. From j.w.r.degoede at hhs.nl Tue Jul 10 13:24:02 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Jul 2007 15:24:02 +0200 Subject: Video and Keymap Quirks In-Reply-To: <1184071274.2249.108.camel@work> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> <1184071274.2249.108.camel@work> Message-ID: <46938872.4090502@hhs.nl> Richard Hughes wrote: > On Tue, 2007-07-10 at 14:35 +0200, Hans de Goede wrote: >> Richard Hughes wrote: >>> On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: >>>> I've been working on this, but currently I'm stuck on getting my intermediate >>>> solution for the generation of XKeysyms for these keys integrated into the >>>> xkeyboard-config package. I say intermediate, because in the long run X should >>>> switch from the kbd driver to the evdev driver, changing the way keyysyms get >>>> generated significantly. >>> Sure, that will be done before F8. >>> >> Will it, is evdev scheduled for F-8, this the first time I've heard this. Also >> evdev upstream has told me that evdev currently cannot handle chinese/japanese >> input, so I think a switch atm is very unlikely. > > Ahh, I didn't know this. Is this a long term problem or just a bug? > I don't know when I discussed this with them no details were provided. >> I'm mainly focusing on normal (ps2/usb keyboards) with extra keys for >> multimedia and internet stuff. My solution currently assumes that: >> 1) The kernel generates the correct keycodes for these keys (which is >> true for all usb keyboards and most ps/2 keyboards) >> For the few exceptional ps/2 non laptop keyboards manual setkeycodes calls >> will be necessary, but that will be the case no matter what so for now I'm >> ignoring this. > > Cool. > >> 2) That F-8 will keep using the kbd driver for Xorg, if F-8 will change to >> evdev, then my plan needs to be reworked. > > Right. Which may or may not be true. > >> With this assumptions and the focus of internet / multimedia keys, my simple >> and short plan is to: >> 1) Add Linux virtual ps/2 keyboard fake scancode -> keysym translation to the >> (default) "Generic 104 keys" and "Generic 105 keys (international)" keyboard >> models. This is what the patch in bug 245576 does. > > Yes, that seems sane. > >> 2) Start patching applications (starting with metacity) to have default >> keybindings to these keysyms for relevant actions. Currently atleast for >> metacity the default keybindings for multia media actions are empty. > > Sure, also sane. > >> Notice that 2) is something which will also be necessary once switched to >> evdev, so the only work which will be thrown away because of me choosing in >> intermediate solution (in order to have something working for F-8) is the >> (already written) xkb patch > > Then why don't we just merge this now? With this you mean the patch for 1) or patches for 2) ? The xkeyboard-config maintainer isn't sure if he likes the patch for 1), which is exactly why I've asked you to take a look and vote for it if you like it. As for 2) because of the lack of progress with 1) I've been spending my time and energy elsewhere, so there are no patches to merge atm. > Could it break anything that > works already? > Assuming you mean the patch for 1) , No not that I know of. Regards, Hans From bkonrath at redhat.com Tue Jul 10 13:34:44 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Tue, 10 Jul 2007 09:34:44 -0400 Subject: Eclipse plugin version 320v20060603 is badly formatted In-Reply-To: <13dbfe4f0706280536o17256668ref5f2ce5f8632ccc@mail.gmail.com> References: <13dbfe4f0706280536o17256668ref5f2ce5f8632ccc@mail.gmail.com> Message-ID: <1184074484.3094.4.camel@toast.toronto.redhat.com> On Thu, 2007-06-28 at 14:36 +0200, Chitlesh GOORAH wrote: > Hello there, > > I'm trying to rpmbuild "ivi". However, the "ant" fails with > /ivi-1.0.2_1-src/configure.xml:40: plugin version 320v20060603 is > badly formatted: java.lang.NumberFormatException: invalid character at > position 4 in 320v20060603 > > Is that ok with the "v" in the version of > /usr/share/eclipse/plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar > ? The version string is fine. I ran into similar problem with the icu4j-eclipse build but I hacked around it by removing the 'date' line in the jar task. This sed expression did the trick for me: sed --in-place "s///" build.xml Hope this helps, Ben From snecklifter at gmail.com Tue Jul 10 14:00:05 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 10 Jul 2007 15:00:05 +0100 Subject: X woes - can't set the correct resolution no matter what... In-Reply-To: <64b14b300707091120q2098bb3vc5100787c413b6e7@mail.gmail.com> References: <64b14b300707091120q2098bb3vc5100787c413b6e7@mail.gmail.com> Message-ID: <364d303b0707100700v21dc37e3rcacbbc86a57b0a77@mail.gmail.com> On 09/07/07, Valent Turkovic wrote: > > I hope this is the right list to raise this issue... if not point me > in the right direction. > The development list is for the development of Fedora only as has already been pointed out to you here: https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00510.html Try #fedora on IRC or the main fedora list. I also find linuxquestions.organd fedoraforum.org extremely helpful. http://www.redhat.com/mailman/listinfo/fedora-list Regards Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From seandarcy2 at gmail.com Tue Jul 10 12:44:05 2007 From: seandarcy2 at gmail.com (sean) Date: Tue, 10 Jul 2007 08:44:05 -0400 Subject: rawhide report: 20070709 changes In-Reply-To: <200707090849.l698nSKw003485@porkchop.devel.redhat.com> References: <200707090849.l698nSKw003485@porkchop.devel.redhat.com> Message-ID: Broken deps seems to only pick up explicit deps, not not the transactions check that yum, for instance, does after the rpms are dl'd. Any way to catch this? --> Running transaction check ---> Package system-config-kickstart.noarch 0:2.7.7-2.fc8 set to be updated --> Processing Dependency: system-config-securitylevel <= 1.7.0 for package: system-config-kickstart --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package system-config-securitylevel.i386 0:1.7.0-3.fc8 set to be updated ---> Package system-config-kickstart.noarch 0:2.7.7-2.fc8 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: system-config-kickstart noarch 2.7.7-2.fc8 development 1.0 M Installing for dependencies: system-config-securitylevel i386 1.7.0-3.fc8 development 290 k Transaction Summary ============================================================================= Install 1 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 1.3 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Check Error: package system-config-securitylevel-1.8.0-1.fc7 (which is newer than system-config-securitylevel-1.7.0-3.fc8) is already installed file /usr/share/locale/ar/LC_MESSAGES/system-config-securitylevel.mo from install of system-config-securitylevel-1.7.0-3.fc8 conflicts with file from package system-config-securitylevel-tui-1.7.0-3.fc8 file /usr/share/locale/as/LC_MESSAGES/system-config-securitylevel.mo from install of system-config-securitylevel-1.7.0-3.fc8 conflicts with file from package system-config-securitylevel-tui-1.7.0-3.fc8 .................... From harald at redhat.com Tue Jul 10 14:14:38 2007 From: harald at redhat.com (Harald Hoyer) Date: Tue, 10 Jul 2007 16:14:38 +0200 Subject: Parallel Booting In-Reply-To: <20070709190310.GD10904@nostromo.devel.redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <468E6B3C.6070100@redhat.com> <20070709190310.GD10904@nostromo.devel.redhat.com> Message-ID: <4693944E.5010308@redhat.com> Bill Nottingham schrieb: > Got code? I'm interested in how much time is lost in the audit/setroubleshoot > logger logging the AVCs. Should be in rawhide... # yum install prcsys Btw, I am not interested in quenching the last seconds out of the system. My primary interest is in getting dependencies in the initscripts and adding the static dependencies is the first step. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From berrange at redhat.com Tue Jul 10 14:17:59 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 10 Jul 2007 15:17:59 +0100 Subject: Virtualization things. In-Reply-To: <469362D6.60907@redhat.com> References: <698534.53803.qm@web52401.mail.re2.yahoo.com> <469362D6.60907@redhat.com> Message-ID: <20070710141759.GE21319@redhat.com> On Tue, Jul 10, 2007 at 11:43:34AM +0100, Richard W.M. Jones wrote: > Otto Rey wrote: > >- Is somebody working on Virtualization (KVM + QEMU) Performance? > > Maybe Upstream? Some time ago kqemu (qemu accelerator) was released > > under GPL 2 license. Any plans to include in fedora? Or it is > > already included/merged under qemu name? > > I can't find anything about kqemu & its status w.r.t. the upstream Linux > kernel. It isn't upstream & not built as part of the QEMU rpms in Fedora. If you compile / install it from an alternative source, libvirt/virt-manager will detect it & make use of kqemu if you don't have KVM available > KVM is in the upstream & Fedora kernels, and uses QEMU code to do device > emulation. Of course, that requires that your hardware supports > virtualization, but that will become increasingly common in the next > year or two. For performance issues with KVM you should ask upstream > (eg. on kvm-devel mailing list, > https://lists.sourceforge.net/lists/listinfo/kvm-devel). > > >- It is posible to include VirtualBox OSE (Open Source Edition > > - GPL v2) in Fedora repo's? Any problem with Legal Stuff? > > VirtualBox is based on QEMU, right? Can you tell us what features it > has that makes it distinctive? (I mean in the free version, not > interested in proprietary features). It merely ues QEMU as its device model. Its pretty similar in concept to VMWare Workstation from what I can see. It tries to provide a self contained easy to use full virtualized solution. It dosn't need any special hardware support, but does require custom kernel modules. > There's a project to abstract away the differences between > virtualisation technologies so that, for example, the same command line > and graphical tools can be used to manage Xen, QEMU, KVM (so far, others > coming later). It be desirable to support VirtualBox in libvirt at some point if its popularity increases / or if there is already demand. It should fit in with libvirt concepts pretty well based on the cursory examination I've done of its capabilities. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From valent.turkovic at gmail.com Tue Jul 10 14:23:53 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 10 Jul 2007 16:23:53 +0200 Subject: Video and Keymap Quirks In-Reply-To: <1184058738.2249.16.camel@work> References: <1184058738.2249.16.camel@work> Message-ID: <1184077433.30545.5.camel@fedora> On Tue, 2007-07-10 at 10:12 +0100, Richard Hughes wrote: > You might have heard about the HAL quirk site [1] for suspend and > resume > quirks before, but now we are collecting keymap quirks to make the > special buttons such as multimedia keys and Fn function keys do the > right thing. Does this also include usb keyboards or do you only need help with laptop keyboards? I have FC6 running on my work laptop with external USB wireless Labtech keyboard. gnome-keybinding-properties recognises all keys I press and I can assign them to open my default browser or email program - but I can even choose that email button opens terminal or any other combination. Can you please explain if you my contribution with even a keyboard that is recogniosed by the system (kernel+gnome) or not? Or do you need only keys from my IBM thinkpad. Thank you. From valent.turkovic at gmail.com Tue Jul 10 14:26:54 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 10 Jul 2007 16:26:54 +0200 Subject: X woes - can't set the correct resolution no matter what... In-Reply-To: <364d303b0707100700v21dc37e3rcacbbc86a57b0a77@mail.gmail.com> References: <64b14b300707091120q2098bb3vc5100787c413b6e7@mail.gmail.com> <364d303b0707100700v21dc37e3rcacbbc86a57b0a77@mail.gmail.com> Message-ID: <1184077614.30545.9.camel@fedora> On Tue, 2007-07-10 at 15:00 +0100, Chris Brown wrote: > The development list is for the development of Fedora only as has > already been pointed out to you here: > > https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00510.html Sorry the but there are other topics that I see discused that also are in line with my quiestions. I'm not asking this only from users POV but in order that devels see this as an option to make some suggestion how to make this easier and better in newer version of Fedora. > Try #fedora on IRC or the main fedora list. I also find > linuxquestions.org and fedoraforum.org extremely helpful. I'm off to there... thank you. From hughsient at gmail.com Tue Jul 10 14:30:17 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jul 2007 15:30:17 +0100 Subject: Video and Keymap Quirks In-Reply-To: <1184077433.30545.5.camel@fedora> References: <1184058738.2249.16.camel@work> <1184077433.30545.5.camel@fedora> Message-ID: <1184077817.2249.138.camel@work> On Tue, 2007-07-10 at 16:23 +0200, Valent Turkovic wrote: > On Tue, 2007-07-10 at 10:12 +0100, Richard Hughes wrote: > > You might have heard about the HAL quirk site [1] for suspend and > > resume > > quirks before, but now we are collecting keymap quirks to make the > > special buttons such as multimedia keys and Fn function keys do the > > right thing. > > Does this also include usb keyboards or do you only need help with > laptop keyboards? Only laptop keyboards. If you read the http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-intro.html page then you'll see it only should be used for laptop keyboards. > I have FC6 running on my work laptop with external USB wireless Labtech > keyboard. gnome-keybinding-properties recognises all keys I press and I > can assign them to open my default browser or email program - but I can > even choose that email button opens terminal or any other combination. > > Can you please explain if you my contribution with even a keyboard that > is recogniosed by the system (kernel+gnome) or not? Try with the latest hal-info - I've been adding quirks like there is no tomorrow all day today :-) Richard. From Jochen at herr-schmitt.de Tue Jul 10 15:09:51 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 10 Jul 2007 17:09:51 +0200 Subject: Implementation of a wild card usage for the uniqueext option Message-ID: <4693A13F.90709@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I hope, I'm using the right mailing list. If not, I will be happy for any hint to discover the right one for this topic. During the work on the ppc machine, on which I have access via a ssh connection, I have learned knowing about the benefits of the --uniqueext option of mock. - From my point of view this option has the disadvantage, that you have to educate the users to used it. So I have try to develop a patch, which allow you to get the expected result without the need of specified a special option on the command line. My idea is that if you set uniqueext to '*' (Star), the userid of the logon user should be append on the root directory. This behavior allows you, that you can add a "config_opts['unique-ext']='*'" line in the config files of mock. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGk6EiT2AHK6txfgwRAkqNAKD/HzWzjmifdG+9GdN0yxvkLezv9ACcCKlP qbB3t+eSPErwnQ8X1VxGRDU= =yjw4 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: mock-0.7.2-uid.patch Type: text/x-patch Size: 816 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mock-0.7.2-uid.patch.sig Type: application/octet-stream Size: 65 bytes Desc: not available URL: From tcallawa at redhat.com Tue Jul 10 15:19:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Jul 2007 10:19:23 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures Message-ID: <1184080763.3490.66.camel@localhost.localdomain> Hi Fedorans, I've made some small changes to the SecondaryArchitectures draft. It has been added to the schedule for voting at FESCo this week. It can be found at : http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures Thanks, ~spot From jdieter at gmail.com Tue Jul 10 15:21:17 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 10 Jul 2007 18:21:17 +0300 Subject: Problem with Rawhide? Message-ID: <1184080877.11157.2.camel@jndwidescreen.lesbg.loc> Is there a problem with Rawhide? I notice that http://redhat.download.fedoraproject.org/pub/fedora/linux/development/i386/os/repodata is missing the usual yum metadata. Have I missed something? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue Jul 10 15:22:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Jul 2007 11:22:18 -0400 Subject: Problem with Rawhide? In-Reply-To: <1184080877.11157.2.camel@jndwidescreen.lesbg.loc> References: <1184080877.11157.2.camel@jndwidescreen.lesbg.loc> Message-ID: <20070710152218.GA5756@nostromo.devel.redhat.com> Jonathan Dieter (jdieter at gmail.com) said: > Is there a problem with Rawhide? Yes. Working on it. Bill From oliver at linux-kernel.at Tue Jul 10 15:33:40 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 10 Jul 2007 17:33:40 +0200 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184080763.3490.66.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> Message-ID: <4693A6D4.7030002@linux-kernel.at> On 07/10/2007 05:19 PM, Tom "spot" Callaway wrote: > Hi Fedorans, > > I've made some small changes to the SecondaryArchitectures draft. > It has been added to the schedule for voting at FESCo this week. > > It can be found at : > http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures Thx Spot! -of From dwmw2 at infradead.org Tue Jul 10 16:19:34 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 10 Jul 2007 17:19:34 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184080763.3490.66.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> Message-ID: <1184084374.32628.9.camel@pmac.infradead.org> On Tue, 2007-07-10 at 10:19 -0500, Tom "spot" Callaway wrote: > Hi Fedorans, > > I've made some small changes to the SecondaryArchitectures draft. > It has been added to the schedule for voting at FESCo this week. > > It can be found at : > http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures It would be happier if you'd left the discussion on the same page, rather than moving it to http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitecturesDiscussion I feel very strongly that allowing partially-failed builds to be shipped without _any_ intervention from the package maintainer is a mistake. My experience is that the majority of the time when a package fails to build on one architecture but not others, that is actually a generic bug which could bite on all architectures -- not an arch-specific bug. It's just that some bugs aren't 100% reproduceable, and show up in some circumstances and not others. We should at least _glance_ at failures. I'm only suggesting that the packager should need to _look_ at the failure before filing the required ExcludeArch bug and pushing a 'ship it anyway' button. I'm not saying that we should force them to start the build from scratch again like we do at the moment. -- dwmw2 From lsof at nodata.co.uk Tue Jul 10 16:33:43 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 10 Jul 2007 18:33:43 +0200 Subject: Implementation of a wild card usage for the uniqueext option In-Reply-To: <4693A13F.90709@herr-schmitt.de> References: <4693A13F.90709@herr-schmitt.de> Message-ID: <1184085223.3549.4.camel@sb-home> Am Dienstag, den 10.07.2007, 17:09 +0200 schrieb Jochen Schmitt: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I hope, I'm using the right mailing list. If not, I will be happy for > any hint to discover the right one for this > topic. > > During the work on the ppc machine, on which I have access via a ssh > connection, I have learned knowing about > the benefits of the --uniqueext option of mock. > > - From my point of view this option has the disadvantage, that you have > to educate the users to used it. > So I have try to develop a patch, which allow you to get the expected > result without the need of > specified a special option on the command line. > > My idea is that if you set uniqueext to '*' (Star), the userid of the > logon user should be append on the > root directory. This behavior allows you, that you can add a > "config_opts['unique-ext']='*'" line in the > config files of mock. > > Best Regards: > > Jochen Schmitt > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFGk6EiT2AHK6txfgwRAkqNAKD/HzWzjmifdG+9GdN0yxvkLezv9ACcCKlP > qbB3t+eSPErwnQ8X1VxGRDU= > =yjw4 > -----END PGP SIGNATURE----- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Surely the normal way command line options like this work is: 1. avoid wildcards and special characters 2. for hacks like this ("*" is a valid value), have a new option for that, e.g. config_opts['auto-unique-ext']=1 From jwboyer at jdub.homelinux.org Tue Jul 10 17:05:30 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 10 Jul 2007 12:05:30 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184084374.32628.9.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> Message-ID: <1184087130.32199.21.camel@weaponx.rchland.ibm.com> On Tue, 2007-07-10 at 17:19 +0100, David Woodhouse wrote: > On Tue, 2007-07-10 at 10:19 -0500, Tom "spot" Callaway wrote: > > Hi Fedorans, > > > > I've made some small changes to the SecondaryArchitectures draft. > > It has been added to the schedule for voting at FESCo this week. > > > > It can be found at : > > http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures > > It would be happier if you'd left the discussion on the same page, > rather than moving it to > http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitecturesDiscussion > > I feel very strongly that allowing partially-failed builds to be shipped > without _any_ intervention from the package maintainer is a mistake. > > My experience is that the majority of the time when a package fails to > build on one architecture but not others, that is actually a generic bug > which could bite on all architectures -- not an arch-specific bug. It's > just that some bugs aren't 100% reproduceable, and show up in some > circumstances and not others. We should at least _glance_ at failures. > > I'm only suggesting that the packager should need to _look_ at the > failure before filing the required ExcludeArch bug and pushing a 'ship > it anyway' button. I'm not saying that we should force them to start the > build from scratch again like we do at the moment. I agree. This is the largest objection I have to the current proposal. Additional questions are: Does FESCo have to ack the Architecture Leads? What exactly constitutes the buildsystem? E.g. if koji is running on a different distribution, it's not building the packages with the same toolset that the primary architectures are on. (I realize there is a chicken/egg scenario here). How are Secondary arch releases suppose to go about getting official "Fedora" status? Are torrents/URLs to Secondary arch releases to be linked from the fedoraproject.org website assuming they are granted Fedora status? josh From Jochen at herr-schmitt.de Tue Jul 10 17:09:18 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 10 Jul 2007 19:09:18 +0200 Subject: Implementation of a wild card usage for the uniqueext option In-Reply-To: <1184085223.3549.4.camel@sb-home> References: <4693A13F.90709@herr-schmitt.de> <1184085223.3549.4.camel@sb-home> Message-ID: <4693BD3E.5080701@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 nodata schrieb: > Am Dienstag, den 10.07.2007, 17:09 +0200 schrieb Jochen Schmitt: > 1. avoid wildcards and special characters 2. for hacks like this > ("*" is a valid value), have a new option for that, e.g. > config_opts['auto-unique-ext']=1 Thank you for your hints. I have attached a improved version of my patch. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGk70vT2AHK6txfgwRAtn9AJ4qgHUiSuE4L6Y4k2da1TsDjEw9tACg7I+j 748A0G4A+OsTNjg2RxHZgSU= =Sg1T -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: mock-0.7.2-uid.patch Type: text/x-patch Size: 1869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mock-0.7.2-uid.patch.sig Type: application/octet-stream Size: 65 bytes Desc: not available URL: From jspaleta at gmail.com Tue Jul 10 17:29:58 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 10 Jul 2007 09:29:58 -0800 Subject: Please Read: Need help in replacing music in Fedora package In-Reply-To: <1184015028.3490.19.camel@localhost.localdomain> References: <1184015028.3490.19.camel@localhost.localdomain> Message-ID: <604aa7910707101029t76827866q1e5174cf2eec6527@mail.gmail.com> On 7/9/07, Tom spot Callaway wrote: > Hello interweb. I need help. (This is going out to a few places, as to > hopefully have it picked up) > > One of my Fedora packages (rocksndiamonds) has a slight problem. Turns > out that some of its audio files are straight copies of music which was > used without permission. Is any of the music from the Red Hat Summit Compilation appropriate? I know its CC licensed, but I'm not sure of the details as regard to which CC clauses are riding on each song. I guess you would need share-alike and the derivative clauses. Magnatunes has a re-compilation of the songs to listen to. search for Red Hat Summit in the magnatunes plugin for rhythmbox. -jef From kevin.kofler at chello.at Tue Jul 10 17:39:33 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 10 Jul 2007 17:39:33 +0000 (UTC) Subject: Please Read: Need help in replacing music in Fedora package References: <1184015028.3490.19.camel@localhost.localdomain> <604aa7910707101029t76827866q1e5174cf2eec6527@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > Is any of the music from the Red Hat Summit Compilation appropriate? I > know its CC licensed, but I'm not sure of the details as regard to > which CC clauses are riding on each song. I guess you would need > share-alike and the derivative clauses. Share-alike isn't needed for the license to be Free. Absence of the NonCommercial and NoDerivs clauses is. Kevin Kofler From jspaleta at gmail.com Tue Jul 10 17:56:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 10 Jul 2007 09:56:34 -0800 Subject: Please Read: Need help in replacing music in Fedora package In-Reply-To: References: <1184015028.3490.19.camel@localhost.localdomain> <604aa7910707101029t76827866q1e5174cf2eec6527@mail.gmail.com> Message-ID: <604aa7910707101056n6857861do367c15f68bde2787@mail.gmail.com> On 7/10/07, Kevin Kofler wrote: > Share-alike isn't needed for the license to be Free. Absence of the > NonCommercial and NoDerivs clauses is. Greg will know for sure. I'll twist his ear about it later today. -jef From sundaram at fedoraproject.org Tue Jul 10 18:04:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 10 Jul 2007 23:34:00 +0530 Subject: Please Read: Need help in replacing music in Fedora package In-Reply-To: References: <1184015028.3490.19.camel@localhost.localdomain> <604aa7910707101029t76827866q1e5174cf2eec6527@mail.gmail.com> Message-ID: <4693CA10.60807@fedoraproject.org> Kevin Kofler wrote: > Jeff Spaleta gmail.com> writes: >> Is any of the music from the Red Hat Summit Compilation appropriate? I >> know its CC licensed, but I'm not sure of the details as regard to >> which CC clauses are riding on each song. I guess you would need >> share-alike and the derivative clauses. > > Share-alike isn't needed for the license to be Free. Absence of the > NonCommercial and NoDerivs clauses is. Kevin is right but note that our packaging guidelines allow content under licenses that are merely redistributable. Rahul From jkeating at redhat.com Tue Jul 10 17:57:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Jul 2007 13:57:06 -0400 Subject: rsyslog in f8? In-Reply-To: <46934427.4070508@redhat.com> References: <20070703124100.2e704168@ghistelwchlohm.scrye.com> <200707031446.09235.jkeating@redhat.com> <46934427.4070508@redhat.com> Message-ID: <200707101357.06577.jkeating@redhat.com> On Tuesday 10 July 2007 04:32:39 Peter Vrabec wrote: > Jesse, does it mean that init,conf,logrot. and sysconf file should be > named same? I don't necessarily think they need to be named the same. I could be wrong, but that's my understanding. -- 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 Jul 10 18:52:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Jul 2007 14:52:35 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-10 Message-ID: <20070710185235.6769F152134@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 25 aria2-0.11.1-1.fc6 contacts-0.5-1.fc6 dates-0.4.3-1.fc6 fortune-firefly-2.1.2-4.fc6 fwbackups-1.43.0-1.fc6 gscan2pdf-0.9.13-1.fc6 NEW gshutdown-0.2-1.fc6 : GShutDown is an advanced shut down utility for GNOME gtk-gnutella-0.96.4-1.fc6 kbibtex-0.1.5.52-9.fc6 NEW kicker-compiz-3.5.4-3.fc6 : Makes KDE kicker Pager applet work with compiz kmenu-gnome-0.6.5-3.fc6 koffice-1.6.3-6.fc6.2 magic-7.4.35-5.fc6 mantis-1.0.8-1.fc6 nginx-0.5.27-1.fc6 ntfsprogs-1.13.1-5.fc6 perl-Crypt-Simple-0.06-4.fc6 perl-File-Remove-0.37-1.fc6 NEW perl-NetAddr-IP-4.004-2.fc6 : Manages IPv4 and IPv6 addresses and subnets NEW postgresql-pgpool-ha-1.1.0-4.fc6 : Pgpool-HA uses heartbeat to keep pgpool from being a single point of failure python-genshi-0.4.2-2.fc6 scrub-1.9-1.fc6 NEW tgif-4.1.45-3.fc6 : 2-D drawling tool tidy-0.99.0-12.20070228.fc6.1 wavbreaker-0.8.1-2.fc6 Changes in Fedora Extras 6: aria2-0.11.1-1.fc6 ------------------ * Mon Jul 09 2007 Micha? Bentkowski - 0.11.1-1 - Update to 0.11.1 contacts-0.5-1.fc6 ------------------ * Sat Jun 02 2007 Denis Leroy - 0.5-1 - Update to 0.5 - Updated dependencies - Added icon cache and desktop database scripts dates-0.4.3-1.fc6 ----------------- * Mon Jul 09 2007 Denis Leroy - 0.4.3-1 - Update to new upstream release 0.4.3 - Fixed project URL - Minor rpmlint fixes fortune-firefly-2.1.2-4.fc6 --------------------------- * Mon Jul 09 2007 Karen Pease - 2.1.2.4 - Upping tag to sync builds. * Mon Jul 09 2007 Karen Pease - 2.1.2.3 - Upping tag to sync builds. fwbackups-1.43.0-1.fc6 ---------------------- * Sun Jul 08 2007 Stewart Adam 1.43.0-1 - Add BuildRequires python 2.4, gettext - Add Requires python 2.4, notify-python - No longer requires redhat-artwork and usermode - New description - Update to 1.43.0 (see CHANGELOG file for details on version changes) gscan2pdf-0.9.13-1.fc6 ---------------------- * Mon Jul 09 2007 Bernard Johnson - 0.9.13-1 - v 0.9.13 * Thu Jun 21 2007 Bernard Johnson - 0.9.12-2 - fix requires from ImageMagick to ImageMagick-perl - add History to %doc list gshutdown-0.2-1.fc6 ------------------- * Mon Jul 09 2007 Xavier Lamien - 0.2-1 - Updated Release. gtk-gnutella-0.96.4-1.fc6 ------------------------- * Tue Jul 10 2007 Dmitry Butskoy - 0.96.4-1 - update to 0.96.4 * Tue Jun 26 2007 Dmitry Butskoy - drop X-Fedora category from desktop file kbibtex-0.1.5.52-9.fc6 ---------------------- * Mon Jul 09 2007 Christian Nolte - 0.1.5.52-9 - Updated to latest upstream version * Wed Mar 21 2007 Christian Nolte - 0.1.5-7 - latest patches (storesearchurls, webquerypubmedmultiplequeries, xslhtmlexport) kicker-compiz-3.5.4-3.fc6 ------------------------- * Sun Jul 01 2007 Xavier Lamien < lxtnow at gmail.com > - 3.5.4-3 - managed %Description and BR kmenu-gnome-0.6.5-3.fc6 ----------------------- * Sun Jul 08 2007 Chitlesh Goorah - 0.6.5-3 - fixed %description #247365 koffice-1.6.3-6.fc6.2 --------------------- * Sun Jun 24 2007 Rex Dieter 1.6.3-7 - -devel: %exclude %_libdir/libkudesignercore.so (#245333) * Thu Jun 21 2007 Rex Dieter 1.6.3-6 - use simpler NoDisplay=True hack (workaround #245190) - disable (kross)ruby on rawhide (for now) * Wed Jun 20 2007 Rex Dieter 1.6.3-5 - mark applnk/.hidden/*.desktop NoDisplay=True instead (#245061) * Fri Jun 15 2007 Rex Dieter 1.6.3-3 - (really) require version of kdelibs used to build against (#244091) * Fri Jun 15 2007 Rex Dieter 1.6.3-2 - Require version of kdelibs used to build against (#244091) - -suite: use versioned Requires magic-7.4.35-5.fc6 ------------------ * Sun Jul 08 2007 Chitlesh Goorah - 7.4.35-5 - patching properly * Sun Jul 08 2007 Chitlesh Goorah - 7.4.35-4 - patching properly * Sun Jul 08 2007 Chitlesh Goorah - 7.4.35-3 - fix for 64 bit with respect to a hardcoded autopath - fix for %post and %postun - #246778 mantis-1.0.8-1.fc6 ------------------ * Mon Jul 09 2007 Gianluca Sforna - 1.0.8-1 - new upstream release - add Require: php-adodb (and remove embedded one) - remove duplicate docs nginx-0.5.27-1.fc6 ------------------ * Mon Jul 09 2007 Jeremy Hinegardner - 0.5.27-1 - Update to 0.5.27 ntfsprogs-1.13.1-5.fc6 ---------------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.13.1-5 - don't package items which say they should never be installed (resolves bz 247398) perl-Crypt-Simple-0.06-4.fc6 ---------------------------- * Mon Jul 09 2007 Allisson Azevedo 0.06-4 - Add exception for FC-6 perl-File-Remove-0.37-1.fc6 --------------------------- * Tue Jul 10 2007 Ralf Cors?pius - 0.37-1 - Upstream update. * Mon Jul 02 2007 Ralf Cors?pius - 0.36-2 - Increment release due to koji suckage. * Mon Jul 02 2007 Ralf Cors?pius - 0.36-1 - Upsteam update. - BR: perl(ExtUtils::MakeMaker). - BR: perl(Test::More). perl-NetAddr-IP-4.004-2.fc6 --------------------------- * Thu Apr 26 2007 * Thu Apr 12 2007 Andreas Thienemann 4.004-2 - Moar docs! postgresql-pgpool-ha-1.1.0-4.fc6 -------------------------------- * Mon Jul 09 2007 Devrim GUNDUZ 1.1.0-4 - Made package arch, per bz review. - Move ocf path back to datadir/ocf/resource.d . * Thu Jul 05 2007 Devrim GUNDUZ 1.1.0-3 - Fix ocf path * Wed Jul 04 2007 Devrim GUNDUZ 1.1.0-2 - Removed make install (per bz review) - Fix rpmlint errors * Sun Jun 24 2007 Devrim GUNDUZ 1.1.0-1 - Update to 1.1.0 python-genshi-0.4.2-2.fc6 ------------------------- * Mon Jul 09 2007 Jeffrey C. Ollie - 0.4.2-2 - BR python-setuptools so that egg-info files get installed. Fixes #247430. scrub-1.9-1.fc6 --------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.9-1 - bump to 1.9 tgif-4.1.45-3.fc6 ----------------- * Mon Jul 09 2007 TASAKA Mamoru - 4.1.45-3 - Clean up BuildRequies * Thu Jul 05 2007 TASAKA Mamoru - 4.1.45-2 - Explicitly set LANG=ja_JP.eucJP on ja_JP locale - Add needed Requires * Thu Jul 05 2007 TASAKA Mamoru - 4.1.45-1 - Clean up for Fedora tidy-0.99.0-12.20070228.fc6.1 ----------------------------- * Wed Feb 28 2007 Rex Dieter 0.99.0-12.20070228 - 2007-02-28 snapshot wavbreaker-0.8.1-2.fc6 ---------------------- * Fri Jul 06 2007 Homer 0.8.1-2 - new version 0.8.1 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tcallawa at redhat.com Tue Jul 10 19:42:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Jul 2007 14:42:25 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184087130.32199.21.camel@weaponx.rchland.ibm.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> Message-ID: <1184096545.3490.90.camel@localhost.localdomain> On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: > > I'm only suggesting that the packager should need to _look_ at the > > failure before filing the required ExcludeArch bug and pushing a 'ship > > it anyway' button. I'm not saying that we should force them to start the > > build from scratch again like we do at the moment. > > I agree. This is the largest objection I have to the current proposal. This is a significant workflow change. How should we force the packager to look at the failure before letting the packages push? > Additional questions are: Good questions, here are my provisional answers: > Does FESCo have to ack the Architecture Leads? Yes. > What exactly constitutes the buildsystem? E.g. if koji is running on a > different distribution, it's not building the packages with the same > toolset that the primary architectures are on. (I realize there is a > chicken/egg scenario here). Fedora + koji constitutes the buildsystem. The secondary arch team may need to create a manual bootstrap of a Fedora environment before they're ready to build packages. > How are Secondary arch releases suppose to go about getting official > "Fedora" status? The secondary arch team exists, has a working koji buildsystem, is okayed by FESCo, and has packages (and or trees) ready by either the main Fedora timeline or a reasonable timeline defined by the secondary arch team. > Are torrents/URLs to Secondary arch releases to be linked from the > fedoraproject.org website assuming they are granted Fedora status? Yes. ~spot From tcallawa at redhat.com Tue Jul 10 19:43:14 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Jul 2007 14:43:14 -0500 Subject: Please Read: Need help in replacing music in Fedora package In-Reply-To: <4693CA10.60807@fedoraproject.org> References: <1184015028.3490.19.camel@localhost.localdomain> <604aa7910707101029t76827866q1e5174cf2eec6527@mail.gmail.com> <4693CA10.60807@fedoraproject.org> Message-ID: <1184096594.3490.92.camel@localhost.localdomain> On Tue, 2007-07-10 at 23:34 +0530, Rahul Sundaram wrote: > Kevin Kofler wrote: > > Jeff Spaleta gmail.com> writes: > >> Is any of the music from the Red Hat Summit Compilation appropriate? I > >> know its CC licensed, but I'm not sure of the details as regard to > >> which CC clauses are riding on each song. I guess you would need > >> share-alike and the derivative clauses. > > > > Share-alike isn't needed for the license to be Free. Absence of the > > NonCommercial and NoDerivs clauses is. > > Kevin is right but note that our packaging guidelines allow content > under licenses that are merely redistributable. Redistributable without restriction. Thus, the NonComm clause is right out. ~spot From jwboyer at jdub.homelinux.org Tue Jul 10 20:15:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 10 Jul 2007 15:15:37 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184096545.3490.90.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> Message-ID: <1184098537.32199.33.camel@weaponx.rchland.ibm.com> On Tue, 2007-07-10 at 14:42 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: > > > > I'm only suggesting that the packager should need to _look_ at the > > > failure before filing the required ExcludeArch bug and pushing a 'ship > > > it anyway' button. I'm not saying that we should force them to start the > > > build from scratch again like we do at the moment. > > > > I agree. This is the largest objection I have to the current proposal. > > This is a significant workflow change. How should we force the packager > to look at the failure before letting the packages push? Depends on how you look at it really. It's worth discussion anyway. > > Additional questions are: > > Good questions, here are my provisional answers: > > > Does FESCo have to ack the Architecture Leads? > > Yes. OK. > > What exactly constitutes the buildsystem? E.g. if koji is running on a > > different distribution, it's not building the packages with the same > > toolset that the primary architectures are on. (I realize there is a > > chicken/egg scenario here). > > Fedora + koji constitutes the buildsystem. The secondary arch team may > need to create a manual bootstrap of a Fedora environment before they're > ready to build packages. By that definition, the primary arches don't qualify either. They're built using RHEL + koji. Not that I really argue with the definition mind you. Just interesting from a primary vs. secondary requirements perspective. > > How are Secondary arch releases suppose to go about getting official > > "Fedora" status? > > The secondary arch team exists, has a working koji buildsystem, is > okayed by FESCo, and has packages (and or trees) ready by either the > main Fedora timeline or a reasonable timeline defined by the secondary > arch team. Back in Nov. 2006, there was also the concept that FPB had to approve a secondary arch release before it could be called Fedora. Are we delegating that to FESCo? This, of course, implies that some form of review things occurs at some level. > > Are torrents/URLs to Secondary arch releases to be linked from the > > fedoraproject.org website assuming they are granted Fedora status? > > Yes. OK. josh From gemi at bluewin.ch Tue Jul 10 20:24:34 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 10 Jul 2007 22:24:34 +0200 Subject: Fedora Extras Package Build Report 2007-07-10 In-Reply-To: <20070710185235.6769F152134@buildsys.fedoraproject.org> References: <20070710185235.6769F152134@buildsys.fedoraproject.org> Message-ID: <1184099074.9807.2.camel@localhost.localdomain> On Tue, 2007-07-10 at 14:52 -0400, buildsys at fedoraproject.org wrote: > NEW tgif-4.1.45-3.fc6 : 2-D drawling tool Shouldn't this be "drawing"? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From j.w.r.degoede at hhs.nl Tue Jul 10 20:29:19 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Jul 2007 22:29:19 +0200 Subject: Very strange buildsys mail: [Fwd: Broken dependencies: lzo] Message-ID: <4693EC1F.2070609@hhs.nl> Hi all, See the forwarded mail, I got something similar for lua ??? Some kinda glitch? Regards, Hans -------------- next part -------------- An embedded message was scrubbed... From: root Subject: Broken dependencies: lzo Date: Tue, 10 Jul 2007 12:59:53 -0700 Size: 4471 URL: From tcallawa at redhat.com Tue Jul 10 20:31:07 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Jul 2007 15:31:07 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184098537.32199.33.camel@weaponx.rchland.ibm.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <1184098537.32199.33.camel@weaponx.rchland.ibm.com> Message-ID: <1184099467.3490.105.camel@localhost.localdomain> On Tue, 2007-07-10 at 15:15 -0500, Josh Boyer wrote: > By that definition, the primary arches don't qualify either. They're > built using RHEL + koji. Not that I really argue with the definition > mind you. Just interesting from a primary vs. secondary requirements > perspective. Oh, you mean underneath the buildsystem? Don't care. :) I'd prefer Fedora, but if it doesn't exist yet, I won't require it. > > > How are Secondary arch releases suppose to go about getting official > > > "Fedora" status? > > > > The secondary arch team exists, has a working koji buildsystem, is > > okayed by FESCo, and has packages (and or trees) ready by either the > > main Fedora timeline or a reasonable timeline defined by the secondary > > arch team. > > Back in Nov. 2006, there was also the concept that FPB had to approve a > secondary arch release before it could be called Fedora. Are we > delegating that to FESCo? This, of course, implies that some form of > review things occurs at some level. Outside of the scope of the FPB. ~spot From dennis at ausil.us Tue Jul 10 20:33:02 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jul 2007 15:33:02 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184098537.32199.33.camel@weaponx.rchland.ibm.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184098537.32199.33.camel@weaponx.rchland.ibm.com> Message-ID: <200707101533.02286.dennis@ausil.us> On Tuesday 10 July 2007 3:15:37 pm Josh Boyer wrote: > On Tue, 2007-07-10 at 14:42 -0500, Tom "spot" Callaway wrote: > > On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: > > > What exactly constitutes the buildsystem? E.g. if koji is running on a > > > different distribution, it's not building the packages with the same > > > toolset that the primary architectures are on. (I realize there is a > > > chicken/egg scenario here). > > > > Fedora + koji constitutes the buildsystem. The secondary arch team may > > need to create a manual bootstrap of a Fedora environment before they're > > ready to build packages. > > By that definition, the primary arches don't qualify either. They're > built using RHEL + koji. Not that I really argue with the definition > mind you. Just interesting from a primary vs. secondary requirements > perspective. Actually the primary arch builders are all running FC-6 as is koji.fedoraproject.org > > > How are Secondary arch releases suppose to go about getting official > > > "Fedora" status? > > > > The secondary arch team exists, has a working koji buildsystem, is > > okayed by FESCo, and has packages (and or trees) ready by either the > > main Fedora timeline or a reasonable timeline defined by the secondary > > arch team. > Back in Nov. 2006, there was also the concept that FPB had to approve a > secondary arch release before it could be called Fedora. Are we > delegating that to FESCo? This, of course, implies that some form of > review things occurs at some level. I think FESCo is the correct place for the decision. From kevin.kofler at chello.at Tue Jul 10 20:50:05 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 10 Jul 2007 20:50:05 +0000 (UTC) Subject: Will FC6/FE6 merge / move to Koji? Message-ID: Will FC6/FE6 merge and move to Koji at some point? (I believe that was part of the original merge plan, I might be mistaken though. In any case, no date has been determined that I know of.) Or will the old build systems just stay up until Fedora 6 EOL? If a merge is planned, is there any timeframe for it yet? Kevin Kofler From dennis at ausil.us Tue Jul 10 21:06:41 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jul 2007 16:06:41 -0500 Subject: Will FC6/FE6 merge / move to Koji? In-Reply-To: References: Message-ID: <200707101606.41878.dennis@ausil.us> On Tuesday 10 July 2007 3:50:05 pm Kevin Kofler wrote: > Will FC6/FE6 merge and move to Koji at some point? (I believe that was part > of the original merge plan, I might be mistaken though. In any case, no > date has been determined that I know of.) Or will the old build systems > just stay up until Fedora 6 EOL? If a merge is planned, is there any > timeframe for it yet? > > Kevin Kofler Personally I would like to leave it as is. we still need plague for EPEL so by switching we wont be freeing up resources. currently plague and koji are co-existing on the same builders peacefully. Dennis From mclasen at redhat.com Wed Jul 11 02:59:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 10 Jul 2007 22:59:57 -0400 Subject: the gtksourceview situation Message-ID: <1184122797.3275.8.camel@localhost.localdomain> ...has finally been resolved. It took a little longer than I had hoped. There is now a gtksourceview2 package, that will contain (unsurprisingly) version 2 (currently 1.90.2), and gtksourceview has been downgraded to 1.8.5, with an epoch. The python bindings are in pygtksourceview (for version 2) and gnome-python2-gtksourceview (for version 1). gedit has been rebuilt against gtksourceview2. If you maintain packages which depend on gtksourceview, you probably want to check your Requires: and rebuild. Matthias From buildsys at redhat.com Wed Jul 11 03:22:16 2007 From: buildsys at redhat.com (Build System) Date: Tue, 10 Jul 2007 23:22:16 -0400 Subject: rawhide report: 20070710 changes Message-ID: <200707110322.l6B3MGFS011841@porkchop.devel.redhat.com> New package gdesklets-goodweather Themeable weather and condition display for gdesklet New package gshutdown GShutDown is an advanced shut down utility for GNOME New package kicker-compiz Makes KDE kicker Pager applet work with compiz New package libp11 Library for using PKCS#11 modules New package libtomcrypt a comprehensive, portable cryptographic toolkit New package libtommath a portable number theoretic multiple-precision integer library New package perl-NetAddr-IP Manages IPv4 and IPv6 addresses and subnets New package proxychains Provides proxy support to any application New package tgif 2-D drawling tool New package urlview URL extractor/launcher New package xcb-proto XCB protocol descriptions Updated Packages: aria2-0.11.1-1.fc8 ------------------ * Mon Jul 09 2007 Micha?? Bentkowski - 0.11.1-1 - Update to 0.11.1 at-3.1.10-14.fc8 ---------------- * Mon Jul 09 2007 Marcela Maslanova - 3.1.10-14 - feature: add configuration file - fix -V option - fix init script at-spi-1.19.5-1.fc8 ------------------- * Tue Jul 10 2007 Matthias Clasen - 1.19.5-1 - Update to 1.19.5 bcel-0:5.1-10jpp.3.fc8 ---------------------- * Mon Jul 09 2007 Permaine Cheung 0:5.1-10jpp.3 - Fixed unowned directory * Thu Apr 19 2007 Permaine Cheung 0:5.1-10jpp.2 - Rebuild cfitsio-3.040-1.fc8 ------------------- * Mon Jul 09 2007 Matthew Truch - 3.040-1 - Upgrade to version 3.040 of cfitsio. control-center-1:2.19.5-1.fc8 ----------------------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 crossvc-1.5.2-0.1.fc8 --------------------- * Mon Jul 09 2007 Jochen Schmitt 1.5.2-0.1 - Prerelease of CrossVC-1.5.2 (Fix #246024) dasher-4.5.2-1.fc8 ------------------ * Mon Jul 09 2007 Matthias Clasen - 4.5.2-1 - Update to 4.5.2 dates-0.4.3-1.fc8 ----------------- * Mon Jul 09 2007 Denis Leroy - 0.4.3-1 - Update to 0.4.3 - Added X prefix to SingleInstance in desktop file deluge-0.5.2-1.fc8 ------------------ * Sun Jul 08 2007 Peter Gordon - 0.5.2-1 - Update to new upstream release (0.5.2) - Update Summary and %description to reflect new ??Torrent-compatible Peer Exchange ("PEX") functionality. * Thu Jun 07 2007 Peter Gordon - 0.5.0.90.2-2 - Update to new upstream release (0.5.1 Beta 2) dhcp-12:3.0.6-1.fc8 ------------------- * Tue Jul 10 2007 David Cantrell - 12:3.0.6-1 - Upgrade to ISC dhcp-3.0.6 - Remove the -TERM option from killproc command (#245317) * Wed Jun 20 2007 David Cantrell - 12:3.0.5-37 - For init script functions, echo new line after OK or FAIL msg (#244956) * Fri Jun 15 2007 David Cantrell - 12:3.0.5-36 - BOOTP_BROADCAST_ALWAYS is not the same as ATSFP, fixed - Added anycast mac support to dhclient for OLPC dtc-0-0.4.20070709.fc8 ---------------------- * Mon Jul 09 2007 Josh Boyer - Update to new snapshot ebtables-2.0.8-2.fc8 -------------------- * Mon Jul 09 2007 Tom "spot" Callaway 2.0.8-2 - remove "Fedora Core" reference in spec eel2-2.19.5-1.fc8 ----------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 eog-2.19.4-1.fc8 ---------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 epiphany-2.19.5-1.fc8 --------------------- * Tue Jul 10 2007 Matthias Clasen 2.19.5-1 - Update to 2.19.5 * Fri May 25 2007 Christopher Aillon 2.19.2-2 - Rebuild against newer gecko * Mon May 21 2007 Matthias Clasen 2.19.2-1 - Update to 2.19.2 evince-0.9.2-1.fc8 ------------------ * Tue Jul 10 2007 Matthias Clasen - 0.9.2-1 - Update to 0.9.2 evolution-data-server-1.11.5-1.fc8 ---------------------------------- * Mon Jul 09 2007 Matthew Barnes - 1.11.5-1.fc8 - Update to 1.11.5 evolution-exchange-2.11.5-1.fc8 ------------------------------- * Mon Jul 09 2007 Matthew Barnes - 2.11.5-1.fc8 - Update to 2.11.5 firefox-2.0.0.4-3.fc8 --------------------- * Fri Jun 29 2007 Martin Stransky 2.0.0.4-3 - backported pango patches from FC6 (1.5.0.12) fortune-firefly-2.1.2-4.fc8 --------------------------- * Mon Jul 09 2007 Karen Pease - 2.1.2.4 - Upping tag to sync builds. * Mon Jul 09 2007 Karen Pease - 2.1.2.3 - Upping tag to sync builds. * Mon May 07 2007 Karen Pease - 2.1.2.2 - Upping tag to sync builds. gail-1.19.5-1.fc8 ----------------- * Tue Jul 10 2007 Matthias Clasen - 1.19.5-1 - Update to 1.19.5 gc-7.0-1.fc8 ------------ * Mon Jul 09 2007 Rex Dieter 7.0-1 - gc-7.0 * Mon Dec 11 2006 Rex Dieter 6.8-3 - Obsoletes/Provides: libgc(-devel) (rpmforge compatibility) * Mon Aug 28 2006 Rex Dieter 6.8-2 - fc6 respin gimp-2:2.2.16-1.fc8 ------------------- * Mon Jul 09 2007 Nils Philippsen - 2:2.2.16-1 - version 2.2.16 Bugs fixed in GIMP 2.2.16 ========================= - improved input value validation in several file plug-ins (bug #453973) - improved handling of corrupt or invalid XCF files - guard against integer overflows in several file plug-ins (bug #451379) - fixed handling of background alpha channel in XCF files (bug #443097) - improved forward compatibility of the config parser - fixed crash when previewing some animated brushes (bug #446005) - remove obsolete psd-invalid-dimensions patch gnome-keyring-2.19.5-1.fc8 -------------------------- * Mon Jul 09 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 * Sun May 20 2007 Matthias Clasen - 2.19.2-1 - Update to 2.19.2 * Tue Mar 13 2007 Matthias Clasen - 0.8-1 - Update to 0.8 gnome-launch-box-0.4-2.fc8 -------------------------- gnome-panel-2.19.5-1.fc8 ------------------------ * Sun Jul 08 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gnome-screensaver-2.19.1.1-2.fc8 -------------------------------- * Mon Jul 09 2007 Ray Strode - 2.19.1.1-2 - add missing build requires to get fade animation back (bug 247485) gnome-sharp-2.16.0-2.fc8 ------------------------ * Tue Jul 10 2007 Xavier Lamien < lxtnow[at]gmail.com > - 2.16.0-2 - Fixed build with automake-1.10 [bug #247592]. gnome-speech-0.4.15-1.fc8 ------------------------- * Mon Jul 09 2007 Matthias Clasen - 0.4.15-1 - Updat to 0.4.15 gnome-system-monitor-2.19.5-1.fc8 --------------------------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gnome-themes-2.19.5-1.fc8 ------------------------- * Mon Jul 09 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 gok-1.3.1-1.fc8 --------------- * Tue Jul 10 2007 Matthias Clasen - 1.3.1-1 - Update to 1.3.1 gpgme-1.1.5-1.fc8 ----------------- * Mon Jul 09 2007 Rex Dieter 1.1.5-1 - gpgme-1.1.5 gscan2pdf-0.9.13-1.fc8 ---------------------- * Mon Jul 09 2007 Bernard Johnson - 0.9.13-1 - v 0.9.13 * Thu Jun 21 2007 Bernard Johnson - 0.9.12-2 - fix requires from ImageMagick to ImageMagick-perl - add History to %doc list gtk-gnutella-0.96.4-1.fc8 ------------------------- * Tue Jul 10 2007 Dmitry Butskoy - 0.96.4-1 - update to 0.96.4 * Tue Jun 26 2007 Dmitry Butskoy - drop X-Fedora category from desktop file gtk2-engines-2.11.3-1.fc8 ------------------------- * Tue Jul 10 2007 Matthias Clasen - 2.11.3-1 - Update to 2.11.3 gtkhtml3-3.15.5-1.fc8 --------------------- * Mon Jul 09 2007 Matthew Barnes - 3.15.5-1.fc8 - Update to 3.15.5 * Mon Jun 18 2007 Matthew Barnes - 3.15.4-1.fc8 - Update to 3.15.4 * Mon Jun 04 2007 Matthew Barnes - 3.15.3-1.fc8 - Update to 3.15.3 hddtemp-0.3-0.12.beta15.fc8 --------------------------- * Tue Jul 10 2007 Ville Skytt?? - 0.3-0.12.beta15 - Improve init script LSB compliance. hdparm-7.6-1.fc8 ---------------- * Tue Jul 10 2007 Karsten Hopp 7.6-1 - update to version 7.6 highlight-2.6.1-1.fc8 --------------------- * Tue Jul 10 2007 Jochen Schmitt 2.6.1-1 - New upstream release * Tue Feb 06 2007 Jochen Schmitt 2.4.8-2 - fir rpmopt bug (#227292) * Mon Oct 23 2006 Jochen Schmitt 2.4.8-1 - New upstream release hplip-2.7.6-5.fc8 ----------------- * Mon Jul 09 2007 Tim Waugh 2.7.6-5 - Read system config when run as root (bug #242974). * Mon Jul 09 2007 Tim Waugh 2.7.6-4 - Moved reportlab requirement to gui sub-package (bug #189030). - Patchlevel 1. hunspell-bg-4.0-1.fc8 --------------------- hunspell-ca-0.20060508-1.fc8 ---------------------------- hunspell-da-1.7.13-1.fc8 ------------------------ icu4j-0:3.6.1-1jpp.2.fc8 ------------------------ * Wed Jun 27 2007 Ben Konrath - 0:3.6.1-1jpp.2 - Remove requires eclipse-rcp in eclipse sub-package. k3d-0.6.7.0-1.fc8 ----------------- * Mon Jul 09 2007 Denis Leroy - 0.6.7.0-1 - Update to 0.6.7.0 - Removed patches that moved upstream - Added gnome-vfs2-devel, fixed gnome-vfs2 missing config - Fixed lib64 script to avoid autoreconf - Added aqsis dependency - Removed MultipleArgs from desktop file * Fri Dec 29 2006 Denis Leroy - 0.6.5.0-1 - Update to 0.6.5.0 - Added patch to fix x86_64 startup crash in viewport widget - Added patch to fix python 2.5 API changes * Mon Dec 11 2006 Denis Leroy - 0.6.4.0-2 - Rebuild with python 2.5 kdelibs-6:3.5.7-9.fc8 --------------------- * Mon Jul 09 2007 Rex Dieter - 6:3.5.7-9 - omit ICEauthority patch (kde#147454, rh#247455) kernel-2.6.22-1.fc8 ------------------- * Mon Jul 09 2007 Dave Jones - 2.6.22 kexec-tools-1.101-73.fc8 ------------------------ * Mon Jul 09 2007 Neil Horman - 1.101-73.fc8 - Fix up language files for kexec (bz 246508) libgail-gnome-1.19.5-1.fc8 -------------------------- * Tue Jul 10 2007 Matthias Clasen - 1.19.5-1 - Update to 1.19.5 libgnomecanvas-2.19.0-1.fc8 --------------------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.0-1 - Update to 2.19.0 * Thu Dec 07 2006 Matthias Clasen - 2.14.0-5 - Small spec file cleanups * Wed Jul 12 2006 Jesse Keating - 2.14.0-4.1 - rebuild libgtop2-2.19.5-1.fc8 --------------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 libpaper-1.1.21-1.fc8.1 ----------------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.1.21-1.1 - BR: libtool * Mon Jul 09 2007 Tom "spot" Callaway 1.1.21-1 - bump to 1.1.21 - fix automake bug (bz 247458) libpri-1.4.1-1.fc8 ------------------ * Mon Jul 09 2007 Jeffrey C. Ollie - 1.4.1-1 - Update to 1.4.1 libselinux-2.0.23-2.fc8 ----------------------- * Tue Jul 10 2007 Dan Walsh - 2.0.23-2 - Fix man page markup lanquage for translations libtirpc-0.1.7-7.fc8 -------------------- * Mon Jul 09 2007 0.1.7-7 - Fixed infinite loop in svc_run() (bz 246677) * Thu Apr 26 2007 0.1.7-6 - Fixed potential buffer overflow in xdr_strings - Added a optimization to bindresvport that allows more ports to be tried. libvirt-0.3.0-1.fc8 ------------------- * Mon Jul 09 2007 Daniel Veillard - 0.3.0-1.fc8 - Release of 0.3.0 - Secure remote access support - unification of daemons - lots of assorted bugfixes and cleanups - documentation and localization improvements * Fri Jun 08 2007 Daniel Veillard - 0.2.3-1.fc8 - Release of 0.2.3 - lot of assorted bugfixes and cleanups - support for Xen-3.1 - new scheduler API * Tue Apr 17 2007 Daniel Veillard - 0.2.2-1 - Release of 0.2.2 - lot of assorted bugfixes and cleanups - preparing for Xen-3.0.5 lincity-ng-1.1.0-1.fc8.1 ------------------------ * Mon Jul 09 2007 Tom "spot" Callaway 1.1.0-1.1 - rebuild for new SDL_gfx in rawhide logwatch-7.3.6-5.fc8 -------------------- * Tue Jul 10 2007 Ivana Varekova 7.3.6-5 - Resolves: #247511 add zz-disk_space patch * Tue Jul 10 2007 Ivana Varekova 7.3.6-4 - Resolves: #246655 add cron service patch mailcap-2.1.25-1.fc8 -------------------- * Tue Jul 10 2007 Miroslav Lichvar 2.1.25-1 - add image/vnd.microsoft.icon to mime.types (#247222) mdadm-2.6.2-4.fc8 ----------------- * Mon Jul 09 2007 Doug Ledford - 2.6.2-4 - Oops, if we call -C -e1, minor_version is no longer properly set, fix that up - Related: bz230207 minicom-2.2-2.fc8 ----------------- * Tue Jul 10 2007 Miroslav Lichvar 2.2-2 - improve signal handling a bit (#246465) nagios-2.9-2.fc8 ---------------- * Tue Jul 10 2007 Mike McGrath 2.9-2 - Release bump nautilus-2.19.5-1.fc8 --------------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 * Fri Jul 06 2007 Matthias Clasen - 2.19.4-2 - Fix directory ownership issues * Mon Jun 18 2007 Matthias Clasen - 2.19.4-1 - Update to 2.19.4 nethack-3.4.3-14.fc8 -------------------- * Mon Jul 09 2007 Luke Macken 3.4.3-14 - Fix nethack.desktop (Bug #247373) * Sun Jul 08 2007 Florian La Roche 3.4.3-13 - require xorg-x11-font-utils (to run mkfontdir) for post script * Mon Oct 16 2006 Luke Macken 3.4.3-12 - Own /usr/games/nethack-3.4.3 nginx-0.5.27-1.fc8 ------------------ * Mon Jul 09 2007 Jeremy Hinegardner - 0.5.27-1 - Update to 0.5.27 ntfsprogs-1.13.1-5.fc8 ---------------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.13.1-5 - don't package items which say they should never be installed (resolves bz 247398) openldap-2.3.34-6.fc8 --------------------- * Wed Jul 04 2007 Jan Safranek 2.3.34-6.fc8 - fix compat-slapcat compilation. Now it can be found in /usr/lib/compat-openldap/slapcat, because the tool checks argv[0] (#246581) orca-2.19.5-1.fc8 ----------------- * Mon Jul 09 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 perl-Crypt-Simple-0.06-4.fc8 ---------------------------- * Mon Jul 09 2007 Allisson Azevedo 0.06-4 - Add exception for FC-6 perl-File-Remove-0.37-1.fc8 --------------------------- * Tue Jul 10 2007 Ralf Cors??pius - 0.37-1 - Upstream update. * Mon Jul 02 2007 Ralf Cors??pius - 0.36-2 - Increment release due to koji suckage. * Mon Jul 02 2007 Ralf Cors??pius - 0.36-1 - Upsteam update. - BR: perl(ExtUtils::MakeMaker). - BR: perl(Test::More). php-pear-Net-Ping-2.4.2-1.fc8 ----------------------------- pkgconfig-1:0.22-1.fc8 ---------------------- * Tue Jul 10 2007 Matthias Clasen - 1:0.22-1 - Update to 0.22 - Drop upstreamed patch powertop-1.7-3.fc8 ------------------ * Mon Jul 09 2007 Adam Jackson 1.7-3 - powertop-1.7-strncpy.patch: Use strncpy() to avoid stack smash. Patch from Till Maas. (#246796) pygtk2-2.10.6-1.fc8 ------------------- * Tue Jul 10 2007 Matthew Barnes - 2.10.6-1.fc8 - Update to 2.10.6 * Mon Jul 09 2007 Matthew Barnes - 2.10.5-1.fc8 - Update to 2.10.5 python-genshi-0.4.2-2.fc8 ------------------------- * Mon Jul 09 2007 Jeffrey C. Ollie - 0.4.2-2 - BR python-setuptools so that egg-info files get installed. Fixes #247430. qgis-0.8.1-11.fc8 ----------------- * Tue Jul 10 2007 Douglas E. Warner 0.8.1-11 - allowing docs to be installed by qgis so they can be referenced by internal help system (bug#241403) - updated lib64 patch (bug#247549) to try to get plugins found on x86_64 rb_libtorrent-0.12-1.fc8 ------------------------ * Thu Jun 07 2007 Peter Gordon - 0.12-1 - Update to new upstream release (0.12 Final) - Split examples into a subpackage. Applications that use rb_libtorrent don't need the example binaries installed; and splitting the package in this manner is a bit more friendly to multilib environments. * Sun Mar 11 2007 Peter Gordon - 0.12-0.rc1 - Update to new upstream release (0.12 RC). - Forcibly use the system libtool to ensure that we remove any RPATH hacks. rdate-1.4-8.fc8 --------------- * Tue Jul 10 2007 Jiri Moskovcak 1.4-8 - fixes memory allocation - Resolves: #190883 rpm-4.4.2.1-0.4.rc3 ------------------- * Mon Jul 09 2007 Panu Matilainen 4.4.2.1-0.4.rc3 - 4.4.2.1-rc3 * Wed Jul 04 2007 Panu Matilainen 4.4.2.1-0.4.rc2 - 4.4.2.1-rc2 * Thu Jun 28 2007 Panu Matilainen 4.4.2.1-0.3.rc1 - don't hang because of leftover query iterators (#246044) scrub-1.9-1.fc8 --------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.9-1 - bump to 1.9 slang-2.1.1-1.fc8 ----------------- * Mon Jul 09 2007 Miroslav Lichvar - 2.1.1-1 - update to 2.1.1 synaptic-0.57.2-12.fc8 ---------------------- * Tue Jul 10 2007 Panu Matilainen - 0.57.2-12 - fix desktop categories - fix pam_stack autodetection * Sun Jul 08 2007 Panu Matilainen - 0.57.2-11 - add an ugly kludge to make it work with new apt-rpm progress api - update buildreq apt version for the above * Sun Jun 03 2007 Axel Thimm - 0.57.2-10 - Autodetect pam_stack module at build time. system-config-printer-0.7.70-1.fc8 ---------------------------------- * Mon Jul 09 2007 Tim Waugh 0.7.70-1 - Requires pirut for system-install-packages. - 0.7.70: - Increased GetReady->NewPrinter timeout. - More binary names mapped to package named. - Run system-install-packages to install missing drivers (bug #246726). - Less debug output. - Desktop file fixes for KDE (bug #247299). udev-113-3.fc8 -------------- * Mon Jul 09 2007 Harald Hoyer - 113-3 - speedup things a little bit uw-imap-2006j-1.fc8 ------------------- * Mon Jul 09 2007 Rex Dieter 2006j-1 - imap-2006j1 vino-2.19.5-1.fc8 ----------------- * Mon Jul 09 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 vsftpd-2.0.5-18.fc8 ------------------- * Tue Jul 10 2007 Maros Barabas - 2.0.5-18 - Add comment for xferlog_std_format - Resolves #218260 wavbreaker-0.8.1-2.fc8 ---------------------- * Fri Jul 06 2007 Homer 0.8.1-2 - new version 0.8.1 wireshark-0.99.6-1.fc8 ---------------------- * Mon Jul 09 2007 Radek Vokal 0.99.6-1 - upgrade to 0.99.6 final xchat-1:2.8.4-2.fc8 ------------------- * Tue Jul 10 2007 Kevin Kofler - 1:2.8.4-2 - apply xc284-scrollbmkdir.diff from upstream xchat-gnome-0.18-2.fc8 ---------------------- * Mon Jul 09 2007 Brian Pepple - 0.18-2 - Drop requires on python, since dep on python-libs will be pulled in. * Mon Jul 09 2007 Brian Pepple - 0.18-1 - Update to 0.18. - Drop static patch, fixed upstream. - Drop setup-dialog patch, fixed upstream. - Drop gettext patch. - Update config patch. * Sun Jun 10 2007 Brian Pepple - 0.17-7 - Drop requires on yelp. xdg-user-dirs-gtk-0.5-2.fc8 --------------------------- * Fri Jul 06 2007 Matthias Clasen - 0.5-2 - Make the autostart file work in KDE (#247304) xfdesktop-4.4.1-2.fc8 --------------------- * Mon Jul 09 2007 Kevin Fenzi - 4.4.1-2 - Add patch to fix menu lockups with new gtk2 xfwm4-4.4.1-2.fc8 ----------------- * Mon Jul 09 2007 Kevin Fenzi - 4.4.1-2 - Add patch for gtk2 hang issue (fixes #243735) xmoto-0.3.1-1.fc8 ----------------- * Mon Jul 09 2007 Jon Ciesla 0.3.1-1 - Bumped to upstream, BZ 247445. * Wed Jun 20 2007 Jon Ciesla 0.3.0-1 - Bumped to upstream. * Mon Mar 19 2007 Jon Ciesla 0.2.7-1 - Bumped to upstream, fixed man issues. xorg-x11-drv-savage-2.1.2-5.fc8 ------------------------------- * Mon Jul 09 2007 Adam Jackson 2.1.2-5 - savage-2.1.2-panel-range-hack.patch: If we find a panel but no EDID, stretch the sync ranges out to fit the panel size. (#243589) zzuf-0.9-1.fc8 -------------- Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anaconda - 11.3.0.5-1.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) anaconda - 11.3.0.5-1.i386 requires libdhcp4client-3.0.5.so.0 anjuta - 1:2.1.0-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.i386 requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) conglomerate - 0.9.1-3.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.i386 requires libgtksourceview-1.0.so.0 drivel - 2.1.0-0.4.20060527cvs.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 gedit-plugins - 2.18.0-2.fc7.i386 requires libgtksourceview-1.0.so.0 gedit-plugins - 2.18.0-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) glom - 1.4.4-1.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-genius - 0.7.7-2.fc7.i386 requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.i386 requires libgtksourceview-1.0.so.0 gobby - 0.4.3-1.fc7.x86_64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libdhcp - 1.25-1.fc8.i386 requires libdhcp4client-3.0.5.so.0 libdhcp - 1.25-1.fc8.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.i386 requires libgtksourceview-1.0.so.0 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 mkinitrd - 6.0.9-7.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 nemiver - 0.4.0-1.fc8.i386 requires libgtksourceview-1.0.so.0 nemiver - 0.4.0-1.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 ruby-gtksourceview - 0.16.0-6.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.i386 requires libgtksourceview-1.0.so.0 scratchpad - 0.3.0-3.fc8.x86_64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.i386 requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anaconda - 11.3.0.5-1.ppc requires libdhcp4client-3.0.5.so.0 anaconda - 11.3.0.5-1.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) anjuta - 1:2.1.0-1.fc7.ppc requires libgtksourceview-1.0.so.0 ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc requires libgtksourceview-1.0.so.0 conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc requires libgtksourceview-1.0.so.0 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc requires libgtksourceview-1.0.so.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-genius - 0.7.7-2.fc7.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc requires libgtksourceview-1.0.so.0 gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc requires libgtksourceview-1.0.so.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libdhcp - 1.25-1.fc8.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) libdhcp - 1.25-1.fc8.ppc requires libdhcp4client-3.0.5.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc requires libgtksourceview-1.0.so.0 libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.ppc requires libdhcp4client-3.0.5.so.0 mkinitrd - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.ppc requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc requires libgtksourceview-1.0.so.0 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc requires libgtksourceview-1.0.so.0 ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc requires libgtksourceview-1.0.so.0 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anaconda - 11.3.0.5-1.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) conglomerate - 0.9.1-3.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) drivel - 2.1.0-0.4.20060527cvs.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) gedit-plugins - 2.18.0-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-genius - 0.7.7-2.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gnome-python2-gtksourceview - 2.18.0-4.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) gobby - 0.4.3-1.fc7.ppc64 requires libgtksourceview-1.0.so.0()(64bit) kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 libdhcp - 1.25-1.fc8.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) libgtksourceviewmm - 0.3.1-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) mkinitrd - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) nemiver - 0.4.0-1.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtksourceview - 0.16.0-6.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) scratchpad - 0.3.0-3.fc8.ppc64 requires libgtksourceview-1.0.so.0()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From debarshi.ray at gmail.com Wed Jul 11 03:24:22 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 11 Jul 2007 08:54:22 +0530 Subject: hosted.fedoraproject.org Message-ID: <3170f42f0707102024j75e74210x637072a78850e4b8@mail.gmail.com> I am doing a student doing Summer of Code under The Fedora Project (https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay), and would like to host my project at hosted.fedoraproject.org. http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/CreateNewProject says: "1. Log into hosted.fedoraproject.org" How do I log on? https://hosted.fedoraproject.org/ has no such thing, and neither can I SSH. I am a Fedora contributor and have an account ('rishi') on your accounts system, though. What do I do? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From notting at redhat.com Wed Jul 11 04:14:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 11 Jul 2007 00:14:39 -0400 Subject: Parallel Booting In-Reply-To: <4693944E.5010308@redhat.com> References: <467BE85E.4070807@redhat.com> <200706241337.20067.ville.skytta@iki.fi> <20070625164435.GB19608@nostromo.devel.redhat.com> <20070704010938.GA9335@nostromo.devel.redhat.com> <468E6B3C.6070100@redhat.com> <20070709190310.GD10904@nostromo.devel.redhat.com> <4693944E.5010308@redhat.com> Message-ID: <20070711041439.GA24456@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > Should be in rawhide... > # yum install prcsys Will check. > Btw, I am not interested in quenching the last seconds out of the system. > My primary interest is in getting dependencies in the initscripts and > adding the static dependencies is the first step. That's fine... I'm just concerned about using prcsys if it doesn't actually show much benefit. Bill From msaksena at marvell.com Wed Jul 11 05:15:48 2007 From: msaksena at marvell.com (Manas Saksena) Date: Tue, 10 Jul 2007 22:15:48 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184096545.3490.90.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> Message-ID: <46946784.8070902@marvell.com> Tom "spot" Callaway wrote: > On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: > >> How are Secondary arch releases suppose to go about getting official >> "Fedora" status? > > The secondary arch team exists, has a working koji buildsystem, is > okayed by FESCo, and has packages (and or trees) ready by either the > main Fedora timeline or a reasonable timeline defined by the secondary > arch team. A couple of additional questions on that front... First, I assume that secondary arches can have a subset of packages from the main Fedora release. It might be a good idea to specifically say that. I dont know how to quantify it, but it also probably needs to be a reasonably large subset for it to make sense. Second, can secondary architectures go beyond the primary architectures in terms of feature support? For e.g., can a secondary architecture include a cross-compiler toolchain? Along the same lines, can secondary architectures have modified spec files that go beyond fixing build/run-time issues. For e.g., can a secondary architecture take a large package and further split it into more granular subsets for the purpose of better footprint control. Essentially, these are real things that would be relevant for "embedded" architectures (like ARM). And, what I am trying to get to is what would make sense within the context of Fedora, and what may be features that need to be added in a derived from Fedora (but not Fedora) distribution. Manas From msaksena at marvell.com Wed Jul 11 05:18:56 2007 From: msaksena at marvell.com (Manas Saksena) Date: Tue, 10 Jul 2007 22:18:56 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184098537.32199.33.camel@weaponx.rchland.ibm.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <1184098537.32199.33.camel@weaponx.rchland.ibm.com> Message-ID: <46946840.3030904@marvell.com> Josh Boyer wrote: > On Tue, 2007-07-10 at 14:42 -0500, Tom "spot" Callaway wrote: >> On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: >> >>>> I'm only suggesting that the packager should need to _look_ at the >>>> failure before filing the required ExcludeArch bug and pushing a 'ship >>>> it anyway' button. I'm not saying that we should force them to start the >>>> build from scratch again like we do at the moment. >>> I agree. This is the largest objection I have to the current proposal. >> This is a significant workflow change. How should we force the packager >> to look at the failure before letting the packages push? > > Depends on how you look at it really. It's worth discussion anyway. I would like to think that if a package has built for an architecture before in the build system (i.e., we are not talking of the bootstrapping phase), then subsequent build failures deserve a look from the package maintainer. Regards, Manas From tgl at redhat.com Wed Jul 11 06:40:57 2007 From: tgl at redhat.com (Tom Lane) Date: Wed, 11 Jul 2007 02:40:57 -0400 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <46946784.8070902@marvell.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> Message-ID: <18171.1184136057@sss.pgh.pa.us> Manas Saksena writes: > ... First, I assume that secondary arches can have a subset of packages > from the main Fedora release. It might be a good idea to specifically > say that. I dont know how to quantify it, but it also probably needs > to be a reasonably large subset for it to make sense. The real bottom line here is very simple: if package A does not work on arch B, how close will we hold package A's maintainer's toes to the fire? To my mind, most open-source packages should aspire to work on every machine out there --- surely we all have a goal of world domination in mind? But I can see that some folks might have more limited goals, eg make game X work on hardware Y. If they publish their source code then I surely don't want to exclude them from the open-source community. I don't know how to resolve these tensions. But for the most part I think you should have a good excuse if you want to own a Fedora package that doesn't run on anything under the sun. If your goal does not include world domination, why not? regards, tom lane From tla at rasmil.dk Wed Jul 11 06:52:23 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 11 Jul 2007 08:52:23 +0200 Subject: hosted.fedoraproject.org In-Reply-To: <3170f42f0707102024j75e74210x637072a78850e4b8@mail.gmail.com> References: <3170f42f0707102024j75e74210x637072a78850e4b8@mail.gmail.com> Message-ID: <46947E27.3040807@rasmil.dk> Debarshi 'Rishi' Ray wrote: > I am doing a student doing Summer of Code under The Fedora Project > (https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay), and > would like to host my project at hosted.fedoraproject.org. > > http://fedoraproject.org/wiki/Infrastructure/ProjectHosting/CreateNewProject > > says: > "1. Log into hosted.fedoraproject.org" > > How do I log on? https://hosted.fedoraproject.org/ has no such thing, > and neither can I SSH. I am a Fedora contributor and have an account > ('rishi') on your accounts system, though. > > What do I do? > > Thanks, > Debarshi I think this page is instructions for a infrastructure admin. normal contributors can't create a new hosted projects, you have to make a request to the infrastructure team to get one. Tim From oliver at linux-kernel.at Wed Jul 11 08:13:53 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 11 Jul 2007 10:13:53 +0200 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <46946784.8070902@marvell.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> Message-ID: <46949141.8090804@linux-kernel.at> Hi Manas! On 07/11/2007 07:15 AM, Manas Saksena wrote: > Tom "spot" Callaway wrote: >> On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: >> >>> How are Secondary arch releases suppose to go about getting official >>> "Fedora" status? >> >> The secondary arch team exists, has a working koji buildsystem, is >> okayed by FESCo, and has packages (and or trees) ready by either the >> main Fedora timeline or a reasonable timeline defined by the secondary >> arch team. > > A couple of additional questions on that front... > > First, I assume that secondary arches can have a subset of packages > from the main Fedora release. It might be a good idea to specifically > say that. I dont know how to quantify it, but it also probably needs > to be a reasonably large subset for it to make sense. No subset. Koji will start every build on primary and secondary archs. If it's a package that only works on i386 (eg. lilo), then it will have an ExclusiveArch and therefor will not be built on SecArch. If it's something like openoffice that doesn't work yet on some SecArch, there must be an ExcludeArch in the spec. > Second, can secondary architectures go beyond the primary architectures > in terms of feature support? For e.g., can a secondary architecture > include a cross-compiler toolchain? Only if you do the usual package review process and it lands on fp.o CVS. > Along the same lines, can secondary architectures have modified spec > files that go beyond fixing build/run-time issues. For e.g., can a > secondary architecture take a large package and further split it into > more granular subsets for the purpose of better footprint control. No. Everything that is built, uis checked-out via CVS from fp.o CVS. If you want to modify a spec, you need to talk with the package maintainer... > Essentially, these are real things that would be relevant for "embedded" > architectures (like ARM). And, what I am trying to get to is what would > make sense within the context of Fedora, and what may be features that > need to be added in a derived from Fedora (but not Fedora) distribution. SecArch is just like ppc(64) and s390(x), everything get's built. If something breaks, ArchTeam needs to take care of. If something will never work on the SecArch because it's unfixable, you need to ExcludeArch it in the spec. Spot: Well, maybe we should think about the 'subset question'. It might make sense to exclude packages that *would* compile find on a SecArch, but doesn't make sense at all to have it on that arch. :-) -of From buildsys at redhat.com Wed Jul 11 09:36:34 2007 From: buildsys at redhat.com (Build System) Date: Wed, 11 Jul 2007 05:36:34 -0400 Subject: rawhide report: 20070711 changes Message-ID: <200707110936.l6B9aYAG028595@porkchop.devel.redhat.com> New package gdesklets-calendar A navigable calendar showing the entire month for gdesklet New package gtksourceview2 A library for viewing source files Removed package compat-wxPythonGTK2 Updated Packages: audit-1.5.5-1.fc8 ----------------- * Tue Jul 10 2007 Steve Grubb 1.5.5-1 - Add system-config-audit (Miloslav Trmac) - Correct bug in audit_make_equivalent function (Al Viro) * Tue Jun 26 2007 Steve Grubb 1.5.4-1 - Add feed interface to auparse library (John Dennis) - Apply patch to libauparse for unresolved symbols (#241178) - Apply patch to add line numbers for file events in libauparse (John Dennis) - Change seresults to seresult in libauparse (John Dennis) - Add unit32_t definition to swig (#244210) - Add support for directory auditing - Update acct field to be escaped ganymed-ssh2-210-3.fc8 ---------------------- gdm-1:2.19.4-1.fc8 ------------------ * Tue Jul 10 2007 Ray Strode - 1:2.19.4-1 - Update to 2.19.4 gedit-1:2.19.2-1.fc8 -------------------- * Tue Jul 10 2007 Matthias Clasen - 1:2.19.2-1 - Update to 2.19.2 - Require gtksourceview2 gnome-python2-desktop-2.19.1-2.fc8 ---------------------------------- * Tue Jul 10 2007 Matthias Clasen - 2.19.1-2 - Rebuild against gtksourceview * Sat Jul 07 2007 Matthew Barnes - 2.19.1-1 - Update to 2.19.1 - Update versions of required packages. - Remove patch for GNOME bug #428697 (fixed upstream). gtksourceview-1:1.8.5-2.fc8 --------------------------- * Tue Jul 10 2007 Matthias Clasen - 1:1.8.5-2 - Add an epoch and downgrade to 1.8.5; gtksourceview 2.x will live in the gtksourceview2 package2 * Wed Jun 27 2007 Matthias Clasen - 1.90.1-2 - Avoid a conflict with compat-gtksourceview * Mon Jun 18 2007 Matthias Clasen - 1.90.1-1 - Update to 1.90.1 - Update dependencies kernel-2.6.22-8.fc8 ------------------- * Tue Jul 10 2007 John W. Linville - Update git-wireless-dev.patch - Add upstream version of rtl8187 patch * Tue Jul 10 2007 Dave Jones - Split utrace up into multiple patches. * Mon Jul 09 2007 Chuck Ebbert - sky2: restore workarounds for lost interrupts libdhcp-1.25-2.fc8 ------------------ * Tue Jul 10 2007 David Cantrell - 1.25-2 - Rebuild against new dhcp packages lm_sensors-2.10.3-3.fc8 ----------------------- * Mon Jul 09 2007 Hans de Goede - 2.10.3-3 - Remove no longer needed patches 1, 2 & 6 - Various specfile cleanups to match the Fedora packaging guidelines this fixes bz 238787 amongst other things - Use lm_sensors provided initscript instead of our own private one, this stops the sometimes unnecessary loading of i2c-dev - No longer ship a static version of the library in -devel - Compile sensord and eepromer extra programs and put each in its own subpackage (bz 236904) phpPgAdmin-4.1.3-1.fc8 ---------------------- * Tue Jul 10 2007 Devrim Gunduz 4.1.3-1 - Update to 4.1.3 pygtksourceview-1.90.2-2.fc8 ---------------------------- * Tue Jul 10 2007 Matthias Clasen - 1.90.2-2 - Rebuild against the gtksourceview2 package rrdtool-1.2.999-0.3.r1144.fc8 ----------------------------- * Tue Jul 10 2007 Jarod Wilson 1.2.999-0.3.r1144 - Update to latest rrdtool pre-1.3 svn snapshot (svn r1144) - Add php abi check (Resolves: #247339) svnkit-1.1.2-3.fc8 ------------------ tclhttpd-3.5.1-14.fc8 --------------------- * Tue Jul 03 2007 Wart - 3.5.1-14 - Fix download URL - Remove dependency on fedora-usermgmt Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anaconda - 11.3.0.5-1.i386 requires libdhcp4client-3.0.5.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-em8300-PAE - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7debug kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libdhcp - 1.25-2.fc8.i386 requires libdhcp4client-3.0.5.so.0 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anaconda - 11.3.0.5-1.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-em8300-debug - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7debug kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libdhcp - 1.25-2.fc8.i386 requires libdhcp4client-3.0.5.so.0 libdhcp - 1.25-2.fc8.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anaconda - 11.3.0.5-1.ppc requires libdhcp4client-3.0.5.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7 kmod-em8300-smp - 0.16.2-7.2.6.21_1.3228.fc7.ppc requires kernel-ppc = 0:2.6.21-1.3228.fc7smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libdhcp - 1.25-2.fc8.ppc requires libdhcp4client-3.0.5.so.0 libdhcp - 1.25-2.fc8.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.ppc requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.ppc requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anaconda - 11.3.0.5-1.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7 kmod-em8300-kdump - 0.16.2-7.2.6.21_1.3228.fc7.ppc64 requires kernel-ppc64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 libdhcp - 1.25-2.fc8.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) mkinitrd - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From dwmw2 at infradead.org Wed Jul 11 10:35:49 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Jul 2007 11:35:49 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184096545.3490.90.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> Message-ID: <1184150149.17833.70.camel@pmac.infradead.org> On Tue, 2007-07-10 at 14:42 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-07-10 at 12:05 -0500, Josh Boyer wrote: > > > > I'm only suggesting that the packager should need to _look_ at the > > > failure before filing the required ExcludeArch bug and pushing a 'ship > > > it anyway' button. I'm not saying that we should force them to start the > > > build from scratch again like we do at the moment. > > > > I agree. This is the largest objection I have to the current proposal. > > This is a significant workflow change. It's a change from our current 'failure causes the whole build to abort' situation, yes. That's probably a good thing though. > How should we force the packager > to look at the failure before letting the packages push? I assume it'd just be another command to koji; from the command line or through the web interface. To push a partially-failed build, you just give it the bug number as required for the ExcludeArch, it'll (probably) rebuild the SRPM with the ExcludeArch added and then release the binary versions which _did_ build into their respective repositories. That doesn't seem like such a divergence from what we have a the moment, which waits for a final 'OK' that the package has built OK everywhere, before releasing the build to rawhide. It's just that it would now be "built OK _or_ approved anyway" instead of just "built OK". If a partially-failed build gets pushed, we may have to make the architectures on which it failed use the _older_ version of the package, rather than losing the package from the repository entirely. Otherwise, you end up with thinks like kernel-headers going missing and screwing the whole system whenever a kernel fails to build. Things _used_ to work like this, until relatively recently. -- dwmw2 From dwmw2 at infradead.org Wed Jul 11 10:29:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Jul 2007 11:29:31 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <18171.1184136057@sss.pgh.pa.us> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <18171.1184136057@sss.pgh.pa.us> Message-ID: <1184149771.17833.63.camel@pmac.infradead.org> On Wed, 2007-07-11 at 02:40 -0400, Tom Lane wrote: > Manas Saksena writes: > > ... First, I assume that secondary arches can have a subset of packages > > from the main Fedora release. It might be a good idea to specifically > > say that. I dont know how to quantify it, but it also probably needs > > to be a reasonably large subset for it to make sense. > > The real bottom line here is very simple: if package A does not work > on arch B, how close will we hold package A's maintainer's toes to > the fire? If package A _never_ worked, then the answer is 'not at all', in almost all cases. If there's a package which doesn't work and has never worked, then it'll usually fall to the architecture team to fix it unless the package maintainer is feeling particularly conscientious. Mostly, that'll be because there's real porting work to be done. Occasionally I suppose it might be because the code is crap and has problems like endianness issues, assumptions about 'char' being signed, etc. -- but if we have competent maintainers and decent code that shouldn't _often_ be the case. If the offending package is a _core_ package, and actually _matters_, then the architecture team will have fixed it before they ever call for their arch to be included as a secondary architecture. If, on the other hand, the package _used_ to work and has now broken, then the package maintainer should care about that. It's actually quite likely to turn out to be a generic bug and not really arch-specific at all. If they conclude that it _is_ arch-specific, and that they really don't care about it, then they have the option of pushing the failed build anyway. > To my mind, most open-source packages should aspire to work on every > machine out there --- surely we all have a goal of world domination > in mind? I agree. To that end, I agree with Chris that it would be useful to keep at least one big-endian arch and one arch with unsigned char in the 'primary' set, to help keep maintainers honest and set the expectations. It's not as if it's that hard to admit defeat and an ExcludeArch if you really have to -- or even if you just can't be bothered. > But I can see that some folks might have more limited goals, > eg make game X work on hardware Y. If they publish their source code > then I surely don't want to exclude them from the open-source > community. And we don't. There are packages in Fedora now which have ExcludeArch: x86_64 because the packager doesn't understand the code well enough to fix the basic word size issues. I think it's unwise for us to prioritise quantity over quality to such an extent, > I don't know how to resolve these tensions. But for the most part > I think you should have a good excuse if you want to own a Fedora > package that doesn't run on anything under the sun. If your goal > does not include world domination, why not? A good excuse, and an ExcludeArch: bug filed. That's the policy we already have, and it works quite well. -- dwmw2 From dwmw2 at infradead.org Wed Jul 11 11:02:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Jul 2007 12:02:19 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184149771.17833.63.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <18171.1184136057@sss.pgh.pa.us> <1184149771.17833.63.camel@pmac.infradead.org> Message-ID: <1184151739.17833.75.camel@pmac.infradead.org> On Wed, 2007-07-11 at 11:29 +0100, David Woodhouse wrote: > I think it's unwise for us to prioritise > quantity over quality to such an extent, Oops, there was supposed to be and end to that sentence, but Evolution kept going into an infinite malloc loop and I kept having to kill it before it ate all the memory in the system. I think it's unwise for us to prioritise quantity over quality to such an extent, but we do -- and that's a separate issue not directly related to the matter at hand. -- dwmw2 From jkeating at redhat.com Wed Jul 11 11:00:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 07:00:40 -0400 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <46949141.8090804@linux-kernel.at> References: <1184080763.3490.66.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> Message-ID: <200707110700.44026.jkeating@redhat.com> On Wednesday 11 July 2007 04:13:53 Oliver Falk wrote: > Spot: > Well, maybe we should think about the 'subset question'. It might make > sense to exclude packages that *would* compile find on a SecArch, but > doesn't make sense at all to have it on that arch. I think the subset question is more a matter of what you publish as a release. But that isn't the same as what builds for your arch, because while you as the arch maintainer may want to publish one subset, somebody else with a different need may wish to publish a larger or different subset and those packages should be available to them should they wish it. Just like we do the "Fedora" spin which is a subset of the Everything collection. -- 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 Wed Jul 11 11:02:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 07:02:18 -0400 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184150149.17833.70.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> Message-ID: <200707110702.18434.jkeating@redhat.com> On Wednesday 11 July 2007 06:35:49 David Woodhouse wrote: > If a partially-failed build gets pushed, we may have to make the > architectures on which it failed use the _older_ version of the package, > rather than losing the package from the repository entirely. Otherwise, > you end up with thinks like kernel-headers going missing and screwing > the whole system whenever a kernel fails to build. Things _used_ to work > like this, until relatively recently. They stopped because it led to a lot of weird package situations and mixed results. It was not a very good situation, it only made you /think/ you were moving on correctly when you really weren't and should have rebuilt everything with the new version once it was fixed anyway instead of keeping going. -- 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 oliver at linux-kernel.at Wed Jul 11 11:13:43 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 11 Jul 2007 13:13:43 +0200 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <200707110700.44026.jkeating@redhat.com> References: <1184080763.3490.66.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <200707110700.44026.jkeating@redhat.com> Message-ID: <4694BB67.7050800@linux-kernel.at> On 07/11/2007 01:00 PM, Jesse Keating wrote: > On Wednesday 11 July 2007 04:13:53 Oliver Falk wrote: >> Spot: >> Well, maybe we should think about the 'subset question'. It might make >> sense to exclude packages that *would* compile find on a SecArch, but >> doesn't make sense at all to have it on that arch. > > I think the subset question is more a matter of what you publish as a release. > But that isn't the same as what builds for your arch, because while you as > the arch maintainer may want to publish one subset, somebody else with a > different need may wish to publish a larger or different subset and those > packages should be available to them should they wish it. Just like we do > the "Fedora" spin which is a subset of the Everything collection. Good point Jesse. You're totally right. Forget about the subset question from my side :-) -of From dwmw2 at infradead.org Wed Jul 11 11:42:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Jul 2007 12:42:02 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <200707110702.18434.jkeating@redhat.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> Message-ID: <1184154122.17833.93.camel@pmac.infradead.org> On Wed, 2007-07-11 at 07:02 -0400, Jesse Keating wrote: > They stopped because it led to a lot of weird package situations and > mixed results. It was not a very good situation, it only made > you /think/ you were moving on correctly when you really weren't and > should have rebuilt everything with the new version once it was fixed > anyway instead of keeping going. Yes, I understand that there are disadvantages with that approach, just as there are disadvantages with the new approach. Nevertheless, if we're going to make it a frequent occurrence that packages can go missing on secondary architectures, then we are going to have to cope with that _somehow_. For the package in question to just disappear isn't likely to be workable. That's true even if we take the sensible option and require explicit approval from the package owner before shipping a partially-failed build. It's even more true if we do the insane thing and just let the partially-failed builds out into the repository automatically. (Although there's a school of thought that perhaps in that case in fact it becomes less important, because the secondary arch folks might as well not bother with us at all -- they'd not really be any better off than they are at the moment, fending for themselves entirely.) -- dwmw2 From jkeating at redhat.com Wed Jul 11 11:44:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 07:44:12 -0400 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184154122.17833.93.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <200707110702.18434.jkeating@redhat.com> <1184154122.17833.93.camel@pmac.infradead.org> Message-ID: <200707110744.12433.jkeating@redhat.com> On Wednesday 11 July 2007 07:42:02 David Woodhouse wrote: > Yes, I understand that there are disadvantages with that approach, just > as there are disadvantages with the new approach. > > Nevertheless, if we're going to make it a frequent occurrence that > packages can go missing on secondary architectures, then we are going to > have to cope with that _somehow_. For the package in question to just > disappear isn't likely to be workable. > > That's true even if we take the sensible option and require explicit > approval from the package owner before shipping a partially-failed > build. Actually I think you get what you want by default here. If the build fails on the secondary arch, that build isn't /imported/ on the secondary arch, and thus when querying the secondary arch collection on the secondary arch koji, you'll get the last successful build. Maybe not, I'm not entirely sure how the 'latest package' routines for repo creation are going to be handled between downstream and upstream kojis. There is certainly value in both approaches, and I think you're right, if the secondary arch koji just doesn't import the build that failed, it just has the previously built one, then it might be easier for that secondary arch to keep up, even if they have to do some rebuilding to really "catch up". -- 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 Wed Jul 11 13:30:57 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jul 2007 05:30:57 -0800 Subject: Please Read: Need help in replacing music in Fedora package In-Reply-To: <1184096594.3490.92.camel@localhost.localdomain> References: <1184015028.3490.19.camel@localhost.localdomain> <604aa7910707101029t76827866q1e5174cf2eec6527@mail.gmail.com> <4693CA10.60807@fedoraproject.org> <1184096594.3490.92.camel@localhost.localdomain> Message-ID: <604aa7910707110630w47d2f72ep51c70af424858d6f@mail.gmail.com> On 7/10/07, Tom spot Callaway wrote: > Redistributable without restriction. Thus, the NonComm clause is right > out. bah it looks like the summit music is noncomm. Magnatunes sells commercial licenses as a business model... so you'd have to negotiate a license change... don't know if its worth it. -jef"will never forgive the blender instructors at rhh for introducing him to the term 'man candy'"spaleta From ndbecker2 at gmail.com Wed Jul 11 14:22:13 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Jul 2007 10:22:13 -0400 Subject: improving listings editing? Message-ID: I am just trying out listings and it seems pretty good. One problem I see is I just needed to re-indent a bunch of code (happens to be python, so indent matters). I thought maybe I'd just edit the lyx file in emacs, but found out that the form of the listing in the lyx file was not very friendly to this. Since I doubt lyx will implement auto-indent or other emacs abilities (like re-indent region), it would be nice if there was a more convenient way to move back and forth between the lyx listing and an external tool. From pjones at redhat.com Wed Jul 11 14:31:39 2007 From: pjones at redhat.com (Peter Jones) Date: Wed, 11 Jul 2007 10:31:39 -0400 Subject: dmraid failure/test cases [fc5-7] In-Reply-To: <1183704185.3591.14.camel@home-desk> References: <1183704185.3591.14.camel@home-desk> Message-ID: <4694E9CB.1090804@redhat.com> Sean Bruno wrote: > I spent some time trying to arm wrestle my machines fake raid > controllers(ck804, sil 3118) and a pci board I had lying around(adaptec > 1210sa), and came to the conclusion that dmraid was causing me serious > grief. > > First off, I could _not_ get dmraid to go away during the install on > x86_64. Even the nodmraid kernel option failed me. Each time I booted > up with two disks connected to any controller, the only drive I had at > my disposal was /dev/mapper/mapper0. I did notice that there was a > 'disable dmraid' toggle in the advanced setup button in the installer, > however this option was grayed out in all situations that I could come > up with. You're sure that's "mapper0"? That looks suspicious to me. Asside from lvm (which would typically say "VolGroupMM-LogVolNN" or similar), the names we create for device mapper devices such as multipath and dmraid are of the forms "mpathN" (for multipath) and "format_$METADATAINFO", i.e. "sil_ahadejcacefa", where "sil" reflects that it's a SiL metadata format and "ahadejcacefa" is a hash of information from the metadata itself. "mapper0" isn't something the installer would choose for a device name. -- Peter From ffesti at redhat.com Wed Jul 11 14:49:45 2007 From: ffesti at redhat.com (Florian Festi) Date: Wed, 11 Jul 2007 16:49:45 +0200 Subject: Making evdev X11 input driver default? Message-ID: <4694EE09.2050604@redhat.com> Hi! Are there already any efforts/plans to make the evdev driver default for F8 or any later release? Who would be in charge of such decision? Is there anyone else working on xkbd files for evdev currently? Florian From ndbecker2 at gmail.com Wed Jul 11 15:01:12 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Jul 2007 11:01:12 -0400 Subject: improving listings editing? References: Message-ID: Sorry, that was sent to the wrong list From sean.bruno at dsl-only.net Wed Jul 11 15:14:05 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed, 11 Jul 2007 08:14:05 -0700 Subject: dmraid failure/test cases [fc5-7] In-Reply-To: <4694E9CB.1090804@redhat.com> References: <1183704185.3591.14.camel@home-desk> <4694E9CB.1090804@redhat.com> Message-ID: <1184166845.3161.49.camel@home-desk> On Wed, 2007-07-11 at 10:31 -0400, Peter Jones wrote: > Sean Bruno wrote: > > I spent some time trying to arm wrestle my machines fake raid > > controllers(ck804, sil 3118) and a pci board I had lying around(adaptec > > 1210sa), and came to the conclusion that dmraid was causing me serious > > grief. > > > > First off, I could _not_ get dmraid to go away during the install on > > x86_64. Even the nodmraid kernel option failed me. Each time I booted > > up with two disks connected to any controller, the only drive I had at > > my disposal was /dev/mapper/mapper0. I did notice that there was a > > 'disable dmraid' toggle in the advanced setup button in the installer, > > however this option was grayed out in all situations that I could come > > up with. > > You're sure that's "mapper0"? That looks suspicious to me. Asside from > lvm (which would typically say "VolGroupMM-LogVolNN" or similar), the > names we create for device mapper devices such as multipath and dmraid > are of the forms "mpathN" (for multipath) and "format_$METADATAINFO", > i.e. "sil_ahadejcacefa", where "sil" reflects that it's a SiL metadata > format and "ahadejcacefa" is a hash of information from the metadata > itself. "mapper0" isn't something the installer would choose for a > device name. > I just went back and retested, it is definitely "/dev/mapper/mpath0" as you stated Peter. I have no idea why I said mapper0 and why I repeated it so frequently. Anyway, what things can I test out for you folks? Sean From chris.stone at gmail.com Wed Jul 11 16:20:19 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 11 Jul 2007 09:20:19 -0700 Subject: Very strange buildsys mail: [Fwd: Broken dependencies: lzo] In-Reply-To: <4693EC1F.2070609@hhs.nl> References: <4693EC1F.2070609@hhs.nl> Message-ID: Yes I got 22 emails saying all my php-pear packages were missing the dependency /usr/bin/pear for el5. I sent the emails straight to /dev/null. Please fix this. On 7/10/07, Hans de Goede wrote: > Hi all, > > See the forwarded mail, I got something similar for lua ??? Some kinda glitch? > > Regards, > > Hans > > > > > lzo has broken dependencies in the development tree: > On ppc: > lzo - 2.02-2.el5.1.ppc requires libc.so.6 > lzo - 2.02-2.el5.1.ppc requires libc.so.6(GLIBC_2.0) > lzo - 2.02-2.el5.1.ppc requires rtld(GNU_HASH) > lzo - 2.02-2.el5.1.ppc requires /sbin/ldconfig > lzo - 2.02-2.el5.1.ppc requires libc.so.6(GLIBC_2.1.3) > On x86_64: > lzo - 2.02-2.el5.1.i386 requires libc.so.6(GLIBC_2.0) > lzo - 2.02-2.el5.1.i386 requires libc.so.6(GLIBC_2.4) > lzo - 2.02-2.el5.1.i386 requires rtld(GNU_HASH) > lzo - 2.02-2.el5.1.i386 requires /sbin/ldconfig > lzo - 2.02-2.el5.1.i386 requires libc.so.6(GLIBC_2.1.3) > lzo - 2.02-2.el5.1.i386 requires libc.so.6 > On i386: > lzo - 2.02-2.el5.1.i386 requires libc.so.6(GLIBC_2.0) > lzo - 2.02-2.el5.1.i386 requires libc.so.6(GLIBC_2.4) > lzo - 2.02-2.el5.1.i386 requires rtld(GNU_HASH) > lzo - 2.02-2.el5.1.i386 requires /sbin/ldconfig > lzo - 2.02-2.el5.1.i386 requires libc.so.6(GLIBC_2.1.3) > lzo - 2.02-2.el5.1.i386 requires libc.so.6 > On ppc: > lzo - 2.02-2.el5.ppc requires libc.so.6 > lzo - 2.02-2.el5.ppc requires libc.so.6(GLIBC_2.0) > lzo - 2.02-2.el5.ppc requires rtld(GNU_HASH) > lzo - 2.02-2.el5.ppc requires /sbin/ldconfig > lzo - 2.02-2.el5.ppc requires libc.so.6(GLIBC_2.1.3) > On x86_64: > lzo - 2.02-2.el5.i386 requires libc.so.6(GLIBC_2.0) > lzo - 2.02-2.el5.i386 requires libc.so.6(GLIBC_2.4) > lzo - 2.02-2.el5.i386 requires rtld(GNU_HASH) > lzo - 2.02-2.el5.i386 requires /sbin/ldconfig > lzo - 2.02-2.el5.i386 requires libc.so.6(GLIBC_2.1.3) > lzo - 2.02-2.el5.i386 requires libc.so.6 > On i386: > lzo - 2.02-2.el5.i386 requires libc.so.6(GLIBC_2.0) > lzo - 2.02-2.el5.i386 requires libc.so.6(GLIBC_2.4) > lzo - 2.02-2.el5.i386 requires rtld(GNU_HASH) > lzo - 2.02-2.el5.i386 requires /sbin/ldconfig > lzo - 2.02-2.el5.i386 requires libc.so.6(GLIBC_2.1.3) > lzo - 2.02-2.el5.i386 requires libc.so.6 > On ppc: > lzo-devel - 2.02-2.el5.ppc requires zlib-devel > On x86_64: > lzo-devel - 2.02-2.el5.i386 requires zlib-devel > On i386: > lzo-devel - 2.02-2.el5.i386 requires zlib-devel > On ppc: > lzo-devel - 2.02-2.el5.1.ppc requires zlib-devel > On x86_64: > lzo-devel - 2.02-2.el5.1.i386 requires zlib-devel > On i386: > lzo-devel - 2.02-2.el5.1.i386 requires zlib-devel > Please resolve this as soon as possible. > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dennis at ausil.us Wed Jul 11 16:47:33 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 11 Jul 2007 11:47:33 -0500 Subject: Very strange buildsys mail: [Fwd: Broken dependencies: lzo] In-Reply-To: References: <4693EC1F.2070609@hhs.nl> Message-ID: <200707111147.33550.dennis@ausil.us> On Wednesday 11 July 2007 11:20:19 am Christopher Stone wrote: > Yes I got 22 emails saying all my php-pear packages were missing the > dependency /usr/bin/pear for el5. > > I sent the emails straight to /dev/null. > > Please fix this. > > On 7/10/07, Hans de Goede wrote: > > Hi all, > > > > See the forwarded mail, I got something similar for lua ??? Some kinda > > glitch? > > I sent an announcement to epel-devel and fedora-maintainers stating exactly what happend. why and that it was not intentional. Again sorry for the inconvenience Dennis From ajackson at redhat.com Wed Jul 11 16:47:00 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 11 Jul 2007 12:47:00 -0400 Subject: Making evdev X11 input driver default? In-Reply-To: <4694EE09.2050604@redhat.com> References: <4694EE09.2050604@redhat.com> Message-ID: <1184172420.2794.28.camel@localhost.localdomain> On Wed, 2007-07-11 at 16:49 +0200, Florian Festi wrote: > Hi! > > Are there already any efforts/plans to make the evdev driver default for F8 > or any later release? Who would be in charge of such decision? Is there > anyone else working on xkbd files for evdev currently? Not yet. It sort of requires working input hotplug, which isn't quite baked upstream. It'd probably be either my domain or Kristian's. - ajax From lists at dresco.co.uk Wed Jul 11 17:00:03 2007 From: lists at dresco.co.uk (Jon Escombe) Date: Wed, 11 Jul 2007 18:00:03 +0100 (BST) Subject: F7 suspend/resume on T60 - broken by linux-2.6-clockevents-fix-resume-logic.patch Message-ID: <12927184.171184173203831.JavaMail.root@epia.dresco.co.uk> I'd not been able to resume my Lenovo T60 from a suspend to ram since upgrading from FC6 to F7. Vanilla 2.6.21 and .22 kernels from the same .config have been working fine. Lots of test kernels later and I'm able to attribute this to the linux-2.6-clockevents-fix-resume-logic.patch. Is there any scope for fixing/removing this patch? Regards, Jon. From bpepple at fedoraproject.org Wed Jul 11 17:40:21 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 11 Jul 2007 13:40:21 -0400 Subject: Plan for tomorrows (20070712) FESCO meeting Message-ID: <1184175621.2815.6.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00127.html /topic FESCO-Meeting -- MISC -- Secondary Arches - http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures -spot /topic FESCO-Meeting -- MISC -- Schedule for future branching of CVS - f13 ? /topic FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 limb at jcomserv.net Wed Jul 11 18:51:57 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 11 Jul 2007 13:51:57 -0500 (CDT) Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] Message-ID: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> I still haven't seen this in a mirror yet, and it's Stable in Bodhi. Am I missing something? ---------------------------- Original Message ---------------------------- Subject: Fedora 7 Update: pitivi-0.10.3-2.fc7 From: updates at fedoraproject.org Date: Tue, July 3, 2007 11:22 am To: fedora-package-announce at redhat.com -------------------------------------------------------------------------- -------------------------------------------------------------------------------- Fedora Update Notification FEDORA-2007-0762 2007-07-03 09:22:48.402239 -------------------------------------------------------------------------------- Name : pitivi Product : Fedora 7 Version : 0.10.3 Release : 2.fc7 Summary : Non-linear video editor Description : Pitivi is an application using the GStreamer multimedia framework to manipulate a large set of multimedia sources. At this level of development it can be compared to a classic video editing program. -------------------------------------------------------------------------------- Update Information: Add versioned requires on gnonlin -------------------------------------------------------------------------------- ChangeLog: * Wed Jun 27 2007 Jeffrey C. Ollie - 0.10.3-2 - Add versioned requires for gnonlin. (BZ#245981) * Fri Jun 22 2007 Jeffrey C. Ollie - 0.10.3-1 - Update to 0.10.3 * Mon May 28 2007 Jeffrey C. Ollie - 0.10.2.2-3 - BR gettext * Mon May 28 2007 Jeffrey C. Ollie - 0.10.2.2-2 - BR perl(XML::Parser) * Mon May 28 2007 Jeffrey C. Ollie - 0.10.2.2-1 - Update to 0.10.2.2 * Wed Jan 31 2007 Jeffrey C. Ollie - 0.10.2-2 - Don't forget to add new patch to CVS * Wed Jan 31 2007 Jeffrey C. Ollie - 0.10.2-1 - Update to 0.10.2 - Drop sync patch - Add find_lang to pick up localizations - Temporarily re-run auto* tools until PyGTK detection is fixed. - See http://bugzilla.gnome.org/show_bug.cgi?id=402995 -------------------------------------------------------------------------------- Updated packages: 5d158281f7bd4db71d27d24136874d1ce2cc9909 pitivi-0.10.3-2.fc7.noarch.rpm 949aa8569f33882b7e713e34c44e912261ee7c80 pitivi-0.10.3-2.fc7.src.rpm This update can be installed with the 'yum' update program. Use 'yum update package-name' at the command line. For more information, refer to 'Managing Software with yum,' available at http://docs.fedoraproject.org/yum/. -------------------------------------------------------------------------------- _______________________________________________ Fedora-package-announce mailing list Fedora-package-announce at redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-announce -- novus ordo absurdum From jkeating at redhat.com Wed Jul 11 19:01:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 15:01:09 -0400 Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> Message-ID: <200707111501.10116.jkeating@redhat.com> On Wednesday 11 July 2007 14:51:57 Jon Ciesla wrote: > I still haven't seen this in a mirror yet, and it's Stable in Bodhi. ?Am I > missing something? It can take a while. We look hourly for the output of what mash does with the updates collections to sync, then it will take however long to sync those bits, and then the mirrors to get the bits. -- 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 limb at jcomserv.net Wed Jul 11 19:21:53 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 11 Jul 2007 14:21:53 -0500 (CDT) Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <200707111501.10116.jkeating@redhat.com> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> <200707111501.10116.jkeating@redhat.com> Message-ID: <32217.65.192.24.164.1184181713.squirrel@mail.jcomserv.net> But this came out 7/3. > On Wednesday 11 July 2007 14:51:57 Jon Ciesla wrote: >> I still haven't seen this in a mirror yet, and it's Stable in Bodhi. Am >> I >> missing something? > > It can take a while. We look hourly for the output of what mash does with > the > updates collections to sync, then it will take however long to sync those > bits, and then the mirrors to get the bits. > > -- > Jesse Keating > Release Engineer: Fedora > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From Michael_E_Brown at dell.com Wed Jul 11 19:35:23 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 11 Jul 2007 14:35:23 -0500 Subject: Implementation of a wild card usage for the uniqueext option In-Reply-To: <4693BD3E.5080701@herr-schmitt.de> References: <4693A13F.90709@herr-schmitt.de> <1184085223.3549.4.camel@sb-home> <4693BD3E.5080701@herr-schmitt.de> Message-ID: <20070711193522.GC9945@humbolt.us.dell.com> On Tue, Jul 10, 2007 at 07:09:18PM +0200, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > nodata schrieb: > > Am Dienstag, den 10.07.2007, 17:09 +0200 schrieb Jochen Schmitt: > > > 1. avoid wildcards and special characters 2. for hacks like this > > ("*" is a valid value), have a new option for that, e.g. > > config_opts['auto-unique-ext']=1 > > Thank you for your hints. I have attached a improved version of my patch. fedora-buildsys-list is the normal place where we discuss mock. I'll take a look at your patch. -- Michael From Michael_E_Brown at dell.com Wed Jul 11 19:39:17 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 11 Jul 2007 14:39:17 -0500 Subject: Implementation of a wild card usage for the uniqueext option In-Reply-To: <4693BD3E.5080701@herr-schmitt.de> References: <4693A13F.90709@herr-schmitt.de> <1184085223.3549.4.camel@sb-home> <4693BD3E.5080701@herr-schmitt.de> Message-ID: <20070711193916.GD9945@humbolt.us.dell.com> On Tue, Jul 10, 2007 at 07:09:18PM +0200, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > nodata schrieb: > > Am Dienstag, den 10.07.2007, 17:09 +0200 schrieb Jochen Schmitt: > > > 1. avoid wildcards and special characters 2. for hacks like this > > ("*" is a valid value), have a new option for that, e.g. > > config_opts['auto-unique-ext']=1 > > Thank you for your hints. I have attached a improved version of my patch. You can already implement this feature without any patch to mock. In your chroot config file, simply do this: ============ import pwd config_opts['unique-ext'] = pwd.getpwuid(os.getuid())[0] ============ -- Michael From jkeating at redhat.com Wed Jul 11 19:34:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 15:34:29 -0400 Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <32217.65.192.24.164.1184181713.squirrel@mail.jcomserv.net> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> <200707111501.10116.jkeating@redhat.com> <32217.65.192.24.164.1184181713.squirrel@mail.jcomserv.net> Message-ID: <200707111534.29507.jkeating@redhat.com> On Wednesday 11 July 2007 15:21:53 Jon Ciesla wrote: > But this came out 7/3. Hrm, investigating. -- 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 Michael_E_Brown at dell.com Wed Jul 11 19:47:02 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 11 Jul 2007 14:47:02 -0500 Subject: Doing away with 'groups' repo in mock In-Reply-To: <200707051257.43480.jkeating@redhat.com> References: <200706281352.57015.jkeating@redhat.com> <200707051257.43480.jkeating@redhat.com> Message-ID: <20070711194701.GE9945@humbolt.us.dell.com> On Thu, Jul 05, 2007 at 12:57:39PM -0400, Jesse Keating wrote: > On Thursday 28 June 2007 13:52:56 Jesse Keating wrote: > > The comps change can be made at any time, however changes to mock need to > > be coordinated with the maintainer for redhat-rpm-config. ?I'd also like to > > move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the > > packages already being pulled into the buildroot (redhat-rpm-config > > perhaps, since it will be referencing it?), and thus we'll need to > > coordinate with the rpmdevtools maintainer. > > To date: > > comps change made. 'yum groupinfo buildsys-build' on rawhide for details. > buildroot check scripts now included in upstream rpm, also in rawhide. > mock changes created in > http://people.redhat.com/jkeating/git/mock-nogrouprepo.git , RFE filed. > redhat-rpm-config changes created in > http://people.redhat.com/jkeating/git/redhat-rpm-config.git , upstream > maintainer notified. > > Once the redhat-rpm-config and mock changes go through, we'll be done with > this little change. mock-0.7.3 built for rawhide with this one change. -- Michael From jkeating at redhat.com Wed Jul 11 19:43:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 15:43:44 -0400 Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <200707111534.29507.jkeating@redhat.com> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> <32217.65.192.24.164.1184181713.squirrel@mail.jcomserv.net> <200707111534.29507.jkeating@redhat.com> Message-ID: <200707111543.44352.jkeating@redhat.com> On Wednesday 11 July 2007 15:34:29 Jesse Keating wrote: > On Wednesday 11 July 2007 15:21:53 Jon Ciesla wrote: > > But this came out 7/3. > > Hrm, investigating. Looks like the maintainer asked for both -1 and -2 to go out as updates, and the -2 got tagged first, then -1, so -1 is the 'latest' one. Adjusting. -- 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 limb at jcomserv.net Wed Jul 11 19:45:38 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 11 Jul 2007 14:45:38 -0500 (CDT) Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <200707111543.44352.jkeating@redhat.com> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> <32217.65.192.24.164.1184181713.squirrel@mail.jcomserv.net> <200707111534.29507.jkeating@redhat.com> <200707111543.44352.jkeating@redhat.com> Message-ID: <52153.65.192.24.164.1184183139.squirrel@mail.jcomserv.net> > On Wednesday 11 July 2007 15:34:29 Jesse Keating wrote: >> On Wednesday 11 July 2007 15:21:53 Jon Ciesla wrote: >> > But this came out 7/3. >> >> Hrm, investigating. > > Looks like the maintainer asked for both -1 and -2 to go out as updates, > and > the -2 got tagged first, then -1, so -1 is the 'latest' one. Adjusting. Odd. Something I'll watch for with my own packages in the future, unless you think there might be a software solution to the problem that could be added to koji. Thank you! > -- > Jesse Keating > Release Engineer: Fedora > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From dwmw2 at infradead.org Wed Jul 11 19:57:54 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Jul 2007 20:57:54 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <200707110702.18434.jkeating@redhat.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> Message-ID: <1184183874.31598.18.camel@pmac.infradead.org> On Wed, 2007-07-11 at 07:02 -0400, Jesse Keating wrote: > They stopped because it led to a lot of weird package situations and > mixed results. It was not a very good situation, it only made > you /think/ you were moving on correctly when you really weren't and > should have rebuilt everything with the new version once it was fixed > anyway instead of keeping going. You're right to remind us of the problems with this, btw. It's exactly the kind of hell that Spot's proposal as-is would have us impose on the secondary architectures. If packages are going to be absent on any given architecture, that should happen only through a conscious decision on the part of the maintainer -- not just automatically after a build failure which is probably going to turn out to be a generic issue when it's investigated anyway. -- dwmw2 From jkeating at redhat.com Wed Jul 11 19:57:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 15:57:16 -0400 Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <52153.65.192.24.164.1184183139.squirrel@mail.jcomserv.net> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> <200707111543.44352.jkeating@redhat.com> <52153.65.192.24.164.1184183139.squirrel@mail.jcomserv.net> Message-ID: <200707111557.16574.jkeating@redhat.com> On Wednesday 11 July 2007 15:45:38 Jon Ciesla wrote: > Odd. ?Something I'll watch for with my own packages in the future, unless > you think there might be a software solution to the problem that could be > added to koji. Not koji, but bodhi. -- 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 Michael_E_Brown at dell.com Wed Jul 11 20:05:58 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 11 Jul 2007 15:05:58 -0500 Subject: Video and Keymap Quirks In-Reply-To: <1184067618.2249.84.camel@work> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> Message-ID: <20070711200558.GF9945@humbolt.us.dell.com> On Tue, Jul 10, 2007 at 12:40:18PM +0100, Richard Hughes wrote: > On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: > > Great that you're working on this and targeting F-8 with it. Unfortunately > > having only scancode -> keycode mappings in the kernel is not enough to make > > most keys just work. This also requires mapping to X keysyms and configurations > > of applications. > > Sure, but this is the first part of the jigsaw. For stuff like > rfkill-input we need the kernel to _know_ that KEY_FN_F1 is actually > KEY_BLUETOOTH. When X switches to evdev (soon?) the keysym problem > should be a lot simpler to fix. Does the kernel have a concept for a key that can be on-the-fly configured to individually turn on/off any combination of wlan, bluetooth and/or cellular modems? Recent Dell laptops all have a wireless switch. This switch can be configured at runtime by dellWirelessCtl (part of libsmbios-bin) to individually turn on/off any combination of each of the above. -- Michael From sdl.web at gmail.com Wed Jul 11 19:32:20 2007 From: sdl.web at gmail.com (Leo) Date: Wed, 11 Jul 2007 21:32:20 +0200 Subject: emacs-22.x - comments highlighting is "wrong" References: <200707072339.37806.jaroslav@aster.pl> Message-ID: On 2007-07-07T23:39:26+0200, Jaroslaw Gorny wrote: > I've recently upgraded FC6 -> F7 and I've noticed that in emacs > comments are being highlighted very different than in 21.x versions. > I've checked it in {C,Python,Shell}-modes. > > In 21.x if you put a comment mark at the beginning of the line or > comment a region with "/*" and "*/", _all_ the text that is commented > changes its color to "comment_font_color" (please forgive this > arbitrary and non-technical term). In 22.x _only_ the comment > characters color is "comment_font_color" and the whole commented text > is "plain_text_font_color" You should test by starting emacs with "emacs -Q". Because you old config file might be causing those problems. -- Leo (GPG Key: 9283AA3F) From hughsient at gmail.com Wed Jul 11 20:29:54 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 11 Jul 2007 21:29:54 +0100 Subject: Video and Keymap Quirks In-Reply-To: <20070711200558.GF9945@humbolt.us.dell.com> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <20070711200558.GF9945@humbolt.us.dell.com> Message-ID: <1184185794.2241.7.camel@work> On Wed, 2007-07-11 at 15:05 -0500, Michael E Brown wrote: > On Tue, Jul 10, 2007 at 12:40:18PM +0100, Richard Hughes wrote: > > On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: > > > Great that you're working on this and targeting F-8 with it. Unfortunately > > > having only scancode -> keycode mappings in the kernel is not enough to make > > > most keys just work. This also requires mapping to X keysyms and configurations > > > of applications. > > > > Sure, but this is the first part of the jigsaw. For stuff like > > rfkill-input we need the kernel to _know_ that KEY_FN_F1 is actually > > KEY_BLUETOOTH. When X switches to evdev (soon?) the keysym problem > > should be a lot simpler to fix. > > Does the kernel have a concept for a key that can be on-the-fly > configured to individually turn on/off any combination of wlan, > bluetooth and/or cellular modems? Err, we can use the setkeycode ioctl to remap the button, but I'm guessing this isn't the answer to the question you are asking. > Recent Dell laptops all have a wireless switch. This switch can be > configured at runtime by dellWirelessCtl (part of libsmbios-bin) to > individually turn on/off any combination of each of the above. We could hook this up to HAL (although I'm not sure yet how) but I'm guessing the most sane thing to do would be to tie it to a hardware killswitch that killed all the wireless devices for aircraft scenario. Richard. From bernie at codewiz.org Wed Jul 11 20:34:39 2007 From: bernie at codewiz.org (Bernardo Innocenti) Date: Wed, 11 Jul 2007 16:34:39 -0400 Subject: Unwanted RPM dependencies In-Reply-To: References: <4663C148.1040909@codewiz.org> <1180974633.14854.3.camel@dhcp83-66.boston.redhat.com> Message-ID: <46953EDF.5070200@codewiz.org> C. Scott Ananian wrote: > We do/will have an initrd which is used for activation, but it does > not use mkinitrd and certainly doesn't require its binary to be on the > XO. If the image contains modules and we want to allow kernel updates through rpm, then we need to ship this fork of mkinitrd with the system. I've not yet figured out whether rpm and yum are only meant for us developers or also for the end users. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ From tcallawa at redhat.com Wed Jul 11 21:58:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 11 Jul 2007 16:58:56 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184183874.31598.18.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> Message-ID: <1184191136.3404.42.camel@localhost.localdomain> On Wed, 2007-07-11 at 20:57 +0100, David Woodhouse wrote: > On Wed, 2007-07-11 at 07:02 -0400, Jesse Keating wrote: > > They stopped because it led to a lot of weird package situations and > > mixed results. It was not a very good situation, it only made > > you /think/ you were moving on correctly when you really weren't and > > should have rebuilt everything with the new version once it was fixed > > anyway instead of keeping going. > > You're right to remind us of the problems with this, btw. It's exactly > the kind of hell that Spot's proposal as-is would have us impose on the > secondary architectures. If packages are going to be absent on any given > architecture, that should happen only through a conscious decision on > the part of the maintainer -- not just automatically after a build > failure which is probably going to turn out to be a generic issue when > it's investigated anyway. So, it would look like this for workflow: 1. Maintainer requests build (make build) 2. Packages build on primary architectures successfully. 3. Build requests get sent out to secondary architectures. 4a. All secondary architectures report success. Primary packages automatically move into their repository. Secondary packages automatically move into their repository. ***End of workflow*** OR 4b. At least one secondary architecture fails to build. Maintainer is notified (say, by email). Notification tells packager that all packages are being held back from repo for all architectures, pending packager action. At this point, the maintainer either has to: A) Decide that the build is bad, tell koji to let those bits die, don't push any built packages into their repository. B) Open an bugzilla against the arch(es) that failed to build, then tell koji to push the built packages anyway. It might be possible to automate this step somewhat: ***WARNING: Pseudo-code*** [spot at localhost devel]$ koji push-failed-task 64178 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=64178 This task failed on architecture(sparc). Open a new bug for this package against the Fedora-sparc tracker? (y/n) y Bug 123456 filed. Pushing packages. Task unblocked. [spot at localhost devel]$ ***END Pseudo-code*** Obviously, koji doesn't work _at all_ like this now. I'm still not convinced this is necessary. I think this puts too much burden on the maintainer, when this should fall to the secondary architecture team. The secondary architecture team will get notified when a build fails on their arch, and we can whip up scripts that show the differences between a secondary arch repository packagetree and the primaries (they can even look for ExcludeArch/ExclusiveArch and focus only on the unknowns). ~spot From msaksena at marvell.com Wed Jul 11 22:51:06 2007 From: msaksena at marvell.com (Manas Saksena) Date: Wed, 11 Jul 2007 15:51:06 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <46949141.8090804@linux-kernel.at> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> Message-ID: <46955EDA.8050602@marvell.com> Oliver Falk wrote: > Hi Manas! Hi Oliver -- thanks for your response. >> Second, can secondary architectures go beyond the primary architectures >> in terms of feature support? For e.g., can a secondary architecture >> include a cross-compiler toolchain? > > Only if you do the usual package review process and it lands on fp.o CVS. > >> Along the same lines, can secondary architectures have modified spec >> files that go beyond fixing build/run-time issues. For e.g., can a >> secondary architecture take a large package and further split it into >> more granular subsets for the purpose of better footprint control. > > No. Everything that is built, uis checked-out via CVS from fp.o CVS. If > you want to modify a spec, you need to talk with the package maintainer... I understand. We can certainly do this outside of Fedora, and probably will. I just wanted clarification on that. The idea that I am pursuing is of "derivative distributions" that: -- derive sources/spec files from Fedora whenever appropriate -- customizes sources/spec file per the needs of the derivative distro's audience -- e.g., if I am building am ARM distro for my wireless access point. Not all Fedora packaging rules may make sense for me. Note that this is a step beyond what the current Fedora "compose tools" allow (revisor etc.) -- in that we need to modify at the source level & rebuild. Not just pick a subset of the pre-built packages, and then do some post-processing on it. This is a real need. In the embedded space, pretty much every device has its own custom distribution. These tend to be created in all kinds of ways -- many of them lacking any kind of rigor that you see in distros like Fedora. For the curious, you may want to take a look at Sony's GPL download site as an example -- which has the packages that it puts in its various consumer devices (cameras, videocams, mylo, and many others..). http://www.sony.net/Products/Linux/Download/search.html It would be useful if in the future this use case is explicitly considered and supported through the Fedora infrastructure and tools (e.g., using a distributed VCS) that allows users to leverage the base Fedora distribution and customize from there. Regards, Manas ps: Note that this is not a secondary architecture issue, per se. From what I can tell, the OLPC-Fedora distribution is already doing this within the Fedora infrastructure. From dwmw2 at infradead.org Wed Jul 11 23:22:28 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jul 2007 00:22:28 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184191136.3404.42.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> Message-ID: <1184196148.31598.51.camel@pmac.infradead.org> On Wed, 2007-07-11 at 16:58 -0500, Tom "spot" Callaway wrote: > I'm still not convinced this is necessary. I think this puts too much > burden on the maintainer, when this should fall to the secondary > architecture team. I think you're mistaken on both counts -- on where the responsibility is likely to lie, and on the amount of this 'burden'. My experience is that _most_ such failures are going to turn out to be generic bugs in the package; not really arch-specific problems at all. They'll bite on more than one, if not all, architecture(s); if not immediately then over time. It's just that some bugs don't show up 100% of the time; they're dependent on subtle things like the number of CPUs, the amount of memory available, how the compiler chooses to lay out registers, etc. Shipping the affected packages without even expecting the maintainer to _look_ at the failure is a very bad idea, from a QA point of view. It's also an unreasonable thing to do to the arch team for the affected architecture(s) -- both because we're making them take on the initial investigation of bugs in arbitrary packages which are likely not to be arch-specific at all, and because we'd be making them deal with the build system inconsistencies which arise from the unnecessary missing packages; just as Jesse reminded us only worse. And the 'burden' of which you speak is _trivial_ -- you spelled it out yourself. We're talking, in the minimal case, about the amount of time it takes to _glance_ at the build failure (for a package you _know_) and make a decision about whether or not you care; whether your build is so urgent that it has to be shipped now without waiting for a fix; whether the secondary arch in question is going to be screwed by the absence of the updated package because you're about to build a dozen other packages against it, or whether it's a 'leaf' package which doesn't really matter, etc. Let the maintainer make that decision; really. It'll work out right -- the people who maintain the core packages are in general more conscientious than those who maintain only leaf-node packages, and will tend to do the job properly where it matters. I know you're worried about the lowest common denominator; the people who don't even understand the language which their package -- the package which they're supposed to be supporting and fixing bugs in -- is written in. But that's fine -- all they have to do is file an empty bug saying "the build failed but I do not know anything about why", and push the "ship it anyway" button. It sucks that we have such poorly supported packages, but it doesn't really hurt the secondary architectures much more than it hurts anywhere else. They'll generally not be packages we depend upon for much. It just isn't that much of a burden, for those who don't want it to be or who aren't up to the task. It only helps to set expectations, and stops us from _automatically_ shipping something which is actually quite likely to be broken on the primary architectures too. -- dwmw2 From dwmw2 at infradead.org Wed Jul 11 23:24:28 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jul 2007 00:24:28 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184191136.3404.42.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> Message-ID: <1184196268.31598.53.camel@pmac.infradead.org> On Wed, 2007-07-11 at 16:58 -0500, Tom "spot" Callaway wrote: > This task failed on architecture(sparc). Open a new bug for this > package against the Fedora-sparc tracker? (y/n) y > > Bug 123456 filed. Better to give a URl to bugzilla with a template for filing the bug; not just file it automatically. They can explain the failure then, and why they've concluded it isn't a generic problem. -- dwmw2 From tcallawa at redhat.com Wed Jul 11 23:31:51 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 11 Jul 2007 18:31:51 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184196148.31598.51.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> Message-ID: <1184196711.3404.51.camel@localhost.localdomain> On Thu, 2007-07-12 at 00:22 +0100, David Woodhouse wrote: > My experience is that _most_ such failures are going to turn out to be > generic bugs in the package; not really arch-specific problems at > all. You keep saying this, and I disagree whole-heartedly. My experience with sparc tells me this is absolutely not the case. ~spot From tcallawa at redhat.com Wed Jul 11 23:33:50 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 11 Jul 2007 18:33:50 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <46955EDA.8050602@marvell.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> Message-ID: <1184196830.3404.53.camel@localhost.localdomain> On Wed, 2007-07-11 at 15:51 -0700, Manas Saksena wrote: > Note that this is not a secondary architecture issue, per se. From > what > I can tell, the OLPC-Fedora distribution is already doing this within > the Fedora infrastructure. To an extent, yes, although, they're still following the Fedora Packaging Guidelines. I'd be very interested in the guidelines that you feel you might need to break/ignore. :) ~spot From caillon at redhat.com Wed Jul 11 23:45:52 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 11 Jul 2007 19:45:52 -0400 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184196148.31598.51.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> Message-ID: <46956BB0.2070301@redhat.com> David Woodhouse wrote: > On Wed, 2007-07-11 at 16:58 -0500, Tom "spot" Callaway wrote: >> I'm still not convinced this is necessary. I think this puts too much >> burden on the maintainer, when this should fall to the secondary >> architecture team. > > I think you're mistaken on both counts -- on where the responsibility is > likely to lie, and on the amount of this 'burden'. > > My experience is that _most_ such failures are going to turn out to be > generic bugs in the package; not really arch-specific problems at all. > They'll bite on more than one, if not all, architecture(s); if not > immediately then over time. The term package is overloaded here. In general the failures are in upstream packages; not the Fedora package glue. While we want to and should encourage packagers to fix bugs in upstream code, dealing with bugs that are not part of an official Fedora release should never be a requirement for Fedora packagers, IMHO. From davej at redhat.com Wed Jul 11 23:51:58 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 19:51:58 -0400 Subject: rawhide report: 20070711 changes In-Reply-To: <46951FAA.5090803@online.de> References: <200707110936.l6B9aYAG028595@porkchop.devel.redhat.com> <46951FAA.5090803@online.de> Message-ID: <20070711235158.GD13314@redhat.com> On Wed, Jul 11, 2007 at 08:21:30PM +0200, Ronald Warsow wrote: > Build System wrote: > > > > kernel-2.6.22-8.fc8 > > ------------------- > > * Tue Jul 10 2007 John W. Linville > > - Update git-wireless-dev.patch > > - Add upstream version of rtl8187 patch > > > > * Tue Jul 10 2007 Dave Jones > > - Split utrace up into multiple patches. > > > > * Mon Jul 09 2007 Chuck Ebbert > > - sky2: restore workarounds for lost interrupts > > > > apart from mkinitrd stuff, are the above and the one from here > http://people.redhat.com/davej/kernels/Fedora/fc7/RPMS.kernel/x86_64/ > > [very] different to run them on f7 ? They've now diverged quite a bit. Rawhide is on its way towards 2.6.23rc whilst f7 will be on .22 Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Jul 11 23:52:32 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jul 2007 19:52:32 -0400 Subject: F7 suspend/resume on T60 - broken by linux-2.6-clockevents-fix-resume-logic.patch In-Reply-To: <12927184.171184173203831.JavaMail.root@epia.dresco.co.uk> References: <12927184.171184173203831.JavaMail.root@epia.dresco.co.uk> Message-ID: <20070711235232.GE13314@redhat.com> On Wed, Jul 11, 2007 at 06:00:03PM +0100, Jon Escombe wrote: > I'd not been able to resume my Lenovo T60 from a suspend to ram since upgrading from FC6 to F7. Vanilla 2.6.21 and .22 kernels from the same .config have been working fine. > > Lots of test kernels later and I'm able to attribute this to the linux-2.6-clockevents-fix-resume-logic.patch. Is there any scope for fixing/removing this patch? gone in the .22 rebase in progress. Dave -- http://www.codemonkey.org.uk From dwmw2 at infradead.org Wed Jul 11 23:55:15 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jul 2007 00:55:15 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <46956BB0.2070301@redhat.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <46956BB0.2070301@redhat.com> Message-ID: <1184198115.31598.75.camel@pmac.infradead.org> On Wed, 2007-07-11 at 19:45 -0400, Christopher Aillon wrote: > The term package is overloaded here. In general the failures are in > upstream packages; not the Fedora package glue. > > While we want to and should encourage packagers to fix bugs in upstream > code, dealing with bugs that are not part of an official Fedora release > should never be a requirement for Fedora packagers, IMHO. (That's actually a topic on which I violently disagree. If the person responsible can't deal with bugs and properly maintain the package with any degree of quality, we're better of not having the package at all. I understand that some people value quantity over quality though.?) But still, it wouldn't be a _requirement_. The only requirement would be that they _look_ at the failure and decide whether they care or not. Hell, I suppose even that isn't required -- we wouldn't _even_ force them to look, if they _really_ don't want to even look at why their package failed to build. They could just follow the link to bugzilla and click 'submit' without putting _any_ more information into the template they're given, then ship the package anyway. It just isn't that hard. (Regardless of my opinion of whether we actually want that kind of package{,r} quality in Fedora.) -- dwmw2 ? If the sponsor were expected to co-maintain, that might help. From dwmw2 at infradead.org Wed Jul 11 23:58:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jul 2007 00:58:02 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184196711.3404.51.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <1184196711.3404.51.camel@localhost.localdomain> Message-ID: <1184198282.31598.80.camel@pmac.infradead.org> On Wed, 2007-07-11 at 18:31 -0500, Tom "spot" Callaway wrote: > You keep saying this, and I disagree whole-heartedly. My experience > with sparc tells me this is absolutely not the case. I posted the bug numbers to support my observations, and they supported my qualitative recollection. Perhaps it's just that PowerPC is in dramatically better shape than SPARC, in general. Or maybe you've suffered a lot by being out of sync with Fedora proper. I'd be interested to see your data and how you've classified the bugs. If your recollection _is_ indicative of what we'll get when we pull in more esoteric architectures, even that isn't necessarily so much cause for concern -- we'll be a lot better off if we can keep those architectures in sync with the main Fedora repository, and we'll also be able to improve on it a lot just by enforcing the 'SHOULD regularly rebuild in mock' rule?. That'll tend to catch what I suspect would be the most common arch-specific failure mode, which would be GCC or other toolchain issues. (With your multitude of arch-specific bugs, perhaps you can confirm or deny that's what the most common such bug is likely to be?) Besides, the fact remains that the 'burden' it places on the package maintainer is _trivial_. The minimal case is that they just file an _empty_ bug for the ExcludeArch and ship the failed package anyway. Obviously we expect better from our competent maintainers than that, but the lowest common denominator wouldn't be _forced_ into anything even approaching conscientiousness; only encouraged towards it. -- dwmw2 ? I'd like to stick to the RFC2119 definition of 'SHOULD' -- as in; you don't have to, but you'd better have a damn good reason why not. From msaksena at marvell.com Thu Jul 12 00:13:18 2007 From: msaksena at marvell.com (Manas Saksena) Date: Wed, 11 Jul 2007 17:13:18 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184196830.3404.53.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> Message-ID: <4695721E.1010107@marvell.com> Tom "spot" Callaway wrote: > On Wed, 2007-07-11 at 15:51 -0700, Manas Saksena wrote: >> Note that this is not a secondary architecture issue, per se. From >> what >> I can tell, the OLPC-Fedora distribution is already doing this within >> the Fedora infrastructure. > > To an extent, yes, although, they're still following the Fedora > Packaging Guidelines. > > I'd be very interested in the guidelines that you feel you might need to > break/ignore. :) Packaging guidelines may be the wrong term. But, you often need to do surgery (and sometimes a deep one ) to packages when you are trying to squeeze functionality into a 4MB flash (or 16, 32, 64MB -- whatever). At other times, you want to have tools (much like pilgrim, revisor, etc.) that can ensure that whatever hacked up distro you end up creating can be re-created automagically from your package repository (and, have some resilience when packages get updated etc.). For e.g., Lets start with the simple stuff. Many systems will have busybox, and will want to have a custom busybox config. If you use glibc, you will almost certainly not want much of the stuff that glibc carries. People might want to build against uClibc. Or, maybe eglibc (www.eglibc.org). Both have them require a config file that may be customized. Maybe you have an application that needs openssl library. But, you probably dont want to carry along everything else that the openssl package provides. You almost always want only a subset of the files that a package provides (although, this can be often hacked by some post-processing, but you lose the package level integrity then). (Virtually all packages will need to be hacked up this way when you are operating under serious footprint constraints. And, BTW, footprint in embedded/consumer devices means money -- so it matters an awful lot to device manufacturers). The locale stuff tends to be a big bloating thing and much of that may not be needed in many cases. Maybe you will have a custom init scripts package. Sometimes you may want to change configure options for a package so that it doesnt build with pam, or ipv6, or kerberos -- if you are not going to need it. Maybe you want to have a small footprint package db on target (e.g., something like ipkg). Some of these, if they are deemed to be broadly useful, can be pushed into mainstream fedora distro. Others will inherently end-up being device specific since each device has to make its own unique tradeoff of footprint and functionality -- a problem that desktop/server distros generally dont have to worry about. Etc. Regards, Manas From caillon at redhat.com Thu Jul 12 00:24:39 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 11 Jul 2007 20:24:39 -0400 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184198115.31598.75.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <46956BB0.2070301@redhat.com> <1184198115.31598.75.camel@pmac.infradead.org> Message-ID: <469574C7.5060000@redhat.com> David Woodhouse wrote: > But still, it wouldn't be a _requirement_. The only requirement would be > that they _look_ at the failure and decide whether they care or not. > Hell, I suppose even that isn't required -- we wouldn't _even_ force > them to look, if they _really_ don't want to even look at why their > package failed to build. They could just follow the link to bugzilla and > click 'submit' without putting _any_ more information into the template > they're given, then ship the package anyway. So why make them do anything at all? Let's just auto file the bug. Let the ones who want to care shine out. From dwmw2 at infradead.org Thu Jul 12 00:58:51 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jul 2007 01:58:51 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <469574C7.5060000@redhat.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <46956BB0.2070301@redhat.com> <1184198115.31598.75.camel@pmac.infradead.org> <469574C7.5060000@redhat.com> Message-ID: <1184201931.31598.103.camel@pmac.infradead.org> On Wed, 2007-07-11 at 20:24 -0400, Christopher Aillon wrote: > So why make them do anything at all? Let's just auto file the bug. > Let the ones who want to care shine out. Because I was only talking about the lowest common denominator; the people who are either unwilling or unable to maintain their package properly. In the cases where the packager _is_ actually doing their job properly, they _will_ be looking at the build failures; at least for long enough to decide whether it's an arch-specific issue (which mostly it won't be, in my experience). It isn't _really_ expected that anyone would ever ship a failed build without even looking at the failure; I was just pointing out that they _could_. If we really want that kind of person responsible for packages carrying the 'Fedora' brand, nothing in what I've suggested would actually _prevent_ them from doing just that. Their packages are probably a lost cause if there are ever any problems (of any kind), both in primary architectures and in secondary. But for packages which _are_ actually maintained properly? we don't want partially-failed buggy builds landing in the repository automatically, and making the secondary trees gratuitously inconsistent; we want that to happen only after a _conscious_ decision by the maintainer that that's what should happen. The idea is that it should be a relatively rare occurrence. If it's frequent, we might as well ditch the whole secondary architecture thing altogether; they're no better off than they were when they were entirely separate. We also want to encourage coherent bugzilla reports, by giving them a template to fill in instead of just automatically filing it. Again, those who really can't be bothered wouldn't _have_ to fill it in properly; they could just submit the template unaltered. But again, we wouldn't expect that to happen in the common case. -- dwmw2 ? which is most, if not all of them. While people have got all pointlessly Californian about the terminology used to describe these 'lowest common denominator' packagers, I don't think anyone _specific_ has ever been mentioned, apart from myself (mostly in the context that I really shouldn't be responsible for anything even remotely involved with dbus). But you seem worried about making life harder for these people if they exist, so I'm pointing out that it _wouldn't_ be harder for them. As long as they can refrain from breaking their mouse by drooling on it, they don't even need to _look_ at build failures before they ship their buggy package. For better or worse. From jwboyer at jdub.homelinux.org Thu Jul 12 02:24:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Jul 2007 21:24:50 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <4695721E.1010107@marvell.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> <4695721E.1010107@marvell.com> Message-ID: <1184207090.11325.4.camel@vader.jdub.homelinux.org> On Wed, 2007-07-11 at 17:13 -0700, Manas Saksena wrote: > Tom "spot" Callaway wrote: > > On Wed, 2007-07-11 at 15:51 -0700, Manas Saksena wrote: > >> Note that this is not a secondary architecture issue, per se. From > >> what > >> I can tell, the OLPC-Fedora distribution is already doing this within > >> the Fedora infrastructure. > > > > To an extent, yes, although, they're still following the Fedora > > Packaging Guidelines. > > > > I'd be very interested in the guidelines that you feel you might need to > > break/ignore. :) > > Packaging guidelines may be the wrong term. But, you often need to do > surgery (and sometimes a deep one ) to packages when you are trying to > squeeze functionality into a 4MB flash (or 16, 32, 64MB -- whatever). > At other times, you want to have tools (much like pilgrim, revisor, > etc.) that can ensure that whatever hacked up distro you end up creating > can be re-created automagically from your package repository (and, have > some resilience when packages get updated etc.). There's also hardware that lacks FPU. So you have to build every package with -msoft-float. The list for the embedded cases is endless. I also believe basing something off of Fedora and expecting the main Fedora distro to accommodate them at all is unrealistic. If you're going to make a distribution that does not have it's changes in CVS, it's not "based on Fedora" or "derived from Fedora". It's "the OMG WTF BBQ distribution, built with some tools from Fedora.. maybe." Derivative distributions are entirely outside the scope of secondary arches. josh From halfline at gmail.com Thu Jul 12 02:25:44 2007 From: halfline at gmail.com (Ray Strode) Date: Wed, 11 Jul 2007 22:25:44 -0400 Subject: Video and Keymap Quirks In-Reply-To: <46936DFC.4090904@hhs.nl> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> Message-ID: <45abe7d80707111925p58d342ccn6554f8c867ac4fe6@mail.gmail.com> Hi, > Great that you're working on this and targeting F-8 with it. Unfortunately > having only scancode -> keycode mappings in the kernel is not enough to make > most keys just work. This also requires mapping to X keysyms and configurations > of applications. While the default mappings for the various multimedia keys are to the XF86 keysyms, gnome-keybinding-properties will less you manually choose a keycode even if it doesn't have a keysym associated with it. So you're right that without the keysym things won't "just work" (the user will need to go to a dialog and set things up), at least with the scancode -> keycode mapping the user /can/ get it working, so it's a nice piece to the puzzle. --Ray From jwboyer at jdub.homelinux.org Thu Jul 12 02:41:46 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Jul 2007 21:41:46 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184198282.31598.80.camel@pmac.infradead.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <1184196711.3404.51.camel@localhost.localdomain> <1184198282.31598.80.camel@pmac.infradead.org> Message-ID: <1184208106.11325.8.camel@vader.jdub.homelinux.org> On Thu, 2007-07-12 at 00:58 +0100, David Woodhouse wrote: > On Wed, 2007-07-11 at 18:31 -0500, Tom "spot" Callaway wrote: > > You keep saying this, and I disagree whole-heartedly. My experience > > with sparc tells me this is absolutely not the case. > > I posted the bug numbers to support my observations, and they supported > my qualitative recollection. > > Perhaps it's just that PowerPC is in dramatically better shape than > SPARC, in general. Or maybe you've suffered a lot by being out of sync > with Fedora proper. I'd be interested to see your data and how you've > classified the bugs. Personally, I don't think PowerPC and SPARC are the hard cases. The hard ones will be architectures that glibc doesn't build for. For more than one reason. Still would be good to see Spot's SPARC data though, if he has some. josh From tcallawa at redhat.com Thu Jul 12 03:02:31 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 11 Jul 2007 22:02:31 -0500 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184208106.11325.8.camel@vader.jdub.homelinux.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <1184196711.3404.51.camel@localhost.localdomain> <1184198282.31598.80.camel@pmac.infradead.org> <1184208106.11325.8.camel@vader.jdub.homelinux.org> Message-ID: <1184209351.3404.58.camel@localhost.localdomain> On Wed, 2007-07-11 at 21:41 -0500, Josh Boyer wrote: > On Thu, 2007-07-12 at 00:58 +0100, David Woodhouse wrote: > > On Wed, 2007-07-11 at 18:31 -0500, Tom "spot" Callaway wrote: > > > You keep saying this, and I disagree whole-heartedly. My experience > > > with sparc tells me this is absolutely not the case. > > > > I posted the bug numbers to support my observations, and they supported > > my qualitative recollection. > > > > Perhaps it's just that PowerPC is in dramatically better shape than > > SPARC, in general. Or maybe you've suffered a lot by being out of sync > > with Fedora proper. I'd be interested to see your data and how you've > > classified the bugs. > > Personally, I don't think PowerPC and SPARC are the hard cases. The > hard ones will be architectures that glibc doesn't build for. For more > than one reason. > > Still would be good to see Spot's SPARC data though, if he has some. Don't have hard data. Just 6 years experience in kicking RHL and Fedora into working for SPARC. What I've learned: Most open source apps build fine on SPARC. Those that do not are either: - endian unclean - missing sparc configure options - miscompile on sparc64 - glibc/gcc/kernel/openssl (only broken on sparc) - tools need to be made aware of sparc specifics - irrelevant on sparc I _never_ in 6 years uncovered a generic bug while working on sparc. The "primary" arches in RHL and Fedora always covered those bases (even before ppc was in the mix again). ~spot From msaksena at marvell.com Thu Jul 12 04:12:25 2007 From: msaksena at marvell.com (Manas Saksena) Date: Wed, 11 Jul 2007 21:12:25 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184207090.11325.4.camel@vader.jdub.homelinux.org> References: <1184080763.3490.66.camel@localhost.localdomain> <1184084374.32628.9.camel@pmac.infradead.org> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> <4695721E.1010107@marvell.com> <1184207090.11325.4.camel@vader.jdub.homelinux.org> Message-ID: <4695AA29.2090708@marvell.com> Josh Boyer wrote: > On Wed, 2007-07-11 at 17:13 -0700, Manas Saksena wrote: >> Tom "spot" Callaway wrote: >>> On Wed, 2007-07-11 at 15:51 -0700, Manas Saksena wrote: >>>> Note that this is not a secondary architecture issue, per se. From >>>> what >>>> I can tell, the OLPC-Fedora distribution is already doing this within >>>> the Fedora infrastructure. >>> To an extent, yes, although, they're still following the Fedora >>> Packaging Guidelines. >>> >>> I'd be very interested in the guidelines that you feel you might need to >>> break/ignore. :) >> Packaging guidelines may be the wrong term. But, you often need to do >> surgery (and sometimes a deep one ) to packages when you are trying to >> squeeze functionality into a 4MB flash (or 16, 32, 64MB -- whatever). >> At other times, you want to have tools (much like pilgrim, revisor, >> etc.) that can ensure that whatever hacked up distro you end up creating >> can be re-created automagically from your package repository (and, have >> some resilience when packages get updated etc.). > > There's also hardware that lacks FPU. So you have to build every > package with -msoft-float. The list for the embedded cases is endless. ACK. > I also believe basing something off of Fedora and expecting the main > Fedora distro to accommodate them at all is unrealistic. I agree. But, it is not necessary unrealistic to allow derivative distros under the Fedora project umbrella. Nor, is it necessarily unrealistic (or a bad idea) for Fedora infrastructure to make it a little easier to create these derivative distros (with appropriate support added to infrastructure and tools, etc.). Not today, but sometime in future --- maybe. > If you're > going to make a distribution that does not have it's changes in CVS, > it's not "based on Fedora" or "derived from Fedora". It's "the OMG WTF > BBQ distribution, built with some tools from Fedora.. maybe." Sure, however.. At least in the case of ARM, the interesting part is largely in the derivative distributions. The base distribution can be used in some limited contexts (e.g., for development or in systems where you can hook up a disk), but the real success will depend on our ability to create (and, allow other developers to create) these derivative distributions. And, it is certainly fine for us to do these outside the scope of the Fedora project umbrella. Fedora is used as an upstream for many embedded distros already. Our goal is to make it easy for the various embedded ARM distributions (including the ones we create ourselves) to make use of the Fedora-ARM as the upstream. Regardless, it is beneficial to us to ensure that packages work well on ARM. And, since Fedora is close to upstream, this is beneficial to all downstream users. > Derivative distributions are entirely outside the scope of secondary > arches. Thats fine. As I said before, I wanted to make sure where the boundaries were. Regards, Manas From bojan at rexursive.com Thu Jul 12 04:44:38 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 12 Jul 2007 04:44:38 +0000 (UTC) Subject: F7 suspend/resume on T60 - broken by linux-2.6-clockevents-fix-resume-logic.patch References: <12927184.171184173203831.JavaMail.root@epia.dresco.co.uk> <20070711235232.GE13314@redhat.com> Message-ID: Dave Jones redhat.com> writes: > .22 rebase in progress. Drooling already :-) -- Bojan From bojan at rexursive.com Thu Jul 12 05:03:51 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 12 Jul 2007 05:03:51 +0000 (UTC) Subject: F7 suspend/resume on T60 - broken by linux-2.6-clockevents-fix-resume-logic.patch References: <12927184.171184173203831.JavaMail.root@epia.dresco.co.uk> <20070711235232.GE13314@redhat.com> Message-ID: Dave Jones redhat.com> writes: > .22 rebase in progress. Oh, and nice work with the new kernel versioning! Finally it makes sense. -- Bojan From lists at dresco.co.uk Thu Jul 12 07:23:57 2007 From: lists at dresco.co.uk (Jon Escombe) Date: Thu, 12 Jul 2007 08:23:57 +0100 Subject: F7 suspend/resume on T60 - broken by linux-2.6-clockevents-fix-resume-logic.patch In-Reply-To: <20070711235232.GE13314@redhat.com> References: <12927184.171184173203831.JavaMail.root@epia.dresco.co.uk> <20070711235232.GE13314@redhat.com> Message-ID: <4695D70D.8040003@dresco.co.uk> Dave Jones wrote: > On Wed, Jul 11, 2007 at 06:00:03PM +0100, Jon Escombe wrote: > > I'd not been able to resume my Lenovo T60 from a suspend to ram since upgrading from FC6 to F7. Vanilla 2.6.21 and .22 kernels from the same .config have been working fine. > > > > Lots of test kernels later and I'm able to attribute this to the linux-2.6-clockevents-fix-resume-logic.patch. Is there any scope for fixing/removing this patch? > > gone in the .22 rebase in progress. > > Dave > > That's good news. Thanks. Jon. From valent.turkovic at gmail.com Thu Jul 12 07:57:19 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jul 2007 09:57:19 +0200 Subject: Tomboy for FC6 not being updated... why? Message-ID: <1184227039.23921.27.camel@fedora> I use Tomboy all the time on my work FC6 and my home F7 and I didn't check before but I now noticed that Tomboy on FC6 is still 0.4.1 version when in F7 it is 0.6 version. Tomboy 0.7.1 version came out recently... so my question is this: is there a reason or some policy why Tomboy on FC6 is leftout from being updated to some newer version? Thank you, Valent. From nicu_fedora at nicubunu.ro Thu Jul 12 08:35:27 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 12 Jul 2007 11:35:27 +0300 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184227039.23921.27.camel@fedora> References: <1184227039.23921.27.camel@fedora> Message-ID: <4695E7CF.8080200@nicubunu.ro> Valent Turkovic wrote: > I use Tomboy all the time on my work FC6 and my home F7 and I didn't > check before but I now noticed that Tomboy on FC6 is still 0.4.1 version > when in F7 it is 0.6 version. > > Tomboy 0.7.1 version came out recently... so my question is this: is > there a reason or some policy why Tomboy on FC6 is leftout from being > updated to some newer version? Tomboy is not a stand-alone application, it is part of the GNOME Desktop, so its version will match your GNOME version. On top of that, 0.7.1 is an unstable version. Use the development branch if you want such cutting-edge versions of your applications. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From valent.turkovic at gmail.com Thu Jul 12 08:52:05 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jul 2007 10:52:05 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <4695E7CF.8080200@nicubunu.ro> References: <1184227039.23921.27.camel@fedora> <4695E7CF.8080200@nicubunu.ro> Message-ID: <1184230325.23921.32.camel@fedora> Nicu thank you for your answer. On Thu, 2007-07-12 at 11:35 +0300, Nicu Buculei wrote: > > Tomboy is not a stand-alone application, it is part of the GNOME > Desktop, so its version will match your GNOME version. I didn't know that. So do you know how tomboy releases match gnome releases? > On top of that, 0.7.1 is an unstable version. > Yes, but tomboy 0.6.3 is a stable one. > Use the development branch if you want such cutting-edge versions of > your applications. Oh, so you are saying that in FC6 devel repository I can find a newer version of Tomboy? I'm off the to look for it... thank you. Hm, why does yum spit out errors when I try to enable extras-developement repository? Do extras exist for FC6 or are they also meing merged to core as in F7? From nicu_fedora at nicubunu.ro Thu Jul 12 09:16:16 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 12 Jul 2007 12:16:16 +0300 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184230325.23921.32.camel@fedora> References: <1184227039.23921.27.camel@fedora> <4695E7CF.8080200@nicubunu.ro> <1184230325.23921.32.camel@fedora> Message-ID: <4695F160.1040905@nicubunu.ro> Valent Turkovic wrote: > Nicu thank you for your answer. > > I didn't know that. > So do you know how tomboy releases match gnome releases? From their FTP site: GNOME 2.16 -> Tomboy 0.4.1 http://ftp.gnome.org/pub/GNOME/desktop/2.16/2.16.3/sources/ Gnome 2.18 -> Tomboy 0.6.3 http://ftp.gnome.org/pub/GNOME/desktop/2.18/2.18.3/sources/ Normally, being part of the desktop, Tomboy should adopt the same numbering scheme, but this is up to their developers. >> On top of that, 0.7.1 is an unstable version. > > Yes, but tomboy 0.6.3 is a stable one. I have not checked this, but it may have dependence on certain versions of other GNOME/GTK+ libraries >> Use the development branch if you want such cutting-edge versions of >> your applications. > > Oh, so you are saying that in FC6 devel repository I can find a newer > version of Tomboy? I'm off the to look for it... thank you. There is no such thing as FC6 devel repo, there is only one devel repo and it is heading to Fedora 8 > Hm, why does yum spit out errors when I try to enable > extras-developement repository? Do extras exist for FC6 or are they also > meing merged to core as in F7? After the merger, Extras still exists only for older releases, not for current or development. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From valent.turkovic at gmail.com Thu Jul 12 11:00:03 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jul 2007 13:00:03 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <4695F160.1040905@nicubunu.ro> References: <1184227039.23921.27.camel@fedora> <4695E7CF.8080200@nicubunu.ro> <1184230325.23921.32.camel@fedora> <4695F160.1040905@nicubunu.ro> Message-ID: <1184238003.23921.46.camel@fedora> On Thu, 2007-07-12 at 12:16 +0300, Nicu Buculei wrote: > I have not checked this, but it may have dependence on certain > versions > of other GNOME/GTK+ libraries I have abandoned my attempts to compile tomboy 0.6.3 and 0.7.1 from source because that gave me too much dependency errors! I installed tomboy 0.7.1 from developement repository without any dependencies and it works great! Now even conduit works with it an I can sync my notes across different machines and different users! I love it! if you have FC6 and want new tomboy just do this as root: yum update tomboy --enablerepo=development From buildsys at redhat.com Thu Jul 12 11:14:05 2007 From: buildsys at redhat.com (Build System) Date: Thu, 12 Jul 2007 07:14:05 -0400 Subject: rawhide report: 20070712 changes Message-ID: <200707121114.l6CBE5l1013050@porkchop.devel.redhat.com> New package engine_pkcs11 A PKCS#11 engine for use with OpenSSL New package fcgi FastCGI development kit New package gifsicle Powerful program for manipulating GIF images and animations New package mysql-proxy A proxy for the MySQL Client/Server protocol New package qtpfsgui A graphical tool for creating and tone-mapping HDR images Removed package graveman Updated Packages: aqbanking-2.3.2-1.fc8 --------------------- * Wed Jul 11 2007 Bill Nottingham - 2.3.2-1 - update to 2.3.2 avahi-0.6.20-5.fc8 ------------------ * Wed Jul 11 2007 Lennart Poettering - 0.6.20-5 - add two patches which are important to get RR updating work properly. Will be part of upstream 0.6.21 bigboard-0.5.0-1.fc8 -------------------- * Wed Jul 11 2007 Colin Walters - 0.5.0-1 - new upstream - Require latest canvas - add more stuff to files cmigemo-1.3-0.6.c_MIT.fc8 ------------------------- * Wed Jul 11 2007 Mamoru Tasaka - 1.3-0.6.c_MIT - Re-enable Migemo autocompletion curl-7.16.4-1.fc8 ----------------- * Wed Jul 11 2007 Jindrich Novy 7.16.4-1 - update to 7.16.4 deltarpm-3.4-4.fc8 ------------------ * Wed Jul 11 2007 Jonathan Dieter - 3.4-4 - Fix prelink bug - Ignore verify bits on %doc files as they were set incorrectly in older versions of rpm. Without this patch, deltarpm will not delta doc files in rpm created before April-May 2007 eclipse-subclipse-1.2.2-3.fc8 ----------------------------- em8300-0.16.3-0.1.rc1.fc8 ------------------------- * Wed Jul 11 2007 Ville Skytt?? - 0.16.3-0.1.rc1 - 0.16.3-rc1, fixes #241041. - Update icon cache and group handling to current guidelines/drafts. em8300-kmod-0.16.3-0.1.rc1.2.6.22_8.fc8 --------------------------------------- * Wed Jul 11 2007 Ville Skytt?? - 0.16.3-0.1.rc1 - 0.16.3-rc1, build for kernel 2.6.22-8.fc8. - Bring up to date with current Rawhide kernel archs and variants. * Sat May 12 2007 Ville Skytt?? - Rebuild for kernel 2.6.21-1.3149.fc7. * Mon May 07 2007 Ville Skytt?? - 0.16.2-5 - 0.16.2, build for kernel 2.6.21-1.3141.fc7. ez-ipupdate-3.0.11-0.14.b8.fc7 ------------------------------ * Fri Jun 15 2007 J. Randall Owens - 3.0.11-0.14.b8 - fix doc directory permissions * Thu Mar 08 2007 Jeff Layton - 3.0.11-0.13.b8 - remove Requires(postun) for user/groupdel since they're no longer needed ghostscript-8.60-0.svn8117.1.fc8 -------------------------------- * Tue Jul 10 2007 Tim Waugh 8.60-0.r8112.1 - 8.60 snapshot from svn. Patches dropped: - big-cmap-post - split-cidfnmap - exactly-enable-cidfnmap - Fontmap.local No longer needed: - gxcht-64bit-crash * Tue Apr 17 2007 Tim Waugh 8.15.4-3 - Apply fonts in CIDFnmap even if the same fontnames are already registered (bug #163231). - New file CIDFmap (bug #233966). - Allow local overrides for FAPIcidfmap, cidfmap and Fontmap (bug #233966). * Tue Apr 03 2007 Tim Waugh 8.15.4-2 - Fixed configuration file locations (bug #233966). gimp-2:2.2.16-2.fc8 ------------------- * Wed Jul 11 2007 Nils Philippsen - 2:2.2.16-2 - don't let gimp-plugin-mgr --uninstall fail %post scriptlet glibc-2.6-4 ----------- * Sun Jul 08 2007 Jakub Jelinek 2.6-4 - filter pseudo-files from debuginfo source lists (#245714) - fix sscanf when errno is EINTR before the call (BZ#4745) - save/restore errno around reading /etc/default/nss (BZ#4702) - fix LD_HWCAP_MASK handling - disable workaround for #210748, instead backport ld.so locking fixes from the trunk (#235026) - new x86_64 memcpy - don't write uninitialized padding bytes to nscd socket - fix dl{,v}sym, dl_iterate_phdr and dlopen if some library is mapped into ld.so's inter-segment hole on x86_64 (#245035, #244545) - fix LD_AUDIT=a:b program (#180432) - don't crash on pseudo-zero long double values passed to *printf on i?86/x86_64/ia64 (BZ#4586) - fix *printf %La and strtold with some hexadecimal floating point constants on ppc/ppc64 - fix nextafterl on ppc/ppc64 - fix sem_timedwait on i?86 and x86_64 gscan2pdf-0.9.14-1.fc8 ---------------------- * Wed Jul 11 2007 Bernard Johnson - 0 9.14-1 - v 0.9.14 hippo-canvas-0.2.23-1.fc8 ------------------------- * Wed Jul 11 2007 Marco Pesenti Gritti - 0.2.23-1 - Update to 0.2.23 * Mon Jul 09 2007 Marco Pesenti Gritti - 0.2.22-1 - Update to 0.2.22 * Fri Jul 06 2007 Marco Pesenti Gritti - 0.2.21-1 - Update to 0.2.21 hotwire-0.590-1.fc8 ------------------- * Thu Jul 12 2007 Colin Walters - 0.590-1 - new upstream hplip-2.7.6-6.fc8 ----------------- * Wed Jul 11 2007 Tim Waugh 2.7.6-6 - Add hp-check back, but in the gui sub-package. - Show the HP Toolbox menu entry again. hunspell-sk-1:0.5.6-1.fc8 ------------------------- iproute-2.6.22-1.fc8 -------------------- * Wed Jul 11 2007 Radek Vok??l - 2.6.22-1 - upgrade to 2.6.22 kernel-2.6.23-0.14.rc0.git1.fc8 ------------------------------- * Wed Jul 11 2007 John W. Linville - Reinstate git-wireless-dev.patch - Add updated iwlwifi driver from intellinuxwireless.org * Tue Jul 10 2007 Dave Jones - Fix issue with PIE randomization (#246623). * Tue Jul 10 2007 Dave Jones - 2.6.22-git1 kmenu-gnome-0.6.6-2.fc8 ----------------------- * Wed Jul 11 2007 Chitlesh Goorah - 0.6.6-2 - new upstream release * Mon Jul 09 2007 Ariszlo - 0.6.6-1 - release 0.6.6 - Added printer.png -> gnome-dev-printer.png symlinks libdaemon-0.12-1.fc8 -------------------- * Wed Jul 11 2007 Lennart Poettering - 0.12-1 - Update to upstream 0.12. (Basically just includes patch from 0.11-2) libgnomecanvas-2.19.1-1.fc8 --------------------------- * Wed Jul 11 2007 Matthias Clasen - 2.19.1-1 - Update to 2.19.1 * Tue Jul 10 2007 Matthias Clasen - 2.19.0-1 - Update to 2.19.0 * Thu Dec 07 2006 Matthias Clasen - 2.14.0-5 - Small spec file cleanups libselinux-2.0.23-3.fc8 ----------------------- * Wed Jul 11 2007 Dan Walsh - 2.0.23-3 - Update to match flask/access_vectors in policy liferea-1.2.20-1.fc8 -------------------- * Wed Jul 11 2007 Brian Pepple - 1.2.20-1 - Update to 1.2.20. ltrace-0.5-7.45svn.fc7 ---------------------- * Fri May 04 2007 Petr Machata - 0.5-7.45svn - added fork/exec patches, mostly IBM's work - added trace-exec tests into suite - added ia64 sigill patch * Thu Jan 25 2007 Petr Machata - 0.5-6.45svn - tidy up the specfile per rpmlint comments - fix man page m2crypto-0.17-3 --------------- * Wed Jul 11 2007 Miloslav Trma?? - 0.17-3 - Try to fix build on Alpha Resolves: #246828 mock-0.7.3-1.fc8 ---------------- * Fri Jul 06 2007 Michael Brown - 0.7.3-1 - remove redundant defaults.cfg entries. * Wed Jun 20 2007 Michael Brown - 0.7.2-1 - fix exclude list - remove legacy configs - disable 'local' repos by default (koji-repos) mutt-5:1.5.16-2.fc8 ------------------- * Wed Jul 11 2007 Miroslav Lichvar 5:1.5.16-2 - split urlview off, fix requires and description (#226167) mysql++-2.3.1-1.fc8 ------------------- * Wed Jul 11 2007 Remi Collet 2.3.1-1 - update to 2.3.1 nss-3.11.7-5.fc8 ---------------- * Wed Jul 11 2007 Kai Engert - 3.11.7-5 - Ensure the workaround for mozilla bug 51429 really get's built. ntfsprogs-1.13.1-6.fc8 ---------------------- * Wed Jul 11 2007 Tom "spot" Callaway 1.13.1-6 - build and install "extra" binaries by default (I was accidentally installing the scripts, not the binaries) This better resolves bz 247398 (thanks to Martin Riarte) openoffice.org-1:2.2.1-18.5.fc8 ------------------------------- * Tue Jul 10 2007 Caolan McNamara - 1:2.2.1-18.5 - Resolves: rhbz#245729 openoffice.org-2.2.1.ooo78921.sw.embedded.patch - update setlangtolocale for prettier fonts when appropiate langpack is missing - add openoffice.org-2.2.1.oooXXXXX.sw.titlepagedialog.patch phpPgAdmin-4.1.3-2.fc8 ---------------------- * Wed Jul 11 2007 Devrim Gunduz 4.1.3-2 - Added temporary patch #2 , per sf.net bug #1751614 presto-utils-0.3.1-1.fc8 ------------------------ revisor-2.0.4.1-2.fc8 --------------------- * Tue Jul 10 2007 Jonathan Steffan 2.0.4.1-2 - Trivial specfile change - Added one for one delta suport selinux-policy-3.0.2-5.fc8 -------------------------- * Wed Jul 11 2007 Dan Walsh 3.0.2-5 - Add new devices * Tue Jul 10 2007 Dan Walsh 3.0.2-4 - Add brctl policy tgif-4.1.45-4.fc8 ----------------- * Wed Jul 11 2007 MATSUURA Takanori - 4.1.45-4 - based on tgif-4.1.44-0vl6.src.rpm from VineSeed main - use scalable bitmap font vim-2:7.1.28-1.fc8 ------------------ * Wed Jul 11 2007 Karsten Hopp 7.1.28-1 - patchlevel 28 * Wed Jun 27 2007 Karsten Hopp 7.1.12-1 - Patchlevel 12 * Mon Jun 04 2007 Karsten Hopp 7.1.2-1 - vim 7.1 - drop 240 patches wxGTK-2.8.4-1.fc8 ----------------- * Wed Jul 11 2007 Matthew Miller - 2.8.4-1 - update to 2.8.4 - obsolete compat-wxGTK - add -fno-strict-aliasing xar-1.5.1-1.fc8 --------------- xorg-x11-drv-nv-2.1.2-1.fc8 --------------------------- * Tue Jul 10 2007 Adam Jackson 2.1.2-1 - xf86-video-nv 2.1.2. xorg-x11-proto-devel-7.2-10.fc8 ------------------------------- * Wed Jul 11 2007 Adam Jackson 7.2-10 - inputproto-1.4.2-horrible-header-hack.patch: Re-add some #defines from older inputproto to make old drivers build. Do not commit this patch upstream. yum-presto-0.4.0-1.fc8 ---------------------- * Wed Jul 11 2007 Jonathan Dieter - 0.4.0-1 - Complete rewrite (thanks, Jeremy) - Many features removed in preparation for inclusion in Fedora 8 Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anaconda - 11.3.0.5-1.i386 requires libdhcp4client-3.0.5.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 libdhcp - 1.25-2.fc8.i386 requires libdhcp4client-3.0.5.so.0 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anaconda - 11.3.0.5-1.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 libdhcp - 1.25-2.fc8.i386 requires libdhcp4client-3.0.5.so.0 libdhcp - 1.25-2.fc8.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.i386 requires libdhcp4client-3.0.5.so.0 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anaconda - 11.3.0.5-1.ppc requires libdhcp4client-3.0.5.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 libdhcp - 1.25-2.fc8.ppc requires libdhcp4client-3.0.5.so.0 libdhcp - 1.25-2.fc8.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 mkinitrd - 6.0.9-7.ppc requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.ppc requires libdhcp4client-3.0.5.so.0 nash - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anaconda - 11.3.0.5-1.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 libdhcp - 1.25-2.fc8.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) mkinitrd - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) nash - 6.0.9-7.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) perl-Pugs-Compiler-Rule - 0.24-1.fc8.noarch requires perl(Pugs::Grammar::MiniPerl6) php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From valent.turkovic at gmail.com Thu Jul 12 11:15:59 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 12 Jul 2007 13:15:59 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <4695F160.1040905@nicubunu.ro> References: <1184227039.23921.27.camel@fedora> <4695E7CF.8080200@nicubunu.ro> <1184230325.23921.32.camel@fedora> <4695F160.1040905@nicubunu.ro> Message-ID: <1184238959.23921.48.camel@fedora> On Thu, 2007-07-12 at 12:16 +0300, Nicu Buculei wrote: > I have not checked this, but it may have dependence on certain > versions > of other GNOME/GTK+ libraries Just a followup: http://kernelreloaded.blog385.com/index.php/archives/howto-install-latest-tomboy-in-fedora-core-6/ tinyurl: http://tinyurl.com/273mxo From limb at jcomserv.net Thu Jul 12 11:08:50 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 12 Jul 2007 06:08:50 -0500 (CDT) Subject: [Fwd: Fedora 7 Update: pitivi-0.10.3-2.fc7] In-Reply-To: <200707111557.16574.jkeating@redhat.com> References: <5836.65.192.24.164.1184179917.squirrel@mail.jcomserv.net> <200707111543.44352.jkeating@redhat.com> <52153.65.192.24.164.1184183139.squirrel@mail.jcomserv.net> <200707111557.16574.jkeating@redhat.com> Message-ID: <10996.65.192.24.164.1184238530.squirrel@mail.jcomserv.net> > On Wednesday 11 July 2007 15:45:38 Jon Ciesla wrote: >> Odd. Something I'll watch for with my own packages in the future, >> unless >> you think there might be a software solution to the problem that could >> be >> added to koji^H^H^H^Hbodhi. > > Not koji, but bodhi. Right, bodhi, I said that. :) That's what I meant. :) > -- > Jesse Keating > Release Engineer: Fedora > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From dwmw2 at infradead.org Thu Jul 12 11:42:58 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jul 2007 12:42:58 +0100 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <1184209351.3404.58.camel@localhost.localdomain> References: <1184080763.3490.66.camel@localhost.localdomain> <1184096545.3490.90.camel@localhost.localdomain> <1184150149.17833.70.camel@pmac.infradead.org> <200707110702.18434.jkeating@redhat.com> <1184183874.31598.18.camel@pmac.infradead.org> <1184191136.3404.42.camel@localhost.localdomain> <1184196148.31598.51.camel@pmac.infradead.org> <1184196711.3404.51.camel@localhost.localdomain> <1184198282.31598.80.camel@pmac.infradead.org> <1184208106.11325.8.camel@vader.jdub.homelinux.org> <1184209351.3404.58.camel@localhost.localdomain> Message-ID: <1184240578.31598.135.camel@pmac.infradead.org> On Wed, 2007-07-11 at 22:02 -0500, Tom "spot" Callaway wrote: > Most open source apps build fine on SPARC. Those that do not are > either: > > - endian unclean > - missing sparc configure options > - miscompile on sparc64 > - glibc/gcc/kernel/openssl (only broken on sparc) > - tools need to be made aware of sparc specifics > - irrelevant on sparc I've seen some of that kind of thing too -- but those are generally things which prevent the package from ever getting built in the first place, and thus largely outside the scope of what we were talking about. Of _course_ the arch team is expected to get involved in the _first_ build of the package set. And there should be an ExcludeArch (and corresponding bug) in place for any package which isn't yet ported, before the secondary arch ever comes online. The case we were discussing wasn't the _first_ build of a package though -- it was the case when a package fails, but it _used_ to build OK. _Those_ failures do tend to be generic bugs at least half the time, in my experience. And thus the failures are worthy of at least a _glance_ from the maintainer before shipping the failed package. I'm not saying the maintainer should be on the hook to _fix_ it every time, like we used to be for s390 (although I appreciate that some people have been psychologically scarred for life by that experience and thus find it difficult to rationally contemplate what I'm saying). I'm just saying that the maintainer should be expected to _look_ at the log and make a conscious decision about the failure mode and the pros and cons of shipping the partially-failed package anyway. That really isn't much of a burden. -- dwmw2 From lfarkas at bppiac.hu Thu Jul 12 11:54:57 2007 From: lfarkas at bppiac.hu (Farkas Levente) Date: Thu, 12 Jul 2007 13:54:57 +0200 Subject: High Performance SSH/SCP - HPN-SSH Message-ID: <46961691.4090800@bppiac.hu> hi, is there any plan to include High Performance SSH/SCP - HPN-SSH into fedora's ssh? http://www.psc.edu/networking/projects/hpn-ssh/ -- Levente "Si vis pacem para bellum!" From rdieter at math.unl.edu Thu Jul 12 12:42:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jul 2007 07:42:17 -0500 Subject: High Performance SSH/SCP - HPN-SSH References: <46961691.4090800@bppiac.hu> Message-ID: Farkas Levente wrote: > is there any plan to include High Performance SSH/SCP - HPN-SSH into > fedora's ssh? > http://www.psc.edu/networking/projects/hpn-ssh/ more questions: why isn't this feature included in upstream openssh? are they working to get this feature/code upstream? -- Rex From bpepple at fedoraproject.org Thu Jul 12 13:30:38 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 12 Jul 2007 09:30:38 -0400 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184227039.23921.27.camel@fedora> References: <1184227039.23921.27.camel@fedora> Message-ID: <1184247038.2789.2.camel@kennedy> On Thu, 2007-07-12 at 09:57 +0200, Valent Turkovic wrote: > I use Tomboy all the time on my work FC6 and my home F7 and I didn't > check before but I now noticed that Tomboy on FC6 is still 0.4.1 version > when in F7 it is 0.6 version. > > Tomboy 0.7.1 version came out recently... so my question is this: is > there a reason or some policy why Tomboy on FC6 is leftout from being > updated to some newer version? FC6 isn't rawhide. IMO the only updates to FC6 should be security related. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 caillon at redhat.com Thu Jul 12 13:46:54 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 12 Jul 2007 09:46:54 -0400 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184247038.2789.2.camel@kennedy> References: <1184227039.23921.27.camel@fedora> <1184247038.2789.2.camel@kennedy> Message-ID: <469630CE.3050001@redhat.com> Brian Pepple wrote: > On Thu, 2007-07-12 at 09:57 +0200, Valent Turkovic wrote: >> I use Tomboy all the time on my work FC6 and my home F7 and I didn't >> check before but I now noticed that Tomboy on FC6 is still 0.4.1 version >> when in F7 it is 0.6 version. >> >> Tomboy 0.7.1 version came out recently... so my question is this: is >> there a reason or some policy why Tomboy on FC6 is leftout from being >> updated to some newer version? > > FC6 isn't rawhide. IMO the only updates to FC6 should be security > related. Agreed. And that should happen for F7 as well at some point, too... though I suppose it's not entirely clear when that ought to happen. From limb at jcomserv.net Thu Jul 12 13:43:08 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 12 Jul 2007 08:43:08 -0500 (CDT) Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <469630CE.3050001@redhat.com> References: <1184227039.23921.27.camel@fedora> <1184247038.2789.2.camel@kennedy> <469630CE.3050001@redhat.com> Message-ID: <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> > Brian Pepple wrote: >> On Thu, 2007-07-12 at 09:57 +0200, Valent Turkovic wrote: >>> I use Tomboy all the time on my work FC6 and my home F7 and I didn't >>> check before but I now noticed that Tomboy on FC6 is still 0.4.1 >>> version >>> when in F7 it is 0.6 version. >>> >>> Tomboy 0.7.1 version came out recently... so my question is this: is >>> there a reason or some policy why Tomboy on FC6 is leftout from being >>> updated to some newer version? >> >> FC6 isn't rawhide. IMO the only updates to FC6 should be security >> related. > > Agreed. And that should happen for F7 as well at some point, too... > though I suppose it's not entirely clear when that ought to happen. My understanding was that updates, both security-related and non-security-related would continue for F-N until F-N+1 was released. At that point, F-N would join F-N-1 in a security-only mode until EOL. People expect churn on Fedora, so stay on the bleeding edge (not so bleeding as rawhide, mind you). Is that not correct? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jkeating at redhat.com Thu Jul 12 13:52:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jul 2007 09:52:59 -0400 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> Message-ID: <200707120952.59274.jkeating@redhat.com> On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote: > My understanding was that updates, both security-related and > non-security-related would continue for F-N until F-N+1 was released. ?At > that point, F-N would join F-N-1 in a security-only mode until EOL. > People expect churn on Fedora, so stay on the bleeding edge (not so > bleeding as rawhide, mind you). Is that not correct? Well, since the old end of life was F-N+2 Test2, we talked about making /that/ the security only point and the no new packages point. We could move it back to F-N but that is a short time frame, 6 months. Something to re-visit in FESCo -- 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 Thu Jul 12 14:20:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Jul 2007 16:20:35 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <200707120952.59274.jkeating@redhat.com> References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> Message-ID: <1184250035.22644.90.camel@mccallum.corsepiu.local> On Thu, 2007-07-12 at 09:52 -0400, Jesse Keating wrote: > On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote: > > My understanding was that updates, both security-related and > > non-security-related would continue for F-N until F-N+1 was released. At > > that point, F-N would join F-N-1 in a security-only mode until EOL. > > People expect churn on Fedora, so stay on the bleeding edge (not so > > bleeding as rawhide, mind you). Is that not correct? > > Well, since the old end of life was F-N+2 Test2, we talked about making /that/ > the security only point and the no new packages point. Well, IMO, Fedora's purpose should be "stable while following upstream without API/ABI breakages of existing packages". In practice, this means "frequent updates", "adopt early", "fix ASAP" ("fixed rawhide" and "fixed upstream" should be banned in Fedora) on a "stable foundation (API/ABIs)". It's one fundamental point rendering Fedora interesting. Another one closely related to it is "exposure of user-contributed/developed packages". IMO, users wanting a "security-only updated" distro should probably better choose EPEL or an even more "boring" Linux distro. Ralf From jwilson at redhat.com Thu Jul 12 14:20:45 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 12 Jul 2007 10:20:45 -0400 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: References: <46961691.4090800@bppiac.hu> Message-ID: <469638BD.1090202@redhat.com> Rex Dieter wrote: > Farkas Levente wrote: > >> is there any plan to include High Performance SSH/SCP - HPN-SSH into >> fedora's ssh? >> http://www.psc.edu/networking/projects/hpn-ssh/ > > more questions: > why isn't this feature included in upstream openssh? > are they working to get this feature/code upstream? I just dropped a query to the hpn-ssh maintainers, as I'd love to have this feature myself, having noticed less-than-spectacular scp performance on gigabit links... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ndbecker2 at gmail.com Thu Jul 12 14:41:10 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 12 Jul 2007 10:41:10 -0400 Subject: High Performance SSH/SCP - HPN-SSH References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> Message-ID: Jarod Wilson wrote: > Rex Dieter wrote: >> Farkas Levente wrote: >> >>> is there any plan to include High Performance SSH/SCP - HPN-SSH into >>> fedora's ssh? >>> http://www.psc.edu/networking/projects/hpn-ssh/ >> >> more questions: >> why isn't this feature included in upstream openssh? >> are they working to get this feature/code upstream? > > I just dropped a query to the hpn-ssh maintainers, as I'd love to have > this feature myself, having noticed less-than-spectacular scp > performance on gigabit links... > A related issue: Long ago, ssh included an encryption option "none". I wish it still did! I'd love to have ssh authentication without encryption overhead, when backing up my own data over my own lan. From jwboyer at jdub.homelinux.org Thu Jul 12 14:49:10 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Jul 2007 09:49:10 -0500 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> Message-ID: <1184251750.32199.106.camel@weaponx.rchland.ibm.com> On Thu, 2007-07-12 at 10:41 -0400, Neal Becker wrote: > Jarod Wilson wrote: > > > Rex Dieter wrote: > >> Farkas Levente wrote: > >> > >>> is there any plan to include High Performance SSH/SCP - HPN-SSH into > >>> fedora's ssh? > >>> http://www.psc.edu/networking/projects/hpn-ssh/ > >> > >> more questions: > >> why isn't this feature included in upstream openssh? > >> are they working to get this feature/code upstream? > > > > I just dropped a query to the hpn-ssh maintainers, as I'd love to have > > this feature myself, having noticed less-than-spectacular scp > > performance on gigabit links... > > > > A related issue: > Long ago, ssh included an encryption option "none". I wish it still did! > I'd love to have ssh authentication without encryption overhead, when > backing up my own data over my own lan. Funny, I just asked for the same thing in #fedora-devel this morning and was provided with this link: http://arctic.org/~dean/patches/openssh-3.8.1p1-cipher-none.patch josh From opensource at till.name Thu Jul 12 14:52:09 2007 From: opensource at till.name (Till Maas) Date: Thu, 12 Jul 2007 16:52:09 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184250035.22644.90.camel@mccallum.corsepiu.local> References: <1184227039.23921.27.camel@fedora> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> Message-ID: <200707121652.10999.opensource@till.name> On Do Juli 12 2007, Ralf Corsepius wrote: > Well, IMO, Fedora's purpose should be "stable while following upstream > without API/ABI breakages of existing packages". > > In practice, this means "frequent updates", "adopt early", "fix > ASAP" ("fixed rawhide" and "fixed upstream" should be banned in Fedora) > on a "stable foundation (API/ABIs)". > > It's one fundamental point rendering Fedora interesting. Another one > closely related to it is "exposure of user-contributed/developed > packages". > > IMO, users wanting a "security-only updated" distro should probably > better choose EPEL or an even more "boring" Linux distro. I agree totally, regards, Till From limb at jcomserv.net Thu Jul 12 14:53:07 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 12 Jul 2007 09:53:07 -0500 (CDT) Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <200707121652.10999.opensource@till.name> References: <1184227039.23921.27.camel@fedora> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <200707121652.10999.opensource@till.name> Message-ID: <43076.65.192.24.164.1184251987.squirrel@mail.jcomserv.net> > On Do Juli 12 2007, Ralf Corsepius wrote: > >> Well, IMO, Fedora's purpose should be "stable while following upstream >> without API/ABI breakages of existing packages". >> >> In practice, this means "frequent updates", "adopt early", "fix >> ASAP" ("fixed rawhide" and "fixed upstream" should be banned in Fedora) >> on a "stable foundation (API/ABIs)". >> >> It's one fundamental point rendering Fedora interesting. Another one >> closely related to it is "exposure of user-contributed/developed >> packages". >> >> IMO, users wanting a "security-only updated" distro should probably >> better choose EPEL or an even more "boring" Linux distro. > > I agree totally, +1 > regards, > Till > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jwilson at redhat.com Thu Jul 12 15:07:34 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 12 Jul 2007 11:07:34 -0400 Subject: Heads up: kernel 2.6.23-0.14.rc0.git1.fc8 busted Message-ID: <469643B6.7040705@redhat.com> With the transition to the new kernel rpm versioning scheme, we ended up having to call things such as the pre-2.6.23-rc1 git kernels, which upstream are 2.6.22-gitX, 2.6.23-rc0-gitX. However, I missed a tiny detail, which leaves the kernel package showing 2.6.23, but the resulting kernel's uname 2.6.22. Makes Bad Things happen with any kernel in the 2.6.23-0.x.rc0.git1.fc8 range, where x is . Fixing now (in theory, this is a simple fix by twiddling the kernel Makefile's SUBLEVEL), will push a fixed build ASAP... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From P at draigBrady.com Thu Jul 12 15:10:13 2007 From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Thu, 12 Jul 2007 16:10:13 +0100 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46961691.4090800@bppiac.hu> References: <46961691.4090800@bppiac.hu> Message-ID: <46964455.20805@draigBrady.com> Farkas Levente wrote: > hi, > is there any plan to include High Performance SSH/SCP - HPN-SSH into > fedora's ssh? > http://www.psc.edu/networking/projects/hpn-ssh/ I noticed that for scp if you disable compression (yes disable), then transfer rate increases a lot. I looked at it very quickly and it seemed worse the more the data compressed. Also Protocol=1 seems much better: dd bs=1M count=50 if=/dev/zero of=50MB_zeros dd bs=1M count=50 if=/dev/urandom of=50MB_random $ scp localhost:50MB_random /tmp 50MB_random 100% 50MB 10.0MB/s 00:05 $ scp -C localhost:50MB_random /tmp 50MB_random 100% 50MB 4.6MB/s 00:11 $ scp -C localhost:50MB_zeros /tmp 50MB_zeros 100% 50MB 2.3MB/s 00:22 #setting Protocol=1 in sshd_config I get the following speed: $ scp -C localhost:50MB_zeros /tmp #Includes time to type password! 50MB_zeros 100% 50MB 12.5MB/s 00:04 When talking about improvements to ssh, chrootssh seems useful: http://chrootssh.sourceforge.net/ Also upstream openssh breaks X forwarding in interesting ways unless -Y is specified (at least fedora fixes this). Also scp does full remote login etc. even if local specified files don't exist Also scp has weird error messages: $ scp /etc/fstab localhost:/non_existent/ scp: /non_existent/: Is a directory Don't get me started... P?draig. From jwilson at redhat.com Thu Jul 12 16:02:30 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 12 Jul 2007 12:02:30 -0400 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <469638BD.1090202@redhat.com> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> Message-ID: <46965096.1020503@redhat.com> Jarod Wilson wrote: > Rex Dieter wrote: >> Farkas Levente wrote: >> >>> is there any plan to include High Performance SSH/SCP - HPN-SSH into >>> fedora's ssh? >>> http://www.psc.edu/networking/projects/hpn-ssh/ >> more questions: >> why isn't this feature included in upstream openssh? >> are they working to get this feature/code upstream? > > I just dropped a query to the hpn-ssh maintainers, as I'd love to have > this feature myself, having noticed less-than-spectacular scp > performance on gigabit links... Fun. So apparently, the hpn-ssh folks have been trying to get this into upstream openssh for about 3 years now, and always get put off by openssh folks being "too busy to validate such a big patch". However, I've been assured the code has been vetted by multiple 3rd-parties, and gets heavily utilized in the high-performance networking community, and has been without any incompatibilities w/stock openssh or serious bug reports in over a year. Personally, I'd say lets add it to rawhide and see how it goes... Anyone else have an opinion? Adding Tomas to the cc list, since he maintains our openssh packages, to solicit his opinion as well... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Thu Jul 12 16:05:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jul 2007 18:05:34 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46964455.20805@draigBrady.com> References: <46961691.4090800@bppiac.hu> <46964455.20805@draigBrady.com> Message-ID: <1184256334.16549.1.camel@rousalka.dyndns.org> Le jeudi 12 juillet 2007 ? 16:10 +0100, P?draig Brady a ?crit : > Farkas Levente wrote: > > hi, > > is there any plan to include High Performance SSH/SCP - HPN-SSH into > > fedora's ssh? > > http://www.psc.edu/networking/projects/hpn-ssh/ > > I noticed that for scp if you disable compression (yes disable), > then transfer rate increases a lot. Compression is a big win for remote tranfers. For local ones of course it's a net loss. -- 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 Thu Jul 12 16:12:04 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 12 Jul 2007 11:12:04 -0500 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46964455.20805@draigBrady.com> References: <46961691.4090800@bppiac.hu> <46964455.20805@draigBrady.com> Message-ID: <7874d9dd0707120912q796cf02k482a1f17217972f0@mail.gmail.com> On 7/12/07, P?draig Brady

wrote: > Farkas Levente wrote: > > hi, > > is there any plan to include High Performance SSH/SCP - HPN-SSH into > > fedora's ssh? > > http://www.psc.edu/networking/projects/hpn-ssh/ > > I noticed that for scp if you disable compression (yes disable), > then transfer rate increases a lot. I looked at it very quickly > and it seemed worse the more the data compressed. > Also Protocol=1 seems much better: > > dd bs=1M count=50 if=/dev/zero of=50MB_zeros > dd bs=1M count=50 if=/dev/urandom of=50MB_random > > $ scp localhost:50MB_random /tmp > 50MB_random 100% 50MB 10.0MB/s 00:05 > > $ scp -C localhost:50MB_random /tmp > 50MB_random 100% 50MB 4.6MB/s 00:11 > > $ scp -C localhost:50MB_zeros /tmp > 50MB_zeros 100% 50MB 2.3MB/s 00:22 > > #setting Protocol=1 in sshd_config I get the following speed: > $ scp -C localhost:50MB_zeros /tmp #Includes time to type password! > 50MB_zeros 100% 50MB 12.5MB/s 00:04 > If all you care about is speed why use SSH? Use FTP. Protocol is has some flaws that really can't be overcome, hence, the existance of protocol 2. > > > When talking about improvements to ssh, chrootssh seems useful: > http://chrootssh.sourceforge.net/ > > Also upstream openssh breaks X forwarding in interesting ways > unless -Y is specified (at least fedora fixes this). Remember that upstream's job is for SSH to be SECURE, not to have all these bells and whistles. I asked them about X.509 support, tab-completion in sftp, Public keys in LDAP, and several other features and the answer is always, "will it introduce more bugs specifially in the security space?" Since they are not sure, they decide to be cautious. I actually am kind of surprised the project hasn't forked into the feature-rich SSH and a stable/secure one (classic) OpenSSH. stahnma > > Also scp does full remote login etc. > even if local specified files don't exist > > Also scp has weird error messages: > $ scp /etc/fstab localhost:/non_existent/ > scp: /non_existent/: Is a directory > > > Don't get me started... > > P?draig. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From P at draigBrady.com Thu Jul 12 16:18:25 2007 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Thu, 12 Jul 2007 17:18:25 +0100 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <1184256334.16549.1.camel@rousalka.dyndns.org> References: <46961691.4090800@bppiac.hu> <46964455.20805@draigBrady.com> <1184256334.16549.1.camel@rousalka.dyndns.org> Message-ID: <46965451.3040807@draigBrady.com> Nicolas Mailhot wrote: > Compression is a big win for remote tranfers. For local ones of course > it's a net loss. It's not as simple as that. I also tested across the LAN, and compression slowed things down there also. Also notice, I demonstrated that compressing and transfering random data is faster than zeros. It's something to do with the twisty maze of (zlib) buffers and sleeps within ssh I think. P?draig. From sundaram at fedoraproject.org Thu Jul 12 16:56:46 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 12 Jul 2007 22:26:46 +0530 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184238959.23921.48.camel@fedora> References: <1184227039.23921.27.camel@fedora> <4695E7CF.8080200@nicubunu.ro> <1184230325.23921.32.camel@fedora> <4695F160.1040905@nicubunu.ro> <1184238959.23921.48.camel@fedora> Message-ID: <46965D4E.1040307@fedoraproject.org> Valent Turkovic wrote: > On Thu, 2007-07-12 at 12:16 +0300, Nicu Buculei wrote: >> I have not checked this, but it may have dependence on certain >> versions >> of other GNOME/GTK+ libraries > > Just a followup: > http://kernelreloaded.blog385.com/index.php/archives/howto-install-latest-tomboy-in-fedora-core-6/ > Note that development repository is headed for the next release and in general is not a good place to get later versions. If tomboy depends on newer GNOME development libraries which can happen at any point of time the yum command on your blog will result in breakage. Many other packages might also have debug options enabled which will slow down performance. Fair warning. Rahul From rayvd at bludgeon.org Thu Jul 12 17:09:05 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 12 Jul 2007 10:09:05 -0700 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46965096.1020503@redhat.com> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> Message-ID: <20070712170905.GA28035@bludgeon.org> > Personally, I'd say lets add it to rawhide and see how it goes... Anyone > else have an opinion? Adding Tomas to the cc list, since he maintains > our openssh packages, to solicit his opinion as well... +1 I'd start testing this right away! Hope it gets merged in. Ray From rayvd at bludgeon.org Thu Jul 12 17:20:13 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 12 Jul 2007 10:20:13 -0700 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46965096.1020503@redhat.com> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> Message-ID: <20070712172013.GA28435@bludgeon.org> > Personally, I'd say lets add it to rawhide and see how it goes... Anyone > else have an opinion? Adding Tomas to the cc list, since he maintains > our openssh packages, to solicit his opinion as well... Also.... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224489 It's only been open for about six months with no one looking at it ;) Ray From rdieter at math.unl.edu Thu Jul 12 17:20:17 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jul 2007 12:20:17 -0500 Subject: High Performance SSH/SCP - HPN-SSH References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> Message-ID: Jarod Wilson wrote: > Personally, I'd say lets add it to rawhide and see how it goes... Anyone > else have an opinion? Adding Tomas to the cc list, since he maintains > our openssh packages, to solicit his opinion as well... Diverging from upstream is a wee-bit against fedora's objectives/goals, but ultimately, it is the pkg maintainer's call to make. -- Rex From caillon at redhat.com Thu Jul 12 17:31:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 12 Jul 2007 13:31:05 -0400 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <1184250035.22644.90.camel@mccallum.corsepiu.local> References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> Message-ID: <46966559.7020607@redhat.com> Ralf Corsepius wrote: > On Thu, 2007-07-12 at 09:52 -0400, Jesse Keating wrote: >> On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote: >> > My understanding was that updates, both security-related and >> > non-security-related would continue for F-N until F-N+1 was released. At >> > that point, F-N would join F-N-1 in a security-only mode until EOL. >> > People expect churn on Fedora, so stay on the bleeding edge (not so >> > bleeding as rawhide, mind you). Is that not correct? >> >> Well, since the old end of life was F-N+2 Test2, we talked about making /that/ >> the security only point and the no new packages point. > Well, IMO, Fedora's purpose should be "stable while following upstream > without API/ABI breakages of existing packages". But we also practice don't fix what isn't broken. This is one of the reasons we don't force mass rebuilds of all packages for each release: packages are a known quantity and changing them might fix some bugs but break other things. I get this in Firefox updates all the time, and those _are_ security fixes. I'd bet other packages do as well. If someone files a bug which happens to be fixed in the latest stable upstream, feel free to take the version bump if you think it's right. But don't simply assume that users are seeing the bug when the version bump can introduce more problems than it fixes (how many times have we seen various upstreams make a release only to follow it up with a new release the next day to correct "serious problems"? updates-testing helps here, but that assumes that users of your package use updates-testing which we cannot guarantee). From jspaleta at gmail.com Thu Jul 12 17:50:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jul 2007 09:50:20 -0800 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> Message-ID: <604aa7910707121050x1d89caa0lcddf66a2a8e4f49f@mail.gmail.com> On 7/12/07, Rex Dieter wrote: > Diverging from upstream is a wee-bit against fedora's objectives/goals, but > ultimately, it is the pkg maintainer's call to make. When upstream is working actively with downstream contributors, this policy works well. If upstream blows off downstream contributors who are trying to play ball (and there isn't some sort of weird personality conflict nastiness) the policy can feel burdensome because its re-enforcing a broken process instead of re-enforcing a healthy innovation process. I can't judge the problem here, but if this work has been going on in parallel for 3+ years, something in the upstream communication is broken. The question is, is this a fixable or a forkable situation? Does Fedora has as a community have any leverage with upstream openssh (via an active fedora contributor who conributes to upstream perhaps?) to put this functionality/patch firmly onto the roadmap for upstream adoption? -jef From Michael_E_Brown at dell.com Thu Jul 12 18:00:51 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 12 Jul 2007 13:00:51 -0500 Subject: Video and Keymap Quirks In-Reply-To: <1184185794.2241.7.camel@work> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <20070711200558.GF9945@humbolt.us.dell.com> <1184185794.2241.7.camel@work> Message-ID: <20070712180051.GD24045@humbolt.us.dell.com> On Wed, Jul 11, 2007 at 09:29:54PM +0100, Richard Hughes wrote: > On Wed, 2007-07-11 at 15:05 -0500, Michael E Brown wrote: > > On Tue, Jul 10, 2007 at 12:40:18PM +0100, Richard Hughes wrote: > > > On Tue, 2007-07-10 at 13:31 +0200, Hans de Goede wrote: > > > > Great that you're working on this and targeting F-8 with it. Unfortunately > > > > having only scancode -> keycode mappings in the kernel is not enough to make > > > > most keys just work. This also requires mapping to X keysyms and configurations > > > > of applications. > > > > > > Sure, but this is the first part of the jigsaw. For stuff like > > > rfkill-input we need the kernel to _know_ that KEY_FN_F1 is actually > > > KEY_BLUETOOTH. When X switches to evdev (soon?) the keysym problem > > > should be a lot simpler to fix. > > > > Does the kernel have a concept for a key that can be on-the-fly > > configured to individually turn on/off any combination of wlan, > > bluetooth and/or cellular modems? > > Err, we can use the setkeycode ioctl to remap the button, but I'm > guessing this isn't the answer to the question you are asking. I havent had a lot of time to pursue it, but I have seen several people working on things to handle killswitches. The problem I've seen is that several of them dont take into account features that the Dell notebooks have: software configurable killswitches, and killswitch for cellular in particular. Part of the problem would be that I dont know exactly who to talk to... > > Recent Dell laptops all have a wireless switch. This switch can be > > configured at runtime by dellWirelessCtl (part of libsmbios-bin) to > > individually turn on/off any combination of each of the above. > > We could hook this up to HAL (although I'm not sure yet how) but I'm > guessing the most sane thing to do would be to tie it to a hardware > killswitch that killed all the wireless devices for aircraft scenario. I wrote dellWirelessCtl. There was a patch a while back that integrated it into HAL, but I didnt write that. -- Michael From kevin.kofler at chello.at Thu Jul 12 18:29:53 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 12 Jul 2007 18:29:53 +0000 (UTC) Subject: Will FC6/FE6 merge / move to Koji? References: <200707101606.41878.dennis@ausil.us> Message-ID: Dennis Gilmore ausil.us> writes: > Personally I would like to leave it as is. we still need plague for EPEL so > by switching we wont be freeing up resources. currently plague and koji are > co-existing on the same builders peacefully. However, merging F6 would have some benefits: * maintainer ignorance of Bodhi would no longer cause broken upgrade paths (because everything would have to go through Bodhi or not be updated at all), * community comaintainers could push updates for FC6 packages too. Kevin Kofler From jspaleta at gmail.com Thu Jul 12 18:31:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jul 2007 10:31:20 -0800 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <4695AA29.2090708@marvell.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> <4695721E.1010107@marvell.com> <1184207090.11325.4.camel@vader.jdub.homelinux.org> <4695AA29.2090708@marvell.com> Message-ID: <604aa7910707121131i30cb755ai5cb18e4abddac934@mail.gmail.com> On 7/11/07, Manas Saksena wrote: > I agree. But, it is not necessary unrealistic to allow derivative > distros under the Fedora project umbrella. I think it is necessarily unrealistic for that to happen when you take into account branding policy considerations. If the bits be wrapped up are not under the directly accessible via the centralized fedora codebase thing (cvs or whatever comes after it) then you simply cannot expect that collection of software to be able to be called Fedora. Its unrealistic that this situation is going to change over night, even with new technical bits that make it easier for people to actually produced derived collections. > And, it is certainly fine for us to do these outside the scope of the > Fedora project umbrella. Fedora is used as an upstream for many embedded > distros already. Our goal is to make it easy for the various embedded > ARM distributions (including the ones we create ourselves) to make use > of the Fedora-ARM as the upstream. Uhm, is are current examples of packaging level problems that package maintainers need to address for packages to work on ARM? As compared to... upstream codebase issues that upstream needs to patch? -jef From sean.bruno at dsl-only.net Thu Jul 12 18:35:12 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 12 Jul 2007 11:35:12 -0700 Subject: F8 dmraid/anaconda Message-ID: <1184265312.3161.61.camel@home-desk> Is there anything I can do for F8(testing and debugging) to try and work out some of the kinks with anaconda and dmraid? I can start trying installs from rawhide if that's helpful to you folks. Sean From kevin.kofler at chello.at Thu Jul 12 18:36:42 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 12 Jul 2007 18:36:42 +0000 (UTC) Subject: Tomboy for FC6 not being updated... why? References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <46966559.7020607@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > If someone files a bug which happens to be fixed in the latest stable > upstream, feel free to take the version bump if you think it's right. > But don't simply assume that users are seeing the bug when the version > bump can introduce more problems than it fixes (how many times have we > seen various upstreams make a release only to follow it up with a new > release the next day to correct "serious problems"? updates-testing > helps here, but that assumes that users of your package use > updates-testing which we cannot guarantee). But your suggestion assumes users actually file the bugs they're seeing, which unfortunately we cannot guarantee either. Also, new versions often come with nice new features. For example, XChat 2.8.4 can now save the scrollback buffer for the session and display it as context the next time you open that chan or dialog window. The KDE 3.5.x updates also came with small feature additions like that. Kevin Kofler From mattdm at mattdm.org Thu Jul 12 18:43:59 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Jul 2007 14:43:59 -0400 Subject: re-kicking review request for calc Message-ID: <20070712184359.GA16646@jadzia.bu.edu> I finally made some time to get the Calc (very good arbitrary-precision calculator) package updated. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Jul 12 18:37:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jul 2007 14:37:34 -0400 Subject: F8 dmraid/anaconda In-Reply-To: <1184265312.3161.61.camel@home-desk> References: <1184265312.3161.61.camel@home-desk> Message-ID: <200707121437.35008.jkeating@redhat.com> On Thursday 12 July 2007 14:35:12 Sean Bruno wrote: > I can start trying installs from rawhide if that's helpful to you folks. Yes, since we're not going to go back and fix F7 anaconda. -- 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 Thu Jul 12 18:49:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Jul 2007 00:19:32 +0530 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <46966559.7020607@redhat.com> Message-ID: <469677BC.3060606@fedoraproject.org> Kevin Kofler wrote: The KDE 3.5.x updates also > came with small feature additions like that. > It also broke IMAP filters in Kmail. Robustness is a factor to consider when pushing updates. Sometimes the advantages of new features are outweighed by new bugs. Rahul From mastahnke at gmail.com Thu Jul 12 19:10:19 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 12 Jul 2007 14:10:19 -0500 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <604aa7910707121050x1d89caa0lcddf66a2a8e4f49f@mail.gmail.com> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> <604aa7910707121050x1d89caa0lcddf66a2a8e4f49f@mail.gmail.com> Message-ID: <7874d9dd0707121210ne9a9430r12bef3b9a507a821@mail.gmail.com> On 7/12/07, Jeff Spaleta wrote: > On 7/12/07, Rex Dieter wrote: > > Diverging from upstream is a wee-bit against fedora's objectives/goals, but > > ultimately, it is the pkg maintainer's call to make. > > > When upstream is working actively with downstream contributors, this > policy works well. > If upstream blows off downstream contributors who are trying to play > ball (and there isn't some sort of weird personality conflict > nastiness) the policy can feel burdensome because its re-enforcing a > broken process instead of re-enforcing a healthy innovation process. > > I can't judge the problem here, but if this work has been going on in > parallel for 3+ years, something in the upstream communication is > broken. The question is, is this a fixable or a forkable situation? > Does Fedora has as a community have any leverage with upstream openssh > (via an active fedora contributor who conributes to upstream perhaps?) > to put this functionality/patch firmly onto the roadmap for upstream > adoption? You might want to post to comp.security.ssh, Darren Tucker (one of the Upstream devs from OpenSSH) often responds quickly and politely. stahnma > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From sean.bruno at dsl-only.net Thu Jul 12 19:22:11 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 12 Jul 2007 12:22:11 -0700 Subject: F8 dmraid/anaconda In-Reply-To: <200707121437.35008.jkeating@redhat.com> References: <1184265312.3161.61.camel@home-desk> <200707121437.35008.jkeating@redhat.com> Message-ID: <1184268131.3161.65.camel@home-desk> On Thu, 2007-07-12 at 14:37 -0400, Jesse Keating wrote: > On Thursday 12 July 2007 14:35:12 Sean Bruno wrote: > > I can start trying installs from rawhide if that's helpful to you folks. > > Yes, since we're not going to go back and fix F7 anaconda. Great! I'm glad to help out here. Unfortunately, I'm not sure how to install from: ftp://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os There doesn't appear to be a boot.iso or any installer available(images directory) at the moment for my use. Sean From jkeating at redhat.com Thu Jul 12 19:19:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Jul 2007 15:19:04 -0400 Subject: F8 dmraid/anaconda In-Reply-To: <1184268131.3161.65.camel@home-desk> References: <1184265312.3161.61.camel@home-desk> <200707121437.35008.jkeating@redhat.com> <1184268131.3161.65.camel@home-desk> Message-ID: <200707121519.04256.jkeating@redhat.com> On Thursday 12 July 2007 15:22:11 Sean Bruno wrote: > There doesn't appear to be a boot.iso or any installer available(images > directory) at the moment for my use. The 'make it installable' part of the rawhide compose failed last night. It happens from time to time. Check back tomorrow. -- 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 wtogami at redhat.com Thu Jul 12 19:06:41 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 12 Jul 2007 15:06:41 -0400 Subject: Reminder: Fedora Update Tips Message-ID: <46967BC1.3020800@redhat.com> Tips for Fedora Package Maintainers when issuing updates. 1) Push or Revoke Updates-Testing ================================= https://admin.fedoraproject.org/updates/testing/F7 Please don't forget to deal with your packages sitting in updates-testing. Some packages were sitting here for more than a month. Your Updates Testing package may be marked as "Stable" if they are ready to be pushed as an official update. If you want to cancel an update, or if it was superseded by a newer package, you will want to "Unpush" it. 2) EVR Version Problems ======================= Currently F7 uses Bodhi (the Fedora Updates System) while FE-6 uses the legacy Extras buildsystem. This can sometimes create EVR promotion problems between the distributions. Example: 1) foo-1.2.3-1.fc7 foo-1.2.3-1.fc6 2) foo-1.2.4-1.fc7 is pushed to F7 updates-testing foo-1.2.4-1.fc6 is built for FE-6 3) FC6 version of foo is "newer" than foo in F7, because the FC6 package went directly into the repository while the F7 package is only in testing. Suggested Workaround: Build for FE6 only *after* the F7 update has been officially pushed. Warren Togami wtogami at redhat.com _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From sean.bruno at dsl-only.net Thu Jul 12 19:30:41 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 12 Jul 2007 12:30:41 -0700 Subject: F8 dmraid/anaconda In-Reply-To: <200707121519.04256.jkeating@redhat.com> References: <1184265312.3161.61.camel@home-desk> <200707121437.35008.jkeating@redhat.com> <1184268131.3161.65.camel@home-desk> <200707121519.04256.jkeating@redhat.com> Message-ID: <1184268641.3161.67.camel@home-desk> On Thu, 2007-07-12 at 15:19 -0400, Jesse Keating wrote: > happens from time to time. Check back tomorrow. Thanks...I will. Sean From orion at cora.nwra.com Thu Jul 12 19:36:38 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 12 Jul 2007 13:36:38 -0600 Subject: koji watchlogs hangs firefox Message-ID: <469682C6.4080102@cora.nwra.com> Does koji's watchlogs function hang up anyone else's browser? It generally makes my Firefox window under F7 completely unresponsive. -- 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 msaksena at marvell.com Thu Jul 12 19:56:14 2007 From: msaksena at marvell.com (Manas Saksena) Date: Thu, 12 Jul 2007 12:56:14 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <604aa7910707121131i30cb755ai5cb18e4abddac934@mail.gmail.com> References: <1184080763.3490.66.camel@localhost.localdomain> <1184087130.32199.21.camel@weaponx.rchland.ibm.com> <1184096545.3490.90.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> <4695721E.1010107@marvell.com> <1184207090.11325.4.camel@vader.jdub.homelinux.org> <4695AA29.2090708@marvell.com> <604aa7910707121131i30cb755ai5cb18e4abddac934@mail.gmail.com> Message-ID: <4696875E.7050006@marvell.com> Jeff Spaleta wrote: > On 7/11/07, Manas Saksena wrote: >> I agree. But, it is not necessary unrealistic to allow derivative >> distros under the Fedora project umbrella. > > I think it is necessarily unrealistic for that to happen when you take > into account > branding policy considerations. If the bits be wrapped up are not > under the directly accessible via the centralized fedora codebase > thing (cvs or whatever comes after it) then you simply cannot expect > that collection of software to be able to be called Fedora. Its > unrealistic that this situation is going to change over night, even > with new technical bits that make it easier for people to actually > produced derived collections. Fair enough. I dont really expect anything to change in the near future. What I am saying is that you can creating a branding notion that captures the essence of "derived from" without diluting the original brand. If done right, this should enhance the Fedora brand. Whether or not that is done is upto the people who make these decisions in the Fedora/RedHat hierarchy. Every one derives from Linus' kernel tree and creates their own custom Linux kernel. But, they are all still Linux kernels. And, they dont dilute the "Linux" brand. >> And, it is certainly fine for us to do these outside the scope of the >> Fedora project umbrella. Fedora is used as an upstream for many embedded >> distros already. Our goal is to make it easy for the various embedded >> ARM distributions (including the ones we create ourselves) to make use >> of the Fedora-ARM as the upstream. > > Uhm, is are current examples of packaging level problems that package > maintainers need to address for packages to work on ARM? As compared > to... upstream codebase issues that upstream needs to patch? I am not sure I understand fully. Hopefully, this will make it clear. Most upstream software runs fine on ARM. And, where we have issues, we try to get them fixed in upstream codebase. We have a few packaging issues in Fedora -- these are Fedora issues, not upstream code issues. These are filed in bugzilla. You can see these at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418 For Fedora-ARM, we would need these to be addressed, so we can build in the Fedora infrastructure. This falls under the scope of the Secondary Architecture proposal. The other packaging issues that I am talking about are more to deal with customizing for a specific footprint/functionality tradeoff. So, that kind of packaging tradeoffs need to be handled "locally" (i.e., by the person/team assembling that custom distribution). These are the derived distros that are outside of the Fedora-ARM project -- which is fair. Some of it might have been useful as a deliverable within the Fedora-ARM distro (e.g., inclusion of cross-compilers), but from the discussion, that is not likely to be the case either. So, we will keep that outside of the Fedora-ARM distribution as well. Manas From mikeb at redhat.com Thu Jul 12 19:58:36 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 12 Jul 2007 15:58:36 -0400 Subject: koji watchlogs hangs firefox In-Reply-To: <469682C6.4080102@cora.nwra.com> References: <469682C6.4080102@cora.nwra.com> Message-ID: <1184270316.19343.41.camel@liffey.home> On Thu, 2007-07-12 at 13:36 -0600, Orion Poplawski wrote: > Does koji's watchlogs function hang up anyone else's browser? It > generally makes my Firefox window under F7 completely unresponsive. Something of a known problem. The AJAX library we're using (jsolait) doesn't handle the "asynchronous" part well, and is making blocking calls to the XML-RPC server. I haven't had time to look in to what could be done to improve the situation, if someone has a chance I'd gladly accept patches. From hughsient at gmail.com Thu Jul 12 20:20:56 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 12 Jul 2007 21:20:56 +0100 Subject: Video and Keymap Quirks In-Reply-To: <20070712180051.GD24045@humbolt.us.dell.com> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <20070711200558.GF9945@humbolt.us.dell.com> <1184185794.2241.7.camel@work> <20070712180051.GD24045@humbolt.us.dell.com> Message-ID: <1184271656.2359.7.camel@work> On Thu, 2007-07-12 at 13:00 -0500, Michael E Brown wrote: > I havent had a lot of time to pursue it, but I have seen several people > working on things to handle killswitches. The problem I've seen is that > several of them dont take into account features that the Dell notebooks > have: software configurable killswitches, and killswitch for cellular in > particular. Why do we need to configure a killswitch? Surely a kill switch is just something that kills _all_ wireless for aircraft. If you want to power down individual devices surely this should be done in sysfs. > > > Recent Dell laptops all have a wireless switch. This switch can be > > > configured at runtime by dellWirelessCtl (part of libsmbios-bin) to > > > individually turn on/off any combination of each of the above. > > > > We could hook this up to HAL (although I'm not sure yet how) but I'm > > guessing the most sane thing to do would be to tie it to a hardware > > killswitch that killed all the wireless devices for aircraft scenario. > > I wrote dellWirelessCtl. There was a patch a while back that integrated > it into HAL, but I didnt write that. Sure, unless this stuff just works, very few people are going to use it. Richard. From tmraz at redhat.com Thu Jul 12 20:40:26 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 12 Jul 2007 22:40:26 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46965096.1020503@redhat.com> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> Message-ID: <1184272826.10340.17.camel@perun.kabelta.loc> On Thu, 2007-07-12 at 12:02 -0400, Jarod Wilson wrote: > Jarod Wilson wrote: > > Rex Dieter wrote: > >> Farkas Levente wrote: > >> > >>> is there any plan to include High Performance SSH/SCP - HPN-SSH into > >>> fedora's ssh? > >>> http://www.psc.edu/networking/projects/hpn-ssh/ > >> more questions: > >> why isn't this feature included in upstream openssh? > >> are they working to get this feature/code upstream? > > > > I just dropped a query to the hpn-ssh maintainers, as I'd love to have > > this feature myself, having noticed less-than-spectacular scp > > performance on gigabit links... > > Fun. So apparently, the hpn-ssh folks have been trying to get this into > upstream openssh for about 3 years now, and always get put off by > openssh folks being "too busy to validate such a big patch". However, > I've been assured the code has been vetted by multiple 3rd-parties, and > gets heavily utilized in the high-performance networking community, and > has been without any incompatibilities w/stock openssh or serious bug > reports in over a year. > > Personally, I'd say lets add it to rawhide and see how it goes... Anyone > else have an opinion? Adding Tomas to the cc list, since he maintains > our openssh packages, to solicit his opinion as well... I'm still a little bit uneasy to allow this patch in. We were trying to keep as close to upstream as possible. On the other hand we have other changes we have other patches in like the SELinux changes for MLS and the recent support for keys in NSS by which we significantly diverge from upstream already. So maybe we could reconsider applying the HPN patch or at least some less controversial parts of it. But also note that ssh was designed to be primarily a protocol for interactive shell sessions and thus it has its limitations which mean that it never can be 100% efficient as protocol for large file transfers or even establishing VPNs. It seems to me that people which want extremely fast and secure file transfers should use different solutions like stunnel. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From rayvd at bludgeon.org Thu Jul 12 21:07:06 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 12 Jul 2007 14:07:06 -0700 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46961691.4090800@bppiac.hu> References: <46961691.4090800@bppiac.hu> Message-ID: <20070712210706.GA4358@bludgeon.org> On Thu, Jul 12, 2007 at 01:54:57PM +0200, Farkas Levente wrote: > hi, > is there any plan to include High Performance SSH/SCP - HPN-SSH into > fedora's ssh? > http://www.psc.edu/networking/projects/hpn-ssh/ This OpenSSH bug may be of interest: https://bugzilla.mindrot.org/show_bug.cgi?id=1311 This is not the HPN patch, but a different patch offering some performance gains. Sounds like it'll be in OpenSSH 4.7. Here's another bug with some commentary (and there is plenty more discussion on the OpenSSH mailing list): https://bugzilla.mindrot.org/show_bug.cgi?id=1337 Ray From abo at kth.se Thu Jul 12 21:21:00 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Thu, 12 Jul 2007 23:21:00 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46965096.1020503@redhat.com> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> Message-ID: <1184275260.27984.11.camel@home.alexander.bostrom.net> tor 2007-07-12 klockan 12:02 -0400 skrev Jarod Wilson: > Personally, I'd say lets add it to rawhide and see how it goes... Anyone > else have an opinion? Adding Tomas to the cc list, since he maintains > our openssh packages, to solicit his opinion as well... The problem with this is that if one patch goes in, other will come knocking on the door. :) Here's one example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187211 It adds proper GSSAPI support for OpenSSH so that within a Kerberised infrastructure you never again need to answer that question about if the public key fingerprint is correct. It's a well known patch, it's been around for several years (more than three, I think) but never got fully applied (se bug for more info about that), so the situation is similar. /abo From tmraz at redhat.com Thu Jul 12 21:49:59 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 12 Jul 2007 23:49:59 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <1184275260.27984.11.camel@home.alexander.bostrom.net> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> <1184275260.27984.11.camel@home.alexander.bostrom.net> Message-ID: <1184276999.10340.24.camel@perun.kabelta.loc> On Thu, 2007-07-12 at 23:21 +0200, Alexander Bostr?m wrote: > tor 2007-07-12 klockan 12:02 -0400 skrev Jarod Wilson: > > > Personally, I'd say lets add it to rawhide and see how it goes... Anyone > > else have an opinion? Adding Tomas to the cc list, since he maintains > > our openssh packages, to solicit his opinion as well... > > The problem with this is that if one patch goes in, other will come > knocking on the door. :) Yes, that's exactly what I'm afraid of. And then there is LDAP public key patch, and PKCS#11 patch and X509 patch and who knows what else patch etc. etc. And in the end we will have openssh package which is so diverged from upstream that it will take weeks of work to simply rebase to new upstream version. Also as ssh(d) are realy security sensitive applications if there is some unnoticed security problem in one of these patches it has much bigger risk of staying unnoticed in public for a long time than in the base upstream package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From Michael_E_Brown at dell.com Thu Jul 12 21:59:56 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 12 Jul 2007 16:59:56 -0500 Subject: Video and Keymap Quirks In-Reply-To: <1184271656.2359.7.camel@work> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <20070711200558.GF9945@humbolt.us.dell.com> <1184185794.2241.7.camel@work> <20070712180051.GD24045@humbolt.us.dell.com> <1184271656.2359.7.camel@work> Message-ID: <20070712215956.GD28549@humbolt.us.dell.com> On Thu, Jul 12, 2007 at 09:20:56PM +0100, Richard Hughes wrote: > On Thu, 2007-07-12 at 13:00 -0500, Michael E Brown wrote: > > I havent had a lot of time to pursue it, but I have seen several people > > working on things to handle killswitches. The problem I've seen is that > > several of them dont take into account features that the Dell notebooks > > have: software configurable killswitches, and killswitch for cellular in > > particular. > > Why do we need to configure a killswitch? Surely a kill switch is just > something that kills _all_ wireless for aircraft. If you want to power > down individual devices surely this should be done in sysfs. The word "surely" implies policy. The dell implementation provides mechanism, the user provides policy. Aircraft is one policy. I'm-sitting-at-starbucks-and-dont-want-somebody-to-hack-my-wireless- while-I-upload-pictures-from-my-phone-to-my-laptop-over-bluetooth is another policy. The user can decide which policy they want the killswitch to provide via either BIOS configuration options or through dellWirelessCtl. Writing software that just assumes that the killswitch can only ever do an all-or-nothing operation is encoding bad policy in our software. Also, sysfs, as I've mentioned elsewhere, is a crappy interface for this specific functionality. dellWirelessCtl is implemented in userspace, and it doesnt make sense to try to write a kernel module to do it. > > > > Recent Dell laptops all have a wireless switch. This switch can be > > > > configured at runtime by dellWirelessCtl (part of libsmbios-bin) to > > > > individually turn on/off any combination of each of the above. > > > > > > We could hook this up to HAL (although I'm not sure yet how) but I'm > > > guessing the most sane thing to do would be to tie it to a hardware > > > killswitch that killed all the wireless devices for aircraft scenario. > > > > I wrote dellWirelessCtl. There was a patch a while back that integrated > > it into HAL, but I didnt write that. > > Sure, unless this stuff just works, very few people are going to use it. At the moment, the HAL guys say that it Just Works (havent tested it myself). -- Michael From kevin.kofler at chello.at Thu Jul 12 22:20:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 12 Jul 2007 22:20:18 +0000 (UTC) Subject: High Performance SSH/SCP - HPN-SSH References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> <1184275260.27984.11.camel@home.alexander.bostrom.net> <1184276999.10340.24.camel@perun.kabelta.loc> Message-ID: Tomas Mraz redhat.com> writes: > Yes, that's exactly what I'm afraid of. > > And then there is LDAP public key patch, and PKCS#11 patch and X509 > patch and who knows what else patch etc. etc. And in the end we will > have openssh package which is so diverged from upstream that it will > take weeks of work to simply rebase to new upstream version. What about forking OpenSSH at hosted.fedoraproject.org and trying to get other distributions to join efforts? Kevin Kofler From Christian.Iseli at licr.org Thu Jul 12 22:24:14 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 13 Jul 2007 00:24:14 +0200 Subject: Fedora Package Status of Jul 12, 2007 Message-ID: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> Hi folks, This week's batch. Number of NEW review ticket has gone slightly down, which is good. But the number of open bug reports is increasing pretty rapidly, which is not so good... Next week, I'll be traveling, so there will not be an update for a while (unless someone volunteers, of course :-) ) Cheers, Christian ---- Fedora Package Status of Jul 12, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4716 packages - 7759 binary rpms in devel - 110 orphans - 61 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtkdata Axel dot Thimm at ATrpms dot net vtk afb at users dot sourceforge dot net slim andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue arozansk at redhat dot com edac-utils bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago bdpepple at ameritech dot net brutus-keyring cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask devrim at commandprompt dot com postgresql-pgpool-ha foolish at guezz dot net perl-Net-Packet foolish at guezz dot net perl-SQLite-Simple gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils icon at fedoraproject dot org mod_evasive jafo at tummy dot com python-mechanoid jafo at tummy dot com python-memcached jeff at ocjtech dot us sofsip-cli jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client kwizart at gmail dot com cinepaint lindner at inuus dot com memcached mastahnke at gmail dot com epel-release mkpai at redhat dot com perl-Callback mmahut at redhat dot com sub2srt mpg at redhat dot com olpc-hardware-manager mpg at redhat dot com sugar mpg at redhat dot com sugar-presence-service mpg at redhat dot com xulrunner mpg at redhat dot com sugar-artwork mpg at redhat dot com sugar-datastore mpg at redhat dot com hulahop mpg at redhat dot com xapian-core mpg at redhat dot com pyxapian mpg at redhat dot com xapian-bindings mra at hp dot com engine_pkcs11 opensource at till dot name fcgi orion at cora dot nwra dot com gifsicle paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman pvrabec at redhat dot com rsyslog qspencer at ieee dot org suitesparse rpm at greysector dot net ekg2 ruben at rubenkerkhof dot com mysql-proxy rvokal at redhat dot com gaim-guifications silfreed at silfreed dot net qtpfsgui splinux at fedoraproject dot org drapes steve at silug dot org perl-Net-DNS-Resolver-Programmable sundaram at redhat dot com olpc-utils vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp xgl-maint at redhat dot com xorg-x11-drv-vermilion yufanyufan at gmail dot com audacious-plugins-docklet - 3 packages not available in devel but present in release caolanm at redhat dot com hunspell-he jorton at redhat dot com newt-perl notting at redhat dot com g-wrap - 7 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=222191,231861 eclipse bkonrath at redhat.com cyrus-imapd tjanouse at redhat.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221717,224458,245649,247227,247930 agg caolanm at redhat.com libsilc wtogami at redhat.com gnome-password-generator debarshi.ray at gmail.com Nabi sbehera at redhat.com linkchecker mike at flyn.org - 7 packages present in the development repo which have no owners entry audacious-docklet lablgl lablgtk s390utils stardict-dic ufsparse ws-commons-util - 21 orphaned packages, yet available in devel docbook-dtds docbook-simple docbook-slides docbook-style-dsssl docbook-style-xsl docbook-utils driftnet empathy gnome-bluetooth gob2 libbtctl libedit linuxdoc-tools luks-tools ndesk-dbus openjade opensp pam_usb udftools xmltex xmlto FE-ACCEPT packages stats: - 2853 accepted, closed package reviews - 44 accepted, closed package reviews not in repo - 7 accepted, closed package reviews not in owners - 74 accepted, open package reviews older than 4 weeks; - 86 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 226 open tickets - 82 tickets with no activity in eight weeks - 33 tickets with no activity in four weeks - 13 closed tickets FE-NEW packages stats: - 899 open tickets - 708 tickets with no activity in eight weeks - 45 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 33 open tickets - 3 tickets with no activity in eight weeks - 2 tickets with no activity in four weeks FE-LEGAL 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: - 8535 open tickets - 5347 tickets with no activity in eight weeks - 1140 tickets with no activity in four weeks CVS stats: - 4721 packages with a devel directory - 1 packages with no owners entry tdma - 205 packages were dropped from Fedora Maintainers stats: - 398 maintainers - 2 inactive maintainers with open bugs - 3 inactive maintainers Dropped Fedora packages: - 6 packages were dropped since Fedora 7 Comps.xml files stats: - 2413 packages in comps-f8 file - 1035 packages missing from comps-f8 file - 25 packages in comps-f8 but not in repo - 2392 packages in comps-f7 file - 1003 packages missing from comps-f7 file - 33 packages in comps-f7 but not in repo From sundaram at fedoraproject.org Thu Jul 12 22:35:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Jul 2007 04:05:05 +0530 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> Message-ID: <4696AC99.8020907@fedoraproject.org> Christian Iseli wrote: > Hi folks, > > This week's batch. Number of NEW review ticket has gone slightly down, > which is good. But the number of open bug reports is increasing pretty > rapidly, which is not so good... > > Next week, I'll be traveling, so there will not be an update for a > while (unless someone volunteers, of course :-) ) > > Cheers, > Christian Is there a document on how you are generating these stats? If there are instructions linked from say the bottom of the package status page others might be able to step in while you are away. Also I would exclude the packages in OLPC-2 branch from the devel branch check since they are unlikely to be branched for devel unless they go into the Fedora branches too. Rahul From petersen at redhat.com Thu Jul 12 22:41:31 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 13 Jul 2007 08:41:31 +1000 Subject: Reminder: Fedora Update Tips In-Reply-To: <46967BC1.3020800@redhat.com> References: <46967BC1.3020800@redhat.com> Message-ID: <4696AE1B.4030709@redhat.com> Warren Togami wrote: > https://admin.fedoraproject.org/updates/testing/F7 > Please don't forget to deal with your packages sitting in > updates-testing. Some packages were sitting here for more than a month. Will there be reminders sent out by mail eventually? Jens From Christian.Iseli at licr.org Thu Jul 12 23:11:19 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 13 Jul 2007 01:11:19 +0200 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <4696AC99.8020907@fedoraproject.org> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> <4696AC99.8020907@fedoraproject.org> Message-ID: <20070713011119.60bda1d5@ludwig-alpha.unil.ch> On Fri, 13 Jul 2007 04:05:05 +0530, Rahul Sundaram wrote: > Is there a document on how you are generating these stats? Hmm, not really. There are some hopefully useful comments in the script itself, but they could definitely be improved... The script is here, BTW: http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora I run the script thusly: ./parseBZbugList -bu -p \ -comps \ -o \ -cvs \ >out At the moment, I experience some trouble with bugzilla, which will time out pretty often while retrieving the list of CLOSED package review tickets (both through XMLRPC and through the web query page), so I'm still experimenting to get a stable way to run the script... > If there are > instructions linked from say the bottom of the package status page > others might be able to step in while you are away. That's an idea. I had something up at the UsefulScripts page at some point... Long time since I last checked there. > Also I would exclude the packages in OLPC-2 branch from the devel branch > check since they are unlikely to be branched for devel unless they go > into the Fedora branches too. I'd tend to agree, but since the packages are also listed in owners.list, I'm not sure. I tend to think they should not be listed in owners.list at all, only in owners.olpc.list, to indicate the fact they will not be built for Fedora. Regards, Christian From tibbs at math.uh.edu Fri Jul 13 00:02:39 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Jul 2007 19:02:39 -0500 Subject: Some merge review statistics Message-ID: (Sorry, Warren, if you get this twice; I typoed the list address.) Here are a few bits of information, gleaned from the review trackers at http://fedoraproject.org/PackageReviewStatus/ Number of open merge reviews: in any state: 815 not receiving any commentary since April 18 (the date of a big bugzilla update that reset all of the dates): 709 in progress (fedora-review=?): 88 rejected (fedora-review=-, probably a holdover from an older procedure): 31 in NEEDINFO state: 28 Here are the 28 NEEDINFO merge reviews. It's kind of obvious why some of them aren't receiving attention. Parenthetical comments are mine. With fedora-review = "-" ------------------------ Merge Review: bitmap-fonts https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225617 RH CC: majain at redhat.com Status: NEEDINFO requested of roozbeh at farsiweb.info Since: 2007-02-27 08:16 EST Merge Review: cracklib https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225659 RH CC: nalin at redhat.com Status: NEEDINFO requested of anyone (Status was set by nalin) Merge Review: ethtool https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225735 RH CC: jgarzik at redhat.com Status: NEEDINFO requested of jgarzik at redhat.com Since: 2007-02-16 04:11 EST With fedora-review unset ------------------------ Merge Review: automake15 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225299 RH CC: karsten at redhat.com Status: NEEDINFO requested of anyone Merge Review: automake17 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225301 RH CC: karsten at redhat.com Status: NEEDINFO requested of nobody at fedoraproject.org (Any bets on that needinfo being answered? It was set by Karsten.) Merge Review: automake https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225302 RH CC: karsten at redhat.com Status: NEEDINFO requested of rc040203 at freenet.de Merge Review: bc https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225611 RH CC: tcallowa at redhat.com twoerner at redhat.com Status: NEEDINFO requested of anyone Merge Review: libgtop2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226026 RH CC: sandmann at redhat.com Status: NEEDINFO requested of sandmann at redhat.com Since: 2007-03-29 09:58 EST Merge Review: xfig https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226557 RH CC: than at redhat.com Status: NEEDINFO requested of anyone With fedora-review = "?" ------------------------ Merge Review: arptables_jf https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225255 RH CC: fenalson at redhat.com Status: NEEDINFO requested of mbarabas at redhat.com Since: 2007-06-14 14:15 EST (I'm not sure why mbarabas gets the NEEDINFO here, as he doesn't seem to be involved in the ticket in any way.) Merge Review: attr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225290 RH CC: twoerner at redhat.com Status: NEEDINFO (of nobody) Merge Review: bootparamd https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225623 RH CC: odvorace at redhat.com Status: NEEDINFO (of nobody) Merge Review: busybox https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225631 RH CC: varekova at redhat.com Status: NEEDINFO requested of anyone (really) Merge Review: cryptsetup-luks https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225667 RH CC: pjones at redhat.com Status: NEEDINFO requested of pjones at redhat.com Since: 2007-03-06 00:15 EST Merge Review: dialog https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225693 RH CC: harald at redhat.com Status: NEEDINFO requested of anyone Merge Review: gnupg https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225847 RH CC: nalin at redhat.com Status: NEEDINFO requested of nalin at redhat.com Since: 2007-02-12 14:10 EST Merge Review: gnuplot https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225849 RH CC: varekova at redhat.com Status: NEEDINFO requested of anyone Merge Review: iptables https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225906 RH CC: twoerner at redhat.com Status: NEEDINFO requested of twoerner at redhat.com Since: 2007-02-23 21:53 EST Merge Review: lftp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225984 RH CC: mbarabas at redhat.com Status: NEEDINFO Merge Review: libpng https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226038 RH CC: tgl at redhat.com Status: NEEDINFO requested of anyone Merge Review: nano https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226181 RH CC: dwmw2 at redhat.com Status: NEEDINFO requested of dwmw2 at redhat.com Since: 2007-02-23 11:04 EST Merge Review: net-snmp https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226192 RH CC: jsafrane at redhat.com, rvokal at redhat.com Status: NEEDINFO requested of anyone Merge Review: pm-utils https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226302 RH CC: pknirsch at redhat.com Status: NEEDINFO requested of pknirsch at redhat.com Since: 2007-02-23 22:02 EST Merge Review: rpm https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226377 RH CC: pmatilai at redhat.com, pnasrat at redhat.com Status: NEEDINFO requested of pnasrat at redhat.com Since: 2007-02-23 22:29 EST Merge Review: strace https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226437 RH CC: roland at redhat.com Status: NEEDINFO requested of roland at redhat.com Since: 2007-02-23 22:25 EST Merge Review: vim https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226526 RH CC: karsten at redhat.com Status: NEEDINFO Merge Review: webalizer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226536 RH CC: jorton at redhat.com Status: NEEDINFO Merge Review: xrestop https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226657 RH CC: sandmann at redhat.com Status: NEEDINFO requested of sandmann at redhat.com Since: 2007-02-23 22:07 EST From linux_4ever at yahoo.com Fri Jul 13 00:20:14 2007 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 12 Jul 2007 17:20:14 -0700 (PDT) Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46961691.4090800@bppiac.hu> Message-ID: <537021.8427.qm@web51511.mail.re2.yahoo.com> >is there any plan to include High Performance SSH/SCP - HPN-SSH into >fedora's ssh? Not unless upstream takes it. The Fedora merge did not happen so that we don't have to work with upstream anymore. We should never think about putting a patch in Fedora first and then seeing if upstream takes it. -Steve ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From chitlesh at fedoraproject.org Fri Jul 13 00:42:12 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 13 Jul 2007 02:42:12 +0200 Subject: LICENSE: alliance ; VLSI CAD system Message-ID: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> Hello there, I want to package alliance for fedora, which is a powerful and the best in digital VLSI design. http://www-asim.lip6.fr/recherche/alliance/ ALLIANCE is a complete set of CAD tools and portable libraries for research and education in digital VLSI design. It includes a VHDL compiler and simulator, logic synthesis tools, automatic place and route, DRC, extractor, functional abstraction and formal proof tools etc... All the ALLIANCE cell libraries use a symbolic layout approach in order to provide process independence: Cmos process from 1.6 micron to 0.8 micron have been successfully targetted. However I'm a bit concerned about their license. They called it GPL version 2 and distribute a copy of it: http://www-asim.lip6.fr/pub/alliance/distribution/5.0/ But on their webpage they wrote: Alliance VLSI CAD System is free software. Binaries, source code and cells libraries are freely available under the GNU General Public License (GPL). You are welcome to use the software package even for commercial designs without any fee. You are kindly requested to mention : "Designed with Alliance (c) LIP6, Universit? Pierre et Marie Curie" This particular line confuses me: "You are kindly requested to mention : "Designed with Alliance (c) LIP6, Universit? Pierre et Marie Curie" How would I mention it ? or will fedora permit such"mention" ? However each time a tool under the alliance umbrella is launched under the konsole, it will spit: (for example: graal) [build at goorah ~]$ graal @@@@ @ @@@@ @@ @@ @@ @@ @ @@ @@ @@@ @@@ @@@@ @@@@ @@ @@ @@@ @@ @@ @ @@ @ @@ @@ @@@@@ @@ @@ @@ @@ @@ @@ @@ @@ @ @@ @@ @@@@@ @@@@@ @@ @@ @ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@ @@@ @@ @@@ @@ @@@@ @@@@ @@@@ @@ @@@@ @@ @@@@@@ Graphic layout editor Alliance CAD System 5.0 20060509, graal 5.0 Copyright (c) 1999-2007, ASIM/LIP6/UPMC Author(s): Ludovic Jacomme and Frederic Venot E-mail : alliance-users at asim.lip6.fr There are also some examples which contains copyrighted materials from Cadence. Surely, if ever alliance would enter the fedora collection, those examples would be removed. So what do you think about it ? Can I still ask for review ? There was a discussion in the debian community as well: http://osdir.com/ml/debian.devel.legal/2002-04/msg00007.html This is part of a tutorial I'm writing on how to use alliance (which needs to be completed): http://chitlesh.googlepages.com/full_adder_alliance regards, Chitlesh -- http://clunixchit.blogspot.com From sundaram at fedoraproject.org Fri Jul 13 00:52:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Jul 2007 06:22:21 +0530 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> Message-ID: <4696CCC5.8090009@fedoraproject.org> Chitlesh GOORAH wrote: > > This particular line confuses me: > "You are kindly requested to mention : "Designed with Alliance (c) > LIP6, Universit? Pierre et Marie Curie" > > How would I mention it ? or will fedora permit such"mention" ? You aren't required to mention it. People who create designs with this software are required to give some credit in some way within their design. A request like this might be considered a contradiction with the license. I would recommend you contact upstream and ask for a clarification. > However each time a tool under the alliance umbrella is launched under > the konsole, it will spit: (for example: graal) This is acceptable. > There are also some examples which contains copyrighted materials from > Cadence. Surely, if ever alliance would enter the fedora collection, > those examples would be removed. By "copyrighted" do you mean they are under restrictive copyright licenses? If so, they should be removed. > So what do you think about it ? > Can I still ask for review ? Ask for clarification from upstream. You should point out the any software licensed under GPL does not allow any additional restrictions. If the designs created using such software is required to carry a credit notice even for commercial purposes then what they need is a entirely different license and not GPL and that license will probably be considered proprietary. A self contradictory license makes the software non-redistributable by anyone except the original authors. Rahul From kevin.kofler at chello.at Fri Jul 13 00:55:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 13 Jul 2007 00:55:18 +0000 (UTC) Subject: LICENSE: alliance ; VLSI CAD system References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > This particular line confuses me: > "You are kindly requested to mention : "Designed with Alliance (c) > LIP6, Universit? Pierre et Marie Curie" As I read it, "kindly requested" is not a requirement, so it can be ignored. But be warned that I am not a lawyer. Kevin Kofler From kevin.kofler at chello.at Fri Jul 13 00:59:34 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 13 Jul 2007 00:59:34 +0000 (UTC) Subject: High Performance SSH/SCP - HPN-SSH References: <46961691.4090800@bppiac.hu> <537021.8427.qm@web51511.mail.re2.yahoo.com> Message-ID: Steve G yahoo.com> writes: > Not unless upstream takes it. The Fedora merge did not happen so that we > don't have to work with upstream anymore. We should never think about putting > a patch in Fedora first and then seeing if upstream takes it. Fedora ships and has always shipped plenty of patches. It not being upstream is definitely an argument against shipping it, but there might be reasons why shipping it is a net win after all. Also, if upstream isn't willing to merge patches, it might even make sense to fork the project. Kevin Kofler From jwboyer at jdub.homelinux.org Fri Jul 13 01:02:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Jul 2007 20:02:43 -0500 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: References: <46961691.4090800@bppiac.hu> <537021.8427.qm@web51511.mail.re2.yahoo.com> Message-ID: <1184288563.17091.3.camel@vader.jdub.homelinux.org> On Fri, 2007-07-13 at 00:59 +0000, Kevin Kofler wrote: > Steve G yahoo.com> writes: > > Not unless upstream takes it. The Fedora merge did not happen so that we > > don't have to work with upstream anymore. We should never think about putting > > a patch in Fedora first and then seeing if upstream takes it. > > Fedora ships and has always shipped plenty of patches. It not being upstream is > definitely an argument against shipping it, but there might be reasons why > shipping it is a net win after all. > > Also, if upstream isn't willing to merge patches, it might even make sense to > fork the project. Please don't use the 'f' word lightly. Forking is the exact opposite goal of Fedora. josh From jspaleta at gmail.com Fri Jul 13 02:50:26 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jul 2007 18:50:26 -0800 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <4696875E.7050006@marvell.com> References: <1184080763.3490.66.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> <4695721E.1010107@marvell.com> <1184207090.11325.4.camel@vader.jdub.homelinux.org> <4695AA29.2090708@marvell.com> <604aa7910707121131i30cb755ai5cb18e4abddac934@mail.gmail.com> <4696875E.7050006@marvell.com> Message-ID: <604aa7910707121950h63ddcc28i7e7a735bd679ded3@mail.gmail.com> On 7/12/07, Manas Saksena wrote: > Every one derives from Linus' kernel tree and creates their own custom > Linux kernel. But, they are all still Linux kernels. And, they dont > dilute the "Linux" brand. Its more complicated than brand value. My interpretation, from sitting outside the red hat fenceline, is that there's also potential liability associated with 'blessing' a codebase that is not under the direct control of the fedora build system. I'd absolutely LOVE to find a solution in derived-distribution space that let the builders of these distros share credit with the Fedora community. It sure be super nice to be able to have people gloat and preen over their consumption of the work we are doing. There's no doubt in my mind, that its a PR win all around if we can find a way to present Fedora as an ecosystem of distributions, even the derived ones and march forward into the future arm-in-ARM singing obnoxiously. But since linus, as the trademark holder to linux, isn't the name of a corporation incorporated in a hyper-litigious country with enough assests to be worth protecting... the parallel between the trademark situations is not really the same. -jef"all analogies are like the expensive suit you bought a couple of years back, before you stopped exercising."spaleta From nicolas.mailhot at laposte.net Fri Jul 13 05:29:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Jul 2007 07:29:03 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <46965451.3040807@draigBrady.com> References: <46961691.4090800@bppiac.hu> <46964455.20805@draigBrady.com> <1184256334.16549.1.camel@rousalka.dyndns.org> <46965451.3040807@draigBrady.com> Message-ID: <1184304543.3921.3.camel@rousalka.dyndns.org> Le jeudi 12 juillet 2007 ? 17:18 +0100, P?draig Brady a ?crit : > Nicolas Mailhot wrote: > > Compression is a big win for remote tranfers. For local ones of course > > it's a net loss. > > It's not as simple as that. > I also tested across the LAN, LAN counts as local too. You can find many discussions on compression pros & cons at the protocol level on the internet. -- 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 kevin.kofler at chello.at Fri Jul 13 06:21:09 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 13 Jul 2007 06:21:09 +0000 (UTC) Subject: Existing features listed for Fedora 8 Message-ID: Are the features already listed for Fedora 8 (e.g. FeatureKDE4) supposed to get FESCo approval too? If not, should they be added directly to CategoryApprovedFedora8? Or should they just stay in the legacy CategoraFedora8Features? I added FeatureKDE4 to CategoryProposedFedora8, but I'm asking to make sure I'm following the proper procedure here, and also to get the awareness of the owners of the other features in the same situation. Kevin Kofler From rc040203 at freenet.de Fri Jul 13 06:24:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Jul 2007 08:24:38 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <46966559.7020607@redhat.com> References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <46966559.7020607@redhat.com> Message-ID: <1184307880.22644.240.camel@mccallum.corsepiu.local> On Thu, 2007-07-12 at 13:31 -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > > On Thu, 2007-07-12 at 09:52 -0400, Jesse Keating wrote: > >> On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote: > >> > My understanding was that updates, both security-related and > >> > non-security-related would continue for F-N until F-N+1 was released. At > >> > that point, F-N would join F-N-1 in a security-only mode until EOL. > >> > People expect churn on Fedora, so stay on the bleeding edge (not so > >> > bleeding as rawhide, mind you). Is that not correct? > >> > >> Well, since the old end of life was F-N+2 Test2, we talked about making /that/ > >> the security only point and the no new packages point. > > Well, IMO, Fedora's purpose should be "stable while following upstream > > without API/ABI breakages of existing packages". > > But we also practice don't fix what isn't broken. Well, ... the crucial point about this is the definition of "brokenness". In practice, many packages contain many (mostly unknown) tiny bugs, which only hit (and limit a package's usability) on occasion. In most cases, they are gradually being addressed/fixed by upstream and/or a package's Fedora maintainer. The point we are discussing here is: When and how to propagate these fixes to current users? A responsibly acting maintainer will balance between tradeoffs. In some cases (seemingly most of mine) pushing updates immediately is possible, in some cases, other issues will outweigh a bugfix. As a user, to me, the nagging cases however are those Fedora maintainers who claim to have fixed bugs "rawhide"/"upstream", even in obvious cases, without having released new packages. To put it bluntly, I consider these maintainers to be acting grossly negligent and them to be harmful to Fedora. > This is one of the > reasons we don't force mass rebuilds of all packages for each release: > packages are a known quantity and changing them might fix some bugs but > break other things. I get this in Firefox updates all the time, and > those _are_ security fixes. I'd bet other packages do as well. This doesn't apply to the packages I maintain. For them, it's primarily "upstream finds+fixes bugs", no Fedora user has ever reported and fixes them as part of their on-going upstream development flow (in many cases in "very simple and obvious" manners). > If someone files a bug which happens to be fixed in the latest stable > upstream, feel free to take the version bump if you think it's right. Right, IMO, "Trying to fix what's known to be broken ASAP" should be the default policy, but maintainers acting responsibly also should be taken for granted. > But don't simply assume that users are seeing the bug when the version > bump can introduce more problems than it fixes (how many times have we > seen various upstreams make a release only to follow it up with a new > release the next day to correct "serious problems"? Right, but .. judging upon upstream development and letting upstream work flow back into Fedora in reasonable manners should be a package's maintainer's task and responsibility. Changing the workflow in such a way that "Fedora should receive security updates only" would be silly, IMO. > updates-testing > helps here, but that assumes that users of your package use > updates-testing which we cannot guarantee). My opinion on "testing" probably is known ;) Ralf From kevin.kofler at chello.at Fri Jul 13 06:40:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 13 Jul 2007 06:40:07 +0000 (UTC) Subject: Tomboy for FC6 not being updated... why? References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <46966559.7020607@redhat.com> <469677BC.3060606@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > It also broke IMAP filters in Kmail. I know. I was fully aware of this regression, as were Than and Rex, we decided to push the update anyway in the KDE SIG meeting because we all felt the benefits of the update outweighed the regressions we knew about. Maybe we could have handled this in some better way (how? unpushing the update which was already in the buildroots (dist-fc7-override) and causing lots of chaos? letting the update and all the updates built against it stay in testing for weeks (until we have a fix)? pushing only portions of 3.5.7 (like kdelibs) and not others (like kdepim)?), but this regression wasn't a surprise to us. Kevin Kofler From opensource at till.name Fri Jul 13 07:46:24 2007 From: opensource at till.name (Till Maas) Date: Fri, 13 Jul 2007 09:46:24 +0200 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: References: <1184227039.23921.27.camel@fedora> <469677BC.3060606@fedoraproject.org> Message-ID: <200707130946.27147.opensource@till.name> On Fr Juli 13 2007, Kevin Kofler wrote: > I know. I was fully aware of this regression, as were Than and Rex, we > decided to push the update anyway in the KDE SIG meeting because we all > felt the benefits of the update outweighed the regressions we knew about. > Maybe we could have handled this in some better way (how? unpushing the Is this about the KDE 3.5.7 update? In this case, you could habe included this information in the update announce mail. Regards, Till From sundaram at fedoraproject.org Fri Jul 13 07:50:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Jul 2007 13:20:47 +0530 Subject: Tomboy for FC6 not being updated... why? In-Reply-To: References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <46966559.7020607@redhat.com> <469677BC.3060606@fedoraproject.org> Message-ID: <46972ED7.6050104@fedoraproject.org> Kevin Kofler wrote: > Rahul Sundaram fedoraproject.org> writes: >> It also broke IMAP filters in Kmail. > > I know. I was fully aware of this regression, as were Than and Rex, we decided > to push the update anyway in the KDE SIG meeting because we all felt the > benefits of the update outweighed the regressions we knew about I migrated to Thunderbird in the system I was using Kmail on because receiving thousands of mails on the inbox instead of carefully filtered mails into dozens of folders was completely unacceptable to me. I might take filtering out of mail clients entirely and I am planning to use pan and gmane since that appears to be the better path atleast for fedora lists but neverthless I don't think the decision to let this into regression knowingly into updates was a right one. I went back and read after this happened the KDE SIG meeting minutes and it was very surprising to me that the team would have made such a decision. Not to harp on KDE SIG but it does seem that we don't value robustness as much as we should for updates in general and that is worrisome to me as I rely on Fedora everyday as a end user to get work done. Rahul From ffesti at redhat.com Fri Jul 13 08:14:04 2007 From: ffesti at redhat.com (Florian Festi) Date: Fri, 13 Jul 2007 10:14:04 +0200 Subject: Making evdev X11 input driver default? In-Reply-To: <1184172420.2794.28.camel@localhost.localdomain> References: <4694EE09.2050604@redhat.com> <1184172420.2794.28.camel@localhost.localdomain> Message-ID: <4697344C.3060203@redhat.com> Adam Jackson wrote: > On Wed, 2007-07-11 at 16:49 +0200, Florian Festi wrote: >> Are there already any efforts/plans to make the evdev driver default for F8 >> or any later release? Who would be in charge of such decision? Is there >> anyone else working on xkbd files for evdev currently? > > Not yet. It sort of requires working input hotplug, which isn't quite > baked upstream. > > It'd probably be either my domain or Kristian's. Is there already a ETA for these upstream changes? Florian From nicolas.mailhot at laposte.net Fri Jul 13 08:41:38 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Jul 2007 10:41:38 +0200 (CEST) Subject: Tomboy for FC6 not being updated... why? In-Reply-To: <46972ED7.6050104@fedoraproject.org> References: <1184227039.23921.27.camel@fedora> <469630CE.3050001@redhat.com> <48443.65.192.24.164.1184247788.squirrel@mail.jcomserv.net> <200707120952.59274.jkeating@redhat.com> <1184250035.22644.90.camel@mccallum.corsepiu.local> <46966559.7020607@redhat.com> <469677BC.3060606@fedoraproject.org> <46972ED7.6050104@fedoraproject.org> Message-ID: <11517.192.54.193.51.1184316098.squirrel@rousalka.dyndns.org> Le Ven 13 juillet 2007 09:50, Rahul Sundaram a ?crit : > Not to > harp on KDE SIG but it does seem that we don't value robustness as > much > as we should for updates in general and that is worrisome to me as I > rely on Fedora everyday as a end user to get work done. There is a worrying tendency to systematically push updates to every Fedora version under the sun. Fedora-devel is supposed to get this stuff and spend a few months stabilizing it before the next Fedora release. Users that want the latest and greatest should use devel. Users that want regular releases + some bleeding-edge enhancements should selectively install rawhide packages. Users that just want to use stable Fedora releases without worrying about compatibility breakage between release bumps should be entitled to configure stable+updates without needing any dangerous update filtering. The argument is always "but if I'm the only one doing this I'm not destabilising Fedora too much, and the result is less user-hostile than Devel". It's basic premise is wrong - why should other packagers restrict themselves just so some can go update-happy safely? And if they don't restrict themselves, how stable is the result going to be? If users are not getting new versions fast enough the Fedora cycle needs to be shortened, not bypassed. If it's not possible to shorten the cycle while preserving stability, how is delivering rawhide bits piecemeal without any devel staging is going to be any more stable and user-friendly? Fedora is merged now. Cycle length is in the community's hand. There's no need to workaround a RedHat-controlled cycle length like in the Fedora Core + Third party repositories days. If needs be we can add RHEL-like in-cycle coordinated (& tested) minor release pushes. Anything that strengths the "RHEL alpha" perception that turns out vast numbers of potential users is bad for the project. -- Nicolas Mailhot From spng.yang at gmail.com Fri Jul 13 08:43:47 2007 From: spng.yang at gmail.com (Ken YANG) Date: Fri, 13 Jul 2007 16:43:47 +0800 Subject: KRegExpEditor not in fedora? Message-ID: <46973B43.4040403@gmail.com> hi, all i want to use KRegExpEditor in fedora, but i can not find it in fedora repository, is it renamed? -(:16:42:$)-> sudo yum search KRegExpEditor Loading "changelog" plugin Loading "installonlyn" plugin Excluding Packages in global exclude list Finished No Matches found i enabled fedora-development and livna-devel repo From asric at asric.com Fri Jul 13 08:55:42 2007 From: asric at asric.com (Steven Ringwald) Date: Fri, 13 Jul 2007 01:55:42 -0700 Subject: KRegExpEditor not in fedora? In-Reply-To: <46973B43.4040403@gmail.com> References: <46973B43.4040403@gmail.com> Message-ID: <46973E0E.5000904@asric.com> Ken YANG wrote: > i want to use KRegExpEditor in fedora, but i can not find it > in fedora repository, is it renamed? > > -(:16:42:$)-> sudo yum search KRegExpEditor > Loading "changelog" plugin > Loading "installonlyn" plugin > Excluding Packages in global exclude list > Finished > No Matches found > > > i enabled fedora-development and livna-devel repo > I think that it is in the kdeutils or kdeutils-extras package.. Which release of Fedora are you using?? Steve From hughsient at gmail.com Fri Jul 13 08:58:07 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Jul 2007 09:58:07 +0100 Subject: Video and Keymap Quirks In-Reply-To: <20070712215956.GD28549@humbolt.us.dell.com> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <20070711200558.GF9945@humbolt.us.dell.com> <1184185794.2241.7.camel@work> <20070712180051.GD24045@humbolt.us.dell.com> <1184271656.2359.7.camel@work> <20070712215956.GD28549@humbolt.us.dell.com> Message-ID: <1184317087.2382.8.camel@work> On Thu, 2007-07-12 at 16:59 -0500, Michael E Brown wrote: > On Thu, Jul 12, 2007 at 09:20:56PM +0100, Richard Hughes wrote: > > On Thu, 2007-07-12 at 13:00 -0500, Michael E Brown wrote: > > > I havent had a lot of time to pursue it, but I have seen several people > > > working on things to handle killswitches. The problem I've seen is that > > > several of them dont take into account features that the Dell notebooks > > > have: software configurable killswitches, and killswitch for cellular in > > > particular. > > > > Why do we need to configure a killswitch? Surely a kill switch is just > > something that kills _all_ wireless for aircraft. If you want to power > > down individual devices surely this should be done in sysfs. > > The word "surely" implies policy. No the work surely was intended to mean "it should". > The dell implementation provides > mechanism, the user provides policy. Aircraft is one policy. > I'm-sitting-at-starbucks-and-dont-want-somebody-to-hack-my-wireless- > while-I-upload-pictures-from-my-phone-to-my-laptop-over-bluetooth > is another policy. Then you don't use a kill switch, you just don't set your bluetooth adapter to discoverable. Bluetooth adapters use lots of power - the device should be powered down when not in use and only powered up when needed. But that's not my point. > The user can decide which policy they want the > killswitch to provide via either BIOS configuration options or through > dellWirelessCtl. It seems to me the default action should be kill _everything_ and only lets really advanced users who know what thay are doing can use dellWirelessCtl. > Writing software that just assumes that the killswitch can only ever do > an all-or-nothing operation is encoding bad policy in our software. I disagree. Getting on a plane and switching the kill switch to off, only to find it's only disabled the bluetooth and not the wlan is a totally bad design decision in my opinion. > Also, sysfs, as I've mentioned elsewhere, is a crappy interface for this > specific functionality. dellWirelessCtl is implemented in userspace, and > it doesnt make sense to try to write a kernel module to do it. Unfortunately I think Dell hardware is the odd-one-out here - in all the hardware I've used the kill switch is either implemented in hardware or involves writing low level commands or poking values in registers, and hence handled in kernel drivers. Richard. From drago01 at gmail.com Fri Jul 13 09:46:48 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 13 Jul 2007 11:46:48 +0200 Subject: no update info in repo data? In-Reply-To: <20070607061825.GA15374@nostromo.devel.redhat.com> References: <4667A052.5050508@gmail.com> <20070607061825.GA15374@nostromo.devel.redhat.com> Message-ID: <46974A08.2060803@gmail.com> Bill Nottingham wrote: > dragoran (drago01 at gmail.com) said: > >> Updates in F7 seem not to contain any additional info like chnagelog, >> security update or not etc. >> Atleast pup does not display this information... in FC6 it did. >> Known issue? >> > > Yes, it's not fully ported to bodhi yet. > > any update on this? From buildsys at redhat.com Fri Jul 13 10:07:41 2007 From: buildsys at redhat.com (Build System) Date: Fri, 13 Jul 2007 06:07:41 -0400 Subject: rawhide report: 20070713 changes Message-ID: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> New package R-mvtnorm Multivariate normal and T distribution R Package New package gconf-cleaner A Cleaning tool for GConf New package libxcb A C binding to the X11 protocol New package mod_evasive Denial of Service evasion module for Apache New package naturette Naturette, an AGI adventure game New package ocaml-findlib Objective CAML package manager and build helper New package perl-Gearman-Client-Async Asynchronous Client for the Gearman distributed job system New package perl-Net-DNS-Resolver-Programmable Programmable DNS resolver class for offline emulation of DNS New package perl-Net-DNS-SEC DNSSEC modules for Perl New package redland Redland RDF Application Framework New package sofsip-cli SIP VoIP/IM example client New package xoo Xoo is a graphical wrapper around xnest Updated Packages: amanda-2.5.2p1-4.fc8 -------------------- * Thu Jul 12 2007 Radek Brich 2.5.2.p1-4 - Enable backing up ACL/SElinux xattrs with tar (#201916). - Removed obsolete patches and sources. at-3.1.10-15.fc8 ---------------- * Wed Jul 11 2007 Marcela Maslanova - 3.1.10-15 - rewrite init script - add own session - setsid - Resolves: rhbz#247091 bigboard-0.5.2-1.fc8 -------------------- * Thu Jul 12 2007 Colin Walters - 0.5.2-1 - new upstream - add gconf to files * Thu Jul 12 2007 Colin Walters - 0.5.1-1 - new upstream clamav-0.91-0.fc8 ----------------- * Thu Jul 12 2007 Enrico Scholz - 0.91-1 - updated to 0.91 control-center-1:2.19.5-2.fc8 ----------------------------- * Thu Jul 12 2007 Matthias Clasen - 2.19.5-2 - Tiny improvement to the default applications capplet emacs-common-muse-3.03-3.fc8 ---------------------------- * Thu Jul 12 2007 Jonathan G. Underwood - 3.03-3 - Added patch with various fixes from upstream maintainer to fix issues raised in BZ 247369 exiv2-0.15-1.fc8 ---------------- * Thu Jul 12 2007 Rex Dieter 0.15-1 - exiv2-0.15 flac123-0.0.11-1.fc8 -------------------- * Thu Jul 12 2007 Sindre Pedersen Bj??rdal - 0.0.11-1 - Bump to 0.0.11, this fixes #246322 and adds flac 1.1.4 support - Remove flac 1.1.3 patch, it's not needed anymore glib2-2.13.7-2.fc8 ------------------ * Thu Jul 12 2007 Matthias Clasen - 2.13.7-2 - Fix build issues on ppc * Thu Jul 12 2007 Matthias Clasen - 2.13.7-1 - Update to 2.13.7 gnome-bluetooth-0.9.0-1.fc8 --------------------------- * Thu Jul 12 2007 - Bastien Nocera - 0.9.0-1 - Update for 0.9.0 - Fix installation of the python bindings gnome-panel-2.19.5-2.fc8 ------------------------ * Thu Jul 12 2007 Matthias Clasen - 2.19.5-2 - Fix a crash in the new timezone code in the clock applet gnome-user-share-0.11-6.fc8 --------------------------- * Thu Jul 12 2007 Matthias Clasen - 0.11-6 - Disable the password entry for "never" * Thu Jul 12 2007 Owen Taylor - 0.11-5 - Regenerate configure since patch1 changes configure.in * Thu Jul 12 2007 Owen Taylor - 0.11-4 - Add a patch from SVN to export DBUS session ID via Avahi (b.g.o #455307) graphviz-2.12-8.fc8 ------------------- * Thu Jul 12 2007 Patrick "Jima" Laughton 2.12-8 - Patch to fix BZ#241790 (thanks John!) hwdata-0.206-1.fc8 ------------------ * Thu Jul 12 2007 Karsten Hopp 0.206-1 - build -* Wed Jul 11 2007 Matt Domsch - add dell-monitors.patch so Dell can update these themselves. * Mon Jul 02 2007 Karsten Hopp 0.206-1 - add Acer AL1916W monitor (#200572) - add Eizo L568D, L568 (#200572) - add Samsung 795DF/795MB/Magic CD175GP (#200572) jakarta-commons-logging-0:1.0.4-6jpp.2 -------------------------------------- * Wed Jul 11 2007 Ben Konrath - 0:1.0.4-6jpp.2 - Add eclipse-manifest patch. kbackup-0.5.1-7.fc8 ------------------- * Thu Jul 12 2007 Alain Portal 0.5.1-7 - Disable parallel building until this is fixed by upstream * Thu Jul 12 2007 Alain Portal 0.5.1-6 - Try a build without parallel make support * Thu Jul 12 2007 Alain Portal 0.5.1-5 - Fix date in changelog kernel-2.6.23-0.15.rc0.git1.fc8 ------------------------------- * Wed Jul 11 2007 Roland McGrath - core dump enhancement: include first page of ELF files, with sysctl control * Wed Jul 11 2007 John W. Linville - Reinstate git-wireless-dev.patch - Add updated iwlwifi driver from intellinuxwireless.org * Tue Jul 10 2007 Dave Jones - Fix issue with PIE randomization (#246623). kernel-xen-2.6-2.6.20-2925.11.fc8 --------------------------------- * Thu Jul 12 2007 Eduardo Habkost - Remove #ifdef CONFIG_PM from acpi poweroff code (fix bug #241381) - BuildRequires: python for xen buildsystem mkheader.py ksh-20070628-1.fc8 ------------------ * Thu Jul 12 2007 Tomas Smetana 20070628-1 - new upstream version - fix unaligned access messages (Related: #219420) libbtctl-0.9.0-1.fc8 -------------------- * Thu Jul 12 2007 - Bastien Nocera - 0.9.0-1 - Update to 0.9.0 - Remove out-dated patches * Wed Feb 28 2007 Harald Hoyer - 0.8.2-3.fc8 - specfile review - portet crash patch to 0.8.2 * Thu Dec 07 2006 Jeremy Katz - 0.8.2-2.fc8 - rebuild for python 2.5 libdhcp-1.25-3.fc8 ------------------ * Thu Jul 12 2007 Jesse Keating - 1.25-3 - Rebuild against new dhcp packages, again libgsf-1.14.5-1.fc8 ------------------- * Thu Jul 12 2007 Caolan McNamara 1.14.5-1 - next version libpciaccess-0.8-0.2.20070712git.fc8 ------------------------------------ mesa-6.5.2-13.fc7 ----------------- * Mon Jul 09 2007 Adam Jackson 6.5.2-13 - mesa-6.5.2-radeon-backports-231787.patch: One more fix for r300. (#231787) * Mon Jul 09 2007 Adam Jackson 6.5.2-12 - Don't install header files for APIs that we don't provide. (#247390) * Fri Jul 06 2007 Adam Jackson 6.5.2-11 - mesa-6.5.2-via-respect-my-cliplist.patch: Backport a via fix. (#247254) mkinitrd-6.0.9-9 ---------------- * Thu Jul 12 2007 Bill Nottingham - 6.0.9-9 - fix build against new libdhcp * Thu Jul 12 2007 Jesse Keating - 6.0.9-8 - Rebuild for new libdhcp online-desktop-0.2.5-2.fc8 -------------------------- * Thu Jul 12 2007 Colin Walters - 0.2.5-2 - bump bigboard req openmpi-1.2.3-3.fc8 ------------------- * Thu Jul 12 2007 Florian La Roche - 1.2.3-3 - requires alternatives for various sub-rpms paraview-3.0.2-1.fc8 -------------------- * Wed Jul 11 2007 - Orion Poplawski - 3.0.2-1 - Update to 3.0.2 - Turn mpi build back on - Add devel packages - Remove demo package no longer in upstream - Use cmake macros pciutils-2.2.6-2.fc8 -------------------- * Thu Jul 12 2007 Harald Hoyer - 2.2.6-2 - fixed update-pciids.sh perl-Mail-SPF-2.005-1.fc8 ------------------------- perl-Pugs-Compiler-Rule-0.25-1.fc8 ---------------------------------- * Thu Jul 12 2007 Steven Pritchard 0.25-1 - Update to 0.25. - Drop broken Pugs::Emitter::Rule::Parsec. pikloops-0.2.2-5.fc8 -------------------- * Thu Jul 12 2007 Alain Portal 0.2.2-5 - Fix potential EVR problem * Thu Jul 12 2007 Alain Portal 0.2.2-4 - Test if gtk-update-icon-cache exists before running it * Wed Jul 11 2007 Alain Portal 0.2.2-3 - Add BR gettext policycoreutils-2.0.22-5.fc8 ---------------------------- * Wed Jul 11 2007 Dan Walsh 2.0.22-5 - Require newer libselinux version selinux-policy-3.0.2-7.fc8 -------------------------- * Thu Jul 12 2007 Dan Walsh 3.0.2-7 - Begin adding policy to separate setsebool from semanage - Fix xserver.if definition to not break sepolgen.if vixie-cron-4:4.1-84.fc8 ----------------------- * Wed Jul 11 2007 Marcela Maslanova - 4:4.1-84 - fix init script - Resolves: rhbz#247091 wxGTK-2.8.4-3.fc8 ----------------- * Thu Jul 12 2007 Matthew Miller - 2.8.4-3 - include libwx_gtk2u_media, since I'm now listing the buildreqs properly. * Thu Jul 12 2007 Matthew Miller - 2.8.4-2 - buildrequires for libSM-devel, gstreamer-plugins-base-devel, and GConf2-devel wxPython-2.8.4.0-1.fc8 ---------------------- * Wed Jul 11 2007 Matthew Miller - 2.8.4.0-1 - update to 2.8.4.0 - obsolete compat-wxPythonGTK xorg-x11-drv-calcomp-1.1.0-3.fc8 -------------------------------- * Mon Jun 18 2007 Adam Jackson 1.1.0-3 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-drv-evdev-1.1.2-4.fc8 ------------------------------ * Mon Jun 18 2007 Adam Jackson 1.1.2-4 - Update Requires and BuildRequires. Disown the module directories. xorg-x11-server-1.3.0.0-15.fc8 ------------------------------ * Thu Jul 12 2007 Adam Jackson 1.3.0.0-15 - xserver-1.3.0-edid-quirk-backports.patch: Backport EDID quirks from master; fixes some Samsung monitors. (#232810) * Thu Jul 12 2007 Adam Jackson 1.3.0.0-14 - xserver-1.3.0-composite-version.patch: Force the server to report the Composite extension version it supports, not simply the version defined by the protocol headers it was built against. * Mon Jul 02 2007 Adam Jackson 1.3.0.0-13 - Add IDLETIME sync counter for great powersaving justice. - Conditionalise default font path for F7 spec compatibility. zoneminder-1.22.3-7.fc8 ----------------------- * Thu Jul 12 2007 Martin Ebourne - 1.22.3-7 - Fixes from testing by Jitz including missing dependencies and database creation Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 anaconda - 11.3.0.5-1.i386 requires libdhcp4client-3.0.5.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) anaconda - 11.3.0.5-1.x86_64 requires libdhcp4client-3.0.5.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 anaconda - 11.3.0.5-1.ppc requires libdhcp4client-3.0.5.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) anaconda - 11.3.0.5-1.ppc64 requires libdhcp4client-3.0.5.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From hughsient at gmail.com Fri Jul 13 10:22:56 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Jul 2007 11:22:56 +0100 Subject: rawhide report: 20070713 changes In-Reply-To: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> References: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> Message-ID: <1184322176.2382.13.camel@work> On Fri, 2007-07-13 at 06:07 -0400, Build System wrote: > > mesa-6.5.2-13.fc7 > ----------------- > * Mon Jul 09 2007 Adam Jackson 6.5.2-13 > - mesa-6.5.2-radeon-backports-231787.patch: One more fix for r300. > (#231787) How come no mesa 7.0.0? Also, fwiw, the mesa nouveau 3D driver seems to work well for me. Maybe we can enable that in the the new build? Richard. From spng.yang at gmail.com Fri Jul 13 10:21:26 2007 From: spng.yang at gmail.com (Ken YANG) Date: Fri, 13 Jul 2007 18:21:26 +0800 Subject: KRegExpEditor not in fedora? In-Reply-To: <46973E0E.5000904@asric.com> References: <46973B43.4040403@gmail.com> <46973E0E.5000904@asric.com> Message-ID: <46975226.7090703@gmail.com> Steven Ringwald wrote: > Ken YANG wrote: >> i want to use KRegExpEditor in fedora, but i can not find it >> in fedora repository, is it renamed? >> >> -(:16:42:$)-> sudo yum search KRegExpEditor >> Loading "changelog" plugin >> Loading "installonlyn" plugin >> Excluding Packages in global exclude list >> Finished >> No Matches found >> >> >> i enabled fedora-development and livna-devel repo >> > I think that it is in the kdeutils or kdeutils-extras package.. Which > release of Fedora are you using?? thanks, steven i use gnome, so i dont have most of the kde component, but i will check it. additionally, i find a similar tool, called redet, which is tk-based program > > Steve > From dev at nigelj.com Fri Jul 13 10:57:53 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 13 Jul 2007 22:57:53 +1200 Subject: KRegExpEditor not in fedora? In-Reply-To: <46975226.7090703@gmail.com> References: <46973B43.4040403@gmail.com> <46973E0E.5000904@asric.com> <46975226.7090703@gmail.com> Message-ID: <46975AB1.1060300@nigelj.com> Ken YANG wrote: > Steven Ringwald wrote: >> Ken YANG wrote: >>> i want to use KRegExpEditor in fedora, but i can not find it >>> in fedora repository, is it renamed? >>> >>> -(:16:42:$)-> sudo yum search KRegExpEditor >>> Loading "changelog" plugin >>> Loading "installonlyn" plugin >>> Excluding Packages in global exclude list >>> Finished >>> No Matches found >>> >>> >>> i enabled fedora-development and livna-devel repo >>> >> I think that it is in the kdeutils or kdeutils-extras package.. Which >> release of Fedora are you using?? > > thanks, steven > > i use gnome, so i dont have most of the kde component, but i will check it. > > additionally, i find a similar tool, called redet, which is tk-based > program $ rpm -q --whatprovides /usr/bin/kregexpeditor kdeutils-3.5.7-1.fc6 redet is good if you don't feel like downloading all the KDE dependencies > >> Steve >> > From zboszor at freemail.hu Fri Jul 13 11:11:58 2007 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Fri, 13 Jul 2007 13:11:58 +0200 Subject: rawhide report: 20070713 changes In-Reply-To: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> References: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> Message-ID: <46975DFE.4000100@freemail.hu> Build System ?rta: > mesa-6.5.2-13.fc7 > ----------------- > * Mon Jul 09 2007 Adam Jackson 6.5.2-13 > - mesa-6.5.2-radeon-backports-231787.patch: One more fix for r300. (#231787) > > * Mon Jul 09 2007 Adam Jackson 6.5.2-12 > - Don't install header files for APIs that we don't provide. (#247390) > > * Fri Jul 06 2007 Adam Jackson 6.5.2-11 > - mesa-6.5.2-via-respect-my-cliplist.patch: Backport a via fix. (#247254) > Mesa 7.0 was already released about 3 weeks ago. Shouldn't rawhide incorporate it? Or for that matter, FC6 and FC7, too? Mesa 6.5.x is the beta series leading to 7.0 Best regards, Zolt?n B?sz?rm?nyi From spng.yang at gmail.com Fri Jul 13 12:40:30 2007 From: spng.yang at gmail.com (Ken YANG) Date: Fri, 13 Jul 2007 20:40:30 +0800 Subject: KRegExpEditor not in fedora? In-Reply-To: <46975AB1.1060300@nigelj.com> References: <46973B43.4040403@gmail.com> <46973E0E.5000904@asric.com> <46975226.7090703@gmail.com> <46975AB1.1060300@nigelj.com> Message-ID: <469772BE.40600@gmail.com> Nigel Jones wrote: > Ken YANG wrote: >> Steven Ringwald wrote: >>> Ken YANG wrote: >>>> i want to use KRegExpEditor in fedora, but i can not find it >>>> in fedora repository, is it renamed? >>>> >>>> -(:16:42:$)-> sudo yum search KRegExpEditor >>>> Loading "changelog" plugin >>>> Loading "installonlyn" plugin >>>> Excluding Packages in global exclude list >>>> Finished >>>> No Matches found >>>> >>>> >>>> i enabled fedora-development and livna-devel repo >>>> >>> I think that it is in the kdeutils or kdeutils-extras package.. Which >>> release of Fedora are you using?? >> thanks, steven >> >> i use gnome, so i dont have most of the kde component, but i will check it. >> >> additionally, i find a similar tool, called redet, which is tk-based >> program > $ rpm -q --whatprovides /usr/bin/kregexpeditor > kdeutils-3.5.7-1.fc6 > > redet is good if you don't feel like downloading all the KDE dependencies thanks, Nigel i have yum install kdeutils. i will compare these two tools, and use one >>> Steve >>> > From dtimms at iinet.net.au Fri Jul 13 12:51:08 2007 From: dtimms at iinet.net.au (David Timms) Date: Fri, 13 Jul 2007 22:51:08 +1000 Subject: package reviews from beginners Message-ID: <4697753C.1020605@iinet.net.au> Could I get some feedback on whether people feel it is appropriate for a person wanting to get sponsored for packaging to be providing non-official reviews on any random package ? Can I just "follow da rulez", pointing out the diversions, so that the packaging fits Fedora ? [and state that I have no knowledge of the software being package ?] Or should I at minimum understand what the particular package /software /application is actually trying to do ? Should I only choose potential packages that are written in a language I have good knowledge of ? Can a package submitter submit software written by themselves ? Even if they can't, can't a patch I/someone add to a package do ~anything~ to a users system ? For software that is open but may be only targeted for a narrow audience, or that has not had updates for some years, will a package be automatically rejected ? Hope I didn't miss the answers to these queries in the packaging guidelines; if so please point them out. DaveT. From chitlesh at fedoraproject.org Fri Jul 13 12:56:37 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 13 Jul 2007 14:56:37 +0200 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <4696CCC5.8090009@fedoraproject.org> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> <4696CCC5.8090009@fedoraproject.org> Message-ID: <13dbfe4f0707130556t2135bbc8u842829aa43659dc3@mail.gmail.com> > Chitlesh GOORAH wrote: > > There are also some examples which contains copyrighted materials from > > Cadence. Surely, if ever alliance would enter the fedora collection, > > those examples would be removed. On 7/13/07, Rahul Sundaram wrote: > By "copyrighted" do you mean they are under restrictive copyright > licenses? If so, they should be removed. I received a mail from upstream concerning those examples: Hi Chitlesh, Are you speaking about .ioc files ? Those files are Input/Output placement file specification for all given examples and of course they are NOT copyrighted by Cadence at all. May be it is just a copy/paste mistake of the header of a sample ioc file given in Cadence tutorials (because we use their ASCII file format like many other place & route tools). So you can remove the line "Copyright (c) 1997 by Cadence. All rights reserved." in all ioc files header, since it is not revelant. Those file are manually written, and are not part of any Cadence product. Regards, Ludo https://www-asim.lip6.fr/wws/arc/alliance-users/2007-07/msg00006.html regards, Chitlesh -- http://clunixchit.blogspot.com From j.w.r.degoede at hhs.nl Fri Jul 13 12:58:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Jul 2007 14:58:47 +0200 Subject: package reviews from beginners In-Reply-To: <4697753C.1020605@iinet.net.au> References: <4697753C.1020605@iinet.net.au> Message-ID: <46977707.7050808@hhs.nl> Hi, Welcome to the Fedora Community! David Timms wrote: > Could I get some feedback on whether people feel it is appropriate for a > person wanting to get sponsored for packaging to be providing > non-official reviews on any random package ? > > Can I just "follow da rulez", pointing out the diversions, so that the > packaging fits Fedora ? [and state that I have no knowledge of the > software being package ?] > > Or should I at minimum understand what the particular package /software > /application is actually trying to do ? > As a beginner I would advice you to only try and review programs which you can test yourself. So for example something exotic like my cross compiling packages for the gp2x handheld console would not be a good idea. A simple cmdline / gui utility which you can actually give a quick test run, would be a good idea. > Should I only choose potential packages that are written in a language I > have good knowledge of ? > If you know a programming language, reviewing packages in that language is a good idea, however being able to program is not a skill you must have as a packager. Keep in mind when you don't know the programming language that: -the generic guidelines were written with mostly C/C++ programs in mind -there are special interest groups (SIGs) for other languages with additonal guidelines see: http://fedoraproject.org/wiki/SIGs/#head-cd259dc1b2b40c7d270203b0be0d801986d33ec0 > Can a package submitter submit software written by themselves ? If that software is acceptable according to the legal guidelines (FOSS license, no patents): http://fedoraproject.org/wiki/Packaging/Guidelines#head-8be956fd12dbe4ae927e65c989e7e83b9fcc0b80 > Even if they can't, can't a patch I/someone add to a package do > ~anything~ to a users system ? Yes, thats why: 1) You must first earn some trust 2) All commits to CVS get checked by various people and checks are also done to ensure that the used source are identical to upstream. But in the end trust is the most important factor, that however doesn't go for just the Fedora Project, why on earth do you think a small paper someone printed $100 on is worth a couple of shopping carts filled with food? Because you trust the system / person who printed the small paper. If I were hungry and I could choose I know what I would choose :) > For software that is open but may be only targeted for a narrow > audience, or that has not had updates for some years, will a package be > automatically rejected ? > Nope, if you're interested in it, and can make it work against the latest versions of the libs it needs, then thats fine. Regards, Hans From dtimms at iinet.net.au Fri Jul 13 13:12:42 2007 From: dtimms at iinet.net.au (David Timms) Date: Fri, 13 Jul 2007 23:12:42 +1000 Subject: package reviews from beginners In-Reply-To: <46977707.7050808@hhs.nl> References: <4697753C.1020605@iinet.net.au> <46977707.7050808@hhs.nl> Message-ID: <46977A49.90002@iinet.net.au> Hans de Goede wrote: > Hi, > > Welcome to the Fedora Community! > > David Timms wrote: >> Could I get some feedback on whether people feel it is appropriate for >> a person wanting to get sponsored for packaging to be providing >> non-official reviews on any random package ? >> >> Can I just "follow da rulez", pointing out the diversions, so that the >> packaging fits Fedora ? [and state that I have no knowledge of the >> software being package ?] >> >> Or should I at minimum understand what the particular package >> /software /application is actually trying to do ? >> > > As a beginner I would advice you to only try and review programs which > you can test yourself. So for example something exotic like my cross > compiling packages for the gp2x handheld console would not be a good > idea. A simple cmdline / gui utility which you can actually give a quick > test run, would be a good idea. > >> Should I only choose potential packages that are written in a language >> I have good knowledge of ? >> > > If you know a programming language, reviewing packages in that language > is a good idea, however being able to program is not a skill you must > have as a packager. Keep in mind when you don't know the programming > language that: > -the generic guidelines were written with mostly C/C++ programs in mind > -there are special interest groups (SIGs) for other languages with > additonal > guidelines see: > http://fedoraproject.org/wiki/SIGs/#head-cd259dc1b2b40c7d270203b0be0d801986d33ec0 > > >> Can a package submitter submit software written by themselves ? > If that software is acceptable according to the legal guidelines (FOSS > license, no patents): > http://fedoraproject.org/wiki/Packaging/Guidelines#head-8be956fd12dbe4ae927e65c989e7e83b9fcc0b80 > > >> Even if they can't, can't a patch I/someone add to a package do >> ~anything~ to a users system ? > Yes, thats why: > 1) You must first earn some trust > 2) All commits to CVS get checked by various people and > checks are also done to ensure that the used source are identical to > upstream. > > But in the end trust is the most important factor, that however doesn't > go for just the Fedora Project, why on earth do you think a small paper > someone printed $100 on is worth a couple of shopping carts filled with > food? Because you trust the system / person who printed the small paper. > If I were hungry and I could choose I know what I would choose :) > >> For software that is open but may be only targeted for a narrow >> audience, or that has not had updates for some years, will a package >> be automatically rejected ? >> > > Nope, if you're interested in it, and can make it work against the > latest versions of the libs it needs, then thats fine. OK, thanks Hans. DaveT. From fedora at camperquake.de Fri Jul 13 13:17:19 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 13 Jul 2007 15:17:19 +0200 Subject: rawhide report: 20070713 changes In-Reply-To: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> References: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> Message-ID: <20070713151719.53fcf34e@banea.int.addix.net> Hi. On Fri, 13 Jul 2007 06:07:41 -0400, Build System wrote: > kernel-2.6.23-0.15.rc0.git1.fc8 > ------------------------------- > * Wed Jul 11 2007 Roland McGrath > - core dump enhancement: include first page of ELF files, with sysctl > control Something with that kernel or mkinitrd or module-tools is broken (modprobe and friends look in /lib/modules/2.6.22-0.15.rc0.git1.fc8 for modules) From darrellpf at gmail.com Fri Jul 13 14:27:49 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 13 Jul 2007 07:27:49 -0700 Subject: rawhide report: 20070713 changes In-Reply-To: <20070713151719.53fcf34e@banea.int.addix.net> References: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> <20070713151719.53fcf34e@banea.int.addix.net> Message-ID: On 7/13/07, Ralf Ertzinger wrote: > Hi. > > On Fri, 13 Jul 2007 06:07:41 -0400, Build System wrote: > > > kernel-2.6.23-0.15.rc0.git1.fc8 > > ------------------------------- > > * Wed Jul 11 2007 Roland McGrath > > - core dump enhancement: include first page of ELF files, with sysctl > > control > > Something with that kernel or mkinitrd or module-tools is broken > (modprobe and friends look in /lib/modules/2.6.22-0.15.rc0.git1.fc8 > for modules) > Broken for me too. Also, it looks like yum's installonlyn needs some work too in order to retain the correct kernels. (Unless this is a symptom of the same problem) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248155 darrell From tibbs at math.uh.edu Fri Jul 13 14:46:40 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Jul 2007 09:46:40 -0500 Subject: package reviews from beginners In-Reply-To: <4697753C.1020605@iinet.net.au> References: <4697753C.1020605@iinet.net.au> Message-ID: >>>>> "DT" == David Timms writes: DT> Could I get some feedback on whether people feel it is appropriate DT> for a person wanting to get sponsored for packaging to be DT> providing non-official reviews on any random package ? That's how it's intended to work. Of course, "random" is up to you; you can choose the packages you want to review. DT> Can I just "follow da rulez", pointing out the diversions, so that DT> the packaging fits Fedora ? [and state that I have no knowledge DT> of the software being package ?] Well, that's what I do. It's nice if you can review software you're interested in or understand but obviously it can't always work that way if some of the more obscure packages are ever going to get reviewed. DT> Can a package submitter submit software written by themselves ? Yes. DT> Even if they can't, can't a patch I/someone add to a package do DT> ~anything~ to a users system ? Yes. Which is the reason we require all of this sponsorship process. DT> For software that is open but may be only targeted for a narrow DT> audience, or that has not had updates for some years, will a DT> package be automatically rejected ? No; we have plenty of software like that. Numerical libraries often fall into that category. Of course, the maintainer should consider the security implications of such software first, because they're on the hook for fixing issues. - J< From ajackson at redhat.com Fri Jul 13 15:05:58 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 13 Jul 2007 11:05:58 -0400 Subject: Making evdev X11 input driver default? In-Reply-To: <4697344C.3060203@redhat.com> References: <4694EE09.2050604@redhat.com> <1184172420.2794.28.camel@localhost.localdomain> <4697344C.3060203@redhat.com> Message-ID: <1184339158.2794.65.camel@localhost.localdomain> On Fri, 2007-07-13 at 10:14 +0200, Florian Festi wrote: > Adam Jackson wrote: > > On Wed, 2007-07-11 at 16:49 +0200, Florian Festi wrote: > > >> Are there already any efforts/plans to make the evdev driver default for F8 > >> or any later release? Who would be in charge of such decision? Is there > >> anyone else working on xkbd files for evdev currently? > > > > Not yet. It sort of requires working input hotplug, which isn't quite > > baked upstream. > > > > It'd probably be either my domain or Kristian's. > > Is there already a ETA for these upstream changes? No. - ajax From ajackson at redhat.com Fri Jul 13 15:06:37 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 13 Jul 2007 11:06:37 -0400 Subject: rawhide report: 20070713 changes In-Reply-To: <1184322176.2382.13.camel@work> References: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> <1184322176.2382.13.camel@work> Message-ID: <1184339197.2794.67.camel@localhost.localdomain> On Fri, 2007-07-13 at 11:22 +0100, Richard Hughes wrote: > On Fri, 2007-07-13 at 06:07 -0400, Build System wrote: > > > > mesa-6.5.2-13.fc7 > > ----------------- > > * Mon Jul 09 2007 Adam Jackson 6.5.2-13 > > - mesa-6.5.2-radeon-backports-231787.patch: One more fix for r300. > > (#231787) > > How come no mesa 7.0.0? Also, fwiw, the mesa nouveau 3D driver seems to > work well for me. Maybe we can enable that in the the new build? Because it requires rebasing the X server at the same time, which I haven't had time for yet. - ajax From ajackson at redhat.com Fri Jul 13 15:23:21 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 13 Jul 2007 11:23:21 -0400 Subject: rawhide report: 20070713 changes In-Reply-To: <46975DFE.4000100@freemail.hu> References: <200707131007.l6DA7fKu031981@porkchop.devel.redhat.com> <46975DFE.4000100@freemail.hu> Message-ID: <1184340201.2794.69.camel@localhost.localdomain> On Fri, 2007-07-13 at 13:11 +0200, Zoltan Boszormenyi wrote: > Build System ?rta: > > mesa-6.5.2-13.fc7 > > ----------------- > > * Mon Jul 09 2007 Adam Jackson 6.5.2-13 > > - mesa-6.5.2-radeon-backports-231787.patch: One more fix for r300. (#231787) > > > > * Mon Jul 09 2007 Adam Jackson 6.5.2-12 > > - Don't install header files for APIs that we don't provide. (#247390) > > > > * Fri Jul 06 2007 Adam Jackson 6.5.2-11 > > - mesa-6.5.2-via-respect-my-cliplist.patch: Backport a via fix. (#247254) > > > > Mesa 7.0 was already released about 3 weeks ago. > Shouldn't rawhide incorporate it? Or for that matter, > FC6 and FC7, too? Mesa 6.5.x is the beta series leading to 7.0 It requires fixing the X server's build system too. Something I haven't done yet. - ajax From msaksena at marvell.com Fri Jul 13 16:40:34 2007 From: msaksena at marvell.com (Manas Saksena) Date: Fri, 13 Jul 2007 09:40:34 -0700 Subject: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures In-Reply-To: <604aa7910707121950h63ddcc28i7e7a735bd679ded3@mail.gmail.com> References: <1184080763.3490.66.camel@localhost.localdomain> <46946784.8070902@marvell.com> <46949141.8090804@linux-kernel.at> <46955EDA.8050602@marvell.com> <1184196830.3404.53.camel@localhost.localdomain> <4695721E.1010107@marvell.com> <1184207090.11325.4.camel@vader.jdub.homelinux.org> <4695AA29.2090708@marvell.com> <604aa7910707121131i30cb755ai5cb18e4abddac934@mail.gmail.com> <4696875E.7050006@marvell.com> <604aa7910707121950h63ddcc28i7e7a735bd679ded3@mail.gmail.com> Message-ID: <4697AB02.80802@marvell.com> Jeff Spaleta wrote: > On 7/12/07, Manas Saksena wrote: >> Every one derives from Linus' kernel tree and creates their own custom >> Linux kernel. But, they are all still Linux kernels. And, they dont >> dilute the "Linux" brand. > > Its more complicated than brand value. My interpretation, from sitting > outside the red hat fenceline, is that there's also potential > liability associated with 'blessing' a codebase that is not under the > direct control of the fedora build system. I'd absolutely LOVE to > find a solution in derived-distribution space that let the builders of > these distros share credit with the Fedora community. It sure be super > nice to be able to have people gloat and preen over their consumption > of the work we are doing. There's no doubt in my mind, that its a PR > win all around if we can find a way to present Fedora as an ecosystem > of distributions, even the derived ones and march forward into the > future arm-in-ARM singing obnoxiously. But since linus, as the > trademark holder to linux, isn't the name of a corporation > incorporated in a hyper-litigious country with enough assests to be > worth protecting... the parallel between the trademark situations is > not really the same. I think we are in agreement here. Regards, Manas From alan at redhat.com Fri Jul 13 18:08:28 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Jul 2007 14:08:28 -0400 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> Message-ID: <20070713180828.GR20762@devserv.devel.redhat.com> On Fri, Jul 13, 2007 at 12:55:18AM +0000, Kevin Kofler wrote: > Chitlesh GOORAH fedoraproject.org> writes: > > This particular line confuses me: > > "You are kindly requested to mention : "Designed with Alliance (c) > > LIP6, Universit? Pierre et Marie Curie" > > As I read it, "kindly requested" is not a requirement, so it can be ignored. > But be warned that I am not a lawyer. Put it in the RPM info so that its nice and visible ? From chitlesh at fedoraproject.org Fri Jul 13 18:22:25 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 13 Jul 2007 20:22:25 +0200 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <20070713180828.GR20762@devserv.devel.redhat.com> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> <20070713180828.GR20762@devserv.devel.redhat.com> Message-ID: <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> On 7/13/07, Alan Cox wrote: > Put it in the RPM info so that its nice and visible ? I was thinking to add it in a separate "alliance.fedora" file. Chitlesh -- http://clunixchit.blogspot.com From sean.bruno at dsl-only.net Sat Jul 14 00:22:25 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri, 13 Jul 2007 17:22:25 -0700 Subject: Installable rawhide? Message-ID: <1184372545.3161.80.camel@home-desk> Am I looking at the right directory for an installable rawhide? I don't see an images directory and just wanted to double check. ftp://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os Sean From jkeating at redhat.com Sat Jul 14 01:03:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jul 2007 21:03:02 -0400 Subject: Installable rawhide? In-Reply-To: <1184372545.3161.80.camel@home-desk> References: <1184372545.3161.80.camel@home-desk> Message-ID: <20070713210302.0a9cc59e@ender> On Fri, 13 Jul 2007 17:22:25 -0700 Sean Bruno wrote: > Am I looking at the right directory for an installable rawhide? I > don't see an images directory and just wanted to double check Over the last couple days we've had issues getting the "make it installable" part of rawhide composes to complete. It may take us a few more days but we'll get it going again (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sat Jul 14 01:34:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 13 Jul 2007 20:34:21 -0500 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> <20070713180828.GR20762@devserv.devel.redhat.com> <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> Message-ID: <1184376861.3337.11.camel@localhost.localdomain> On Fri, 2007-07-13 at 20:22 +0200, Chitlesh GOORAH wrote: > On 7/13/07, Alan Cox wrote: > > Put it in the RPM info so that its nice and visible ? > > I was thinking to add it in a separate "alliance.fedora" file. Whatever you'd like. Its not a legal requirement, just a friendly request. ~spot From sean.bruno at dsl-only.net Sat Jul 14 02:29:02 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri, 13 Jul 2007 19:29:02 -0700 Subject: Installable rawhide? In-Reply-To: <20070713210302.0a9cc59e@ender> References: <1184372545.3161.80.camel@home-desk> <20070713210302.0a9cc59e@ender> Message-ID: <1184380142.3161.82.camel@home-desk> > Over the last couple days we've had issues getting the "make it > installable" part of rawhide composes to complete. It may take us a > few more days but we'll get it going again (: No worries. I'll be here when it's ready. Sean From mattdm at mattdm.org Sat Jul 14 02:54:35 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 13 Jul 2007 22:54:35 -0400 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <1184376861.3337.11.camel@localhost.localdomain> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> <20070713180828.GR20762@devserv.devel.redhat.com> <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> <1184376861.3337.11.camel@localhost.localdomain> Message-ID: <20070714025435.GA16396@jadzia.bu.edu> On Fri, Jul 13, 2007 at 08:34:21PM -0500, Tom spot Callaway wrote: > > > Put it in the RPM info so that its nice and visible ? > > I was thinking to add it in a separate "alliance.fedora" file. > Whatever you'd like. Its not a legal requirement, just a friendly > request. Since it *is* so nice and friendly, I'd be inclined to put it in the RPM description. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Sat Jul 14 05:08:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 14 Jul 2007 00:08:10 -0500 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <20070714025435.GA16396@jadzia.bu.edu> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> <20070713180828.GR20762@devserv.devel.redhat.com> <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> <1184376861.3337.11.camel@localhost.localdomain> <20070714025435.GA16396@jadzia.bu.edu> Message-ID: <1184389690.3337.13.camel@localhost.localdomain> On Fri, 2007-07-13 at 22:54 -0400, Matthew Miller wrote: > On Fri, Jul 13, 2007 at 08:34:21PM -0500, Tom spot Callaway wrote: > > > > Put it in the RPM info so that its nice and visible ? > > > I was thinking to add it in a separate "alliance.fedora" file. > > Whatever you'd like. Its not a legal requirement, just a friendly > > request. > > Since it *is* so nice and friendly, I'd be inclined to put it in the RPM > description. So would I. I was merely pointing out that he didn't have to go out of his way to make it super-obvious. :) ~spot From buildsys at fedoraproject.org Sat Jul 14 09:11:33 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 14 Jul 2007 05:11:33 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-14 Message-ID: <20070714091133.ECF8E152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 33 cksfv-1.3.11-1.fc6 cmigemo-1.3-0.6.c_MIT.fc6 NEW coco-coq-0.1-3.fc6 : Coco Coq in Grostesteing's base, an AGI adventure game deltarpm-3.4-3.fc6 emacs-common-muse-3.03-3.fc6 flac123-0.0.11-1.fc6 NEW gdesklets-calendar-0.41-3.fc6 : A navigable calendar showing the entire month for gdesklet NEW gdesklets-goodweather-0.3-2.fc6 : Themeable weather and condition display for gdesklet kbackup-0.5.1-7.fc6 kdeartwork-extras-3.5.7-2.fc6 kmenu-gnome-0.6.6-2.fc6 libpri-1.4.1-1.fc6 NEW mysql-proxy-0.5.1-1.fc6 : A proxy for the MySQL Client/Server protocol nsd-2.3.7-2.fc6 ntfsprogs-1.13.1-6.fc6 openvrml-0.16.6-1.fc6 NEW perl-Gearman-1.09-1.fc6 : Distributed job system NEW perl-MogileFS-Client-1.07-2.fc6 : Client library for the MogileFS distributed file system NEW perl-Net-DNS-SEC-0.14-2.fc6 : DNSSEC modules for Perl php-pear-SOAP-0.11.0-1.fc6 phpPgAdmin-4.1.3-2.fc6 pikloops-0.2.2-5.fc6 polyester-1.0.1-1.fc6 qgis-0.8.1-11.fc6 NEW qtpfsgui-1.8.9-5.fc6 : A graphical tool for creating and tone-mapping HDR images NEW R-mvtnorm-0.7-2.fc6 : Multivariate normal and T distribution R Package NEW redland-1.0.5-1.fc6 : Redland RDF Application Framework rrdtool-1.2.23-6.fc6 NEW sofsip-cli-0.13-1.fc6 : SIP VoIP/IM example client tgif-4.1.45-4.fc6 xmoto-0.3.1-1.fc6 NEW xoo-0.7-2.fc6 : Xoo is a graphical wrapper around xnest zoneminder-1.22.3-7.fc6 Changes in Fedora Extras 6: cksfv-1.3.11-1.fc6 ------------------ * Fri Jul 13 2007 Christopher Stone 1.3.11-1 - Upstream sync cmigemo-1.3-0.6.c_MIT.fc6 ------------------------- * Wed Jul 11 2007 Mamoru Tasaka - 1.3-0.6.c_MIT - Re-enable Migemo autocompletion coco-coq-0.1-3.fc6 ------------------ * Fri Jul 06 2007 Jon Ciesla 0.1-3 - Fixed source zip. * Fri Jul 06 2007 Jon Ciesla 0.1-2 - Fixed spec typo in URL * Fri Jul 06 2007 Jon Ciesla 0.1-1 - Initial packaging. deltarpm-3.4-3.fc6 ------------------ * Tue Jun 05 2007 Jeremy Katz - 3.4-3 - include colored binaries from non-multilib-dirs so that deltas can work on multilib platforms emacs-common-muse-3.03-3.fc6 ---------------------------- * Thu Jul 12 2007 Jonathan G. Underwood - 3.03-3 - Added patch with various fixes from upstream maintainer to fix issues raised in BZ 247369 flac123-0.0.11-1.fc6 -------------------- * Thu Jul 12 2007 Sindre Pedersen Bj?rdal - 0.0.11-1 - Bump to 0.0.11, this fixes #246322 and adds flac 1.1.4 support - Remove flac 1.1.3 patch, it's not needed anymore * Mon Feb 26 2007 Sindre Pedersen Bj?rdal - 0.0.9-6 - Add fixed patch to really make build work against flac 1.1.3 * Mon Feb 26 2007 Sindre Pedersen Bj?rdal - 0.0.9-3 - Add patch to make build work against flac 1.1.3 * Thu Feb 15 2007 Sindre Pedersen Bj?rdal - 0.0.9-2 - Rebuild against new libflac gdesklets-calendar-0.41-3.fc6 ----------------------------- * Sun Jul 08 2007 Mamoru Tasaka - 0.41-3 - Clean up spec file * Sun Jul 08 2007 Tyler Owen - 0.41-2 - Added -p option to install to preserve timestamps - Fixed missing directory ownership issues * Sun Jun 24 2007 Tyler Owen - 0.41-1 - Initial Packaging for Fedora gdesklets-goodweather-0.3-2.fc6 ------------------------------- * Sat Jul 07 2007 Tyler Owen - 0.3-2 - Added Python to Requires - Added -p option to install to preserve timestamps - Fixed missing directory ownership issues * Sun Jun 24 2007 Tyler Owen - 0.3-1 - Initial Packaging for Fedora kbackup-0.5.1-7.fc6 ------------------- * Thu Jul 12 2007 Alain Portal 0.5.1-7 - Disable parallel building until this is fixed by upstream * Thu Jul 12 2007 Alain Portal 0.5.1-6 - Try a build without parallel make support * Thu Jul 12 2007 Alain Portal 0.5.1-5 - Fix date in changelog * Thu Jul 12 2007 Alain Portal 0.5.1-4 - Test if gtk-update-icon-cache exists before running it * Wed Jul 11 2007 Alain Portal 0.5.1-3 - Add BR gettext * Mon Oct 02 2006 Alain Portal 0.5.1-2 - Really add patch1 * Mon Oct 02 2006 Alain Portal 0.5.1-1 - New upstream tarball - Update patch1 - Add new patch for french doc - Add Application category in desktop file - Fix symlink: english is the only language where common directory is in LANG directory while for other, common is in LANG/docs directory kdeartwork-extras-3.5.7-2.fc6 ----------------------------- * Fri Jul 13 2007 Rex Dieter 3.5.7-2 - webcollagerc: [directory] /usr/share/backgrounds/images/ (#227683) * Mon Jun 11 2007 Rex Dieter 3.5.7-1 - 3.5.7 kmenu-gnome-0.6.6-2.fc6 ----------------------- * Wed Jul 11 2007 Chitlesh Goorah - 0.6.6-2 - new upstream release * Mon Jul 09 2007 Ariszlo - 0.6.6-1 - release 0.6.6 - Added printer.png -> gnome-dev-printer.png symlinks libpri-1.4.1-1.fc6 ------------------ * Mon Jul 09 2007 Jeffrey C. Ollie - 1.4.1-1 - Update to 1.4.1 mysql-proxy-0.5.1-1.fc6 ----------------------- * Tue Jul 10 2007 Ruben Kerkhof 0.5.1-1 - Upstream released new version - Included examples * Sun Jul 01 2007 Ruben Kerkhof 0.5.0-1 - First version nsd-2.3.7-2.fc6 --------------- * Fri Jul 13 2007 Paul Wouters 2.3.7-2 - Fix init script, bug #245546 ntfsprogs-1.13.1-6.fc6 ---------------------- * Wed Jul 11 2007 Tom "spot" Callaway 1.13.1-6 - build and install "extra" binaries by default (I was accidentally installing the scripts, not the binaries) This better resolves bz 247398 (thanks to Martin Riarte) openvrml-0.16.6-1.fc6 --------------------- * Thu Jun 07 2007 Braden McDaniel - 0.16.6-1 - Updated to 0.16.6. perl-Gearman-1.09-1.fc6 ----------------------- * Sat Jun 30 2007 Ruben Kerkhof 1.09-1 - Upstream released new version - New version now includes license information - Filter out just one of the two Provides for Gearman::Client * Thu Jun 28 2007 Ruben Kerkhof 1.08-2 - Filter out double Provides for Gearman::Client - Change Source0 url perl-MogileFS-Client-1.07-2.fc6 ------------------------------- * Wed Jun 20 2007 Ruben Kerkhof 1.07-2 - Incorporate suggestions from tibbs in review #240699: - Remove test which does nothing without a mogilefs server - Change URL to cpan site perl-Net-DNS-SEC-0.14-2.fc6 --------------------------- * Wed Jul 11 2007 Wes Hardaker - 0.14-2 - BuildRequire Digest::SHA - include the demo scripts in the documentation php-pear-SOAP-0.11.0-1.fc6 -------------------------- * Mon Jul 02 2007 Remi Collet 0.11.0-1 - update to 0.11.0 phpPgAdmin-4.1.3-2.fc6 ---------------------- * Wed Jul 11 2007 Devrim Gunduz 4.1.3-2 - Added temporary patch #2 , per sf.net bug #1751614 * Tue Jul 10 2007 Devrim Gunduz 4.1.3-1 - Update to 4.1.3 pikloops-0.2.2-5.fc6 -------------------- * Thu Jul 12 2007 Alain Portal 0.2.2-5 - Add BR automake * Thu Jul 12 2007 Alain Portal 0.2.2-4 - Test if gtk-update-icon-cache exists before running it * Wed Jul 11 2007 Alain Portal 0.2.2-3 - Add BR gettext * Sat Jul 07 2007 Alain Portal 0.2.2-2 - New upstream: new url and source url * Wed Apr 25 2007 Alain Portal 0.2.2-1 - New upstream version - SOURCE1 no more needed polyester-1.0.1-1.fc6 --------------------- * Wed Jun 06 2007 Sebastian Vahl - 1.0.1-1 - new upstream version: 1.0.1 - added README qgis-0.8.1-11.fc6 ----------------- * Tue Jul 10 2007 Douglas E. Warner 0.8.1-11 - allowing docs to be installed by qgis so they can be referenced by internal help system (bug#241403) - updated lib64 patch (bug#247549) to try to get plugins found on x86_64 qtpfsgui-1.8.9-5.fc6 -------------------- * Tue Jul 10 2007 Douglas E. Warner 1.8.9-5 - preserving timestamps on install - removed INSTALL file from docs - updating GTK icon cache * Wed Jul 04 2007 Douglas E. Warner 1.8.9-4 - cleaning up summary and description - fixing newlines in prep instead of install - updating desktop-file-install to call --delete-original to remove that manual step * Mon Jul 02 2007 Douglas E. Warner 1.8.9-3 - removing explicit Requires * Fri Jun 29 2007 Douglas E. Warner 1.8.9-2 - documenting hacks - installing desktop file R-mvtnorm-0.7-2.fc6 ------------------- * Wed Jul 11 2007 Orion Poplawski - 0.7-2 - Comply with R packaging guidelines redland-1.0.5-1.fc6 ------------------- * Thu Jun 28 2007 Kevin Kofler 1.0.5-1 - update to 1.0.5 (1.0.6 needs newer raptor and rasqal than available) - update minimum raptor version rrdtool-1.2.23-6.fc6 -------------------- * Tue Jul 10 2007 Jarod Wilson 1.2.23-6 - Add php abi check (#247339) sofsip-cli-0.13-1.fc6 --------------------- * Sat Jun 09 2007 Jeffrey C. Ollie - 0.13-1 - Update to 0.13 tgif-4.1.45-4.fc6 ----------------- * Wed Jul 11 2007 MATSUURA Takanori - 4.1.45-4 - based on tgif-4.1.44-0vl6.src.rpm from VineSeed main - use scalable bitmap font * Mon Jul 09 2007 TASAKA Mamoru - 4.1.45-3 - Clean up BuildRequires xmoto-0.3.1-1.fc6 ----------------- * Mon Jul 09 2007 Jon Ciesla 0.3.1-1 - Bumped to upstream, BZ 247445. * Wed Jun 20 2007 Jon Ciesla 0.3.0-1 - Bumped to upstream. xoo-0.7-2.fc6 ------------- * Thu Jul 05 2007 Paul Wouters 0.7-2 - Dependancy fixes, removed post/postun sections. zoneminder-1.22.3-7.fc6 ----------------------- * Thu Jul 12 2007 Martin Ebourne - 1.22.3-7 - Fixes from testing by Jitz including missing dependencies and database creation For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at redhat.com Sat Jul 14 09:52:32 2007 From: buildsys at redhat.com (Build System) Date: Sat, 14 Jul 2007 05:52:32 -0400 Subject: rawhide report: 20070714 changes Message-ID: <200707140952.l6E9qWnX016427@porkchop.devel.redhat.com> New package cinepaint CinePaint is a tool for manipulating images New package memcached High Performance, Distributed Memory Object Cache Updated Packages: a2ps-4.13b-66.fc8 ----------------- * Fri Jul 13 2007 Tim Waugh 4.13b-66 - Change build requirement from /usr/bin/emacs to emacs to fix build. - Hebrew fix (bug #247999). anaconda-11.3.0.6-1 ------------------- * Thu Jul 12 2007 Chris Lumens 11.3.0.6-1 - Don't call lvm.pvlist so much (pjones). - Don't log harmless unmounting errors (dlehman, #223059). - Handle F12 on the install key dialog (dlehman, #210673). - Create device nodes and probe for tape drives (dlehman, #218816). - Fix loader network configuration UI flow (lucasgf AT br DOT ibm DOT com, - Include yum-fedorakmod plugin (dlehman). - Don't map Fedora to Fedora Core in the betanag dialog (katzj). - String fixes (katzj, #246703). - Fix module path order so updates get used (pjones). - Install the PAE kernel when applicable (pjones, #207573). - Fix fsset entry sorting (jhutz AT cmu DOT edu, #242294). - Don't display garbage in the ksfile location dialog (#245936). bigboard-0.5.3-1.fc8 -------------------- * Fri Jul 13 2007 Colin Walters - 0.5.3-1 - new upstream cksfv-1.3.11-1.fc8 ------------------ * Fri Jul 13 2007 Christopher Stone 1.3.11-1 - Upstream sync cpanspec-1.72-1.fc8 ------------------- * Fri Jul 13 2007 Steven Pritchard 1.72-1 - Update to 1.72. cups-1:1.2.12-1.fc8 ------------------- * Fri Jul 13 2007 Tim Waugh 1:1.2.12-1 - 1.2.12. No longer need adminutil or str2408 patches. * Mon Jul 09 2007 Tim Waugh - Another small improvement for the textonly filter (bug #244979). eclipse-1:3.3.0-1.fc8 --------------------- * Fri Jun 29 2007 Ben Konrath 3.3.0-1 - 3.3. * Wed Jun 27 2007 Ben Konrath 3.3.0-0.3.RC4 - Restore ppc64, s390{,x} and sparc{,64} support. - Restore multilib support. * Tue Jun 19 2007 Ben Konrath 3.3.0-0.2.RC4 - Use icu4j-eclipse sub-package instead of building icu4j here. - Use exec in binary wrapper. - Add 3.3.0 splashscreen. gimp-2:2.2.17-1.fc8 ------------------- * Fri Jul 13 2007 Nils Philippsen - 2:2.2.17-1 - version 2.2.17 Bugs fixed in GIMP 2.2.17 ========================= - fixed regression in PSD load plug-in (bug #456042) - fixed crash when loading a corrupt PSD file (bug #327444) - work around for Pango appending " Not-Rotated" to font names hippo-canvas-0.2.24-1.fc8 ------------------------- * Fri Jul 13 2007 Owen Taylor - 0.2.24-1 - Update to 0.2.24 kdeartwork-3.5.7-2.fc8 ---------------------- * Fri Jul 13 2007 Rex Dieter 3.5.7-2 - webcollagerc: [directory] /usr/share/backgrounds/images/ (#227683) * Mon Jun 11 2007 Rex Dieter 3.5.7-1 - 3.5.7 * Thu May 17 2007 Rex Dieter 3.5.6-5 - don't include %_bindir/kxs* in main pkg - --enable-final kdebase-6:3.5.7-6.fc8 --------------------- * Mon Jul 02 2007 Than Ngo - 6:3.5.7-6 - fix bz#244906 kdesdk-3.5.7-6.fc8 ------------------ * Thu Jun 28 2007 Than Ngo - 3.5.7-6 - get rid of flex workaround, it's now fixed in new flex * Fri Jun 22 2007 Rex Dieter - 3.5.7-5 - clean up /usr/share/doc/HTML/en/cervisia/common hackery (#246072) lucene-0:1.4.3-1jpp.19 ---------------------- * Fri Jul 13 2007 Ben Konrath - 0:1.4.3-1jpp.19 - Add osgi manifest. nut-2.2.0-1.1.fc8 ----------------- * Fri Jul 13 2007 Tomas Smetana 2.2.0-1.1 - rebuild * Fri Jul 13 2007 Tomas Smetana 2.2.0-1 - new upstream version (Resolves: #248074) - initscripts update - spec file cleanup * Mon May 07 2007 Arnaud Quette 2.1.0-1 - update to 2.1.0 development tree - HAL, ... openarena-0.7.0-3.fc8 --------------------- * Fri Jul 13 2007 Micha?? Bentkowski - 0.7.0-3 - NO_VM_COMPILED flag on ppc64 * Fri Jul 13 2007 Micha?? Bentkowski - 0.7.0-2 - Add libvorbis-devel BR * Wed Jul 11 2007 Micha?? Bentkowski - 0.7.0-1 - Update to 0.7.0 openvrml-0.16.6-1.fc8 --------------------- * Thu Jun 07 2007 Braden McDaniel - 0.16.6-1 - Updated to 0.16.6. perl-BerkeleyDB-0.32-1.fc8 -------------------------- * Fri Jul 13 2007 Steven Pritchard 0.32-1 - Update to 0.32. perl-YAML-Syck-0.94-1.fc8 ------------------------- * Fri Jul 13 2007 Steven Pritchard 0.94-1 - Update to 0.94. perl-YAML-Tiny-1.13-1.fc8 ------------------------- * Fri Jul 13 2007 Steven Pritchard 1.13-1 - Update to 1.13. Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.i386 requires 3.6.1 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.x86_64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.ppc requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.ppc64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From j.w.r.degoede at hhs.nl Sat Jul 14 10:21:17 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 Jul 2007 12:21:17 +0200 Subject: Is this content license acceptable? Message-ID: <4698A39D.6060200@hhs.nl> Hi All, I've been looking at packaging C-dogs SDL, The SDL port an old dos game. This port uses the data files of the original game, which are licenses under then following conditions: The basic terms for redistribution are as follows: a) All files must be distributed unmodified b) There must be no charge for the game as such. Condition a) is not a problem for content, and AFAIK b) isn't a problem either, because it is allowed to sell discs with the game on it and charge for the disc, etc. Still I'm asking to be sure about condition b) Regards, Hans From valent.turkovic at gmail.com Sat Jul 14 12:17:39 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 14 Jul 2007 14:17:39 +0200 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) Message-ID: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> Hi, I'm reporting rawhide update problem. I couldn't update my rawhide system today and I isolated the problematic package and it is anaconda. When I removed 'yum remove anaconda' my system updated. I can't install anaconda after the update because it has unresolved dependencies (libdhcp4client-3.0.5.so.0). Hope this helps. Here are the logs: # yum update Loading "installonlyn" plugin Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package libdhcp.i386 0:1.25-3.fc8 set to be updated ---> Package dhclient.i386 12:3.0.6-1.fc8 set to be updated ---> Package libdhcp4client.i386 12:3.0.6-1.fc8 set to be updated --> Processing Dependency: libdhcp4client-3.0.5.so.0 for package: anaconda --> Finished Dependency Resolution Error: Missing Dependency: libdhcp4client-3.0.5.so.0 is needed by package anaconda # yum remove anaconda Loading "installonlyn" plugin Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package anaconda.i386 0:11.3.0.5-1 set to be erased --> Processing Dependency: anaconda = 11.3.0.5-1 for package: anaconda-runtime --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package anaconda.i386 0:11.3.0.5-1 set to be erased ---> Package anaconda-runtime.i386 0:11.3.0.5-1 set to be erased Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: anaconda i386 11.3.0.5-1 installed 14 M Removing for dependencies: anaconda-runtime i386 11.3.0.5-1 installed 3.3 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 2 Package(s) ]# yum update Loading "installonlyn" plugin Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package libdhcp.i386 0:1.25-3.fc8 set to be updated ---> Package dhclient.i386 12:3.0.6-1.fc8 set to be updated ---> Package libdhcp4client.i386 12:3.0.6-1.fc8 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: dhclient i386 12:3.0.6-1.fc8 development 274 k libdhcp i386 1.25-3.fc8 development 58 k libdhcp4client i386 12:3.0.6-1.fc8 development 246 k Transaction Summary ============================================================================= Install 0 Package(s) Update 3 Package(s) Remove 0 Package(s) ]# yum install anaconda Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package anaconda.i386 0:11.3.0.5-1 set to be updated --> Processing Dependency: libdhcp4client-3.0.5.so.0 for package: anaconda --> Finished Dependency Resolution Error: Missing Dependency: libdhcp4client-3.0.5.so.0 is needed by package anaconda -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From david at lovesunix.net Sat Jul 14 13:21:52 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 14 Jul 2007 15:21:52 +0200 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) In-Reply-To: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> Message-ID: <1184419313.2822.15.camel@dawkins> l?r, 14 07 2007 kl. 14:17 +0200, skrev Valent Turkovic: > Hi, I'm reporting rawhide update problem. I couldn't update my rawhide > system today and I isolated the problematic package and it is > anaconda. > > When I removed 'yum remove anaconda' my system updated. > > I can't install anaconda after the update because it has unresolved > dependencies (libdhcp4client-3.0.5.so.0). You will notice that the daily Rawhide report contains a list of the packages that will not install due to dependency problems. Please check with those lists before posting dependency problems in all likelihood it's a known problem. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From valent.turkovic at gmail.com Sat Jul 14 14:00:47 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 14 Jul 2007 16:00:47 +0200 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) In-Reply-To: <1184419313.2822.15.camel@dawkins> References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> <1184419313.2822.15.camel@dawkins> Message-ID: <64b14b300707140700w5cf05e25l78232c6992e87a08@mail.gmail.com> On 7/14/07, David Nielsen wrote: > l?r, 14 07 2007 kl. 14:17 +0200, skrev Valent Turkovic: > > Hi, I'm reporting rawhide update problem. I couldn't update my rawhide > > system today and I isolated the problematic package and it is > > anaconda. > > > > When I removed 'yum remove anaconda' my system updated. > > > > I can't install anaconda after the update because it has unresolved > > dependencies (libdhcp4client-3.0.5.so.0). > > You will notice that the daily Rawhide report contains a list of the > packages that will not install due to dependency problems. > > Please check with those lists before posting dependency problems in all > likelihood it's a known problem. > > - David > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Well I'm just a user so you can't expect to know where to look if I'm not involved with rawhide and fedora more than I can in my spare time... I searched mailing lists for rawhide and anaconda, but it looks I missed it, sorry. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From zaitcev at redhat.com Sat Jul 14 15:48:53 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 14 Jul 2007 08:48:53 -0700 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) In-Reply-To: <1184419313.2822.15.camel@dawkins> References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> <1184419313.2822.15.camel@dawkins> Message-ID: <20070714084853.82330b8e.zaitcev@redhat.com> On Sat, 14 Jul 2007 15:21:52 +0200, David Nielsen wrote: > > I can't install anaconda after the update because it has unresolved > > dependencies (libdhcp4client-3.0.5.so.0). > > You will notice that the daily Rawhide report contains a list of the > packages that will not install due to dependency problems. No, it's not there. I ran across it when updating nash. I blame mirror inconsistencies. -- Pete From valent.turkovic at gmail.com Sat Jul 14 15:54:38 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 14 Jul 2007 17:54:38 +0200 Subject: rawhide doesn't have suspend - is this a bug or a feature for fedora 8? Message-ID: <64b14b300707140854x153a74exec1f7557cda7669c@mail.gmail.com> I see that rawhide doesn't have suspend or hibernate as an option. I have a issue with suspend in Fedora 7 (and also FC6) and that is that it is the only opion that doesn't popup any dialog box and it doesn't ask for confirmation - and it is the most "dangerous" option because it is usually one with most failures. F7 has especially this problem because suspend/resume is broken[1]&[2] currently and usually hitting suspend leaves users with a frozen system. Will there be a suspend in F8? Will there be a some dialog box asking for a confirmation or at least giving users some explanation that there is some risk involved with suspend under fedora? [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240964 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241310 Thank you. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic -------------- next part -------------- A non-text attachment was scrubbed... Name: shut_down-no_suspend.png Type: image/png Size: 19720 bytes Desc: not available URL: From lsof at nodata.co.uk Sat Jul 14 17:16:01 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 14 Jul 2007 19:16:01 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <1184272826.10340.17.camel@perun.kabelta.loc> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> <1184272826.10340.17.camel@perun.kabelta.loc> Message-ID: <1184433361.3990.0.camel@sb-home> Am Donnerstag, den 12.07.2007, 22:40 +0200 schrieb Tomas Mraz: > I'm still a little bit uneasy to allow this patch in. We were trying to > keep as close to upstream as possible. On the other hand we have other > changes we have other patches in like the SELinux changes for MLS and > the recent support for keys in NSS by which we significantly diverge > from upstream already. So maybe we could reconsider applying the HPN > patch or at least some less controversial parts of it. This paragraph disagrees with your signature. > > But also note that ssh was designed to be primarily a protocol for > interactive shell sessions and thus it has its limitations which mean > that it never can be 100% efficient as protocol for large file transfers > or even establishing VPNs. It seems to me that people which want > extremely fast and secure file transfers should use different solutions > like stunnel. > -- > Tomas Mraz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb From wolfy at nobugconsulting.ro Sat Jul 14 19:15:05 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 14 Jul 2007 22:15:05 +0300 Subject: Some merge review statistics In-Reply-To: References: Message-ID: <469920B9.1000901@nobugconsulting.ro> On 07/13/2007 03:02 AM, Jason L Tibbitts III wrote: > > Merge Review: arptables_jf > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225255 > RH CC: fenalson at redhat.com > Status: NEEDINFO requested of mbarabas at redhat.com > Since: 2007-06-14 14:15 EST > (I'm not sure why mbarabas gets the NEEDINFO here, as he doesn't seem > to be involved in the ticket in any way.) > Because of this: [wolfy at wolfy ~]$ grep arptables owners/owners.list Fedora|arptables_jf|Userspace control program for the arptables network filter.|mbarabas at redhat.com|extras-qa at fedoraproject.org| From dmc.fedora at filteredperception.org Sat Jul 14 21:57:08 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 14 Jul 2007 16:57:08 -0500 Subject: [SCRIPT] rebootless liveinst - the MudPuddle release Message-ID: <469946B4.1050404@filteredperception.org> Greetings fellow Fedora developers! I would like to offer you a first glimpse at a project that I have been making an _aweful_ lot of noise about over on the fedora-livecd-list. In the name of release-early-release-often, here is a proof of concept quality release of what I call a "rebootless livemedia installer". To cut to the chase, it is meant to live alongside /usr/sbin/liveinst as /usr/sbin/rliveinst. It has the same functionality with the interesting addition that it doesn't require a reboot after installation completes. Attached is the abundantly commented bash script rliveinst. A full ALPHA QUALITY livecd that includes and fully supports rliveinst is available at http://g-zyx.org (uploading now, will take a while) enjoy... -dmc/jdog P.S. now I will likely commence work on an anaconda backend that truly provides the same functionality as /usr/sbin/liveinst... rebootlessly :) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rliveinst URL: From lists-gawain at felicity-group.com Sun Jul 15 06:46:41 2007 From: lists-gawain at felicity-group.com (Gawain Lynch) Date: Sun, 15 Jul 2007 16:46:41 +1000 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) In-Reply-To: <64b14b300707140700w5cf05e25l78232c6992e87a08@mail.gmail.com> References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> <1184419313.2822.15.camel@dawkins> <64b14b300707140700w5cf05e25l78232c6992e87a08@mail.gmail.com> Message-ID: <1184482001.3769.3.camel@legolas.felicity-group.com> On Sat, 2007-07-14 at 16:00 +0200, Valent Turkovic wrote: > Well I'm just a user so you can't expect to know where to look if I'm > not involved with rawhide and fedora more than I can in my spare > time... Rawhide eats babies and kills sweet little kittens, as such is generally not for "users". Later test releases (-test3/-test4) are aimed for the less technically inclined who wish to preview upcoming releases. From buildsys at redhat.com Sun Jul 15 09:48:18 2007 From: buildsys at redhat.com (Build System) Date: Sun, 15 Jul 2007 05:48:18 -0400 Subject: rawhide report: 20070715 changes Message-ID: <200707150948.l6F9mI37024688@porkchop.devel.redhat.com> New package ekg2 Multi-protocol instant messaging and chat client New package sub2srt Convert files in .sub format to .srt Updated Packages: SDL_mixer-1.2.7-3.fc8 --------------------- * Sat Jul 14 2007 Brian Pepple - 1.2.7-3 - Add patch fix eopening issue. (#248253) anaconda-11.3.0.6-2 ------------------- * Sat Jul 14 2007 Jesse Keating 11.3.0.6-2 - Rebuild against new dhcp libs deluge-0.5.2-2.fc8 ------------------ * Wed Jul 11 2007 Peter Gordon - 0.5.2-2 - Add patch to fix the existence of stale persistence files by automatically updating the deluge.deluge module name to deluge.core, or removing them if empty (bug 247927): + fix-persistence-upgrade-rhbz_247927.patch evolution-2.11.5-2.fc8 ---------------------- * Fri Jul 13 2007 Matthew Barnes - 2.11.5-1.fc8 - Update to 2.11.5 - Revise patch for GNOME bug #362638 to fix RH bug #245695. * Wed Jun 27 2007 Matthew Barnes - 2.11.4-2.fc8 - Revise patch for GNOME bug #363638 to fix RH bug #245289 (frequent hangs). * Mon Jun 18 2007 Matthew Barnes - 2.11.4-1.fc8 - Update to 2.11.4 - Remove patch for GNOME bug #447727 (fixed upstream). geda-docs-20070708-1.fc8 ------------------------ * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-examples-20070708-1.fc8 ---------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gattrib-20070708-1.fc8 --------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gnetlist-20070708-1.fc8 ---------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gschem-20070708-1.fc8 -------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gsymcheck-20070708-1.fc8 ----------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-symbols-20070708-1.fc8 --------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-utils-20070708-1.fc8 ------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release libgeda-20070708-1.fc8 ---------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release mksh-29g-1.fc8 -------------- muParser-1.28-1.fc8 ------------------- * Sat Jul 14 2007 Frank B??ttner - 1.28-1 - update to 1.28 mysql++-2.3.2-1.fc8 ------------------- * Sat Jul 14 2007 Remi Collet 2.3.2-1 - update to 2.3.2 python-numeric-24.2-5.fc8 ------------------------- * Sat Jul 14 2007 Matthew Barnes - 24.2-5 - Own /usr/include/python2.x (RH bug #245959). redland-1.0.5-4.fc8 ------------------- * Sat Jul 14 2007 Kevin Kofler 1.0.5-4 - get rid of redland-config dependency bloat too (#248106) * Sat Jul 14 2007 Kevin Kofler 1.0.5-3 - fix bug number in changelog * Sat Jul 14 2007 Kevin Kofler 1.0.5-2 - add missing Requires: pkgconfig to the -devel package - get rid of pkgconfig dependency bloat (#248106) system-switch-java-1.1.0-3.fc8 ------------------------------ * Sat Jul 14 2007 Thomas Fitzsimmons - 1.1.0-3 - Use Fedora 8 desktop file categories. - Use desktop-file-install. - Bump release number. tachyon-0.98-0.2.20070319.fc8 ----------------------------- * Sat Jul 14 2007 Dominik 'Rathann' Mierzejewski 0.98-0.2 - add support for ppc64 and sparc64, simplify target setting * Sat Jul 07 2007 Dominik 'Rathann' Mierzejewski 0.98-0.1 - update to 0.98 pre-release udev-113-4.fc8 -------------- * Sat Jul 14 2007 Harald Hoyer - 113-4 - do not collect modprobes (bug #222542), because firmware loading seems to depend on it. Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.i386 requires 3.6.1 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.x86_64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.ppc requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.ppc64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From david at lovesunix.net Sun Jul 15 12:04:08 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 15 Jul 2007 14:04:08 +0200 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) In-Reply-To: <20070714084853.82330b8e.zaitcev@redhat.com> References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> <1184419313.2822.15.camel@dawkins> <20070714084853.82330b8e.zaitcev@redhat.com> Message-ID: <1184501048.3819.3.camel@dawkins> l?r, 14 07 2007 kl. 08:48 -0700, skrev Pete Zaitcev: > On Sat, 14 Jul 2007 15:21:52 +0200, David Nielsen wrote: > > > > I can't install anaconda after the update because it has unresolved > > > dependencies (libdhcp4client-3.0.5.so.0). > > > > You will notice that the daily Rawhide report contains a list of the > > packages that will not install due to dependency problems. > > No, it's not there. I ran across it when updating nash. I blame mirror > inconsistencies. Valents mail went out on the 14th, the dependency problem existed in Rawhide from the prior day. anaconda - 11.3.0.5-1.i386 requires libdhcp4client-3.0.5.so.0 - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From paul at all-the-johnsons.co.uk Sun Jul 15 12:07:03 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sun, 15 Jul 2007 12:07:03 +0000 Subject: MBR seems to have vanished In-Reply-To: <20070714222401.M16040@all-the-johnsons.co.uk> References: <20070714222401.M16040@all-the-johnsons.co.uk> Message-ID: <20070715120703.M33821@all-the-johnsons.co.uk> Hi, No idea how this happened but my MBR seems to have vanished! I can mount the lvm if I use RIPLinux and fsck is not showing up anything untoward. However, I can't actually boot from the hard drive. Is there anyway to restore the MBR using something like RIPLinux? As I say, there is nothing wrong with the drives themselves. All that happens is that when I boot, it says Boot from CD and then hangs. TTFN Paul -- Get your free @ukpost.com account now http://www.ukpost.com/ From bpepple at fedoraproject.org Sun Jul 15 13:11:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 15 Jul 2007 09:11:24 -0400 Subject: FESCo Meeting Summary for 2007-07-05 Message-ID: <1184505084.2831.0.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Jeremy Katz (jeremy) * Christian Iseli (c4chris) * Warren Togami (warren) * Tom Callaway (spot) Absent * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * Rex Dieter (rdieter) == Summary == === FESCo election voting method === * FESCo approved a proposal to use the same voting method as the FPB election, to avoid voter confusion. http://en.wikipedia.org/wiki/Approval_voting === Feature Policy Draft === * FESCo approved John Poelstra's Feature Policy Draft, with the caveat that spot's suggestion regarding the drafting of ideas be incorporated into the policy. === perl-devel in buildroot === * FESCo approved a proposal to remove perl-devel from the buildroot. Many of the FESCo members are willing to help fix the perl modules effected by this decision. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070705 Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 bpepple at fedoraproject.org Sun Jul 15 13:12:08 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 15 Jul 2007 09:12:08 -0400 Subject: FESCo Meeting Summary for 2007-07-12 Message-ID: <1184505128.2831.2.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Kevin Fenzi (nirik) * Christian Iseli (c4chris) * Warren Togami (warren) * Tom Callaway (spot) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * Rex Dieter (rdieter) Absent * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Jeremy Katz (jeremy) == Summary == === R Packaging Guidelines === * FESCo had no objections to the R packaging guidelines proposed by the Packaging Committee. === Secondary Arches Proposal === * FESCo approved spot's secondary arches proposal. * David Woodhouse expressed concern about demoting PPC to a secondary arch before it's been proven that the secondary arch proposal works. FESCo agreed that PPC shouldn't be made a secondary arch until it's proven that the secondary arches can support it. === Core Merge Reviews === * FESCo approved a proposal to make the core merge reviews a Blocker item for F9. warren will make sure that we have buy-in for this goal from RedHat management for engineering time. * FESCo will plan a few merge review days (one probably being during the virtual FUDCon) during the F8 development cycle. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070712 Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 jsacco at gnome.org Sun Jul 15 13:20:19 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Sun, 15 Jul 2007 09:20:19 -0400 Subject: eclipse-rcp dependency list problem Message-ID: <1184505619.2423.5.camel@rt.jesacco.com> eclipse-rcp-3.3.0-1.fc8.ppc.rpm does not install because of a missing dependency: Error: Missing Dependency: 3.6.1 is needed by package eclipse-rcp Hmmm... "3.6.1" ??? What could it be??? icu4j-eclipse.ppc 0:3.6.1-1jpp.2.fc8 -Joseph -- jsacco [at] gnome [dot] org From valent.turkovic at gmail.com Sun Jul 15 13:43:19 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 15 Jul 2007 15:43:19 +0200 Subject: the most serious bug in F7 I found so far... Message-ID: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246593 This is the most serious bug I found in Fedora 7 so please look at it and tell me what more info you need of me. Thank you, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From pertusus at free.fr Sun Jul 15 14:48:09 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 15 Jul 2007 16:48:09 +0200 Subject: the most serious bug in F7 I found so far... In-Reply-To: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> References: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> Message-ID: <20070715144809.GA3070@free.fr> On Sun, Jul 15, 2007 at 03:43:19PM +0200, Valent Turkovic wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246593 > > This is the most serious bug I found in Fedora 7 so please look at it > and tell me what more info you need of me. This list is not for bug reporting, except when bugs need attention from the community, which doesn't seems to be the case for that bug. -- Pat From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun Jul 15 16:54:25 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 15 Jul 2007 18:54:25 +0200 Subject: Unpushing broken or obsolete updates from testing In-Reply-To: <20070706165507.GA19599@ryvius.pekin.waw.pl> References: <20070706165507.GA19599@ryvius.pekin.waw.pl> Message-ID: <20070715185425.1e2e9430@python3.es.egwn.lan> Dominik 'Rathann' Mierzejewski wrote : > On Friday, 06 July 2007 at 03:37, Kevin Kofler wrote: > > Why are updates lingering in updates-testing for weeks when: > > * they are known broken and/or > > * they have already been replaced by a new version, which is already in > > stable? > > IMHO, that's really what the "unpush" option is for. For example, do we > > really need to have that obsolete Thunderbird RC sitting in testing > > forever when the actual release is already out in the stable updates? > > This also makes it harder to track down the legitimate updates which have > > been sitting in testing for way too long. > > This is exactly the kind of thing that should be automated, i.e. run a > script once a week that'd check if there are any obsolete updates in > testing and delete them (notifying the owner perhaps). Removing packages from updates-testing which have newer releases in updates-stable makes sense, but removing "broken" updates from updates-testing might be more of a problem, since it then removes the most recent version of a package, thus theoretically introduces the possibility of breaking update paths for users of the repo, or (possibly worse?) of leaving those users with a broken piece of software for a long time... Pushing fixed packages to testing-updates seems like the right thing to do... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3228.fc7 Load : 0.68 1.53 1.84 From tcallawa at redhat.com Sun Jul 15 17:00:53 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 15 Jul 2007 12:00:53 -0500 Subject: Is this content license acceptable? In-Reply-To: <4698A39D.6060200@hhs.nl> References: <4698A39D.6060200@hhs.nl> Message-ID: <1184518853.2050.3.camel@localhost.localdomain> On Sat, 2007-07-14 at 12:21 +0200, Hans de Goede wrote: > Hi All, > > I've been looking at packaging C-dogs SDL, The SDL port an old dos game. This > port uses the data files of the original game, which are licenses under then > following conditions: > > The basic terms for redistribution are as follows: > a) All files must be distributed unmodified > b) There must be no charge for the game as such. > > Condition a) is not a problem for content, and AFAIK b) isn't a problem either, > because it is allowed to sell discs with the game on it and charge for the > disc, etc. Still I'm asking to be sure about condition b) Sure, this content license is OK. ~spot From sean.bruno at dsl-only.net Sun Jul 15 18:33:46 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 15 Jul 2007 11:33:46 -0700 Subject: [rawhide X86_64] tg3 not loading for my NIC Message-ID: <1184524426.3168.2.camel@home-desk> I attempted to install from the CD image and the USB image in today's rawhide and tg3 isn't detecting my NIC for some strange reason. I tried to manually select it from the list of drivers and it did not detect my card. Here is an lspci -vv from F7: 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 11) Subsystem: ASUSTeK Computer Inc. Unknown device 814b Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- References: <1184524426.3168.2.camel@home-desk> Message-ID: <1184526029.3273.2.camel@home-desk> On Sun, 2007-07-15 at 11:33 -0700, Sean Bruno wrote: > I attempted to install from the CD image and the USB image in today's > rawhide and tg3 isn't detecting my NIC for some strange reason. I tried > to manually select it from the list of drivers and it did not detect my > card. I put in an Intel 10/100 and retested. The system still failed to detect the NIC. I ctrl-alt'd to the virtual terminals and noted that the system was trying to load the appropriate modules, with no errors noted. However, there was no way for me to continue to install after selecting the method(ftp/http in my case). Sean From kevin.kofler at chello.at Sun Jul 15 20:48:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 15 Jul 2007 20:48:38 +0000 (UTC) Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> <1184419313.2822.15.camel@dawkins> <64b14b300707140700w5cf05e25l78232c6992e87a08@mail.gmail.com> <1184482001.3769.3.camel@legolas.felicity-group.com> Message-ID: Gawain Lynch felicity-group.com> writes: > Rawhide eats babies and kills sweet little kittens, as such is generally > not for "users". Later test releases (-test3/-test4) are aimed for the > less technically inclined who wish to preview upcoming releases. No test4 is planned for Fedora 8, that was just added for Fedora 7 to allow the Core-Extras Merge to happen. (Originally, this was supposed to allow it to happen before the feature freeze, at the end, it actually happened after test4!) From seandarcy2 at gmail.com Sun Jul 15 19:58:46 2007 From: seandarcy2 at gmail.com (sean) Date: Sun, 15 Jul 2007 15:58:46 -0400 Subject: [OT] check-buildroot: binary file matches Message-ID: I'm trying to build ffmpeg on rawhide with a spec file that's worked for over 8 months. I'm now getting an error I've never seen - with an error message that leaves me clueless: + /usr/lib/rpm/check-buildroot Binary file /var/tmp/ffmpeg-root/usr/bin/ffmpeg matches Found '/var/tmp/ffmpeg-root' in installed files; aborting I realize this is the wrong place for rpmbuild issues, but I'd appreciate either a lead on fixing this, or a steer to where these rpm issues are addressed. Thanks. sean From dmc.fedora at filteredperception.org Sun Jul 15 21:08:09 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 15 Jul 2007 16:08:09 -0500 Subject: [SCRIPT] rebootless liveinst - the MudPuddle release In-Reply-To: <469946B4.1050404@filteredperception.org> References: <469946B4.1050404@filteredperception.org> Message-ID: <469A8CB9.4030906@filteredperception.org> Douglas McClendon wrote: ... > In the name of release-early-release-often, here is a proof of concept > quality release of what I call a "rebootless livemedia installer". ... Ok, I'm actually a bit surprised that releasing in the tail end of sleep deprived state, that there weren't more problems with the release. The main one that I'll imminently release updates for is the fact that the bootloader config assumes /dev/sda, rather than supporting the advertised /dev/sda[abcd] depending on invocation. Also there should have been a warning that it will be installing grub on your MBR for you (in addition to 'wiping' and installing on the target partition). And, though I don't know if it will work, I can try and make the generated bootloader config work if you have generated a livecd with updated kernel packages (versus the stock f7). Also, my minor tweak to the patch in the comments (that I posted a week ago on fedora-livecd-list) should have unsupport_live_migrate setting support_live_migrate=0, not 1. The patch as I want it to apply to livecd-creator has support_live_migrate disabled by default, but rather than explain how to tweak the bootloader config generated by livecd-tools I wanted to make the patch to it less complicated. Also a minor style thing is that I used [ "" = "" ] *AND*, [ "" == "" ]. Apparently they both work the same??. But, as long as you install to /dev/sdaX, the original release works. Any review/comments/suggestions/criticisms are more than welcome. peace... -dmc From asric at asric.com Sun Jul 15 21:33:08 2007 From: asric at asric.com (Steven Ringwald) Date: Sun, 15 Jul 2007 14:33:08 -0700 Subject: KRegExpEditor not in fedora? In-Reply-To: <46975226.7090703@gmail.com> References: <46973B43.4040403@gmail.com> <46973E0E.5000904@asric.com> <46975226.7090703@gmail.com> Message-ID: > >> i enabled fedora-development and livna-devel repo > >> > > I think that it is in the kdeutils or kdeutils-extras package.. Which > > release of Fedora are you using?? > > thanks, steven > > i use gnome, so i dont have most of the kde component, but i will check > it. > > additionally, i find a similar tool, called redet, which is tk-based > program Ok. Let me know if you need further help looking for it. Steve From tspauld98 at yahoo.com Mon Jul 16 00:25:46 2007 From: tspauld98 at yahoo.com (Timothy Spaulding) Date: Sun, 15 Jul 2007 17:25:46 -0700 (PDT) Subject: squid and squidGuard Message-ID: <439416.31512.qm@web60515.mail.yahoo.com> Hi Folks, Is there a current maintainer for the squid and squidGuard packages? I'm configuring them on my kid's pc and there are a number of suggestions/wish list items that I have compiled. What's the best way to start working on this issue. FWIW, I'm really surprised at how hard it is to get Fedora "kid safe" out of the box. (I'm getting it done, but I can't imagine a casual user accomplishing this feat. It currently requires a working understanding of web proxies and how unix user administration works.) Considering this project's involvement with OLPC, I'm shocked that the web proxy/blacklist stuff isn't more bullet-proof and easy to enable. Who did I need to talk to help fix this? Is the OLPC doing some more advanced integration of kid safe web proxies? Thanks, Tim ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php From kevin.kofler at chello.at Mon Jul 16 00:37:17 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 16 Jul 2007 00:37:17 +0000 (UTC) Subject: squid and squidGuard References: <439416.31512.qm@web60515.mail.yahoo.com> Message-ID: Timothy Spaulding yahoo.com> writes: > Considering this project's involvement with OLPC, I'm shocked that the web > proxy/blacklist stuff isn't more bullet-proof and easy to enable. Who did I > need to talk to help fix this? Is the OLPC doing some more advanced > integration of kid safe web proxies? No, I don't think it does any filtering at all. OLPC isn't about censorship. Kevin Kofler From tmus at tmus.dk Mon Jul 16 00:54:51 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 15 Jul 2007 22:54:51 -0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <1184304543.3921.3.camel@rousalka.dyndns.org> References: <46961691.4090800@bppiac.hu> <46964455.20805@draigBrady.com> <1184256334.16549.1.camel@rousalka.dyndns.org> <46965451.3040807@draigBrady.com> <1184304543.3921.3.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Le jeudi 12 juillet 2007 ? 17:18 +0100, P?draig Brady a ?crit : >> Nicolas Mailhot wrote: >>> Compression is a big win for remote tranfers. For local ones of course >>> it's a net loss. >> It's not as simple as that. >> I also tested across the LAN, > > LAN counts as local too. You can find many discussions on compression > pros & cons at the protocol level on the internet. > > It really comes down to who is the bottleneck - the wire or the CPU... /Thomas From tspauld98 at yahoo.com Mon Jul 16 01:28:07 2007 From: tspauld98 at yahoo.com (Timothy Spaulding) Date: Sun, 15 Jul 2007 18:28:07 -0700 (PDT) Subject: squid and squidGuard In-Reply-To: Message-ID: <310166.74526.qm@web60523.mail.yahoo.com> So I take it that you're in favor of delivering a PC to children to educate them on pr0n? That's extremely radical of you. It seems to me that a minimum configuration that would filter inappropriate web sites that was community managed and transparent would be appropriate. Or am I in the minority here? I'm not talking about censorship here but I believe a minimum set of community-agreed-upon standards would be acceptable. Thanks, Tim --- Kevin Kofler wrote: > Timothy Spaulding yahoo.com> writes: > > Considering this project's involvement with OLPC, I'm shocked that the web > > proxy/blacklist stuff isn't more bullet-proof and easy to enable. Who did I > > need to talk to help fix this? Is the OLPC doing some more advanced > > integration of kid safe web proxies? > > No, I don't think it does any filtering at all. OLPC isn't about censorship. > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 From poelstra at redhat.com Mon Jul 16 02:29:24 2007 From: poelstra at redhat.com (John Poelstra) Date: Sun, 15 Jul 2007 19:29:24 -0700 Subject: Existing features listed for Fedora 8 In-Reply-To: References: Message-ID: <469AD804.8040207@redhat.com> Kevin Kofler said the following on 07/12/2007 11:21 PM Pacific Time: > Are the features already listed for Fedora 8 (e.g. FeatureKDE4) supposed to get > FESCo approval too? If not, should they be added directly to > CategoryApprovedFedora8? Or should they just stay in the legacy > CategoraFedora8Features? I added FeatureKDE4 to CategoryProposedFedora8, but > I'm asking to make sure I'm following the proper procedure here, and also to > get the awareness of the owners of the other features in the same situation. > > Kevin Kofler > Yes, you are doing the right thing by adding CategoryProposedFedora8. I will start querying this category before each FESCo meeting. Now that the Feature process has been ratified I will be rounding up the features slated for F8 and taking them to FESCo. http://fedoraproject.org/wiki/Features/Policy#feature-approval There may be a little confusion for a bit while I sort through what is already on the wiki and get things categorized as CategoryProposedFedora8 where appropriate. I'll also contact the feature owners directly if things are unclear or something is in question. I expect this round of feature wrangling for F8 to be more flexible and a little less organized (which is completely fine) as we start the new process up in the midst of development. :) Once FESCo approves I will change the category to CategoryApprovedFedora8. Hope that helps, John From jkeating at redhat.com Mon Jul 16 02:30:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 15 Jul 2007 22:30:30 -0400 Subject: [OT] check-buildroot: binary file matches In-Reply-To: References: Message-ID: <20070715223030.6b2d93f0@ender> On Sun, 15 Jul 2007 15:58:46 -0400 sean wrote: > I'm trying to build ffmpeg on rawhide with a spec file > that's worked for over 8 months. I'm now getting an error > I've never seen - with an error message that leaves me clueless: > > + /usr/lib/rpm/check-buildroot > Binary file /var/tmp/ffmpeg-root/usr/bin/ffmpeg matches > Found '/var/tmp/ffmpeg-root' in installed files; aborting Looks like something is looking for a path in the rpm buildroot instead of what would be on the system. You should post up your spec and your build log somewhere. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Mon Jul 16 03:50:04 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 15 Jul 2007 20:50:04 -0700 Subject: squid and squidGuard In-Reply-To: <310166.74526.qm@web60523.mail.yahoo.com> References: <310166.74526.qm@web60523.mail.yahoo.com> Message-ID: <1184557804.4403.1.camel@tuxhugs> On Sun, 2007-07-15 at 18:28 -0700, Timothy Spaulding wrote: > So I take it that you're in favor of delivering a PC to children to educate them on pr0n? That's > extremely radical of you. It seems to me that a minimum configuration that would filter > inappropriate web sites that was community managed and transparent would be appropriate. Or am I > in the minority here? I'm not talking about censorship here but I believe a minimum set of > community-agreed-upon standards would be acceptable. > My understanding of the situation is that the governments and institutions to which OLPC machines will be sold are the responsible party for enforcing such blockings, and not the OLPC project itself. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Mon Jul 16 04:06:05 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 16 Jul 2007 04:06:05 +0000 (UTC) Subject: Unpushing broken or obsolete updates from testing References: <20070706165507.GA19599@ryvius.pekin.waw.pl> <20070715185425.1e2e9430@python3.es.egwn.lan> Message-ID: Matthias Saou spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> writes: > Pushing fixed packages to testing-updates seems like the right thing to > do... You still need to manually unpush the broken updates when you do that, or they'll clutter Bodhi forever, and probably even show up in the testing repo again once the fixed version gets promoted to stable. Kevin Kofler From tspauld98 at yahoo.com Mon Jul 16 06:24:32 2007 From: tspauld98 at yahoo.com (Timothy Spaulding) Date: Sun, 15 Jul 2007 23:24:32 -0700 (PDT) Subject: squid and squidGuard In-Reply-To: <1184557804.4403.1.camel@tuxhugs> Message-ID: <51245.66735.qm@web60523.mail.yahoo.com> That's great and it makes alot of sense, but it wasn't really my original point. My original point was the packaging and toolset for managing and enforcing web proxies and filters leave alot to be desired. Is anyone working on this effort? Is there a current maintainer of squid and squidGuard? Are they actively being improved on/incorporated into the Fedora/GNOME configuration toolset? Thanks, Tim --- Peter Gordon wrote: > > On Sun, 2007-07-15 at 18:28 -0700, Timothy Spaulding wrote: > > So I take it that you're in favor of delivering a PC to children to educate them on pr0n? > That's > > extremely radical of you. It seems to me that a minimum configuration that would filter > > inappropriate web sites that was community managed and transparent would be appropriate. Or > am I > > in the minority here? I'm not talking about censorship here but I believe a minimum set of > > community-agreed-upon standards would be acceptable. > > > > My understanding of the situation is that the governments and > institutions to which OLPC machines will be sold are the responsible > party for enforcing such blockings, and not the OLPC project itself. > -- > Peter Gordon (codergeek42) > GnuPG Public Key ID: 0xFFC19479 / Fingerprint: > DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From debarshi.ray at gmail.com Mon Jul 16 08:00:01 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 16 Jul 2007 13:30:01 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released Message-ID: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> I hereby announce the release of the Fedora Offline Package Manager (RUM) 0.0.1. This program is meant to enable users who do not have a viable network connection to manage their packages, ie. install new ones and update existing ones, through the standard package management framework used in Fedora. If you are interested then you can read more about it at https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay This is a beta release and offers the following features: 1. Profile management: a. Exporting the profile of the local system. b. Importing the profile of another system. c. Deleting existing profiles. 2. YumPack creation - Although I have tested this to the best of my ability, I would appreciate if you could try to create new YumPacks and verify whether the dependencies are being correctly resolved. To install package(s) from a YumPack, you would need to untar the YumPack, which is essentially an uncompressed Tar archive, and use 'system-install-packages' to install the RPMs as you would normally do. Tar ball: https://fedoraproject.org/wiki/DebarshiRay/rum?action=AttachFile&do=get&target=rum-0.0.1.tar.gz Pre-requisites: If you are using Pirut <1.3.9, then you would need to apply this patch on /usr/lib/python2.5/site-packages/pirut/__init__.py: https://fedoraproject.org/wiki/DebarshiRay/rum?action=AttachFile&do=get&target=pirut-changes.diff Installation instructions: 1. $ tar -xzvf rum-0.0.1.tar.gz 2. $ cd rum-0.0.1 3. $ ./configure --prefix=/usr (Other prefixes are not expected to work. Please bear with it for the moment.) 4. $ make 5. # make install Execution instructions: 1. $ rum Documentation page: https://fedoraproject.org/wiki/DebarshiRay/rum This is lagging behind a bit, but will be eventually updated. Bug-reports and comments are to be sent to rishi at fedoraproject.org. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From roland at redhat.com Mon Jul 16 09:03:28 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 16 Jul 2007 02:03:28 -0700 (PDT) Subject: rawhide du jour installer can't load modules? Message-ID: <20070716090328.7AC3F4D05BE@magilla.localdomain> Is the rawhide installer broken for loading modules? I tried a network install on i386 & x86_64 using today's images, and it acted like no modules worked. i.e., it didn't find the module for my NIC, and manual selection of the right one (tg3) didn't behave any different. I think this is with the rawhide kernel rpm whose uname -r says 2.6.22 but its install uses 2.6.23, so maybe that is related. Or what? It would be nice to have an installable rawhide. Thanks, Roland From buildsys at redhat.com Mon Jul 16 09:24:29 2007 From: buildsys at redhat.com (Build System) Date: Mon, 16 Jul 2007 05:24:29 -0400 Subject: rawhide report: 20070716 changes Message-ID: <200707160924.l6G9OT2I022214@porkchop.devel.redhat.com> New package R-widgetTools Tools to support the construction of tcltk widgets New package gdesklets-quote-of-the-day Quote of the day desklet for gdesklet New package gnome-specimen A simple tool to view and compare fonts installed on your system New package perl-Net-Packet A framework to easily send and receive frames from layer 2 to layer 7 New package php-pecl-phar Allows running of complete applications out of .phar files Updated Packages: deskbar-applet-2.19.5-1.fc8 --------------------------- * Sat Jul 14 2007 Luke Macken - 2.19.5-1 - 2.19.5 - Add patch to fix beagle-live issue (Bug #248249) based on recommendations from upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=429107 - Add the following temporary patches that I wrote and submitted upstream. deskbar-applet-desklicious-utils.patch (committed upstream, #456969) deskbar-applet-desklicious-results.patch (committed upstream, #456971) deskbar-applet-desklicious-name.patch (pending, #457133) - Remove deskbar-applet-gdmclient.patch dovecot-1.0.2-13.5.fc8 ---------------------- * Sun Jul 15 2007 Tomas Janousek - 1.0.2-13.5 - update to latest upstream fuse-emulator-0.8.0.1-2.fc8 --------------------------- * Sun Jul 15 2007 Ian Chapman 0.8.0.1-2 - Filter unwanted dependancies dragged in by rpm (BZ #248265) * Sat Jun 30 2007 Ian Chapman 0.8.0.1-1 - Upgrade to 0.8.0.1 - Various cleanups to the SPEC including conforming to new guidelines * Thu Feb 09 2006 Paul F. Johnson - 0.7.0-6 - Removed pre and post as they were empty - Fixed the "fuse-emulator" problem gnubiff-2.2.7-1.fc8 ------------------- * Sun Jul 15 2007 Damien Durand - 2.2.7-1 - Updade to 2.2.7 lyx-1.5.0-0.10.rc2.fc8 ---------------------- * Sun Jul 15 2007 Rex Dieter 1.5.0-0.10.rc2 - upstream patch for 'lyx --export latex' crasher (#248282) Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.i386 requires 3.6.1 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.x86_64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.ppc requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.ppc64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) From marcel at mesa.nl Mon Jul 16 09:29:05 2007 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Mon, 16 Jul 2007 11:29:05 +0200 Subject: kde startup problems In-Reply-To: <20070709211005.GB15574@joshua.mesa.nl> References: <20070709200514.GA15574@joshua.mesa.nl> <200707092218.21278.jaroslav@aster.pl> <20070709211005.GB15574@joshua.mesa.nl> Message-ID: <20070716092905.GA21183@joshua.mesa.nl> On Mon, Jul 09, 2007 at 11:10:05PM +0200, Marcel J.E. Mol wrote: > On Mon, Jul 09, 2007 at 10:18:21PM +0200, Jaroslaw Gorny wrote: > > Monday 09 of July 2007 22:05:14 Marcel J.E. Mol napisa?(a): > > > Hello, > > > since last week i seem to have kde startup problems. > > > I get severel popup windows saying things like: > > > > > > 'Malformed URL file:///home/marcel/Desktop' > > > > > > 'Could not find mime type application/octet-stream' > > > > > > 'no mime types installed' > > > > > > I had to re-add Kmenu to the taskbar because it dissapeared... > > > > > > I reinstalled all kde rpms, but the problem persists, so I don't > > > know where to look to fix this. > > > > > > Can anybody help? > > > > > > > Have You tried starting KDE as other user? Or alternatively - temporarily > > renaming ~/.kdrc file and ~/.kde/ dir? > > I did rename .kde but it did not help. I also removed ~/.mailcap en ~/.mimetypes. > I did not rename the .kdrc but it only contains font definitions. I'm still having problems with this... I normally use firefox, but when starting konqueror I first get a message window with "Could not find mime type - application/octet-stream" followed by "no mime types installed" And then when entering the location: http://slashdot.org "Protocol not supported - http" Any idea where to look for this kind of problems? -Marcel From z.kota at gmx.net Mon Jul 16 10:41:21 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Mon, 16 Jul 2007 12:41:21 +0200 (CEST) Subject: python-elementree & F7? Message-ID: Hi, It seems python-elementtree is missing from F7 (and devel)! What is the reason? Maybe I missed something? Koji says: 271 python-elementtree dist-fc7 icon no Zoltan From ivazqueznet at gmail.com Mon Jul 16 10:48:44 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 16 Jul 2007 06:48:44 -0400 Subject: python-elementree & F7? In-Reply-To: References: Message-ID: <1184582924.11917.1.camel@ignacio.lan> On Mon, 2007-07-16 at 12:41 +0200, Zoltan Kota wrote: > It seems python-elementtree is missing from F7 (and devel)! What is the > reason? Maybe I missed something? http://docs.python.org/whatsnew/modules.html#SECTION0001420000000000000000 -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From z.kota at gmx.net Mon Jul 16 10:56:46 2007 From: z.kota at gmx.net (Zoltan Kota) Date: Mon, 16 Jul 2007 12:56:46 +0200 (CEST) Subject: python-elementree & F7? In-Reply-To: References: Message-ID: On Mon, 16 Jul 2007, Zoltan Kota wrote: > It seems python-elementtree is missing from F7 (and devel)! What is the > reason? Maybe I missed something? Ooops. In the meantime I found that it is included in python-2.5. Zoltan From jkeating at j2solutions.net Mon Jul 16 11:01:04 2007 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jul 2007 07:01:04 -0400 Subject: Unpushing broken or obsolete updates from testing In-Reply-To: References: <20070706165507.GA19599@ryvius.pekin.waw.pl> <20070715185425.1e2e9430@python3.es.egwn.lan> Message-ID: <20070716070104.76d2f389@ender> On Mon, 16 Jul 2007 04:06:05 +0000 (UTC) Kevin Kofler wrote: > You still need to manually unpush the broken updates when you do > that, or they'll clutter Bodhi forever, and probably even show up in > the testing repo again once the fixed version gets promoted to stable. Only the latest update will show up in the repo. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Mon Jul 16 11:08:37 2007 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jul 2007 07:08:37 -0400 Subject: Unpushing broken or obsolete updates from testing In-Reply-To: <20070716070104.76d2f389@ender> References: <20070706165507.GA19599@ryvius.pekin.waw.pl> <20070715185425.1e2e9430@python3.es.egwn.lan> <20070716070104.76d2f389@ender> Message-ID: <20070716070837.50df81c3@ender> On Mon, 16 Jul 2007 07:01:04 -0400 Jesse Keating wrote: > > You still need to manually unpush the broken updates when you do > > that, or they'll clutter Bodhi forever, and probably even show up in > > the testing repo again once the fixed version gets promoted to > > stable. > > > Only the latest update will show up in the repo. Whoops, I re-read what you wrote, and you are correct. Pushing the correct build over to stable would unmask the incorrect build from -testing. Of course, yum most likely wouldn't offer it as an update due to n-v-r, but still. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ndbecker2 at gmail.com Mon Jul 16 12:25:37 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 16 Jul 2007 08:25:37 -0400 Subject: ntfsresize for installation Message-ID: I'm about to help a colleague repartition + install fc7. She will need to do ntfsresize. Do I need to download knoppix to do ntfsresze? Shouldn't fc7 iso include the ability to do this as part of the installation, rather than requiring the user to download e.g. knoppix to do it? From dakingun at gmail.com Mon Jul 16 12:38:27 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Mon, 16 Jul 2007 08:38:27 -0400 Subject: ntfsresize for installation In-Reply-To: References: Message-ID: On 7/16/07, Neal Becker wrote: > I'm about to help a colleague repartition + install fc7. She will need to > do ntfsresize. Do I need to download knoppix to do ntfsresze? Shouldn't > fc7 iso include the ability to do this as part of the installation, rather > than requiring the user to download e.g. knoppix to do it? > Fedora Live media and gparted should be able to do the job. Deji From giallu at gmail.com Mon Jul 16 12:39:18 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 16 Jul 2007 14:39:18 +0200 Subject: ntfsresize for installation In-Reply-To: References: Message-ID: On 7/16/07, Neal Becker wrote: > I'm about to help a colleague repartition + install fc7. She will need to > do ntfsresize. Do I need to download knoppix to do ntfsresze? Shouldn't > fc7 iso include the ability to do this as part of the installation, rather > than requiring the user to download e.g. knoppix to do it? > The LiveCD has both ntfs-3g and gparted, which should prove useful for that task. Obviously, having support for this (IMHO very common) scenario in anaconda would be really a leap forward in the ease of installation, but I'm not sure if there are plans to work on the issue. From darrellpf at gmail.com Mon Jul 16 12:48:51 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 16 Jul 2007 05:48:51 -0700 Subject: rawhide du jour installer can't load modules? In-Reply-To: <20070716090328.7AC3F4D05BE@magilla.localdomain> References: <20070716090328.7AC3F4D05BE@magilla.localdomain> Message-ID: On 7/16/07, Roland McGrath wrote: > Is the rawhide installer broken for loading modules? I tried a network > install on i386 & x86_64 using today's images, and it acted like no modules > worked. i.e., it didn't find the module for my NIC, and manual selection > of the right one (tg3) didn't behave any different. > > I think this is with the rawhide kernel rpm whose uname -r says 2.6.22 but > its install uses 2.6.23, so maybe that is related. Or what? > > It would be nice to have an installable rawhide. > > There have been a couple of issues. The current kernel (vmlinuz-2.6.23-0.15.rc0.git1.fc8) is broken, which is what you're seeing. There hasn't been a replacement in rawhide yet. The fedora kernel naming just changed so this is probably an artifact. udev was also causing some module loading to fail on the previous working kernels. That was corrected in the current one (udev-113-4.fc8) darrell From jfontain at free.fr Mon Jul 16 14:18:41 2007 From: jfontain at free.fr (jfontain at free.fr) Date: Mon, 16 Jul 2007 16:18:41 +0200 Subject: any chance to see kernel 2.6.22 for FC6? Message-ID: <1184595521.469b7e417cbb1@imp.free.fr> I'd like to try to get some more battery life out of my laptop... Many thanks, -- Jean-Luc From ndbecker2 at gmail.com Mon Jul 16 13:27:33 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 16 Jul 2007 09:27:33 -0400 Subject: ntfsresize for installation References: Message-ID: Deji Akingunola wrote: > On 7/16/07, Neal Becker wrote: >> I'm about to help a colleague repartition + install fc7. She will need >> to >> do ntfsresize. Do I need to download knoppix to do ntfsresze? Shouldn't >> fc7 iso include the ability to do this as part of the installation, >> rather than requiring the user to download e.g. knoppix to do it? >> > Fedora Live media and gparted should be able to do the job. > > Deji > Can the user install from the live media, or do we require the user to download both the live version, just for ntfsresize, and then download non-live version to do installation? From giallu at gmail.com Mon Jul 16 13:40:36 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 16 Jul 2007 15:40:36 +0200 Subject: ntfsresize for installation In-Reply-To: References: Message-ID: On 7/16/07, Neal Becker wrote: > > Can the user install from the live media, or do we require the user to > download both the live version, just for ntfsresize, and then download > non-live version to do installation? > The former, but the package set is a reduced one, so broadband will be needed to fill in the holes From sundaram at fedoraproject.org Mon Jul 16 14:27:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 16 Jul 2007 19:57:14 +0530 Subject: ntfsresize for installation In-Reply-To: References: Message-ID: <469B8042.5040801@fedoraproject.org> Neal Becker wrote: > > Can the user install from the live media, or do we require the user to > download both the live version, just for ntfsresize, and then download > non-live version to do installation? 1) The live images are installable 2) The live images and regular images use the same central repository http://fedoraproject.org/wiki/Fedora7/FAQ Rahul From tmraz at redhat.com Mon Jul 16 14:29:50 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 16 Jul 2007 16:29:50 +0200 Subject: High Performance SSH/SCP - HPN-SSH In-Reply-To: <1184433361.3990.0.camel@sb-home> References: <46961691.4090800@bppiac.hu> <469638BD.1090202@redhat.com> <46965096.1020503@redhat.com> <1184272826.10340.17.camel@perun.kabelta.loc> <1184433361.3990.0.camel@sb-home> Message-ID: <1184596190.5682.7.camel@perun.kabelta.loc> On Sat, 2007-07-14 at 19:16 +0200, nodata wrote: > Am Donnerstag, den 12.07.2007, 22:40 +0200 schrieb Tomas Mraz: > > I'm still a little bit uneasy to allow this patch in. We were trying to > > keep as close to upstream as possible. On the other hand we have other > > changes we have other patches in like the SELinux changes for MLS and > > the recent support for keys in NSS by which we significantly diverge > > from upstream already. So maybe we could reconsider applying the HPN > > patch or at least some less controversial parts of it. > > This paragraph disagrees with your signature. That depends on what the right and what the wrong road in this case is which I am afraid I don't know. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jul 16 14:53:47 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 16 Jul 2007 16:53:47 +0200 Subject: Unpushing broken or obsolete updates from testing In-Reply-To: <20070716070837.50df81c3@ender> References: <20070706165507.GA19599@ryvius.pekin.waw.pl> <20070715185425.1e2e9430@python3.es.egwn.lan> <20070716070104.76d2f389@ender> <20070716070837.50df81c3@ender> Message-ID: <20070716165347.1f8e4263@python3.es.egwn.lan> Jesse Keating wrote : > On Mon, 16 Jul 2007 07:01:04 -0400 > Jesse Keating wrote: > > > > You still need to manually unpush the broken updates when you do > > > that, or they'll clutter Bodhi forever, and probably even show up in > > > the testing repo again once the fixed version gets promoted to > > > stable. > > > > > > Only the latest update will show up in the repo. > > Whoops, I re-read what you wrote, and you are correct. Pushing the > correct build over to stable would unmask the incorrect build from > -testing. Of course, yum most likely wouldn't offer it as an update > due to n-v-r, but still. But we would then be back to the first (simple) scenario, where we have an obsolete update needing to be cleaned, right? My concern is with updated packages appearing in updates-testing, then "disappearing" because they were considered broken, since those might stick around for a while on many systems, not a good thing since bug reports might be filed against the package long after it has disappeared. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.21-1.3255.fc7 Load : 0.17 0.35 0.53 From overholt at redhat.com Mon Jul 16 15:17:45 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 16 Jul 2007 11:17:45 -0400 Subject: eclipse-rcp dependency list problem In-Reply-To: <1184505619.2423.5.camel@rt.jesacco.com> References: <1184505619.2423.5.camel@rt.jesacco.com> Message-ID: <1184599065.8894.7.camel@localhost.localdomain> On Sun, 2007-07-15 at 09:20 -0400, Joseph Sacco wrote: > eclipse-rcp-3.3.0-1.fc8.ppc.rpm does not install because of a missing > dependency: > > Error: Missing Dependency: 3.6.1 is needed by package eclipse-rcp Weird. This is what is in the specfile: Requires: icu4j-eclipse > = 3.6.1 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 emmanuel.seyman at club-internet.fr Mon Jul 16 15:28:00 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 16 Jul 2007 17:28:00 +0200 Subject: eclipse-rcp dependency list problem In-Reply-To: <1184599065.8894.7.camel@localhost.localdomain> References: <1184505619.2423.5.camel@rt.jesacco.com> <1184599065.8894.7.camel@localhost.localdomain> Message-ID: <20070716152800.GA22139@orient.maison.lan> * Andrew Overholt [16/07/2007 17:25] : > > Weird. This is what is in the specfile: > > Requires: icu4j-eclipse > = 3.6.1 I'm guessing that should read : Requires: icu4j-eclipse >= 3.6.1 Emmanuel From brunson at brunson.com Mon Jul 16 15:49:34 2007 From: brunson at brunson.com (Eric Brunson) Date: Mon, 16 Jul 2007 09:49:34 -0600 Subject: squid and squidGuard In-Reply-To: <51245.66735.qm@web60523.mail.yahoo.com> References: <51245.66735.qm@web60523.mail.yahoo.com> Message-ID: <469B938E.2090705@brunson.com> Sounds like a good project and it seems you have a good head start on it. How about putting together an umbrella rpm with all the package requirements and a set of working configs? Just a thought, e. Timothy Spaulding wrote: > That's great and it makes alot of sense, but it wasn't really my original point. My original > point was the packaging and toolset for managing and enforcing web proxies and filters leave alot > to be desired. Is anyone working on this effort? Is there a current maintainer of squid and > squidGuard? Are they actively being improved on/incorporated into the Fedora/GNOME configuration > toolset? > > Thanks, > > Tim > > --- Peter Gordon wrote: > > >> On Sun, 2007-07-15 at 18:28 -0700, Timothy Spaulding wrote: >> >>> So I take it that you're in favor of delivering a PC to children to educate them on pr0n? >>> >> That's >> >>> extremely radical of you. It seems to me that a minimum configuration that would filter >>> inappropriate web sites that was community managed and transparent would be appropriate. Or >>> >> am I >> >>> in the minority here? I'm not talking about censorship here but I believe a minimum set of >>> community-agreed-upon standards would be acceptable. >>> >>> >> My understanding of the situation is that the governments and >> institutions to which OLPC machines will be sold are the responsible >> party for enforcing such blockings, and not the OLPC project itself. >> -- >> Peter Gordon (codergeek42) >> GnuPG Public Key ID: 0xFFC19479 / Fingerprint: >> DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 >> >>> -- >>> >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > > ____________________________________________________________________________________ > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search > http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz > > From jwilson at redhat.com Mon Jul 16 15:56:37 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jul 2007 11:56:37 -0400 Subject: rawhide du jour installer can't load modules? In-Reply-To: <20070716090328.7AC3F4D05BE@magilla.localdomain> References: <20070716090328.7AC3F4D05BE@magilla.localdomain> Message-ID: <469B9535.4090703@redhat.com> Roland McGrath wrote: > Is the rawhide installer broken for loading modules? I tried a network > install on i386 & x86_64 using today's images, and it acted like no modules > worked. i.e., it didn't find the module for my NIC, and manual selection > of the right one (tg3) didn't behave any different. > > I think this is with the rawhide kernel rpm whose uname -r says 2.6.22 but > its install uses 2.6.23, so maybe that is related. Or what? I'm pretty sure this is solely the kernel build's fault -- I missed one necessary change to fix up what the built kernel actually calls itself in the pre-rc1 case, so all module loading is mostly horked. Its fixed in cvs, but davej is still shaking out compile issues w/the latest git snapshot. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Mon Jul 16 15:58:46 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jul 2007 11:58:46 -0400 Subject: [rawhide X86_64] tg3 not loading for my NIC In-Reply-To: <1184526029.3273.2.camel@home-desk> References: <1184524426.3168.2.camel@home-desk> <1184526029.3273.2.camel@home-desk> Message-ID: <469B95B6.4080302@redhat.com> Sean Bruno wrote: > On Sun, 2007-07-15 at 11:33 -0700, Sean Bruno wrote: >> I attempted to install from the CD image and the USB image in today's >> rawhide and tg3 isn't detecting my NIC for some strange reason. I tried >> to manually select it from the list of drivers and it did not detect my >> card. > I put in an Intel 10/100 and retested. The system still failed to > detect the NIC. > > I ctrl-alt'd to the virtual terminals and noted that the system was > trying to load the appropriate modules, with no errors noted. However, > there was no way for me to continue to install after selecting the > method(ftp/http in my case). This is probably the uname/kernel rpm version mismatch problem biting you. Fixed in cvs, but other kernel compile issues are preventing a newer kernel from hitting rawhide atm. Coming Real Soon Now though... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From joshkel at gmail.com Mon Jul 16 16:09:18 2007 From: joshkel at gmail.com (Josh Kelley) Date: Mon, 16 Jul 2007 12:09:18 -0400 Subject: Disabling brp-strip for mock builds? Message-ID: <97cbd1a90707160909u1282f4b4sfd326b41600a5a5d@mail.gmail.com> (I hope that this is an appropriate place to ask mock questions that aren't Fedora-specific. If not, please direct me to the right place.) I have an RPM for a program that performs an integrity check on itself when it's run, so stripping it would cause it to fail that check. I fixed this by adding a couple of lines to the %install section of the spec file: %undefine __os_install_post /usr/lib/rpm/brp-compress This works fine for normal builds; however, when I build the RPM using mock, brp-strip and its cousins are called anyway. What do I need to do to properly disable brp-strip for mock builds? Thanks. Josh Kelley From overholt at redhat.com Mon Jul 16 16:00:53 2007 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 16 Jul 2007 12:00:53 -0400 Subject: eclipse-rcp dependency list problem In-Reply-To: <20070716152800.GA22139@orient.maison.lan> References: <1184505619.2423.5.camel@rt.jesacco.com> <1184599065.8894.7.camel@localhost.localdomain> <20070716152800.GA22139@orient.maison.lan> Message-ID: <1184601654.8894.12.camel@localhost.localdomain> On Mon, 2007-07-16 at 17:28 +0200, Emmanuel Seyman wrote: > * Andrew Overholt [16/07/2007 17:25] : > > > > Weird. This is what is in the specfile: > > > > Requires: icu4j-eclipse > = 3.6.1 > > I'm guessing that should read : > Requires: icu4j-eclipse >= 3.6.1 Thanks. I see Ben's already fixed it :) 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 hughsient at gmail.com Mon Jul 16 08:07:49 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 16 Jul 2007 09:07:49 +0100 Subject: rawhide doesn't have suspend - is this a bug or a feature for fedora 8? In-Reply-To: <64b14b300707140854x153a74exec1f7557cda7669c@mail.gmail.com> References: <64b14b300707140854x153a74exec1f7557cda7669c@mail.gmail.com> Message-ID: <1184573269.2228.2.camel@work> On Sat, 2007-07-14 at 17:54 +0200, Valent Turkovic wrote: > I see that rawhide doesn't have suspend or hibernate as an option. Can you open a bug please. > I have a issue with suspend in Fedora 7 (and also FC6) and that is > that it is the only opion that doesn't popup any dialog box and it > doesn't ask for confirmation - and it is the most "dangerous" option > because it is usually one with most failures. It's not dangerous, it works fine on many, many systems. > F7 has especially this problem because suspend/resume is broken[1]&[2] > currently and usually hitting suspend leaves users with a frozen > system. On your system... We're really waiting for pm-utils to be pushed from updates-testing to updates, and also for the 2.6.22 kernel to be packaged. > Will there be a suspend in F8? Will there be a some dialog box asking > for a confirmation or at least giving users some explanation that > there is some risk involved with suspend under fedora? Suspend and hibernate will of course be in F8, but with any unsupported product there may be bugs early in the development cycle. Richard, From lostson at lostsonsvault.org Mon Jul 16 17:07:34 2007 From: lostson at lostsonsvault.org (lostson) Date: Mon, 16 Jul 2007 12:07:34 -0500 Subject: pyGTK Message-ID: <1184605654.18448.2.camel@localhost.localdomain> Hello I am currently studying python and am enjoying it quite well along the way. I just happen to catch the update email today that pygtk2 is updated today and I saw this in the email Just about anything you can write in C with GTK+ you can write in Python with PyGTK (within reason), but with all the benefits of Python. My main concern here is the (within reason) what exactly does this mean ? Should I concentrate on another language instead of python. what are the limitations ? Thanks for any ideas and advice. -- LostSon http://www.lostsonsvault.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dan at danny.cz Mon Jul 16 17:21:23 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 16 Jul 2007 19:21:23 +0200 Subject: CD/DVD cataloging software Message-ID: <1184606483.4145.28.camel@eagle.danny.cz> Hello, I have spend this weekend with looking for a software that will catalogue content of CDs and DVDs (I want to know what file is on which CD/DVD). My requirements were simple - work current Fedora (>=6) and automagicly use the disc name when storing the content. As name version platform current use disc Fedora name gtktalog 1.0.4 C/gtk1 no ? gwhere 0.2.3 C/gtk1,gtk2 no* yes CdCat 1.01b C/qt no* no gnomecatalog 0.2.1 Python/gtk no ? cdcollect 0.6.0 Mono no ? * = can read content of the folder where the disc is mounted The main problem is that these softs are looking for CD/DVDs into a fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as it uses gnome-mount which uses HAL. Also most of them are dead or almost dead projects. As a result I have chosen gwhere for my usage. It required not so much effort to make it build and then work. You can find it at http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project looks quite promising, but I don't know how to integrate scanning of gnome-mounted (using HAL) discs. When some other solution exists (Beagle?), please let me know. Dan Horak -- Fedora maintainer: TinyERP, Code::Blocks, QGit, Tailor From tmz at pobox.com Mon Jul 16 17:22:28 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 16 Jul 2007 13:22:28 -0400 Subject: pyGTK In-Reply-To: <1184605654.18448.2.camel@localhost.localdomain> References: <1184605654.18448.2.camel@localhost.localdomain> Message-ID: <20070716172228.GQ13357@psilocybe.teonanacatl.org> lostson wrote: > I am currently studying python and am enjoying it quite well along > the way. I just happen to catch the update email today that pygtk2 > is updated today and I saw this in the email > > Just about anything you can write in C with GTK+ you can write in > Python with PyGTK (within reason), but with all the benefits of > Python. > > My main concern here is the (within reason) what exactly does this > mean ? Should I concentrate on another language instead of python. > what are the limitations ? Thanks for any ideas and advice. This is probably better asked (and answered) on the pygtk list: http://www.daa.com.au/mailman/listinfo/pygtk -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened. -- Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From alan at clueserver.org Mon Jul 16 17:35:00 2007 From: alan at clueserver.org (alan) Date: Mon, 16 Jul 2007 10:35:00 -0700 (PDT) Subject: CD/DVD cataloging software In-Reply-To: <1184606483.4145.28.camel@eagle.danny.cz> References: <1184606483.4145.28.camel@eagle.danny.cz> Message-ID: On Mon, 16 Jul 2007, Dan Hor?k wrote: > Hello, > > I have spend this weekend with looking for a software that will > catalogue content of CDs and DVDs (I want to know what file is on which > CD/DVD). My requirements were simple - work current Fedora (>=6) and > automagicly use the disc name when storing the content. As > > name version platform current use disc > Fedora name > gtktalog 1.0.4 C/gtk1 no ? > gwhere 0.2.3 C/gtk1,gtk2 no* yes > CdCat 1.01b C/qt no* no > gnomecatalog 0.2.1 Python/gtk no ? > cdcollect 0.6.0 Mono no ? > > * = can read content of the folder where the disc is mounted > > The main problem is that these softs are looking for CD/DVDs into a > fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as > it uses gnome-mount which uses HAL. Also most of them are dead or almost > dead projects. > > As a result I have chosen gwhere for my usage. It required not so much > effort to make it build and then work. You can find it at > http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project > looks quite promising, but I don't know how to integrate scanning of > gnome-mounted (using HAL) discs. > > When some other solution exists (Beagle?), please let me know. I have yet to find a good solution. Most of them seem to die when you throw a couple hundred DVDs of software archives at them. I will look at gwhere and see if it is any better. -- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox From lostson at lostsonsvault.org Mon Jul 16 17:35:56 2007 From: lostson at lostsonsvault.org (lostson) Date: Mon, 16 Jul 2007 12:35:56 -0500 Subject: pyGTK In-Reply-To: <20070716172228.GQ13357@psilocybe.teonanacatl.org> References: <1184605654.18448.2.camel@localhost.localdomain> <20070716172228.GQ13357@psilocybe.teonanacatl.org> Message-ID: <1184607356.19044.0.camel@localhost.localdomain> On Mon, 2007-07-16 at 13:22 -0400, Todd Zullinger wrote: > lostson wrote: > > I am currently studying python and am enjoying it quite well along > > the way. I just happen to catch the update email today that pygtk2 > > is updated today and I saw this in the email > > > > Just about anything you can write in C with GTK+ you can write in > > Python with PyGTK (within reason), but with all the benefits of > > Python. > > > > My main concern here is the (within reason) what exactly does this > > mean ? Should I concentrate on another language instead of python. > > what are the limitations ? Thanks for any ideas and advice. > > This is probably better asked (and answered) on the pygtk list: > > http://www.daa.com.au/mailman/listinfo/pygtk > Ok thanks for the link and info. -- LostSon http://www.lostsonsvault.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Mon Jul 16 17:48:10 2007 From: opensource at till.name (Till Maas) Date: Mon, 16 Jul 2007 19:48:10 +0200 Subject: python-elementree & F7? In-Reply-To: References: Message-ID: <200707161948.11735.opensource@till.name> On Mo Juli 16 2007, Zoltan Kota wrote: > On Mon, 16 Jul 2007, Zoltan Kota wrote: > > It seems python-elementtree is missing from F7 (and devel)! What is the > > reason? Maybe I missed something? > > Ooops. In the meantime I found that it is included in python-2.5. It is not completely included, e.g. repoview stopped working because something was missing. Regards, Till From dan at danny.cz Mon Jul 16 18:10:56 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 16 Jul 2007 20:10:56 +0200 Subject: CD/DVD cataloging software In-Reply-To: References: <1184606483.4145.28.camel@eagle.danny.cz> Message-ID: <1184609456.4145.34.camel@eagle.danny.cz> alan p??e v Po 16. 07. 2007 v 10:35 -0700: > On Mon, 16 Jul 2007, Dan Hor?k wrote: > > > Hello, > > > > I have spend this weekend with looking for a software that will > > catalogue content of CDs and DVDs (I want to know what file is on which > > CD/DVD). My requirements were simple - work current Fedora (>=6) and > > automagicly use the disc name when storing the content. As > > > > name version platform current use disc > > Fedora name > > gtktalog 1.0.4 C/gtk1 no ? > > gwhere 0.2.3 C/gtk1,gtk2 no* yes > > CdCat 1.01b C/qt no* no > > gnomecatalog 0.2.1 Python/gtk no ? > > cdcollect 0.6.0 Mono no ? > > > > * = can read content of the folder where the disc is mounted > > > > The main problem is that these softs are looking for CD/DVDs into a > > fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as > > it uses gnome-mount which uses HAL. Also most of them are dead or almost > > dead projects. > > > > As a result I have chosen gwhere for my usage. It required not so much > > effort to make it build and then work. You can find it at > > http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project > > looks quite promising, but I don't know how to integrate scanning of > > gnome-mounted (using HAL) discs. > > > > When some other solution exists (Beagle?), please let me know. > > I have yet to find a good solution. Most of them seem to die when you > throw a couple hundred DVDs of software archives at them. > > I will look at gwhere and see if it is any better. Probably not as it uses plain text files to store the catalogs. Dan From jwilson at redhat.com Mon Jul 16 18:17:05 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jul 2007 14:17:05 -0400 Subject: Heads up: kernel 2.6.23-0.14.rc0.git1.fc8 busted In-Reply-To: <469643B6.7040705@redhat.com> References: <469643B6.7040705@redhat.com> Message-ID: <469BB621.1050603@redhat.com> Jarod Wilson wrote: > With the transition to the new kernel rpm versioning scheme, we ended up > having to call things such as the pre-2.6.23-rc1 git kernels, which > upstream are 2.6.22-gitX, 2.6.23-rc0-gitX. However, I missed a tiny > detail, which leaves the kernel package showing 2.6.23, but the > resulting kernel's uname 2.6.22. Makes Bad Things happen with any kernel > in the 2.6.23-0.x.rc0.git1.fc8 range, where x is . Fixing now (in > theory, this is a simple fix by twiddling the kernel Makefile's > SUBLEVEL), will push a fixed build ASAP... Of course, Linus merged a ton of stuff, and now the latest git snapshots are currently not liking to actually compile, so we don't have a repaired kernel package out just yet. Sorry for the delay folks. The Man (davej) is working through the compile issues though, and hopes to have something relatively soon. Stay tuned... :) -- Jarod Wilson jwilson at redhat.com From notting at redhat.com Mon Jul 16 19:00:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Jul 2007 15:00:42 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184612492.17096.2.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> Message-ID: <20070716190042.GA29413@nostromo.devel.redhat.com> (redirecting to fedora-devel-list) Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > BTW it would be nice if our debuginfo macro made debuginfo packages > depend on the exact version of the package they've been created from. > > All too often debuginfo repositories are not in sync with the main > repositories so users get debuginfo packages installed for the wrong > version of the on-system packages. The problem with that is that someone who runs 'debuginfo-install', even once, is left with an un-upgradeable system, without manual intervention. Bill From nicolas.mailhot at laposte.net Mon Jul 16 19:12:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jul 2007 21:12:43 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <20070716190042.GA29413@nostromo.devel.redhat.com> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> Message-ID: <1184613163.17096.7.camel@rousalka.dyndns.org> Le lundi 16 juillet 2007 ? 15:00 -0400, Bill Nottingham a ?crit : > (redirecting to fedora-devel-list) > > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > BTW it would be nice if our debuginfo macro made debuginfo packages > > depend on the exact version of the package they've been created from. > > > > All too often debuginfo repositories are not in sync with the main > > repositories so users get debuginfo packages installed for the wrong > > version of the on-system packages. > > The problem with that is that someone who runs 'debuginfo-install', even > once, is left with an un-upgradeable system, without manual intervention. well presumably someone who installed debuginfo packages wants them to be useful and not updated separately from the rest of the distro It's very annoying to install debuginfo packages with the aim to produce a nice stack for upstream, and find out when you actually manage to trigger the bug debuginfo packages are out of sync and yum happily updated the rest of the system without taking them into account -- 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 dan at danny.cz Mon Jul 16 19:26:48 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 16 Jul 2007 21:26:48 +0200 Subject: CD/DVD cataloging software In-Reply-To: <1184606483.4145.28.camel@eagle.danny.cz> References: <1184606483.4145.28.camel@eagle.danny.cz> Message-ID: <1184614008.4145.37.camel@eagle.danny.cz> Dan Hor?k p??e v Po 16. 07. 2007 v 19:21 +0200: > Hello, > > I have spend this weekend with looking for a software that will > catalogue content of CDs and DVDs (I want to know what file is on which > CD/DVD). My requirements were simple - work current Fedora (>=6) and > automagicly use the disc name when storing the content. As > > name version platform current use disc > Fedora name > gtktalog 1.0.4 C/gtk1 no ? > gwhere 0.2.3 C/gtk1,gtk2 no* yes > CdCat 1.01b C/qt no* no > gnomecatalog 0.2.1 Python/gtk no ? > cdcollect 0.6.0 Mono no ? > > * = can read content of the folder where the disc is mounted > > The main problem is that these softs are looking for CD/DVDs into a > fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as > it uses gnome-mount which uses HAL. Also most of them are dead or almost > dead projects. > > As a result I have chosen gwhere for my usage. It required not so much > effort to make it build and then work. You can find it at > http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project > looks quite promising, but I don't know how to integrate scanning of > gnome-mounted (using HAL) discs. Looks like I have found a way to make cdcollect work. Stay tuned ;-) Dan From sundaram at fedoraproject.org Mon Jul 16 20:08:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Jul 2007 01:38:20 +0530 Subject: any chance to see kernel 2.6.22 for FC6? In-Reply-To: <1184595521.469b7e417cbb1@imp.free.fr> References: <1184595521.469b7e417cbb1@imp.free.fr> Message-ID: <469BD034.603@fedoraproject.org> jfontain at free.fr wrote: > I'd like to try to get some more battery life out of my laptop... > See the mail in fedora-test list. 2.6.22 based kernel has been pushed into updates-testing repository. Rahul From stickster at gmail.com Mon Jul 16 20:16:08 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 16 Jul 2007 16:16:08 -0400 Subject: Video and Keymap Quirks In-Reply-To: <1184317087.2382.8.camel@work> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <20070711200558.GF9945@humbolt.us.dell.com> <1184185794.2241.7.camel@work> <20070712180051.GD24045@humbolt.us.dell.com> <1184271656.2359.7.camel@work> <20070712215956.GD28549@humbolt.us.dell.com> <1184317087.2382.8.camel@work> Message-ID: <1184616968.8813.1.camel@localhost.localdomain> On Fri, 2007-07-13 at 09:58 +0100, Richard Hughes wrote: > > Writing software that just assumes that the killswitch can only ever do > > an all-or-nothing operation is encoding bad policy in our software. > > I disagree. Getting on a plane and switching the kill switch to off, > only to find it's only disabled the bluetooth and not the wlan is a > totally bad design decision in my opinion. Not to mention which, it would make life harder on users working in office areas where transmitters must be demonstrably disabled. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Jul 16 20:42:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Jul 2007 16:42:41 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184613163.17096.7.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> Message-ID: <20070716204241.GB30896@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > The problem with that is that someone who runs 'debuginfo-install', even > > once, is left with an un-upgradeable system, without manual intervention. > > well presumably someone who installed debuginfo packages wants them to > be useful and not updated separately from the rest of the distro Sure, but debuginfo-install works *without* changing the repo definition. So your upgrade will fail, as the newer version of XYZ won't upgrade because the debuginfo repo isn't active. Bill From roland at redhat.com Mon Jul 16 20:53:48 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 16 Jul 2007 13:53:48 -0700 (PDT) Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: Bill Nottingham's message of Monday, 16 July 2007 16:42:41 -0400 <20070716204241.GB30896@nostromo.devel.redhat.com> Message-ID: <20070716205348.5138F4D05BE@magilla.localdomain> > Sure, but debuginfo-install works *without* changing the repo definition. > So your upgrade will fail, as the newer version of XYZ won't upgrade because > the debuginfo repo isn't active. It would be kewl if yum told you "unhappy rpm comes from no repo in use". I suppose you can't really tell now that if the sometimes the installed version of an updates rpm is no longer in the updates repo. The second suggestion is that yum et al store in some yum cache info somewhere which repo each install rpm came from. Then in various things it tells you about that rpm, it can mention which repo it came from and draw your attention to it being a disabled one if it is. Thanks, Roland From nicolas.mailhot at laposte.net Mon Jul 16 21:06:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Jul 2007 23:06:27 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <20070716204241.GB30896@nostromo.devel.redhat.com> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> <20070716204241.GB30896@nostromo.devel.redhat.com> Message-ID: <1184619987.19754.3.camel@rousalka.dyndns.org> Le lundi 16 juillet 2007 ? 16:42 -0400, Bill Nottingham a ?crit : > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > The problem with that is that someone who runs 'debuginfo-install', even > > > once, is left with an un-upgradeable system, without manual intervention. > > > > well presumably someone who installed debuginfo packages wants them to > > be useful and not updated separately from the rest of the distro > > Sure, but debuginfo-install works *without* changing the repo definition. > So your upgrade will fail, as the newer version of XYZ won't upgrade because > the debuginfo repo isn't active. The usual problem is not debuginfo is not active but it's mirrored several hours after the main repo so without version-lock debuginfo packages are not in sync with main packages even though it's active IMHO if you don't want debuginfo packages to block a debuginfo-uninstall utility should be provided, letting packages rot this way strikes me as a particularly bad compromise. (btw I don't see how debuginfo-install would have worked in the first place if the debug repo was not active) -- 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 skvidal at linux.duke.edu Mon Jul 16 21:15:31 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 16 Jul 2007 17:15:31 -0400 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184619987.19754.3.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> <20070716204241.GB30896@nostromo.devel.redhat.com> <1184619987.19754.3.camel@rousalka.dyndns.org> Message-ID: <1184620531.606.15.camel@cutter> On Mon, 2007-07-16 at 23:06 +0200, Nicolas Mailhot wrote: > Le lundi 16 juillet 2007 ? 16:42 -0400, Bill Nottingham a ?crit : > > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > > The problem with that is that someone who runs 'debuginfo-install', even > > > > once, is left with an un-upgradeable system, without manual intervention. > > > > > > well presumably someone who installed debuginfo packages wants them to > > > be useful and not updated separately from the rest of the distro > > > > Sure, but debuginfo-install works *without* changing the repo definition. > > So your upgrade will fail, as the newer version of XYZ won't upgrade because > > the debuginfo repo isn't active. > > The usual problem is not debuginfo is not active but it's mirrored > several hours after the main repo so without version-lock debuginfo > packages are not in sync with main packages even though it's active > > IMHO if you don't want debuginfo packages to block a debuginfo-uninstall > utility should be provided, letting packages rot this way strikes me as > a particularly bad compromise. > > (btw I don't see how debuginfo-install would have worked in the first > place if the debug repo was not active) debuginfo-install activates the debug repos as it goes. -sv From Lam at Lam.pl Mon Jul 16 21:34:49 2007 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 16 Jul 2007 23:34:49 +0200 Subject: Rawhide debuginfo package problems 2007-07-16 In-Reply-To: <1184619987.19754.3.camel@rousalka.dyndns.org> References: <200707162148.57545.ville.skytta@iki.fi> <1184612492.17096.2.camel@rousalka.dyndns.org> <20070716190042.GA29413@nostromo.devel.redhat.com> <1184613163.17096.7.camel@rousalka.dyndns.org> <20070716204241.GB30896@nostromo.devel.redhat.com> <1184619987.19754.3.camel@rousalka.dyndns.org> Message-ID: <20070716233449.50ba375d@pensja.lam.pl> Dnia 2007-07-16, o godz. 23:06:27 Nicolas Mailhot napisa?(a): > (btw I don't see how debuginfo-install would have worked in the first > place if the debug repo was not active) It does this temporarily, using something like: yum --enablerepo=*-debuginfo install ... If glibc-debuginfo-2.6-1 needs glibc = 2.6-1 and glibc-2.6-2 enters updates, glibc can't get updated without removing/updating glibc-debuginfo. The optimal way would be to change rpmdb so that it stores whether debuginfo package is installed for a given package. Then yum would automatically guess, when to re-enable debuginfo repository to update debuginfo packages along with their parents. Or you can simply write a yum plugin working with the same algorithm as debuginfo-install (based on names and some set of built-in special rules for kernels). We can ship the plugin, but leave it disabled by default. Then, debuginfo-install would also enable the plugin for future upgrading of debuginfo'd packages. Think about it. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lists-gawain at felicity-group.com Mon Jul 16 21:39:31 2007 From: lists-gawain at felicity-group.com (Gawain Lynch) Date: Tue, 17 Jul 2007 07:39:31 +1000 Subject: rawhide can't update because of anaconda (libdhcp4client-3.0.5.so.0) In-Reply-To: References: <64b14b300707140517g2a5d03bbg5cffe1583c9e7436@mail.gmail.com> <1184419313.2822.15.camel@dawkins> <64b14b300707140700w5cf05e25l78232c6992e87a08@mail.gmail.com> <1184482001.3769.3.camel@legolas.felicity-group.com> Message-ID: <1184621972.6008.2.camel@legolas.felicity-group.com> On Sun, 2007-07-15 at 20:48 +0000, Kevin Kofler wrote: > Gawain Lynch felicity-group.com> writes: > > Rawhide eats babies and kills sweet little kittens, as such is generally > > not for "users". Later test releases (-test3/-test4) are aimed for the > > less technically inclined who wish to preview upcoming releases. > > No test4 is planned for Fedora 8, that was just added for Fedora 7 to allow the > Core-Extras Merge to happen. (Originally, this was supposed to allow it to > happen before the feature freeze, at the end, it actually happened after > test4!) > While that is correct, my point is about later releases. Just because one is not planned does not mean there will not be one again. From jwilson at redhat.com Mon Jul 16 21:47:44 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jul 2007 17:47:44 -0400 Subject: Heads up: kernel 2.6.23-0.14.rc0.git1.fc8 busted In-Reply-To: <469BB621.1050603@redhat.com> References: <469643B6.7040705@redhat.com> <469BB621.1050603@redhat.com> Message-ID: <469BE780.9010205@redhat.com> > Jarod Wilson wrote: >> With the transition to the new kernel rpm versioning scheme, we ended = up >> having to call things such as the pre-2.6.23-rc1 git kernels, which >> upstream are 2.6.22-gitX, 2.6.23-rc0-gitX. However, I missed a tiny >> detail, which leaves the kernel package showing 2.6.23, but the >> resulting kernel's uname 2.6.22. Makes Bad Things happen with any kern= el >> in the 2.6.23-0.x.rc0.git1.fc8 range, where x is . Fixing now (in >> theory, this is a simple fix by twiddling the kernel Makefile's >> SUBLEVEL), will push a fixed build ASAP... >=20 > Of course, Linus merged a ton of stuff, and now the latest git snapshot= s > are currently not liking to actually compile, so we don't have a > repaired kernel package out just yet. Sorry for the delay folks. The Ma= n > (davej) is working through the compile issues though, and hopes to have= > something relatively soon. Stay tuned... :) kernel 2.6.23-0.28.rc0.git6.fc8 is built and boot tested on a few systems. The uname mismatch is indeed fixed, though the hpet hang on some ich systems is still present (workaround by booting w/nohpet). Should hit rawhide trees tomorrow... --=20 Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Mon Jul 16 21:55:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Jul 2007 03:25:16 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> Message-ID: <469BE944.1010305@fedoraproject.org> Debarshi 'Rishi' Ray wrote: > I hereby announce the release of the Fedora Offline Package Manager > (RUM) 0.0.1. > You might want to consider renaming this. Rum (though not actively maintained) is a yum based program that existed before your project and it is not very courteous to knowingly start a new project with the same name and cause name conflicts if we want both the old rum and new rum in the repository. > If you are interested then you can read more about it at > https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay > > This is a beta release and offers the following features: > > 1. Profile management: > a. Exporting the profile of the local system. > b. Importing the profile of another system. > c. Deleting existing profiles. I am not sure I understand the need for profiles. > 2. YumPack creation > - Although I have tested this to the best of my ability, I would > appreciate if you could try to create new YumPacks and verify whether > the dependencies are being correctly resolved. Do you have any documentation on creating yum packs? > To install package(s) from a YumPack, you would need to untar the > YumPack, which is essentially an uncompressed Tar archive, and use > 'system-install-packages' to install the RPMs as you would normally > do. Why uncompressed? Do you plan on GUI integration of yum packs to system-install-packages directly? Is there any integration with Presto? I would appreciate if you can provide a rpm package for testing. Thanks for working on this. Rahul --- FYI, In 09/10/2005 05:53 AM, I send a mail to Paul Nasrat and Seth Vidal the following mail without any response. subject: Yum package archive Hi Here is an idea for a tool that would create a yum package archive which is basically a set of RPMS and its dependencies into a bz2 or gzip tarball that are not in Fedora Core itself. Use case 1: I would like to send distribute XFCE for Fedora Core 4 to a friend who is on a dialup connection and a I am running Fedora Core 3. Now I have to figure out XFCE all its dependencies from Fedora Extras repository and then burn into a CD and send it off Use Case 2 A magazine wants to distribute all the Fedora Core 4 updates and users want to update only stuff that they have already installed A GUI (ideally system-config-packages itself in Fedora) would extract this archive and install all the packages. For the second use case, it would prompt for package updates. It can also have the ability to prompt for the CD/DVD to satisfy dependencies regards Rahul From kwizart at gmail.com Mon Jul 16 22:40:35 2007 From: kwizart at gmail.com (KH KH) Date: Tue, 17 Jul 2007 00:40:35 +0200 Subject: firewire (juju) (was: any chance to see kernel 2.6.22 for FC6?) Message-ID: 2007/7/16, Rahul Sundaram : > jfontain at free.fr wrote: > > I'd like to try to get some more battery life out of my laptop... > > > > See the mail in fedora-test list. 2.6.22 based kernel has been pushed > into updates-testing repository. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Well the problem with 2.6.22 in Fedora Core 6 is that it will bring some changes... Actually eth1394.ko and libdc1394(-1) applications that are not currently compatible with libdc1394-2 (with support for the new firewire juju stack) will enter in regression... Whereas users can possibly be aware of thoses regressions in Fedora 7, some can be surprised of that in Fedora Core 6... I don't mean we need to hold kernel update, but how can we prevent thoses issues ? Some links: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239043 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239184 Nicolas (kwizart) From sundaram at fedoraproject.org Mon Jul 16 22:48:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Jul 2007 04:18:23 +0530 Subject: firewire (juju) (was: any chance to see kernel 2.6.22 for FC6?) In-Reply-To: References: Message-ID: <469BF5B7.70907@fedoraproject.org> KH KH wrote: > Well the problem with 2.6.22 in Fedora Core 6 is that it will bring > some changes... > Actually eth1394.ko and libdc1394(-1) applications that are not > currently compatible with libdc1394-2 (with support for the new > firewire juju stack) will enter in regression... > Whereas users can possibly be aware of thoses regressions in Fedora 7, > some can be surprised of that in Fedora Core 6... > > I don't mean we need to hold kernel update, but how can we prevent > thoses issues ? Have you tested the kernel in updates-testing repository and confirmed that the issues still exist? Is there any bug reports on these aside from the pending package review requests you brought up? If the issues still exist we can either fix them or note it in the change log. Rahul From trever.adams at gmail.com Mon Jul 16 22:54:21 2007 From: trever.adams at gmail.com (Trever L. Adams) Date: Mon, 16 Jul 2007 16:54:21 -0600 Subject: Squid 3 Message-ID: <469BF71D.5050506@gmail.com> I was just wondering if it would be time to include squid 3. They are saying release around November. Trever From kwizart at gmail.com Mon Jul 16 23:15:54 2007 From: kwizart at gmail.com (KH KH) Date: Tue, 17 Jul 2007 01:15:54 +0200 Subject: firewire (juju) (was: any chance to see kernel 2.6.22 for FC6?) In-Reply-To: <469BF5B7.70907@fedoraproject.org> References: <469BF5B7.70907@fedoraproject.org> Message-ID: 2007/7/17, Rahul Sundaram : > KH KH wrote: > > > Well the problem with 2.6.22 in Fedora Core 6 is that it will bring > > some changes... > > Actually eth1394.ko and libdc1394(-1) applications that are not > > currently compatible with libdc1394-2 (with support for the new > > firewire juju stack) will enter in regression... > > Whereas users can possibly be aware of thoses regressions in Fedora 7, > > some can be surprised of that in Fedora Core 6... > > > > I don't mean we need to hold kernel update, but how can we prevent > > thoses issues ? > > Have you tested the kernel in updates-testing repository and confirmed > that the issues still exist? Is there any bug reports on these aside > from the pending package review requests you brought up? If the issues > still exist we can either fix them or note it in the change log. Yes indeed i'm testing it... (eth1394.ko is not avaible anymore...) Actually headers for juju firewire stack seems to be needed by libdc1394-2: ----------- gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -Idc1394/juju -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -Wunused -MT control.lo -MD -MP -MF .deps/control.Tpo -c control.c -fPIC -DPIC -o .libs/control.o In file included from capture.c:35: ../juju/juju.h:23:28: error: fw-device-cdev.h: No such file or directory capture.c:36:26: error: juju/capture.h: No such file or directory capture.c: In function 'init_frame': ----------- They are not provided by kernel-headers nor kernel-devel: [root at Kwizatz noarch]# rpm -q kernel-headers kernel-headers-2.6.22.1-15.fc6 [root at Kwizatz noarch]# rpm -ql kernel-headers |grep juju [root at Kwizatz noarch]# rpm -ql kernel-devel |grep juju Any advices ? Nicolas (kwizart) > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From neugens at limasoftware.net Mon Jul 16 23:37:49 2007 From: neugens at limasoftware.net (Mario Torre) Date: Tue, 17 Jul 2007 01:37:49 +0200 Subject: rawhide report: 20070716 changes In-Reply-To: <200707160924.l6G9OT2I022214@porkchop.devel.redhat.com> References: <200707160924.l6G9OT2I022214@porkchop.devel.redhat.com> Message-ID: <1184629069.16566.3.camel@nirvana.limasoftware.net> Il giorno lun, 16/07/2007 alle 05.24 -0400, Build System ha scritto: > f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 Hey! Anyone is working on that? I know mono is evil... but this is a good application that we use to show people how linux works, but now it does not work anymore... News on how to solve? Thanks, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: neugens at jabber.org pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From buildsys at fedoraproject.org Tue Jul 17 00:03:42 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 Jul 2007 20:03:42 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-16 Message-ID: <20070717000342.82DA1152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 25 NEW ftgl-2.1.2-5.fc6 : OpenGL frontend to Freetype 2 fuse-emulator-0.8.0.1-2.fc6 fuse-emulator-utils-0.8.0.1-1.fc6 NEW gdesklets-quote-of-the-day-0.61-3.fc6 : Quote of the day desklet for gdesklet geda-docs-20070708-1.fc6 geda-examples-20070708-1.fc6 geda-gattrib-20070708-1.fc6 geda-gnetlist-20070708-1.fc6 geda-gschem-20070708-1.fc6 geda-gsymcheck-20070708-1.fc6 geda-symbols-20070708-1.fc6 geda-utils-20070708-1.fc6 NEW gnome-specimen-0.2-4.fc6 : A simple tool to view and compare fonts installed on your system gnubiff-2.2.7-1.fc6 NEW hdhomerun-0.0-0.2.20070616.fc6 : HDHomeRun configuration utility libgeda-20070708-1.fc6 libspectrum-0.3.0.1-2.fc6 mksh-29g-1.fc6 NEW naturette-1.3-1.fc6 : Naturette, an AGI adventure game (!) qgis-0.8.1-11.fc6 : INVALID rebuild, not published! qtpfsgui-1.8.10-2.fc6 NEW R-widgetTools-1.12.0-12.fc6 : Tools to support the construction of tcltk widgets redland-1.0.5-4.fc6 NEW soprano-0.9.0-2.fc6 : Qt wrapper API to different RDF storage solutions NEW sub2srt-0.5.3-2.fc6 : Convert files in .sub format to .srt Changes in Fedora Extras 6: ftgl-2.1.2-5.fc6 ---------------- * Sat Jul 14 2007 kwizart < kwizart at gmail.com > - 2.1.2-5 - Fix version field the whole package * Fri Jul 13 2007 kwizart < kwizart at gmail.com > - 2.1.2-4 - Modified ftgl-2.1.2-pc_req.patch - Add Requires freefont to -utils * Fri Jul 13 2007 kwizart < kwizart at gmail.com > - 2.1.2-3 - Add Requirements for -devel - Preserve timestramp for install step - Add ftgl-utils to prevent conflict with multilibs Add patch to prevent rpath fuse-emulator-0.8.0.1-2.fc6 --------------------------- * Sun Jul 15 2007 Ian Chapman 0.8.0.1-2 - Filter unwanted dependancies dragged in by rpm (BZ #248265) * Sat Jun 30 2007 Ian Chapman 0.8.0.1-1 - Upgrade to 0.8.0.1 - Various cleanups to the SPEC including conforming to new guidelines fuse-emulator-utils-0.8.0.1-1.fc6 --------------------------------- * Sat Jul 07 2007 Ian Chapman 0.8.0.1-1.fc6 - Upgrade to 0.8.0.1 - Various cleanups to the SPEC including conforming to new guidelines gdesklets-quote-of-the-day-0.61-3.fc6 ------------------------------------- * Sun Jul 08 2007 Tyler Owen - 0.61-3 - Clean up Spec file * Sun Jul 08 2007 Tyler Owen - 0.61-2 - Added -p option to install to preserve timestamps - Fixed missing directory ownership issues * Sun Jun 24 2007 Tyler Owen - 0.61-1 - Initial Packaging for Fedora geda-docs-20070708-1.fc6 ------------------------ * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-examples-20070708-1.fc6 ---------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gattrib-20070708-1.fc6 --------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release * Wed Jun 27 2007 Chitlesh Goorah - 20070626-2 - removed version from the desktop file geda-gnetlist-20070708-1.fc6 ---------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gschem-20070708-1.fc6 -------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-gsymcheck-20070708-1.fc6 ----------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-symbols-20070708-1.fc6 --------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release geda-utils-20070708-1.fc6 ------------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release gnome-specimen-0.2-4.fc6 ------------------------ * Wed Jul 11 2007 Damien Durand - 0.2-4 - Fix desktop-file section * Wed Jun 27 2007 Damien Durand - 0.2-3 - Fix owned directories gnubiff-2.2.7-1.fc6 ------------------- * Sun Jul 15 2007 Damien Durand - 2.2.7-1 - Updade to 2.2.7 * Sat Mar 10 2007 Damien Durand - 2.2.6-1 - Updade to 2.2.6 * Sat Mar 10 2007 Damien Durand - 2.2.5-3 - Bumped hdhomerun-0.0-0.2.20070616.fc6 ------------------------------ * Thu Jul 12 2007 Jarod Wilson 0.0-0.2.20070616 - Use sed instead of perl, drop perl BR: (jeff at ocjtech.us) - Convert source files to utf8 (jeff at ocjtech.us) * Mon Jun 18 2007 Jarod Wilson 0.0-0.1.20070616 - Update to 20070616 release - Don't install any of the header files and drop lib from the package name, since this really isn't a library libgeda-20070708-1.fc6 ---------------------- * Sat Jul 14 2007 Chitlesh Goorah - 20070708-1 - New upstream release libspectrum-0.3.0.1-2.fc6 ------------------------- * Sat Jun 30 2007 Ian Chapman 0.3.0.1-2.fc6 - Release bump * Sat Jun 30 2007 Ian Chapman 0.3.0.1-1.fc6 - Upgrade to 0.3.0.1 - Changes to spec due to new guidelines mksh-29g-1.fc6 -------------- * Sat Jul 14 2007 Robert Scheck 29g-1 - Upgrade to 29g naturette-1.3-1.fc6 ------------------- * Wed Jul 11 2007 Jon Ciesla 1.3-1 - Initial packaging. qgis-0.8.1-11.fc6 ----------------- * Tue Jul 10 2007 Douglas E. Warner 0.8.1-11 - allowing docs to be installed by qgis so they can be referenced by internal help system (bug#241403) - updated lib64 patch (bug#247549) to try to get plugins found on x86_64 qtpfsgui-1.8.10-2.fc6 --------------------- * Sat Jul 14 2007 Douglas E. Warner 1.8.10-2 - bump for new sources file * Sat Jul 14 2007 Douglas E. Warner 1.8.10-1 - update to version 1.8.10 - removed i18n patch (applied upstream) R-widgetTools-1.12.0-12.fc6 --------------------------- * Tue Jul 10 2007 Pingou 1.12.0-12 - Add the requires on R * Thu Jul 05 2007 Pingou 1.12.0-11 - Change in the post * Thu Jul 05 2007 Pingou 1.12.0-10 - Put the man pages as doc - Correction on the post and postun macro (to fit with the new R packaging guidelines) * Tue Jul 03 2007 Pingou 1.12.0-9 - Test on the postun * Tue Jul 03 2007 Pingou 1.12.0-8 - Change in the files section to add the dir * Sun Jul 01 2007 Pingou 1.12.0-7 - Change in the files section * Sat Jun 30 2007 Pingou 1.12.0-6 - Mark the html file as doc file * Wed Jun 27 2007 Pingou 1.12.0-5 - Remove the DESCRIPTION file in /R/library * Tue Jun 26 2007 Pingou 1.12.0-4 - Change _libdir to _datadir as it is a noarch package * Mon Jun 25 2007 Pingou 1.12.0-3 - Change de %doc to avoid redundancy redland-1.0.5-4.fc6 ------------------- * Sat Jul 14 2007 Kevin Kofler 1.0.5-4 - get rid of redland-config dependency bloat too (#248106) * Sat Jul 14 2007 Kevin Kofler 1.0.5-3 - fix bug number in changelog * Sat Jul 14 2007 Kevin Kofler 1.0.5-2 - add missing Requires: pkgconfig to the -devel package - get rid of pkgconfig dependency bloat (#248106) soprano-0.9.0-2.fc6 ------------------- * Sun Jul 15 2007 Rex Dieter 0.9.0-2 - BR: cmake (doh) * Wed Jun 27 2007 Rex Dieter 0.9.0-1 - soprano-0.9.0 - first try sub2srt-0.5.3-2.fc6 ------------------- * Sat Jul 14 2007 Marek Mahut - 0.5.3-2 - Rebuild * Fri Jun 29 2007 Marek Mahut - 0.5.3-1 - First build For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From kevin.kofler at chello.at Tue Jul 17 01:46:25 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 17 Jul 2007 01:46:25 +0000 (UTC) Subject: Disabling brp-strip for mock builds? References: <97cbd1a90707160909u1282f4b4sfd326b41600a5a5d@mail.gmail.com> Message-ID: Josh Kelley gmail.com> writes: > What do I need to do to properly disable brp-strip for mock builds? Does something like this work? %define __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib/rpm/[^/]*/?brp-strip %{__strip}!!g') Kevin Kofler From debarshi.ray at gmail.com Tue Jul 17 01:58:09 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 17 Jul 2007 07:28:09 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <469BE944.1010305@fedoraproject.org> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> Message-ID: <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> > You might want to consider renaming this. That is why I stressed on "Fedora Offline Package Manager" and put "RUM" in the parenthesis. I could not directly remove "RUM" since a few people had come to call it by that name. If you have any suggestions for a new name, please let me know. :-) >> 1. Profile management: >> a. Exporting the profile of the local system. >> b. Importing the profile of another system. >> c. Deleting existing profiles. > I am not sure I understand the need for profiles. Say you are the only person with an internet connection in your entire friend circle, which has many Fedora users. So while creating YumPacks for each of your friends, you need to know how their rpmdb looks like. That way you only put what is missing on the target machine in the YumPack. The "profile" is nothing but an archive containing the /var/lib/rpm directory. Of course you may want to create a single large YumPack containing all the dependencies of a package irrespective of what the target machine already has. ie., if you are trying to create a YumPack for Totem, it should include Gtk, Gstreamer, etc.. even if your friend has it. You can do this by creating a "new" profile, which would essentially be an empty rpmdb. I have kept this feature out of this release, since the focus was on a low feature-set, yet stably functional application. If there are no major bugs found in 0.0.1, I will tryo to put this in 0.0.2. >> 2. YumPack creation >> - Although I have tested this to the best of my ability, I would >> appreciate if you could try to create new YumPacks and verify whether >> the dependencies are being correctly resolved. > Do you have any documentation on creating yum packs? All the documentation till now were based on the first couple of prototypes which were basically CLI utilities. You can read about the first prototype (rum.sh) at http://www.ilug-cal.org/wiki/index.php/RUM I am writing the documentation for the GUI application https://fedoraproject.org/wiki/DebarshiRay/rum but it is not yet finished. >> To install package(s) from a YumPack, you would need to untar the >> YumPack, which is essentially an uncompressed Tar archive, and use >> 'system-install-packages' to install the RPMs as you would normally > > do. > Why uncompressed? No particular reason, except that on Fedora Core 6 compressed archives of the rpmdb would lead to strange behaviour. Thus I am trying to stay clean of any compressed archive. > Do you plan on GUI integration of yum packs to system-install-packages directly? Yes, and probably some collaboration with RevISOr too. The idea is to have something similar to APTonCD. I need to discuss these with my GSoC 2007 mentor too. > Is there any integration with Presto? Don't know, since I have not yet tried out Presto. > I would appreciate if you can provide a rpm package for testing. Thanks > for working on this. Okay, but one can still install it from source for the time being. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Tue Jul 17 02:26:08 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 17 Jul 2007 07:56:08 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> Message-ID: <3170f42f0707161926i5c303c69w2880e0a0fe53cfd6@mail.gmail.com> >> I would appreciate if you can provide a rpm package for testing. Thanks >> for working on this. > Okay, but one can still install it from source for the time being. On second thoughts, creating a RPM may not be possible since one has to patch /usr/lib/python2.5/site-packages/__init__.py for the Offline Package Manager to work. The patch does not disrupt the normal behaviour of Pirut and has been accepted by Jeremy Katz, but it will only appear in Pirut 1.3.9. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jeff at ocjtech.us Tue Jul 17 02:53:16 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 16 Jul 2007 21:53:16 -0500 Subject: Squid 3 In-Reply-To: <469BF71D.5050506@gmail.com> References: <469BF71D.5050506@gmail.com> Message-ID: <1184640796.3644.7.camel@lt21223.campus.dmacc.edu> On Mon, 2007-07-16 at 16:54 -0600, Trever L. Adams wrote: > I was just wondering if it would be time to include squid 3. They are > saying release around November. Sounds more like a candidate for F9 to me - the F8 feature freeze is set for 28 August 2007. 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 kevin.kofler at chello.at Tue Jul 17 03:31:10 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 17 Jul 2007 03:31:10 +0000 (UTC) Subject: Squid 3 References: <469BF71D.5050506@gmail.com> <1184640796.3644.7.camel@lt21223.campus.dmacc.edu> Message-ID: Jeffrey C. Ollie ocjtech.us> writes: > Sounds more like a candidate for F9 to me - the F8 feature freeze is set > for 28 August 2007. But if there's beta releases, they could get into Rawhide right now, and gradually upgraded to the final. That's what we're doing for KDE 4. Kevin Kofler From petersen at redhat.com Tue Jul 17 05:30:52 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 17 Jul 2007 15:30:52 +1000 Subject: unfiled merge reviews Message-ID: <469C540C.2020005@redhat.com> Hi, I am wondering what to do about former Core packages without merge reviews. I am aware of a number of i18n (input method) related packages without merge reviews (anthy, libchewing, m17n-db, and m17n-lib). There are surely more in the distro. Should merge review bugs be opened for them? One reason for asking is that I would like to build the above packages for EPEL EL-4 and presumably the package need to be reviewed for that? Jens From debarshi.ray at gmail.com Tue Jul 17 06:24:00 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 17 Jul 2007 11:54:00 +0530 Subject: glade3 in fedora7 In-Reply-To: <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> <467E95A5.2060506@fedoraproject.org> <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> Message-ID: <3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com> What is the current status on Glade3 packaging? Is Damien or Xavier trying to package it? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From giallu at gmail.com Tue Jul 17 07:13:44 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 17 Jul 2007 09:13:44 +0200 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> Message-ID: On 7/17/07, Debarshi 'Rishi' Ray wrote: > > You might want to consider renaming this. > > That is why I stressed on "Fedora Offline Package Manager" and put > "RUM" in the parenthesis. I could not directly remove "RUM" since a > few people had come to call it by that name. > > If you have any suggestions for a new name, please let me know. :-) RHUM ? From sean.bruno at dsl-only.net Tue Jul 17 07:15:59 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue, 17 Jul 2007 00:15:59 -0700 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> Message-ID: <1184656559.3383.0.camel@home-desk> On Tue, 2007-07-17 at 09:13 +0200, Gianluca Sforna wrote: > On 7/17/07, Debarshi 'Rishi' Ray wrote: > > > You might want to consider renaming this. > > > > That is why I stressed on "Fedora Offline Package Manager" and put > > "RUM" in the parenthesis. I could not directly remove "RUM" since a > > few people had come to call it by that name. > > > > If you have any suggestions for a new name, please let me know. :-) > > RHUM ? > I'm shocked that nobody has suggested REDRUM yet. :) Sean From nicolas.mailhot at laposte.net Tue Jul 17 07:26:06 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 17 Jul 2007 09:26:06 +0200 (CEST) Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> Message-ID: <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> Le Mar 17 juillet 2007 09:13, Gianluca Sforna a ?crit : > On 7/17/07, Debarshi 'Rishi' Ray wrote: >> > You might want to consider renaming this. >> >> That is why I stressed on "Fedora Offline Package Manager" and put >> "RUM" in the parenthesis. I could not directly remove "RUM" since a >> few people had come to call it by that name. >> >> If you have any suggestions for a new name, please let me know. :-) > > RHUM ? RHUME! (French joke, sorry) -- Nicolas Mailhot From tla at rasmil.dk Tue Jul 17 08:18:13 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 17 Jul 2007 10:18:13 +0200 Subject: glade3 in fedora7 In-Reply-To: <3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com> References: <1182662333.5754.2.camel@localhost.localdomain> <76e72f800706240105r345b9f2en5cdbadb51ac71631@mail.gmail.com> <9F8E9EF3-0AB5-4218-89E1-AF407A391B32@rubenkerkhof.com> <1182676374.7266.2.camel@localhost.localdomain> <467E95A5.2060506@fedoraproject.org> <62bc09df0706240934h1174d578hc4429ffda5f5dcb2@mail.gmail.com> <3170f42f0707162324v54502a43kae6e2dcd88f79240@mail.gmail.com> Message-ID: <469C7B45.4070407@rasmil.dk> Debarshi 'Rishi' Ray wrote: > What is the current status on Glade3 packaging? Is Damien or Xavier > trying to package it? > > Regards, > Debarshi Xavier have created a package here [1], but i don't know if he has requested a package review yet. I have used it for a while, i have found any problems yet. Tim [1]: http://download.tuxfamily.org/lxtnow/fedora/testing/7 From debarshi.ray at gmail.com Tue Jul 17 08:20:37 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 17 Jul 2007 13:50:37 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> Message-ID: <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> What about Opium? Pirut (pronounced 'pirate') stands for Package Installation, Removal & Update Tool. Opium can be Offline Package Installation & Update Manager. The offline tool may be rarely used to remove a package. Cheerio, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tla at rasmil.dk Tue Jul 17 08:28:03 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 17 Jul 2007 10:28:03 +0200 Subject: pyGTK In-Reply-To: <1184605654.18448.2.camel@localhost.localdomain> References: <1184605654.18448.2.camel@localhost.localdomain> Message-ID: <469C7D93.4070002@rasmil.dk> lostson wrote: > Hello > I am currently studying python and am enjoying it quite well along the > way. I just happen to catch the update email today that pygtk2 is > updated today and I saw this in the email > > Just about anything you can write in C with GTK+ you can write > in Python with PyGTK (within reason), but with all the benefits of > Python. > > My main concern here is the (within reason) what exactly does this > mean ? Should I concentrate on another language instead of python. what > are the limitations ? Thanks for any ideas and advice. > Python and PyGTK is a great way to write GUI programs, and if you use glade to design the gui, it all becomes very easy to code and maintain. I think the 'within reason' mean that 99.9 % of the API in GTK+ has be wrapped into pygtk, if you want to use the 0.1% you have to use C, i don't think you will ever need the 0.1% anyway. Tim From stefmanos at gmail.com Tue Jul 17 08:55:59 2007 From: stefmanos at gmail.com (Stephanos Manos) Date: Tue, 17 Jul 2007 11:55:59 +0300 Subject: firewire (juju) (was: any chance to see kernel 2.6.22 for FC6?) In-Reply-To: References: <469BF5B7.70907@fedoraproject.org> Message-ID: KH KH wrote: > 2007/7/17, Rahul Sundaram : >> KH KH wrote: >> >> > Well the problem with 2.6.22 in Fedora Core 6 is that it will bring >> > some changes... >> > Actually eth1394.ko and libdc1394(-1) applications that are not >> > currently compatible with libdc1394-2 (with support for the new >> > firewire juju stack) will enter in regression... >> > Whereas users can possibly be aware of thoses regressions in Fedora 7, >> > some can be surprised of that in Fedora Core 6... >> > >> > I don't mean we need to hold kernel update, but how can we prevent >> > thoses issues ? >> >> Have you tested the kernel in updates-testing repository and confirmed >> that the issues still exist? Is there any bug reports on these aside >> from the pending package review requests you brought up? If the issues >> still exist we can either fix them or note it in the change log. > > Yes indeed i'm testing it... (eth1394.ko is not avaible anymore...) > Actually headers for juju firewire stack seems to be needed by libdc1394-2: > ----------- > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -Idc1394/juju -O2 -g -pipe > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -Wunused -MT > control.lo -MD -MP -MF .deps/control.Tpo -c control.c -fPIC -DPIC -o > .libs/control.o > In file included from capture.c:35: > ../juju/juju.h:23:28: error: fw-device-cdev.h: No such file or directory you are using an older version of libdc1394 (do an svn checkout) and run configure with --with-juju-dir=/usr/src/kernels/2.6.21-1.3233.fc8-i686/include (replace the kernel version with the one you have installed.) Also have in mind for firewire cameras you also need udev/hotplug rules Stephanos > capture.c:36:26: error: juju/capture.h: No such file or directory > capture.c: In function 'init_frame': > ----------- > They are not provided by kernel-headers nor kernel-devel: > [root at Kwizatz noarch]# rpm -q kernel-headers > kernel-headers-2.6.22.1-15.fc6 > [root at Kwizatz noarch]# rpm -ql kernel-headers |grep juju > [root at Kwizatz noarch]# rpm -ql kernel-devel |grep juju > > Any advices ? > > Nicolas (kwizart) > >> Rahul >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > From martin.sourada at seznam.cz Tue Jul 17 09:19:52 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 17 Jul 2007 11:19:52 +0200 Subject: [New Feature Proposition]: Nodoka Theme Message-ID: <1184663992.21133.15.camel@pc-notebook> Hi, following advice from Rahul [1] I propose a new Feature for Fedora 8 - Nodoka Theme. The Nodoka theme is currently targeted on Gnome and contains metacity theme, gtk engine, gtk theme and gnome metatheme. It is supposed to work with echo-icon-theme therefore the metatheme package requires echo icons as well. I've submitted review requests for inclusion in rawhide [2][3] and created a feature wiki page [4]. If you'd like to test it, rpms for i386 (and older ones for x86_64) and noarch are available on the NodokaTheme wiki [5]. Also I'd like to ask for hosting the sources on fedorahosted. Could someone point me as to how/where can I ask for it? Comments, feedback, patches, etc. welcome. Thanks, Martin [1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00120.html [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248163 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248516 [4] http://fedoraproject.org/wiki/Releases/Features/NodokaTheme [5] http://fedoraproject.org/wiki/Artwork/NodokaTheme -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From neugens at limasoftware.net Tue Jul 17 10:14:33 2007 From: neugens at limasoftware.net (Mario Torre) Date: Tue, 17 Jul 2007 12:14:33 +0200 Subject: F-Spot in fedora broken (was: Re: rawhide report: 20070716 changes) In-Reply-To: <1184629069.16566.3.camel@nirvana.limasoftware.net> References: <200707160924.l6G9OT2I022214@porkchop.devel.redhat.com> <1184629069.16566.3.camel@nirvana.limasoftware.net> Message-ID: <1184667274.3488.1.camel@nirvana.limasoftware.net> Il giorno mar, 17/07/2007 alle 01.37 +0200, Mario Torre ha scritto: > News on how to solve? > > Thanks, > Mario Maybe this help: I found the problem, the last update of gnome-sharp does not contains gtkhtml-sharp, so f-sport does not run anymore. I've solved reverting to the old gnome-sharp. Ciao, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: neugens at jabber.org pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From buildsys at redhat.com Tue Jul 17 10:17:46 2007 From: buildsys at redhat.com (Build System) Date: Tue, 17 Jul 2007 06:17:46 -0400 Subject: rawhide report: 20070717 changes Message-ID: <200707171017.l6HAHkAc031954@porkchop.devel.redhat.com> New package angrydd Falling blocks game New package brutus-keyring Small keyring daemon New package ftgl OpenGL frontend to Freetype 2 New package hdhomerun HDHomeRun configuration utility New package perl-Net-SFTP Secure File Transfer Protocol client New package soprano Qt wrapper API to different RDF storage solutions Updated Packages: anaconda-11.3.0.7-1 ------------------- * Mon Jul 16 2007 Jeremy Katz - 11.3.0.7-1 - Don't format rootfs for live installs (#248085) - Handle --only-use option for drives (clumens, #198526) - Avoid reserving labels that won't exist after partitioning is complete (clumens, #209291) * Thu Jul 12 2007 Chris Lumens 11.3.0.6-1 - Don't call lvm.pvlist so much (pjones). - Don't log harmless unmounting errors (dlehman, #223059). - Handle F12 on the install key dialog (dlehman, #210673). - Create device nodes and probe for tape drives (dlehman, #218816). - Fix loader network configuration UI flow (lucasgf AT br DOT ibm DOT com, - Include yum-fedorakmod plugin (dlehman). - Don't map Fedora to Fedora Core in the betanag dialog (katzj). - String fixes (katzj, #246703). - Fix module path order so updates get used (pjones). - Install the PAE kernel when applicable (pjones, #207573). - Fix fsset entry sorting (jhutz AT cmu DOT edu, #242294). - Don't display garbage in the ksfile location dialog (#245936). * Thu Jun 28 2007 Jeremy Katz - 11.3.0.5-1 - Fix traceback opening disks (dcantrell, #245609) - Fix live installs with /usr/local and /usr as separate partitions (#244913) - Driver disk reworking (clumens, #213318) - Write out additional repos in anaconda-ks.cfg (clumens, #206152) - Fix iscsi error reporting (pjones) - Add nss/nspr libs to stage2 (clumens) - Fix code to work with yum 3.2.1 (#245918) - Preserve owners on live install copy (#243479) audit-1.5.5-5.fc8 ----------------- * Tue Jul 17 2007 Miloslav Trma?? - 1.5.5-5 - Fix a double free when auditd receives SIGHUP - Move the system-config-audit menu entry to the Administration menu autofs-1:5.0.2-5 ---------------- * Mon Jul 16 2007 Ian Kent - 5.0.2-5 - fix mount point directory creation for bind mounts. - add quoting for exports gathered by hosts map. binutils-2.17.50.0.17-2 ----------------------- * Sun Jul 15 2007 Roland McGrath - 2.17.50.0.17-2 - ld --build-id support cinepaint-0.22.1-2.fc8 ---------------------- * Mon Jul 16 2007 kwizart < kwizart at gmail.com > - 0.22.1-2 - Add BR ftgl-devel claws-mail-2.10.0-2.fc8 ----------------------- * Mon Jul 16 2007 Andreas Bierfert - 2.10.0-2 - add requires for bogofilter (#246125) contacts-0.6-1.fc8 ------------------ * Mon Jul 16 2007 Denis Leroy - 0.6-1 - Update to 0.6, extra icons - Fixed desktop file dates-0.4.4-1.fc8 ----------------- * Mon Jul 16 2007 Denis Leroy - 0.4.4-1 - Update to 0.4.4, bug fixes dx-4.4.4-3.fc7 -------------- * Wed Jul 04 2007 Dominik Mierzejewski 4.4.4-3 - rebuild against new netcdf shared libs - fix menu icon transparency (#207841) - drop redundant BRs - fix some rpmlint warnings gcompris-8.3.2-2.fc8 -------------------- * Mon Jul 16 2007 Hans de Goede 8.3.2-2 - Rebase to upstream 8.3.2-2 tarbal "respin" - Add a patch to stop unnecessary monitor resolution switching when starting tuxpaint in fullscreen mode. geomview-1.9.3-2.fc8 -------------------- * Mon Jul 16 2007 Rex Dieter 1.9.3-2 - geomview.desktop: Categories=-Education (#241441) gnome-applet-sensors-1.8.1-1.fc8 -------------------------------- * Sun Jul 15 2007 Hans de Goede 1.8.1-1 - New upstream release 1.8.1 (fixes bz 235655, 190509) - Add gtk-icon-update-cache to post scripts (fixes bz 206529) - Pass proper directory for omf files to scrollkeeper-update in post script - Initialize sensors low and high tresholds from libsensors settings - Various specfile cleanups gnome-python2-extras-2.19.1-2.fc8 --------------------------------- * Mon Jul 16 2007 Matthew Barnes - 2.19.1-2.fc8 - New gda subpackage obsoletes the separate gnome-python2-gda package. gnucash-2.2.0-1.fc8 ------------------- * Mon Jul 16 2007 Bill Nottingham - 2.2.0-1 - update to 2.2.0 gnucash-docs-2.2.0-1.fc8 ------------------------ gnupg2-2.0.5-3.fc8 ------------------ * Mon Jul 16 2007 Rex Dieter 2.0.5-3 - 2.0.5 too many open files fix hplip-2.7.6-7.fc8 ----------------- * Mon Jul 16 2007 Tim Waugh 2.7.6-7 - Low ink is a warning condition, not an error. iptables-1.3.8-1 ---------------- * Fri Jul 13 2007 Steve Conklin - 1.3.8-1 - New version 1.3.8 kernel-2.6.23-0.29.rc0.git6.fc8 ------------------------------- * Mon Jul 16 2007 John W. Linville - Update git-wireless-dev.patch * Mon Jul 16 2007 Dave Jones - Disable ppc64 build until upstream merge (Broken PS3 drivers). * Mon Jul 16 2007 Dave Jones - 2.6.22-git6 kvm-28-2.fc8 ------------ * Mon Jul 16 2007 Jeremy Katz - 28-2 - add patch from danpb to fix mac addrs of multiple 8139 nics (#247641) libselinux-2.0.24-1.fc8 ----------------------- * Mon Jul 16 2007 Dan Walsh - 2.0.24-1 - Upgrade to upstream * Fix for getfilecon() for zero-length contexts from Stephen Smalley. netpbm-10.35-14.fc8 ------------------- * Mon Jul 16 2007 Jindrich Novy 10.35-14 - /usr/share/netpbm is no more unowned (#248300) openmpi-1.2.3-4.fc8 ------------------- * Mon Jul 16 2007 Doug Ledford - 1.2.3-4 - Fix a directory permission problem on the base openmpi directories pax-3.4-3.fc8 ------------- * Mon Jul 16 2007 Radek Brich - 3.4-3 - do not truncate file names when extracting (#205324) perl-Text-Aspell-0.08-1.fc8 --------------------------- php-5.2.3-5 ----------- * Mon Jul 16 2007 Joe Orton 5.2.3-5 - define php_extdir in macros.php php-pear-1:1.5.4-4 ------------------ * Mon Jul 16 2007 Remi Collet 1:1.5.4-4 - update macros.pear (without define) pykickstart-1.3-1.fc8 --------------------- * Wed Jul 11 2007 Chris Lumens - 1.3-1 - Add support for ignoredisk --only-use. - Fix traceback in raid command printing method (#246709). qtpfsgui-1.8.10-2.fc8 --------------------- * Sat Jul 14 2007 Douglas E. Warner 1.8.10-2 - bump for new sources file * Sat Jul 14 2007 Douglas E. Warner 1.8.10-1 - update to version 1.8.10 - removed i18n patch (applied upstream) rogue-5.4.2-9.fc8 ----------------- * Sun Jul 15 2007 Wart 5.4.2-9 - New upstream home page and download URL - Add patch when reading long values from the save file on 64-bit arch (BZ #248283) - Add patch removing many compiler warnings - Use proper version in the .desktop file selinux-policy-3.0.2-8.fc8 -------------------------- * Sat Jul 14 2007 Dan Walsh 3.0.2-8 - Fix moilscanner update problem sonata-1.2-2.fc8 ---------------- * Mon Jul 16 2007 Micha?? Bentkowski - 1.2-2 - BR gettext * Mon Jul 16 2007 Micha?? Bentkowski - 1.2-1 - 1.2 with audioscrobbler support sox-13.0.0-2 ------------ * Mon Jul 16 2007 Jiri Moskovcak 13.0.0-2 - uses external libgsm instead of local copy - spec file update: added BuildRequires: gsm-devel - Resolves: #239955 tomoe-0.6.0-2.fc8 ----------------- * Mon Jul 16 2007 Jens Petersen - 0.6.0-2 - add a build switch for python binding - buildrequires for pygobject2-devel, python-devel, and pygtk2-codegen - buildrequire gtk-doc - require gtk-doc for devel package - add a build switch for ruby binding (default off) wine-0.9.41-1.fc8 ----------------- * Mon Jul 16 2007 Andreas Bierfert - 0.9.41-1 - version upgrade * Tue Jul 03 2007 Andreas Bierfert - 0.9.40-1 - version upgrade * Mon Jun 18 2007 Andreas Bierfert - 0.9.39-2 - fix desktop entries wine-docs-0.9.41-1.fc8 ---------------------- * Mon Jul 16 2007 Andreas Bierfert - 0.9.41-1 - version upgrade wxGTK-2.8.4-4.fc8 ----------------- * Mon Jul 16 2007 Matthew Miller - 2.8.4-4 - patch from svn to fix rh bug #247414 Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.i386 requires 3.6.1 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 f-spot - 0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) eclipse-rcp - 1:3.3.0-1.fc8.x86_64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) f-spot - 0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 eclipse-rcp - 1:3.3.0-1.fc8.ppc requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 f-spot - 0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) dkms - 2.0.16-1.fc7.noarch requires kernel-devel eclipse-rcp - 1:3.3.0-1.fc8.ppc64 requires 3.6.1 eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) fuse - 2.6.5-2.fc8.ppc64 requires kernel >= 0:2.6.14 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 pcmciautils - 014-9.fc8.ppc64 requires kernel >= 0:2.6.12-1.1411_FC5 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) systemtap - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) varnish - 1.0.4-2.fc8.ppc64 requires kernel >= 0:2.6.0 vpnc - 0.4.0-2.fc7.ppc64 requires kernel >= 0:2.4 xorg-x11-drv-nouveau - 2.1.2-1.fc8.ppc64 requires kernel-drm-nouveau = 0:6 From spng.yang at gmail.com Tue Jul 17 10:41:06 2007 From: spng.yang at gmail.com (Ken YANG) Date: Tue, 17 Jul 2007 18:41:06 +0800 Subject: compiz fusion, avant-window-navigator and wyneken in rawhide? Message-ID: <469C9CC2.7060900@gmail.com> hi all, i notice in rawhide repo, there are not above package: compiz fusion, avant-window-navigator, and wyneken is there something i missed? wyneken: http://www.linux.com/feature/116343 From drago01 at gmail.com Tue Jul 17 11:01:44 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 17 Jul 2007 13:01:44 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184663992.21133.15.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> Message-ID: <469CA198.8060401@gmail.com> Martin Sourada wrote: > Hi, > > following advice from Rahul [1] I propose a new Feature for Fedora 8 - > Nodoka Theme. The Nodoka theme is currently targeted on Gnome and > contains metacity theme, gtk engine, gtk theme and gnome metatheme. It > is supposed to work with echo-icon-theme therefore the metatheme package > requires echo icons as well. I've submitted review requests for > inclusion in rawhide [2][3] and created a feature wiki page [4]. > > If you'd like to test it, rpms for i386 (and older ones for x86_64) and > noarch are available on the NodokaTheme wiki [5]. > > Also I'd like to ask for hosting the sources on fedorahosted. Could > someone point me as to how/where can I ask for it? > > Comments, feedback, patches, etc. welcome. > is this a gtk2 only theme or does it work for gtk apps too? From david at lovesunix.net Tue Jul 17 11:34:51 2007 From: david at lovesunix.net (David Nielsen) Date: Tue, 17 Jul 2007 13:34:51 +0200 Subject: compiz fusion, avant-window-navigator and wyneken in rawhide? In-Reply-To: <469C9CC2.7060900@gmail.com> References: <469C9CC2.7060900@gmail.com> Message-ID: <1184672091.7738.15.camel@dawkins> tir, 17 07 2007 kl. 18:41 +0800, skrev Ken YANG: > > hi all, > > > i notice in rawhide repo, there are not above > package: > > compiz fusion, avant-window-navigator, and wyneken > > > is there something i missed? I reviewed awn a while ago for Sindre Pedersen Bj?rdal and he managed to get it into cvs yesterday so this with any luck should hit a Fedora repo near you very soon. Compiz Fusion hasn't even got a stable release yet, preliminary rpms can be found here: http://devel.foss.org.my/~kagesenshi/repo/private/testing/ - Kindly provided by Hakiru Amano. No idea when they will be ready to go into Fedora. Wyneken I don't know, but if you need this you can add it to the wishlist on the wiki or better yet learn how to package rpms and become the Fedora maintainer. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From ffesti at redhat.com Tue Jul 17 11:47:17 2007 From: ffesti at redhat.com (Florian Festi) Date: Tue, 17 Jul 2007 13:47:17 +0200 Subject: Parallel Booting In-Reply-To: <200707100255.57096.opensource@till.name> References: <467BE85E.4070807@redhat.com> <468E6B3C.6070100@redhat.com> <200707092211.22925.jaroslav@aster.pl> <200707100255.57096.opensource@till.name> Message-ID: <469CAC45.9050306@redhat.com> Till Maas wrote: > On Mo Juli 9 2007, Jaroslaw Gorny wrote: > >> Friday 06 of July 2007 18:18:04 Harald Hoyer napisa?(a): >>> (...) >>> With: >>> >>> S12syslog >>> (...) >>> S99local >>> >>> /etc/rc.d/rc takes: >>> 8.5s in normal mode >>> 6s in parallel startup >>> >>> >>> so for me thats 140% speedup :) >> Hmm..... >> ((8.5-6)/8.5)*100 = 29.4% > > You calculated the the reduction of boottime. > > I would calculate the speedup this way: > > Bootspeed = 1/(Time to boot) > > normal speed = 10/85 > parralel startup speed = 10/60 > > Speedup in percent: 10/60 / 10/85 * 100 = 141.67 % Speed is 141.67 % of the old speed which gives a 41.67 speedup. The old speed is the reference aka 1 aka 100%. 140% speedup is more than twice as fast. Florian From mk at crc.dk Tue Jul 17 11:55:34 2007 From: mk at crc.dk (Mogens Kjaer) Date: Tue, 17 Jul 2007 13:55:34 +0200 Subject: CD/DVD cataloging software In-Reply-To: <1184606483.4145.28.camel@eagle.danny.cz> References: <1184606483.4145.28.camel@eagle.danny.cz> Message-ID: <469CAE36.2040903@crc.dk> Dan Hor?k wrote: > Hello, > > I have spend this weekend with looking for a software that will > catalogue content of CDs and DVDs (I want to know what file is on which > CD/DVD). It sounds like a simple thing to set up: 1. MySQL database 2. perl script to read contents of CD/DVD 3. PHP to query the database. I wrote a simple setup for this 10 years ago, we still use it with minor modifications. The database contains 1645 CD/DVD's with 704228 directories with 4830632 files. What we do is: 1. read the contents of the folders to be burned into the database. This includes an MD5 sum of each file. 2. Generate iso file 3. Burn 4. Verify (on another computer) the CD with the database. Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From icon at fedoraproject.org Tue Jul 17 12:32:21 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 17 Jul 2007 08:32:21 -0400 Subject: python-elementree & F7? In-Reply-To: <200707161948.11735.opensource@till.name> References: <200707161948.11735.opensource@till.name> Message-ID: On 7/16/07, Till Maas wrote: > On Mo Juli 16 2007, Zoltan Kota wrote: > > On Mon, 16 Jul 2007, Zoltan Kota wrote: > > > It seems python-elementtree is missing from F7 (and devel)! What is the > > > reason? Maybe I missed something? > > > > Ooops. In the meantime I found that it is included in python-2.5. > > It is not completely included, e.g. repoview stopped working because something > was missing. Yeah, SimpleXMLWriter is completely absent, so watch out. -- Konstantin Ryabitsev Montr?al, Qu?bec From kwizart at gmail.com Tue Jul 17 12:54:42 2007 From: kwizart at gmail.com (KH KH) Date: Tue, 17 Jul 2007 14:54:42 +0200 Subject: firewire (juju) (was: any chance to see kernel 2.6.22 for FC6?) In-Reply-To: References: <469BF5B7.70907@fedoraproject.org> Message-ID: 2007/7/17, Stephanos Manos : > KH KH wrote: > > 2007/7/17, Rahul Sundaram : > >> KH KH wrote: > >> > >> > Well the problem with 2.6.22 in Fedora Core 6 is that it will bring > >> > some changes... > >> > Actually eth1394.ko and libdc1394(-1) applications that are not > >> > currently compatible with libdc1394-2 (with support for the new > >> > firewire juju stack) will enter in regression... > >> > Whereas users can possibly be aware of thoses regressions in Fedora 7, > >> > some can be surprised of that in Fedora Core 6... > >> > > >> > I don't mean we need to hold kernel update, but how can we prevent > >> > thoses issues ? > >> > >> Have you tested the kernel in updates-testing repository and confirmed > >> that the issues still exist? Is there any bug reports on these aside > >> from the pending package review requests you brought up? If the issues > >> still exist we can either fix them or note it in the change log. > > > > Yes indeed i'm testing it... (eth1394.ko is not avaible anymore...) > > Actually headers for juju firewire stack seems to be needed by libdc1394-2: > > ----------- > > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I.. -Idc1394/juju -O2 -g -pipe > > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > > --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -Wunused -MT > > control.lo -MD -MP -MF .deps/control.Tpo -c control.c -fPIC -DPIC -o > > .libs/control.o > > In file included from capture.c:35: > > ../juju/juju.h:23:28: error: fw-device-cdev.h: No such file or directory > > you are using an older version of libdc1394 (do an svn checkout) Indeed i'm using the last rc7 with some hack to have theses juju headers taken from libraw1394 cvs > and run configure with > --with-juju-dir=/usr/src/kernels/2.6.21-1.3233.fc8-i686/include > (replace the kernel version with the one you have installed.) I don't have them for my fc6 kernel so i hope they will be there (as kernel-headers) when 2.6.22 will be shipped... > Also have in mind for firewire cameras you also need udev/hotplug rules Thx for this remind i have to do this indeed... Well now that i can have a "working" libdc1394-2 built, i figure out that applications cannot be build upon this version. This will need some work for upstream applications. (for example vlc...) Nicolas (kwizart) > > Stephanos > > > capture.c:36:26: error: juju/capture.h: No such file or directory > > capture.c: In function 'init_frame': > > ----------- > > They are not provided by kernel-headers nor kernel-devel: > > [root at Kwizatz noarch]# rpm -q kernel-headers > > kernel-headers-2.6.22.1-15.fc6 > > [root at Kwizatz noarch]# rpm -ql kernel-headers |grep juju > > [root at Kwizatz noarch]# rpm -ql kernel-devel |grep juju > > > > Any advices ? > > > > Nicolas (kwizart) > > > >> Rahul > >> > >> -- > >> fedora-devel-list mailing list > >> fedora-devel-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > >> > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From martin.sourada at seznam.cz Tue Jul 17 12:56:11 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 17 Jul 2007 14:56:11 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <469CA198.8060401@gmail.com> References: <1184663992.21133.15.camel@pc-notebook> <469CA198.8060401@gmail.com> Message-ID: <1184676971.21133.20.camel@pc-notebook> On Tue, 2007-07-17 at 13:01 +0200, dragoran wrote: > is this a gtk2 only theme or does it work for gtk apps too? > > _______________________________________________ > Fedora-art-list mailing list > Fedora-art-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-art-list GTK2 and Metacity. GTK1 theme is neither included nor planned. There are still gtk1 apps out there? :-O AFAIK, the current default, Clearlooks, don't support it either... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jima at beer.tclug.org Tue Jul 17 13:27:21 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 17 Jul 2007 08:27:21 -0500 (CDT) Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> Message-ID: On Tue, 17 Jul 2007, Debarshi 'Rishi' Ray wrote: >>> To install package(s) from a YumPack, you would need to untar the >>> YumPack, which is essentially an uncompressed Tar archive, and use >>> 'system-install-packages' to install the RPMs as you would normally >> > do. > >> Why uncompressed? > > No particular reason, except that on Fedora Core 6 compressed archives > of the rpmdb would lead to strange behaviour. Thus I am trying to stay > clean of any compressed archive. Since RPM contents are (IIRC) already compressed, I'm not sure you'd squeeze enough space out of compression to make it worth the trouble, anyway. Jima From jeff at ocjtech.us Tue Jul 17 13:27:19 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Tue, 17 Jul 2007 08:27:19 -0500 Subject: Squid 3 In-Reply-To: References: <469BF71D.5050506@gmail.com> <1184640796.3644.7.camel@lt21223.campus.dmacc.edu> Message-ID: <1184678839.4536.15.camel@lt21223.campus.dmacc.edu> On Tue, 2007-07-17 at 03:31 +0000, Kevin Kofler wrote: > Jeffrey C. Ollie ocjtech.us> writes: > > Sounds more like a candidate for F9 to me - the F8 feature freeze is set > > for 28 August 2007. > > But if there's beta releases, they could get into Rawhide right now, and > gradually upgraded to the final. That's what we're doing for KDE 4. If a squid3 package is developed and is parallel-installable with the squid 2.x packages that'd probably work. However, I think that squid is enough of a niche product that the 3.x wouldn't get enough testing before F8 to completely replace the 2.x version. Also, is the schedule for squid 3.x really that firm? There are 3.0 pre-releases available but the last one was issued in May, the pre-release before that took 6 months, and before that it was 3 years in between pre-releases! It looks to me like squid 3.x will be ready when it's ready and we'd be trying to rush it to try and get it into F8. The situation with KDE 4 is different because it will be receiving lots of attention and any major flaws should be found quickly. 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 jkeating at redhat.com Tue Jul 17 13:29:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 09:29:19 -0400 Subject: unfiled merge reviews In-Reply-To: <469C540C.2020005@redhat.com> References: <469C540C.2020005@redhat.com> Message-ID: <20070717092919.44b2c918@localhost.localdomain> On Tue, 17 Jul 2007 15:30:52 +1000 Jens Petersen wrote: > Hi, > > I am wondering what to do about former Core packages without merge > reviews. > > I am aware of a number of i18n (input method) related packages > without merge reviews (anthy, libchewing, m17n-db, and m17n-lib). > There are surely more in the distro. Should merge review bugs be > opened for them? > > One reason for asking is that I would like to build the above > packages for EPEL EL-4 and presumably the package need to be reviewed > for that? > > Jens > Are they just missing merge reviews? Did they have reviews to get into Core the first time? A merge review is only necessary if there wasn't a review to get it into core the first time (I thought...) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jul 17 14:23:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 10:23:40 -0400 Subject: Automating pam_keyring... In-Reply-To: <46730322.6020400@poolshark.org> References: <46730322.6020400@poolshark.org> Message-ID: <20070717102340.43fe40e7@localhost.localdomain> On Fri, 15 Jun 2007 23:22:42 +0200 Denis Leroy wrote: > Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 > problem for me: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741 > > I'll push an update shortly. A friend scanning this mailing list asked me to pose a question; is there any thought to being able to manage ssh-agent passphrases within gnome-keyring as well? This would cut down on the number of times a password has to be entered. Are there known challenges to using gnome-keyring for ssh-agent as well? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jul 17 14:30:22 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 17 Jul 2007 10:30:22 -0400 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184663992.21133.15.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> Message-ID: <20070717143022.GA16499@jadzia.bu.edu> On Tue, Jul 17, 2007 at 11:19:52AM +0200, Martin Sourada wrote: > Comments, feedback, patches, etc. welcome. I'd really love to see a grey version of the theme (a la Mac OS X). Bright color elements are distracting to me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pemboa at gmail.com Tue Jul 17 14:36:56 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 17 Jul 2007 09:36:56 -0500 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> Message-ID: <16de708d0707170736v4c655716ge8e8093781b9e8cf@mail.gmail.com> On 7/17/07, Debarshi 'Rishi' Ray wrote: > What about Opium? > > Pirut (pronounced 'pirate') stands for Package Installation, Removal & > Update Tool. > Opium can be Offline Package Installation & Update Manager. > > The offline tool may be rarely used to remove a package. > > Cheerio, > Debarshi > -- +1 for Opium -- Fedora Core 6 and proud From drago01 at gmail.com Tue Jul 17 14:39:56 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 17 Jul 2007 16:39:56 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184676971.21133.20.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> <469CA198.8060401@gmail.com> <1184676971.21133.20.camel@pc-notebook> Message-ID: On 7/17/07, Martin Sourada wrote: > > On Tue, 2007-07-17 at 13:01 +0200, dragoran wrote: > > is this a gtk2 only theme or does it work for gtk apps too? > > > > _______________________________________________ > > Fedora-art-list mailing list > > Fedora-art-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-art-list > > GTK2 and Metacity. GTK1 theme is neither included nor planned. There are > still gtk1 apps out there? :-O AFAIK, the current default, Clearlooks, > don't support it either... I don't use any gtk1 apps, and when clearlooks does not support them too its ok -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjones at redhat.com Tue Jul 17 14:45:31 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 17 Jul 2007 15:45:31 +0100 Subject: inkscape in rawhide segfaults immediately on start up Message-ID: <469CD60B.8040009@redhat.com> I haven't looked into this in great detail yet, but I wonder if this is a known problem? There is no bugzilla that I can find and it's a complete show-stopper so I can't imagine how it got past even the most minimal test. Rich. $ inkscape Segmentation fault $ rpm -q inkscape inkscape-0.45.1-1.fc7 $ strace inkscape [...] open("/etc/selinux/config", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=512, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaac6000 read(3, "# This file controls the state o"..., 4096) = 512 read(3, "", 4096) = 0 close(3) = 0 munmap(0x2aaaaaac6000, 4096) = 0 statfs("/selinux", {f_type=0xf97cff8c, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 stat("/selinux/class", 0x7fffb5522ae0) = -1 ENOENT (No such file or directory) open("/selinux/mls", O_RDONLY) = 3 read(3, "1", 19) = 1 close(3) = 0 futex(0x2aaaac590b40, FUTEX_WAKE, 2147483647) = 0 brk(0xdb9000) = 0xdb9000 brk(0xdda000) = 0xdda000 gettimeofday({1184683408, 102077}, NULL) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ $ gdb /usr/bin/inkscape [...] 0x00002aaab118aec9 in GC_malloc () from /usr/lib64/libgc.so.1 (gdb) bt #0 0x00002aaab118aec9 in GC_malloc () from /usr/lib64/libgc.so.1 #1 0x0000000000976628 in sp_repr_new (name=) at ./gc-core.h:74 #2 0x0000000000972a4c in sp_repr_svg_read_node (node=0xd8f160, default_ns=0x0, prefix_map=0xd8e400) at xml/repr-io.cpp:472 #3 0x0000000000974150 in sp_repr_do_read (doc=, default_ns=0x0) at xml/repr-io.cpp:382 #4 0x0000000000974272 in sp_repr_read_mem (buffer=, length=10198, default_ns=0x0) at xml/repr-io.cpp:306 #5 0x00000000005a9b25 in Inkscape::Preferences::loadSkeleton () at preferences.cpp:34 #6 0x000000000068f1d5 in Application (this=0x2aaab13930b0, argc=14215168, argv=0x7fff4c3ecbc8, use_gui=11, new_gui=208) at application/application.cpp:45 #7 0x0000000000598976 in main (argc=1, argv=0x7fff4c3ecbc8) at main.cpp:489 From fedora at camperquake.de Tue Jul 17 14:46:29 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 17 Jul 2007 16:46:29 +0200 Subject: Automating pam_keyring... In-Reply-To: <20070717102340.43fe40e7@localhost.localdomain> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> Message-ID: <20070717164629.337db4b0@banea.int.addix.net> Hi. On Tue, 17 Jul 2007 10:23:40 -0400, Jesse Keating wrote: > A friend scanning this mailing list asked me to pose a question; is > there any thought to being able to manage ssh-agent passphrases > within gnome-keyring as well? This would cut down on the number of > times a password has to be entered. Are there known challenges to > using gnome-keyring for ssh-agent as well? That ought to work. SSH just calls a helper process, which has to print the keyphrase to stdout. Where it gets the keyphrase is irrelevant. The current helpers come from openssh-askpass (which is built from the main ssh package), so we'd have to add gnome-keyring-ssh-askpass there. To be honest, such a helper has been somewhere on my to-do-list for two years at least :) From darrellpf at gmail.com Tue Jul 17 14:52:09 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 17 Jul 2007 07:52:09 -0700 Subject: inkscape in rawhide segfaults immediately on start up In-Reply-To: <469CD60B.8040009@redhat.com> References: <469CD60B.8040009@redhat.com> Message-ID: On 7/17/07, Richard W.M. Jones wrote: > I haven't looked into this in great detail yet, but I wonder if this is > a known problem? There is no bugzilla that I can find and it's a > complete show-stopper so I can't imagine how it got past even the most > minimal test. > > Rich. > > $ inkscape > Segmentation fault > Works for me on today's rawhide. I'm 386 though. darrell From rdieter at math.unl.edu Tue Jul 17 14:53:20 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 17 Jul 2007 09:53:20 -0500 Subject: Automating pam_keyring... References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> Message-ID: Jesse Keating wrote: > On Fri, 15 Jun 2007 23:22:42 +0200 > Denis Leroy wrote: > >> Good news here, Jon released pam_keyring 0.0.9. It fixed the F-7 >> problem for me: >> >> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238741 >> >> I'll push an update shortly. > > A friend scanning this mailing list asked me to pose a question; is > there any thought to being able to manage ssh-agent passphrases > within gnome-keyring as well? This would cut down on the number of > times a password has to be entered. Are there known challenges to using > gnome-keyring for ssh-agent as well? Speaking of gpg/ssh integration... I've been asked to enable ssh support in gpg-agent, http://bugzilla.redhat.com/247616 any comment/feedback on how to best make this work? Haven't done much testing myself yet, but would it be worth exploring the idea of augmenting or possibly replacing ssh-agent? -- Rex From tmz at pobox.com Tue Jul 17 15:02:04 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 17 Jul 2007 11:02:04 -0400 Subject: Automating pam_keyring... In-Reply-To: <20070717102340.43fe40e7@localhost.localdomain> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> Message-ID: <20070717150204.GA394@psilocybe.teonanacatl.org> Jesse Keating wrote: > A friend scanning this mailing list asked me to pose a question; is > there any thought to being able to manage ssh-agent passphrases > within gnome-keyring as well? This would cut down on the number of > times a password has to be entered. Are there known challenges to > using gnome-keyring for ssh-agent as well? While this isn't quite an answer to the question, it may be useful to the friend that asked... With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar to what you do to use pam_keyring), you can enter your password once and be done. That is, at the gdm login screen you enter your username and password and your ssh keys get loaded. This requires your login password and the password on your ssh key(s) to match. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I advise you to go on living solely to enrage those who are paying your annuities. It is the only pleasure I have left. -- Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jonathan.underwood at gmail.com Tue Jul 17 15:22:05 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 17 Jul 2007 16:22:05 +0100 Subject: Automating pam_keyring... In-Reply-To: References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> Message-ID: <645d17210707170822m745a799bv21a58197affed585@mail.gmail.com> On 17/07/07, Rex Dieter wrote: > Speaking of gpg/ssh integration... > I've been asked to enable ssh support in gpg-agent, > http://bugzilla.redhat.com/247616 > any comment/feedback on how to best make this work? > > Haven't done much testing myself yet, but would it be worth exploring the > idea of augmenting or possibly replacing ssh-agent? I felt someone should also mention Seahorse at this point, which handles both GPG and ssh keys and is well integrated into gnome: http://www.gnome.org/projects/seahorse/ ... so I just did. J. From jonathan.underwood at gmail.com Tue Jul 17 15:31:00 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 17 Jul 2007 16:31:00 +0100 Subject: Automating pam_keyring... In-Reply-To: <20070717150204.GA394@psilocybe.teonanacatl.org> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <20070717150204.GA394@psilocybe.teonanacatl.org> Message-ID: <645d17210707170831v78ac1898w6c9603c91aa78a44@mail.gmail.com> On 17/07/07, Todd Zullinger wrote: > With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar to > what you do to use pam_keyring), you can enter your password once and > be done. That is, at the gdm login screen you enter your username and > password and your ssh keys get loaded. This requires your login > password and the password on your ssh key(s) to match. That requirement isn't something that should be encouraged, though, IMO. There's a reason that ssh uses passphrases. J. From martin.sourada at seznam.cz Tue Jul 17 15:32:15 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Tue, 17 Jul 2007 17:32:15 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <20070717143022.GA16499@jadzia.bu.edu> References: <1184663992.21133.15.camel@pc-notebook> <20070717143022.GA16499@jadzia.bu.edu> Message-ID: <1184686335.21133.24.camel@pc-notebook> On Tue, 2007-07-17 at 16:30 +0200, Matthew Miller wrote: > On Tue, Jul 17, 2007 at 11:19:52AM +0200, Martin Sourada wrote: > > Comments, feedback, patches, etc. welcome. > > I'd really love to see a grey version of the theme (a la Mac OS X). Bright > color elements are distracting to me. > It should be easy to tweak this to your liking. The metacity theme uses gtk colours and you can customise these on the Theme Details -> Colours page. -------------- next part -------------- A non-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 Jul 17 15:42:55 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 17 Jul 2007 11:42:55 -0400 Subject: Automating pam_keyring... In-Reply-To: <645d17210707170831v78ac1898w6c9603c91aa78a44@mail.gmail.com> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <20070717150204.GA394@psilocybe.teonanacatl.org> <645d17210707170831v78ac1898w6c9603c91aa78a44@mail.gmail.com> Message-ID: <20070717154255.GB394@psilocybe.teonanacatl.org> Jonathan Underwood wrote: > On 17/07/07, Todd Zullinger wrote: >> With pam_ssh installed and a small tweak to /etc/pam.d/gdm (similar >> to what you do to use pam_keyring), you can enter your password >> once and be done. That is, at the gdm login screen you enter your >> username and password and your ssh keys get loaded. This requires >> your login password and the password on your ssh key(s) to match. > > That requirement isn't something that should be encouraged, though, > IMO. Yes, there's a benefit to keeping the passphrases separate. This also affect pam_keyring. Anything that intends to unlock a keyring with one passphrase pretty much requires that the passphrases match. There is always a tradeoff between security and convenience. Are you suggesting that there not be a way for users to enable their login to unlock their various keyrings? Or are there better tools to make this both convenient and more secure? > There's a reason that ssh uses passphrases. You say that like we don't all use passphrases for login. ;) My fault for saying password when I should have said passphrase. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Intaxication (n.) Euphoria at getting a tax refund, which lasts until you realize it was your money to start with. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From lsof at nodata.co.uk Tue Jul 17 16:03:57 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 17 Jul 2007 18:03:57 +0200 Subject: Presto: what happened to it? Message-ID: <1184688237.3732.5.camel@sb-home> A while back there was a conversation about including Presto in F7. The request was rejected due to lack of testing. A few months on, and the loss of the Presto repo later, there doesn't seem to be an awful lot of testing by users. Is this a bandwidth problem? Can the Fedora Project host it to fix this? From mschwendt.tmp0701.nospam at arcor.de Tue Jul 17 16:22:20 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 17 Jul 2007 18:22:20 +0200 Subject: inkscape in rawhide segfaults immediately on start up In-Reply-To: <469CD60B.8040009@redhat.com> References: <469CD60B.8040009@redhat.com> Message-ID: <20070717182220.88eb9197.mschwendt.tmp0701.nospam@arcor.de> On Tue, 17 Jul 2007 15:45:31 +0100, Richard W.M. Jones wrote: > I haven't looked into this in great detail yet, but I wonder if this is > a known problem? There is no bugzilla that I can find ?? No ticket or no bugzilla? -> bugzilla.redhat.com > and it's a > complete show-stopper so I can't imagine how it got past even the most > minimal test. What "minimal test"? This is Rawhide and a Fedora 7 package which might just need a rebuild, because other development updates have broken it. Further, the traceback ends in libgc.so.1, which is not Inkscape. > Rich. > > $ inkscape > Segmentation fault > > $ rpm -q inkscape > inkscape-0.45.1-1.fc7 From dan at danny.cz Tue Jul 17 16:20:10 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 17 Jul 2007 18:20:10 +0200 Subject: Presto: what happened to it? In-Reply-To: <1184688237.3732.5.camel@sb-home> References: <1184688237.3732.5.camel@sb-home> Message-ID: <1184689210.4161.2.camel@eagle.danny.cz> nodata p??e v ?t 17. 07. 2007 v 18:03 +0200: > A while back there was a conversation about including Presto in F7. > The request was rejected due to lack of testing. > > A few months on, and the loss of the Presto repo later, there doesn't > seem to be an awful lot of testing by users. > > Is this a bandwidth problem? Can the Fedora Project host it to fix this? > presto repos exist for FC6, F7 and Development on i386 for details see http://hosted.fedoraproject.org/projects/presto Dan From tonynelson at georgeanelson.com Tue Jul 17 16:22:20 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 17 Jul 2007 12:22:20 -0400 Subject: Presto: what happened to it? In-Reply-To: <1184688237.3732.5.camel@sb-home> References: <1184688237.3732.5.camel@sb-home> Message-ID: At 6:03 PM +0200 7/17/07, nodata wrote: >A while back there was a conversation about including Presto in F7. >The request was rejected due to lack of testing. > >A few months on, and the loss of the Presto repo later, there doesn't >seem to be an awful lot of testing by users. > >Is this a bandwidth problem? Can the Fedora Project host it to fix this? At 3:10 PM +0300 7/12/07, Jonathan Dieter wrote: ... >Subject: Presto repositories for FC6, F7 and Rawhide back up. ... >The Lebanon Evangelical School - Loueizeh has generously lent us a >dedicated server to host Presto repositories and the school has agreed >to continue lending us the server until both FC6 and F7 are EOL'd. > >I've gotten the FC6, F7 and Rawhide repositories up and running for >i386. For Rawhide, you need the new yum-presto-0.4.0, which has been >almost completely rewritten. For FC6 and F7, you will need to continue >using yum-presto-0.3.x (at least for the moment). > >For those wondering what Presto is, it is a method of downloading only >the differences of rpms for updates, rather than full rpms. > >For more information (and the new deltaurls), see: >http://hosted.fedoraproject.org/projects/presto > >Enjoy, >Jonathan -- ____________________________________________________________________ TonyN.:' ' From alan at clueserver.org Tue Jul 17 16:26:57 2007 From: alan at clueserver.org (alan) Date: Tue, 17 Jul 2007 09:26:57 -0700 (PDT) Subject: CD/DVD cataloging software In-Reply-To: <469CAE36.2040903@crc.dk> References: <1184606483.4145.28.camel@eagle.danny.cz> <469CAE36.2040903@crc.dk> Message-ID: On Tue, 17 Jul 2007, Mogens Kjaer wrote: > Dan Hor?k wrote: >> Hello, >> >> I have spend this weekend with looking for a software that will >> catalogue content of CDs and DVDs (I want to know what file is on which >> CD/DVD). > > It sounds like a simple thing to set up: > > 1. MySQL database > 2. perl script to read contents of CD/DVD > 3. PHP to query the database. > > I wrote a simple setup for this 10 years ago, > we still use it with minor modifications. > > The database contains 1645 CD/DVD's with 704228 > directories with 4830632 files. > > What we do is: > > 1. read the contents of the folders to be burned > into the database. This includes an MD5 sum of each file. > 2. Generate iso file > 3. Burn > 4. Verify (on another computer) the CD with the database. How do you recognise individual discs? By label? By hash of the entire disc? Some other method? That is the one problem I have not been able to solve in a quick manner. -- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox From lsof at nodata.co.uk Tue Jul 17 16:28:22 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 17 Jul 2007 18:28:22 +0200 Subject: Presto: what happened to it? In-Reply-To: <1184689210.4161.2.camel@eagle.danny.cz> References: <1184688237.3732.5.camel@sb-home> <1184689210.4161.2.camel@eagle.danny.cz> Message-ID: <1184689702.3732.7.camel@sb-home> Am Dienstag, den 17.07.2007, 18:20 +0200 schrieb Dan Hor?k: > nodata p??e v ?t 17. 07. 2007 v 18:03 +0200: > > A while back there was a conversation about including Presto in F7. > > The request was rejected due to lack of testing. > > > > A few months on, and the loss of the Presto repo later, there doesn't > > seem to be an awful lot of testing by users. > > > > Is this a bandwidth problem? Can the Fedora Project host it to fix this? > > > > presto repos exist for FC6, F7 and Development on i386 > > for details see http://hosted.fedoraproject.org/projects/presto > > > Dan > > Thanks for this. From jonathan.underwood at gmail.com Tue Jul 17 16:54:44 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 17 Jul 2007 17:54:44 +0100 Subject: Automating pam_keyring... In-Reply-To: <20070717154255.GB394@psilocybe.teonanacatl.org> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <20070717150204.GA394@psilocybe.teonanacatl.org> <645d17210707170831v78ac1898w6c9603c91aa78a44@mail.gmail.com> <20070717154255.GB394@psilocybe.teonanacatl.org> Message-ID: <645d17210707170954q46ba8426q47b679413893bb9d@mail.gmail.com> On 17/07/07, Todd Zullinger wrote: > Yes, there's a benefit to keeping the passphrases separate. This > also affect pam_keyring. Anything that intends to unlock a keyring > with one passphrase pretty much requires that the passphrases match. > You were arguing for the login password/phrase matching the ssh password/phrase - that seems like a bad idea and really unecessary. Surely, what you mean is that it's required for the login password/phrase to be the same password/phrase as for whatever application stores the various passphrases for ssh/gpg etc. > There is always a tradeoff between security and convenience. Are you > suggesting that there not be a way for users to enable their login to > unlock their various keyrings? Nope. But that in no way requires login password/phrase == ssh key password/phrase. J. From katzj at redhat.com Tue Jul 17 16:53:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 17 Jul 2007 12:53:35 -0400 Subject: Presto: what happened to it? In-Reply-To: <1184688237.3732.5.camel@sb-home> References: <1184688237.3732.5.camel@sb-home> Message-ID: <1184691215.6534.5.camel@localhost.localdomain> On Tue, 2007-07-17 at 18:03 +0200, nodata wrote: > A while back there was a conversation about including Presto in F7. > The request was rejected due to lack of testing. > > A few months on, and the loss of the Presto repo later, there doesn't > seem to be an awful lot of testing by users. > > Is this a bandwidth problem? Can the Fedora Project host it to fix this? There's actually work underway to get to where we can enable presto by default. Jonathan took a number of patches from me to clean things up a bit and those are present in the most recent presto release (0.4.0). Also, there's some work starting to get underway to add the support within the buildsystem for deltarpm generation. This will make it possible for us to create and distribute them natively as part of the distro/update build process. So the short answer is, we're working on it and it's currently being tracked as a proposed feature for Fedora 8[1] Jeremy [1] http://fedoraproject.org/wiki/Releases/FeaturePresto From tmz at pobox.com Tue Jul 17 17:24:31 2007 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 17 Jul 2007 13:24:31 -0400 Subject: Automating pam_keyring... In-Reply-To: <645d17210707170954q46ba8426q47b679413893bb9d@mail.gmail.com> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <20070717150204.GA394@psilocybe.teonanacatl.org> <645d17210707170831v78ac1898w6c9603c91aa78a44@mail.gmail.com> <20070717154255.GB394@psilocybe.teonanacatl.org> <645d17210707170954q46ba8426q47b679413893bb9d@mail.gmail.com> Message-ID: <20070717172431.GD12135@psilocybe.teonanacatl.org> Jonathan Underwood wrote: > You were arguing for the login password/phrase matching the ssh > password/phrase - that seems like a bad idea and really unecessary. It's necessary for using pam_ssh at the moment. It is also needed for pam_keyring. I'm not arguing that this is the best way. I was only passing on this info that may help the Jesse's friend find a workable solution with the current tools. >> There is always a tradeoff between security and convenience. Are >> you suggesting that there not be a way for users to enable their >> login to unlock their various keyrings? > > Nope. But that in no way requires login password/phrase == ssh key > password/phrase. At present for pam_ssh it does. I'm not sure how much of a risk this really is. Say that gnome-keyring gets support for unlocking ssh keys. Then I could have my ssh passphrase stored in gnome-keyring, which would be using the same passphrase as my login. My ssh passphrase is now only as secure as gnome-keying is. How secure is gnome-keying? I'm not suggesting that gnome-keying is inherently insecure, as I've not looked at it (nor am I really qualified to assess it properly). But I'm not sure that having gnome-keyring -- using the same passphrase as my login -- protecting my ssh passphrase is that much different than using the same passphrase as login for the ssh key. Am I missing something really obvious? For those that want much stronger security, not using any sort of automated passphrase store and using different passphrases for login, ssh keys, etc. is the only way to go. That's not the target audience for the features an automated pam_keyring would provide, as far as I can tell. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The average woman would rather be beautiful than smart because the average man can see better than he can think. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From neugens at limasoftware.net Tue Jul 17 17:41:26 2007 From: neugens at limasoftware.net (Mario Torre) Date: Tue, 17 Jul 2007 19:41:26 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184686335.21133.24.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> <20070717143022.GA16499@jadzia.bu.edu> <1184686335.21133.24.camel@pc-notebook> Message-ID: <1184694086.3467.6.camel@nirvana.limasoftware.net> Il giorno mar, 17/07/2007 alle 17.32 +0200, Martin Sourada ha scritto: > It should be easy to tweak this to your liking. The metacity theme uses > gtk colours and you can customise these on the Theme Details -> Colours > page. Hi! I would suggest to keep the tab colors as they are in clearlooks (not the whole tabs appearance, the shadows is nice, but just the gradient color, as opposed to the current one line stroke on the top), as it is distracting. I'm referring to the this mockup http://fedoraproject.org/wiki/Artwork/NodokaTheme "How we would like it to look". Ciao, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: neugens at jabber.org pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From robert at fedoraproject.org Tue Jul 17 17:53:44 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Tue, 17 Jul 2007 19:53:44 +0200 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> Message-ID: <20070717175344.GA26489@hurricane.linuxnetz.de> Hello Christian, On Fri, 13 Jul 2007, Christian Iseli wrote: > jorton at redhat dot com libc-client please note, that this package got obsoleted in Fedora 7 by uw-imap - right, Joe? > mastahnke at gmail dot com epel-release Hum? Greetings, Robert From kagesenshi.87 at gmail.com Tue Jul 17 17:56:06 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Wed, 18 Jul 2007 01:56:06 +0800 Subject: compiz fusion, avant-window-navigator and wyneken in rawhide? In-Reply-To: <1184672091.7738.15.camel@dawkins> References: <469C9CC2.7060900@gmail.com> <1184672091.7738.15.camel@dawkins> Message-ID: On 7/17/07, David Nielsen wrote: > > tir, 17 07 2007 kl. 18:41 +0800, skrev Ken YANG: > > Compiz Fusion hasn't even got a stable release yet, preliminary rpms can > be found here: > http://devel.foss.org.my/~kagesenshi/repo/private/testing/ - Kindly > provided by Hakiru Amano. No idea when they will be ready to go into > Fedora. > you can read the installation guide here http://wiki.kagesenshi.org/moin.fcgi/CategoryPackages/CompizFusion ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com http://fedoraproject.org/wiki/MohdIzharFirdaus ----------------------------------------------- From dan at danny.cz Tue Jul 17 18:33:06 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 17 Jul 2007 20:33:06 +0200 Subject: CD/DVD cataloging software In-Reply-To: <1184614008.4145.37.camel@eagle.danny.cz> References: <1184606483.4145.28.camel@eagle.danny.cz> <1184614008.4145.37.camel@eagle.danny.cz> Message-ID: <1184697186.4161.6.camel@eagle.danny.cz> Dan Hor?k p??e v Po 16. 07. 2007 v 21:26 +0200: > Dan Hor?k p??e v Po 16. 07. 2007 v 19:21 +0200: > > Hello, > > > > I have spend this weekend with looking for a software that will > > catalogue content of CDs and DVDs (I want to know what file is on which > > CD/DVD). My requirements were simple - work current Fedora (>=6) and > > automagicly use the disc name when storing the content. As > > > > name version platform current use disc > > Fedora name > > gtktalog 1.0.4 C/gtk1 no ? > > gwhere 0.2.3 C/gtk1,gtk2 no* yes > > CdCat 1.01b C/qt no* no > > gnomecatalog 0.2.1 Python/gtk no ? > > cdcollect 0.6.0 Mono no ? > > > > * = can read content of the folder where the disc is mounted > > > > The main problem is that these softs are looking for CD/DVDs into a > > fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as > > it uses gnome-mount which uses HAL. Also most of them are dead or almost > > dead projects. > > > > As a result I have chosen gwhere for my usage. It required not so much > > effort to make it build and then work. You can find it at > > http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project > > looks quite promising, but I don't know how to integrate scanning of > > gnome-mounted (using HAL) discs. > > Looks like I have found a way to make cdcollect work. Stay tuned ;-) Improved CDCollect source package can be found at http://fedora.danny.cz/cdcollect-0.6.0-1.src.rpm Dan From jorton at redhat.com Tue Jul 17 19:01:23 2007 From: jorton at redhat.com (Joe Orton) Date: Tue, 17 Jul 2007 20:01:23 +0100 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <20070717175344.GA26489@hurricane.linuxnetz.de> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> <20070717175344.GA26489@hurricane.linuxnetz.de> Message-ID: <20070717190123.GA8468@redhat.com> On Tue, Jul 17, 2007 at 07:53:44PM +0200, Robert Scheck wrote: > Hello Christian, > > On Fri, 13 Jul 2007, Christian Iseli wrote: > > jorton at redhat dot com libc-client > > please note, that this package got obsoleted in Fedora 7 by uw-imap - > right, Joe? Correct! joe From jorton at redhat.com Tue Jul 17 19:04:04 2007 From: jorton at redhat.com (Joe Orton) Date: Tue, 17 Jul 2007 20:04:04 +0100 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> Message-ID: <20070717190404.GA9859@redhat.com> On Fri, Jul 13, 2007 at 12:24:14AM +0200, Christian Iseli wrote: > - 3 packages not available in devel but present in release ... > jorton at redhat dot com newt-perl This one is a "dropped since F7 release" package - it was renamed to (and is obsoleted by) perl-Newt. joe From sundaram at fedoraproject.org Tue Jul 17 19:14:19 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 00:44:19 +0530 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184663992.21133.15.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> Message-ID: <469D150B.3000604@fedoraproject.org> Martin Sourada wrote: > Hi, > > following advice from Rahul [1] I propose a new Feature for Fedora 8 - > Nodoka Theme. The Nodoka theme is currently targeted on Gnome and > contains metacity theme, gtk engine, gtk theme and gnome metatheme. It > is supposed to work with echo-icon-theme therefore the metatheme package > requires echo icons as well. I've submitted review requests for > inclusion in rawhide [2][3] and created a feature wiki page [4]. > > If you'd like to test it, rpms for i386 (and older ones for x86_64) and > noarch are available on the NodokaTheme wiki [5]. > > Also I'd like to ask for hosting the sources on fedorahosted. Could > someone point me as to how/where can I ask for it? Got to ask in fedora-infrastructure list. Rahul From ad+lists at uni-x.org Tue Jul 17 19:18:11 2007 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 17 Jul 2007 21:18:11 +0200 Subject: Automating pam_keyring... In-Reply-To: <20070717102340.43fe40e7@localhost.localdomain> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> Message-ID: <469D15F3.4040609@uni-x.org> Jesse Keating schrieb: > A friend scanning this mailing list asked me to pose a question; is > there any thought to being able to manage ssh-agent passphrases > within gnome-keyring as well? This would cut down on the number of > times a password has to be entered. Are there known challenges to using > gnome-keyring for ssh-agent as well? Hi Jesse, we have keychain in Fedora, which exactly does this. Alexander From jkeating at redhat.com Tue Jul 17 19:23:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 15:23:26 -0400 Subject: Automating pam_keyring... In-Reply-To: <469D15F3.4040609@uni-x.org> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> Message-ID: <20070717152326.510c5e77@ender> On Tue, 17 Jul 2007 21:18:11 +0200 Alexander Dalloz wrote: > Hi Jesse, > > we have keychain in Fedora, which exactly does this. Is that a second UI prompt though for a passphrase? My friend's main concern is that multiple password/phrase prompts from multiple UIs is pretty gross and they should all be the same UI, potentially a single prompt. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Tue Jul 17 19:33:12 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 17 Jul 2007 15:33:12 -0400 Subject: inkscape in rawhide segfaults immediately on start up In-Reply-To: <469CD60B.8040009@redhat.com> References: <469CD60B.8040009@redhat.com> Message-ID: <8796.1184700792@laptop13.inf.utfsm.cl> Richard W.M. Jones wrote: > I haven't looked into this in great detail yet, but I wonder if this > is a known problem? There is no bugzilla that I can find and it's a > complete show-stopper so I can't imagine how it got past even the most > minimal test. Not here (i686, inkscape-0.45.1-1.fc7) -- 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 ad+lists at uni-x.org Tue Jul 17 19:54:22 2007 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 17 Jul 2007 21:54:22 +0200 Subject: Automating pam_keyring... In-Reply-To: <20070717152326.510c5e77@ender> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> Message-ID: <469D1E6E.5040404@uni-x.org> Jesse Keating schrieb: > On Tue, 17 Jul 2007 21:18:11 +0200 > Alexander Dalloz wrote: > >> Hi Jesse, >> >> we have keychain in Fedora, which exactly does this. > > Is that a second UI prompt though for a passphrase? My friend's main > concern is that multiple password/phrase prompts from multiple UIs is > pretty gross and they should all be the same UI, potentially a single > prompt. Yes, just the same kind of UI prompts for SSH and GPG keys. I have several SSH keys I load into ssh-agent at first login and thus get several UI input popups initiated by keychain. As well the keyring request for my wireless WPA key. Can't think of a way a single application would reduce the onetime amount of passphrase requests. Alexander From jkeating at redhat.com Tue Jul 17 20:21:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 16:21:24 -0400 Subject: Automating pam_keyring... In-Reply-To: <469D1E6E.5040404@uni-x.org> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> Message-ID: <20070717162124.5014a7e2@localhost.localdomain> On Tue, 17 Jul 2007 21:54:22 +0200 Alexander Dalloz wrote: > Yes, just the same kind of UI prompts for SSH and GPG keys. > > I have several SSH keys I load into ssh-agent at first login and thus > get several UI input popups initiated by keychain. As well the keyring > request for my wireless WPA key. Can't think of a way a single > application would reduce the onetime amount of passphrase requests. Well, theoretically you'd allow gnome-keyring to save all those passphrases and then you'd have a master passphrase (different from the rest) that would allow gnome-keyring to dole them out as needed. But yes, that puts all your eggs in the gnome-keyring basket and relying on the strength of your master keyring. I always make sure my login password/phrase is different than that of my master keyring phrase, and that is different from any of the passphrases in my ring. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mk at crc.dk Tue Jul 17 20:27:02 2007 From: mk at crc.dk (Mogens Kjaer) Date: Tue, 17 Jul 2007 22:27:02 +0200 Subject: CD/DVD cataloging software In-Reply-To: References: <1184606483.4145.28.camel@eagle.danny.cz> <469CAE36.2040903@crc.dk> Message-ID: <469D2616.1080301@crc.dk> alan wrote: ... > How do you recognise individual discs? By label? By hash of the entire > disc? Some other method? That is the one problem I have not been able > to solve in a quick manner. > I recognize the disk by the label printed on it :-) I assign names to the disk sequentially, like USERNAME001, USERNAME002, etc. So before burning data for USERNAME I check the database for the last number and add one. The disk is labelled using the -V USERNAME001 option to mkisofs. This means that the disk will be mounted as /media/USERNAME001, and you'll see the label as well when you insert the cd in a windows machine. Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From buildsys at fedoraproject.org Tue Jul 17 20:42:58 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 17 Jul 2007 20:42:58 -0000 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-07-17 Message-ID: <20070717204258.21405.10335@extras64.linux.duke.edu> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): andreas.bierfert AT lowlatency.de syncekonnector - 0.3.2-2.fc7.i386 (28 days) syncekonnector - 0.3.2-2.fc7.i386 (28 days) syncekonnector - 0.3.2-2.fc7.ppc (28 days) syncekonnector - 0.3.2-2.fc7.x86_64 (28 days) bjohnson AT symetrix.com dbmail - 2.2.4-4.fc7.i386 (12 days) caillon AT redhat.com f-spot - 0.3.5-2.fc7.i386 (6 days) f-spot - 0.3.5-2.fc7.ppc (6 days) f-spot - 0.3.5-2.fc7.x86_64 (6 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (45 days) oliver AT linux-kernel.at syck-php - 0.55-16.fc7.i386 (2 days) syck-php - 0.55-16.fc7.ppc (2 days) syck-php - 0.55-16.fc7.x86_64 (2 days) steve AT silug.org cpanspec - 1.72-1.fc7.noarch cpanspec - 1.72-1.fc7.noarch cpanspec - 1.72-1.fc7.noarch tcallawa AT redhat.com compat-wxGTK-devel - 2.4.2-21.fc6.i386 compat-wxGTK-devel - 2.4.2-21.fc6.i386 compat-wxGTK-devel - 2.4.2-21.fc6.ppc compat-wxGTK-devel - 2.4.2-21.fc6.x86_64 compat-wxGTK-gl - 2.4.2-21.fc6.i386 compat-wxGTK-gl - 2.4.2-21.fc6.i386 compat-wxGTK-gl - 2.4.2-21.fc6.ppc compat-wxGTK-gl - 2.4.2-21.fc6.x86_64 compat-wxGTK-stc - 2.4.2-21.fc6.i386 compat-wxGTK-stc - 2.4.2-21.fc6.i386 compat-wxGTK-stc - 2.4.2-21.fc6.ppc compat-wxGTK-stc - 2.4.2-21.fc6.x86_64 compat-wxGTK-xrc - 2.4.2-21.fc6.i386 compat-wxGTK-xrc - 2.4.2-21.fc6.i386 compat-wxGTK-xrc - 2.4.2-21.fc6.ppc compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64 twoerner AT redhat.com postfix-pflogsumm - 2:2.4.3-2.fc7.i386 (32 days) postfix-pflogsumm - 2:2.4.3-2.fc7.ppc (32 days) postfix-pflogsumm - 2:2.4.3-2.fc7.x86_64 (32 days) ====================================================================== Broken packages in fedora-7-i386: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 f-spot-0.3.5-2.fc7.i386 requires mono(gtkhtml-sharp) = 0:2.16.0.0 ====================================================================== Broken packages in fedora-7-ppc: compat-wxGTK-devel-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.ppc requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 f-spot-0.3.5-2.fc7.ppc requires mono(gtkhtml-sharp) = 0:2.16.0.0 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 ====================================================================== Broken packages in fedora-7-x86_64: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires libwx_gtk-2.4.so.0()(64bit) compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-gl-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 dbmail-2.2.4-4.fc7.i386 requires dbmail-database-driver = 0:2.2.4-4.fc7 f-spot-0.3.5-2.fc7.x86_64 requires mono(gtkhtml-sharp) = 0:2.16.0.0 ====================================================================== Broken packages in fedora-updates-7-i386: postfix-pflogsumm-2:2.4.3-2.fc7.i386 requires postfix = 0:2.4.3-2.fc7 syck-php-0.55-16.fc7.i386 requires php = 0:5.2.2 syncekonnector-0.3.2-2.fc7.i386 requires libmultisynk.so.0 syncekonnector-0.3.2-2.fc7.i386 requires libksync.so.1 syncekonnector-0.3.2-2.fc7.i386 requires libkonnector.so.0 ====================================================================== Broken packages in fedora-updates-7-ppc: postfix-pflogsumm-2:2.4.3-2.fc7.ppc requires postfix = 0:2.4.3-2.fc7 syck-php-0.55-16.fc7.ppc requires php = 0:5.2.2 syncekonnector-0.3.2-2.fc7.ppc requires libmultisynk.so.0 syncekonnector-0.3.2-2.fc7.ppc requires libkonnector.so.0 syncekonnector-0.3.2-2.fc7.ppc requires libksync.so.1 ====================================================================== Broken packages in fedora-updates-7-x86_64: postfix-pflogsumm-2:2.4.3-2.fc7.x86_64 requires postfix = 0:2.4.3-2.fc7 syck-php-0.55-16.fc7.x86_64 requires php = 0:5.2.2 syncekonnector-0.3.2-2.fc7.i386 requires libmultisynk.so.0 syncekonnector-0.3.2-2.fc7.i386 requires libksync.so.1 syncekonnector-0.3.2-2.fc7.i386 requires libkonnector.so.0 syncekonnector-0.3.2-2.fc7.x86_64 requires libmultisynk.so.0()(64bit) syncekonnector-0.3.2-2.fc7.x86_64 requires libksync.so.1()(64bit) syncekonnector-0.3.2-2.fc7.x86_64 requires libkonnector.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-testing-7-i386: cpanspec-1.72-1.fc7.noarch requires perl(IO::Uncompress::Bunzip2) ====================================================================== Broken packages in fedora-updates-testing-7-ppc: cpanspec-1.72-1.fc7.noarch requires perl(IO::Uncompress::Bunzip2) ====================================================================== Broken packages in fedora-updates-testing-7-x86_64: cpanspec-1.72-1.fc7.noarch requires perl(IO::Uncompress::Bunzip2) From mschwendt.tmp0701.nospam at arcor.de Tue Jul 17 21:11:12 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 17 Jul 2007 23:11:12 +0200 Subject: Reminder: Fedora Update Tips In-Reply-To: <46967BC1.3020800@redhat.com> References: <46967BC1.3020800@redhat.com> Message-ID: <20070717231112.e7c834b7.mschwendt.tmp0701.nospam@arcor.de> On Thu, 12 Jul 2007 15:06:41 -0400, Warren Togami wrote: > Tips for Fedora Package Maintainers when issuing updates. > 2) EVR Version Problems > ======================= > Currently F7 uses Bodhi (the Fedora Updates System) while FE-6 uses the > legacy Extras buildsystem. This can sometimes create EVR promotion > problems between the distributions. Example: > > 1) foo-1.2.3-1.fc7 > foo-1.2.3-1.fc6 > 2) foo-1.2.4-1.fc7 is pushed to F7 updates-testing > foo-1.2.4-1.fc6 is built for FE-6 > 3) FC6 version of foo is "newer" than foo in F7, because the FC6 package > went directly into the repository while the F7 package is only in testing. That's only half of the story. The EVR problems check-script considers F7 Test Updates and still finds way too many broken upgrade paths. I think there are packagers who don't know about bodhi yet. From jonathan.underwood at gmail.com Tue Jul 17 21:02:07 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 17 Jul 2007 22:02:07 +0100 Subject: Video and Keymap Quirks In-Reply-To: <46937CFA.4050808@hhs.nl> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> Message-ID: <645d17210707171402j7e768b4bqb935b83e4b187057@mail.gmail.com> On 10/07/07, Hans de Goede wrote: > I'm mainly focusing on normal (ps2/usb keyboards) with extra keys for > multimedia and internet stuff. My solution currently assumes that: > 1) The kernel generates the correct keycodes for these keys (which is > true for all usb keyboards and most ps/2 keyboards) > For the few exceptional ps/2 non laptop keyboards manual setkeycodes calls > will be necessary, but that will be the case no matter what so for now I'm > ignoring this. > 2) That F-8 will keep using the kbd driver for Xorg, if F-8 will change to > evdev, then my plan needs to be reworked. [snip] On the subject of USB keyboards - I had a dell laptop and i plug an external USB keyboard into it. As well as the various multimedia keys, it has 3 buttons for Wake, Sleep and Power. On F-7, out of the box, the Sleep button succesfully suspends the laptop. But, once suspended, the Wake button doesn't resume the laptop (pressing the power button actually on the laptop does). Is it possible for the USB subsystem to react to ACPI events? Is it possible for the Wake key to work? [I should add that the Wake key does generate the correct keycodes as far as I can tell]. J. From jkeating at redhat.com Tue Jul 17 21:08:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 17:08:17 -0400 Subject: Video and Keymap Quirks In-Reply-To: <645d17210707171402j7e768b4bqb935b83e4b187057@mail.gmail.com> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> <645d17210707171402j7e768b4bqb935b83e4b187057@mail.gmail.com> Message-ID: <20070717170817.32e798cc@localhost.localdomain> On Tue, 17 Jul 2007 22:02:07 +0100 "Jonathan Underwood" wrote: > On the subject of USB keyboards - I had a dell laptop and i plug an > external USB keyboard into it. As well as the various multimedia keys, > it has 3 buttons for Wake, Sleep and Power. On F-7, out of the box, > the Sleep button succesfully suspends the laptop. But, once suspended, > the Wake button doesn't resume the laptop (pressing the power button > actually on the laptop does). Is it possible for the USB subsystem to > react to ACPI events? Is it possible for the Wake key to work? > > [I should add that the Wake key does generate the correct keycodes as > far as I can tell]. wouldn't that mean leaving the usb bus powered up and waiting for input while sleeping? Wouldn't that chew through battery faster? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Tue Jul 17 21:11:33 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 17 Jul 2007 16:11:33 -0500 Subject: Video and Keymap Quirks In-Reply-To: <20070717170817.32e798cc@localhost.localdomain> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> <645d17210707171402j7e768b4bqb935b83e4b187057@mail.gmail.com> <20070717170817.32e798cc@localhost.localdomain> Message-ID: <20070717211132.GA26028@humbolt.us.dell.com> On Tue, Jul 17, 2007 at 05:08:17PM -0400, Jesse Keating wrote: > On Tue, 17 Jul 2007 22:02:07 +0100 > "Jonathan Underwood" wrote: > > > On the subject of USB keyboards - I had a dell laptop and i plug an > > external USB keyboard into it. As well as the various multimedia keys, > > it has 3 buttons for Wake, Sleep and Power. On F-7, out of the box, > > the Sleep button succesfully suspends the laptop. But, once suspended, > > the Wake button doesn't resume the laptop (pressing the power button > > actually on the laptop does). Is it possible for the USB subsystem to > > react to ACPI events? Is it possible for the Wake key to work? > > > > [I should add that the Wake key does generate the correct keycodes as > > far as I can tell]. > > wouldn't that mean leaving the usb bus powered up and waiting for input > while sleeping? Wouldn't that chew through battery faster? Some BIOS have an option for wakeups via USB. Make sure that you have that option turned on, if available. -- Michael From jonathan.underwood at gmail.com Tue Jul 17 21:13:26 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 17 Jul 2007 22:13:26 +0100 Subject: Video and Keymap Quirks In-Reply-To: <20070717170817.32e798cc@localhost.localdomain> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> <645d17210707171402j7e768b4bqb935b83e4b187057@mail.gmail.com> <20070717170817.32e798cc@localhost.localdomain> Message-ID: <645d17210707171413y714c5c27v4fee195887ba621d@mail.gmail.com> On 17/07/07, Jesse Keating wrote: > > wouldn't that mean leaving the usb bus powered up and waiting for input > while sleeping? Wouldn't that chew through battery faster? You'd think so, wouldn't you. I am not sure how much power is drawn from the keyboard, probably very little. There must be some reason why this button is there though. :) I guess the answer is probably in the ACPI specs, where it presumably says something about the USB bus and ACPI events in S3. Might go look. From kevin.kofler at chello.at Tue Jul 17 21:58:01 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 17 Jul 2007 21:58:01 +0000 (UTC) Subject: [New Feature Proposition]: Nodoka Theme References: <1184663992.21133.15.camel@pc-notebook> Message-ID: Martin Sourada seznam.cz> writes: > following advice from Rahul [1] I propose a new Feature for Fedora 8 - > Nodoka Theme. The Nodoka theme is currently targeted on Gnome and > contains metacity theme, gtk engine, gtk theme and gnome metatheme. How about matching KDE (Qt 4, Qt 3 and KWin 4) themes? Note that I'm not promising they would be the default if you make them, that decision is up to the KDE SIG and would definitely have to be discussed. But having the option of a consistent theme (a second one next to Bluecurve/Quarticurve ;-) ) would be nice. Kevin Kofler From lists-gawain at felicity-group.com Tue Jul 17 21:59:18 2007 From: lists-gawain at felicity-group.com (Gawain Lynch) Date: Wed, 18 Jul 2007 07:59:18 +1000 Subject: Automating pam_keyring... In-Reply-To: <20070717162124.5014a7e2@localhost.localdomain> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> Message-ID: <1184709558.6008.5.camel@legolas.felicity-group.com> On Tue, 2007-07-17 at 16:21 -0400, Jesse Keating wrote: > On Tue, 17 Jul 2007 21:54:22 +0200 > Alexander Dalloz wrote: > > > Yes, just the same kind of UI prompts for SSH and GPG keys. > > > > I have several SSH keys I load into ssh-agent at first login and thus > > get several UI input popups initiated by keychain. As well the keyring > > request for my wireless WPA key. Can't think of a way a single > > application would reduce the onetime amount of passphrase requests. > > Well, theoretically you'd allow gnome-keyring to save all those > passphrases and then you'd have a master passphrase (different from the > rest) that would allow gnome-keyring to dole them out as needed. But > yes, that puts all your eggs in the gnome-keyring basket and relying on > the strength of your master keyring. I always make sure my login > password/phrase is different than that of my master keyring phrase, and > that is different from any of the passphrases in my ring. It is not particularly elegant as such but I made a package based on code from this page that Works for Me... http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases From dtimms at iinet.net.au Tue Jul 17 22:06:44 2007 From: dtimms at iinet.net.au (David Timms) Date: Wed, 18 Jul 2007 08:06:44 +1000 Subject: mysql-administrator segfaults In-Reply-To: References: <200706170921.53623.manuel@todo-linux.com> Message-ID: <469D3D74.4070506@iinet.net.au> Chris Mohler wrote: > On 6/17/07, Manuel Arostegui Ramirez wrote: > [...] >> >> Did you take a look at the strace output? >> > > No - but there's a stack trace on this (duplicate?)bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244090 > > Seems it's fixed upstream and we just need an update... The update has been made, run through testing and is now in updates. This fixes the seg fault for me, OK, and I can create tables now. DaveT. From wtogami at redhat.com Tue Jul 17 22:29:40 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 17 Jul 2007 18:29:40 -0400 Subject: Squid 3 In-Reply-To: References: <469BF71D.5050506@gmail.com> <1184640796.3644.7.camel@lt21223.campus.dmacc.edu> Message-ID: <469D42D4.3010506@redhat.com> Kevin Kofler wrote: > Jeffrey C. Ollie ocjtech.us> writes: >> Sounds more like a candidate for F9 to me - the F8 feature freeze is set >> for 28 August 2007. > > But if there's beta releases, they could get into Rawhide right now, and > gradually upgraded to the final. That's what we're doing for KDE 4. > > Kevin Kofler > Squid stable hasn't changed much for many years now. Let's wait at least until F9 to see how the new Squid 3 fares, and not rush to include it before it is proven. Warren Togami wtogami at redhat.com From chitlesh at fedoraproject.org Tue Jul 17 22:33:08 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Wed, 18 Jul 2007 00:33:08 +0200 Subject: LICENSE: alliance ; VLSI CAD system In-Reply-To: <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> References: <13dbfe4f0707121742m53186e01s8040c868a28be4d1@mail.gmail.com> <20070713180828.GR20762@devserv.devel.redhat.com> <13dbfe4f0707131122j1c85eef4ld29ffccf7229ce0a@mail.gmail.com> Message-ID: <13dbfe4f0707171533r43085d3eu83f48b4a22c5fc01@mail.gmail.com> On 7/13/07, Chitlesh GOORAH wrote: > I was thinking to add it in a separate "alliance.fedora" file. Ok, I've requested a package review for allliance. This package is somehow different from other common packages. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649 Chitlesh -- http://clunixchit.blogspot.com From bojan at rexursive.com Tue Jul 17 23:02:31 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 18 Jul 2007 09:02:31 +1000 Subject: Updates: who's allowed to push Message-ID: <1184713351.17393.2.camel@shrek.rexursive.com> I've been trying to get the package maintainer to push an update of clamav for F7, but I'm guessing he's away ATM. So, in the absence of package maintainer, who's allowed to push the package (which has already been built in Koji)? This is regarding this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240395 -- Bojan From martin.sourada at seznam.cz Tue Jul 17 23:28:20 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 18 Jul 2007 01:28:20 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: References: <1184663992.21133.15.camel@pc-notebook> Message-ID: <1184714900.8695.9.camel@pc-notebook> On Tue, 2007-07-17 at 23:58 +0200, Kevin Kofler wrote: > Martin Sourada seznam.cz> writes: > > following advice from Rahul [1] I propose a new Feature for Fedora 8 - > > Nodoka Theme. The Nodoka theme is currently targeted on Gnome and > > contains metacity theme, gtk engine, gtk theme and gnome metatheme. > > How about matching KDE (Qt 4, Qt 3 and KWin 4) themes? > > Note that I'm not promising they would be the default if you make them, that > decision is up to the KDE SIG and would definitely have to be discussed. But > having the option of a consistent theme (a second one next to > Bluecurve/Quarticurve ;-) ) would be nice. > > Kevin Kofler > I have them in mind as well, but probably I won't start them before Fedora 8 (unless someone volunteers to do them). As I don't have KDE even installed and KDE 4 is probably going to be default in Fedora 8, but packages are still not in Rawhide, AFAIK. But I agree that it would be nice to have it... So, if there is any volunteer who'd like to make a nodoka theme for KDE following the mockup on the nodoka theme wiki [1], his help will be greatly appreciated :) Martin References: [1] http://fedoraproject.org/wiki/Artwork/NodokaTheme -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lostson at lostsonsvault.org Wed Jul 18 00:34:54 2007 From: lostson at lostsonsvault.org (lostson) Date: Tue, 17 Jul 2007 19:34:54 -0500 Subject: F-spot bug Message-ID: <1184718894.28109.1.camel@localhost.localdomain> Hello All When is the f-spot bug or this one if you prefer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247831 Gonna be resolved ? I need to get f-spot installed, thanks. LostSon http://www.lostsonsvault.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed Jul 18 00:45:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 06:15:39 +0530 Subject: F-spot bug In-Reply-To: <1184718894.28109.1.camel@localhost.localdomain> References: <1184718894.28109.1.camel@localhost.localdomain> Message-ID: <469D62B3.80200@fedoraproject.org> lostson wrote: > Hello All > When is the f-spot bug or this one if you prefer > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247831 > > Gonna be resolved ? I need to get f-spot installed, thanks. The bug report says a new package has been built at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247831#c23 which is a good indication that is getting resolved. Rahul From lostson at lostsonsvault.org Wed Jul 18 00:50:56 2007 From: lostson at lostsonsvault.org (lostson) Date: Tue, 17 Jul 2007 19:50:56 -0500 Subject: F-spot bug In-Reply-To: <469D62B3.80200@fedoraproject.org> References: <1184718894.28109.1.camel@localhost.localdomain> <469D62B3.80200@fedoraproject.org> Message-ID: <1184719856.28232.0.camel@localhost.localdomain> On Wed, 2007-07-18 at 06:15 +0530, Rahul Sundaram wrote: > lostson wrote: > > Hello All > > When is the f-spot bug or this one if you prefer > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247831 > > > > Gonna be resolved ? I need to get f-spot installed, thanks. > > The bug report says a new package has been built at > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247831#c23 which is > a good indication that is getting resolved. > > Rahul sweet I hope it hits soon ! -- LostSon http://www.lostsonsvault.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bbbush.yuan at gmail.com Wed Jul 18 01:31:01 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Wed, 18 Jul 2007 09:31:01 +0800 Subject: Presto: what happened to it? In-Reply-To: <1184691215.6534.5.camel@localhost.localdomain> References: <1184688237.3732.5.camel@sb-home> <1184691215.6534.5.camel@localhost.localdomain> Message-ID: <76e72f800707171831x528c26dcqa9168667974a9517@mail.gmail.com> 2007/7/18, Jeremy Katz : > There's actually work underway to get to where we can enable presto by > default. Jonathan took a number of patches from me to clean things up a > bit and those are present in the most recent presto release (0.4.0). > Also, there's some work starting to get underway to add the support > within the buildsystem for deltarpm generation. This will make it > possible for us to create and distribute them natively as part of the > distro/update build process. > > So the short answer is, we're working on it and it's currently being > tracked as a proposed feature for Fedora 8[1] > I have been using presto 0.4.0 since its release. I need to change 3 lines to make it work, one is that it cannot find 'Errors' but 'yum.Errors', another one is add 'DRPM' before file path, because there is nowhere to mention that directory level, it is not in the delta primary xml. After that everything goes without any problem, though not all packages have a delta (because the repo is relatively new I think). The repo is really fast and up-to-date. -- bbbush ^_^ From hellwolf.misty at gmail.com Wed Jul 18 01:41:36 2007 From: hellwolf.misty at gmail.com (ZC Miao) Date: Wed, 18 Jul 2007 09:41:36 +0800 Subject: Proposal : Add a "check partitions on next startup" feature to initrd(or initscript) Message-ID: <1184722897.2900.6.camel@cocteau.freehell.org> As MS Windows has this feature for a long time, is it possible to add this feature to the current startup process? -- http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F Animals can be driven crazy by putting too many in too small a pen. Homo sapiens is the only animal that voluntarily does this to himself. -- Lazarus Long From peter at thecodergeek.com Wed Jul 18 01:59:11 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 17 Jul 2007 18:59:11 -0700 Subject: Proposal : Add a "check partitions on next startup" feature to initrd(or initscript) In-Reply-To: <1184722897.2900.6.camel@cocteau.freehell.org> References: <1184722897.2900.6.camel@cocteau.freehell.org> Message-ID: <1184723951.30590.2.camel@tuxhugs> On Wed, 2007-07-18 at 09:41 +0800, ZC Miao wrote: > As MS Windows has this feature for a long time, is it possible to add > this feature to the current startup process? As in, a filesystem check? This is already done automatically before the partitions are mounted. However, thanks to journaling, these checks are normally very quick, and any repairs that need to be done take only a few brief moments longer. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tonynelson at georgeanelson.com Wed Jul 18 02:33:29 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 17 Jul 2007 22:33:29 -0400 Subject: Proposal : Add a "check partitions on next startup" feature to initrd(or initscript) In-Reply-To: <1184722897.2900.6.camel@cocteau.freehell.org> References: <1184722897.2900.6.camel@cocteau.freehell.org> Message-ID: At 9:41 AM +0800 7/18/07, ZC Miao wrote: > As MS Windows has this feature for a long time, is it possible to add >this feature to the current startup process? It's there. Search for fsck in /etc/rc.d/rc.sysinit. -- ____________________________________________________________________ TonyN.:' ' From notting at redhat.com Wed Jul 18 04:46:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Jul 2007 00:46:52 -0400 Subject: Proposal : Add a "check partitions on next startup" feature to initrd(or initscript) In-Reply-To: <1184722897.2900.6.camel@cocteau.freehell.org> References: <1184722897.2900.6.camel@cocteau.freehell.org> Message-ID: <20070718044652.GA6567@nostromo.devel.redhat.com> ZC Miao (hellwolf.misty at gmail.com) said: > As MS Windows has this feature for a long time, is it possible to add > this feature to the current startup process? shutdown -F? Bill From denis at poolshark.org Wed Jul 18 05:52:12 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 18 Jul 2007 07:52:12 +0200 Subject: inkscape in rawhide segfaults immediately on start up In-Reply-To: <469CD60B.8040009@redhat.com> References: <469CD60B.8040009@redhat.com> Message-ID: <469DAA8C.4060005@poolshark.org> Richard W.M. Jones wrote: > I haven't looked into this in great detail yet, but I wonder if this is > a known problem? There is no bugzilla that I can find and it's a > complete show-stopper so I can't imagine how it got past even the most > minimal test. Works here, what version of glib2 and glibmm24 do you have installed ? I'll make sure to push a rebuild before we hit f8t1. From sean.bruno at dsl-only.net Wed Jul 18 06:41:12 2007 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue, 17 Jul 2007 23:41:12 -0700 Subject: dmraid and rawhide Message-ID: <1184740872.3643.1.camel@home-desk> Tested today's rawhide to see if anaconda can tell if a dmraid controller is disabled(nvidia CK804 in my test). So far so good, it sees two separate disks instead of /dev/mapper/mpath0. Next tests will be to do full installs and test s/w raid and dmraid assisted s/w raid. Sean From tla at rasmil.dk Wed Jul 18 07:05:45 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 18 Jul 2007 09:05:45 +0200 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> Message-ID: <469DBBC9.1040801@rasmil.dk> Debarshi 'Rishi' Ray wrote: > What about Opium? > > Pirut (pronounced 'pirate') stands for Package Installation, Removal & > Update Tool. > Opium can be Offline Package Installation & Update Manager. > > The offline tool may be rarely used to remove a package. > > Cheerio, > Debarshi +1 for Opium Tim From debarshi.ray at gmail.com Wed Jul 18 08:48:33 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 18 Jul 2007 14:18:33 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <469DBBC9.1040801@rasmil.dk> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> Message-ID: <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> http://pho.ucsd.edu/rjhala/papers/opium.pdf http://www.osnews.com/story.php/18021/OPIUM-Optimal-Package-InstallUninstall-Manager There is a package manager named Opium (Optimal Package Install/Uninstall Manager) already. However there seems to be no package named Opium in either Debian or Fedora. If 'Opium' is a problem, can we go for some deviation of it which can still be pronounced as 'Opium'? eg., Opyum -- Offline Package manager using YUM. After all Pirut is a deviation of Pirate. :-) Comments? Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From gilboad at gmail.com Wed Jul 18 09:26:38 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 18 Jul 2007 12:26:38 +0300 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> Message-ID: <1184750798.4382.17.camel@gilboa-work-dev.localdomain> On Wed, 2007-07-18 at 14:18 +0530, Debarshi 'Rishi' Ray wrote: > http://pho.ucsd.edu/rjhala/papers/opium.pdf > http://www.osnews.com/story.php/18021/OPIUM-Optimal-Package-InstallUninstall-Manager > > There is a package manager named Opium (Optimal Package > Install/Uninstall Manager) already. However there seems to be no > package named Opium in either Debian or Fedora. > > If 'Opium' is a problem, can we go for some deviation of it which can > still be pronounced as 'Opium'? eg., Opyum -- Offline Package manager > using YUM. After all Pirut is a deviation of Pirate. :-) > > Comments? > > Cheers, > Debarshi /+1 for Opyum. - Gilboa From gilboad at gmail.com Wed Jul 18 09:28:47 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 18 Jul 2007 12:28:47 +0300 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184714900.8695.9.camel@pc-notebook> References: <1184663992.21133.15.camel@pc-notebook> <1184714900.8695.9.camel@pc-notebook> Message-ID: <1184750927.4382.20.camel@gilboa-work-dev.localdomain> On Wed, 2007-07-18 at 01:28 +0200, Martin Sourada wrote: > On Tue, 2007-07-17 at 23:58 +0200, Kevin Kofler wrote: > > Martin Sourada seznam.cz> writes: > > > following advice from Rahul [1] I propose a new Feature for Fedora 8 - > > > Nodoka Theme. The Nodoka theme is currently targeted on Gnome and > > > contains metacity theme, gtk engine, gtk theme and gnome metatheme. > > > > How about matching KDE (Qt 4, Qt 3 and KWin 4) themes? > > > > Note that I'm not promising they would be the default if you make them, that > > decision is up to the KDE SIG and would definitely have to be discussed. But > > having the option of a consistent theme (a second one next to > > Bluecurve/Quarticurve ;-) ) would be nice. > > > > Kevin Kofler > > > > I have them in mind as well, but probably I won't start them before > Fedora 8 (unless someone volunteers to do them). As I don't have KDE > even installed and KDE 4 is probably going to be default in Fedora 8, > but packages are still not in Rawhide, AFAIK. But I agree that it would > be nice to have it... > > So, if there is any volunteer who'd like to make a nodoka theme for KDE > following the mockup on the nodoka theme wiki [1], his help will be > greatly appreciated :) > > Martin > > References: > [1] http://fedoraproject.org/wiki/Artwork/NodokaTheme Are you going to upstream it? Once upstream it should be easier to find someone in the KDE side of things to create a similar-looking-KDE-port. - Gilboa From sundaram at fedoraproject.org Wed Jul 18 09:34:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 15:04:28 +0530 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184750927.4382.20.camel@gilboa-work-dev.localdomain> References: <1184663992.21133.15.camel@pc-notebook> <1184714900.8695.9.camel@pc-notebook> <1184750927.4382.20.camel@gilboa-work-dev.localdomain> Message-ID: <469DDEA4.2040104@fedoraproject.org> Gilboa Davara wrote: >> [1] http://fedoraproject.org/wiki/Artwork/NodokaTheme > > Are you going to upstream it? > Once upstream it should be easier to find someone in the KDE side of > things to create a similar-looking-KDE-port. What do you mean by upstreaming it? This is a theme that requires it's own engine. Essentially Fedora *is* upstream here. Rahul From buildsys at redhat.com Wed Jul 18 09:53:05 2007 From: buildsys at redhat.com (Build System) Date: Wed, 18 Jul 2007 05:53:05 -0400 Subject: rawhide report: 20070718 changes Message-ID: <200707180953.l6I9r5Du027735@porkchop.devel.redhat.com> New package R-BufferedMatrix A matrix data storage object held in temporary files New package slim Simple Login Manager New package teckit Conversion library and mapping compiler Updated Packages: bind-31:9.5.0a5-3.fc8 --------------------- * Tue Jul 17 2007 Adam Tkac 31:9.5.0a5-3.fc8 - handle integer overflow in isc_time_secondsastimet function gracefully (#247856) * Mon Jul 16 2007 Adam Tkac 31:9.5.0a5-2.2.fc8 - moved chroot configfiles into chroot subpackage (#248306) clamav-0.91.1-0.fc8 ------------------- * Tue Jul 17 2007 Enrico Scholz - 0.91.1-0 - updated to 0.91.1 compat-libosip2-2.2.2-13.fc8 ---------------------------- * Tue Jul 17 2007 Jeffrey C. Ollie - 2.2.2-13 - Remove provides libosip2-devel crossfire-1.10.0-2.fc8 ---------------------- * Thu Jul 12 2007 Wart 1.10.0-2 - Move client images outside of the server data directory. - Update selinux policy device-mapper-1.02.21-1.fc8 --------------------------- * Tue Jul 17 2007 Alasdair Kergon - 1.02.21-1 - Add tree-based and dependency fields to dmsetup reports. - Fix default dmsetup report buffering and add --unbuffered. - Avoid trailing separator in reports when there are hidden sort fields. - Add regex functions to library. - Fix segfault in 'dmsetup status' without --showkeys against crypt target. * Tue Feb 27 2007 Alasdair Kergon - 1.02.17-7 - The -libs package Obsoletes pre-split packages. * Wed Feb 14 2007 Alasdair Kergon - 1.02.17-6 - Move shared library into a separate -libs package. eclipse-1:3.3.0-2.fc8 --------------------- * Mon Jul 16 2007 Ben Konrath 3.3.0-2 - Fix dep in rcp sub-package. - Add Alpha support. - Link to commons-logging.jar - Resolves: #248359. * Fri Jun 29 2007 Ben Konrath 3.3.0-1 - 3.3. * Wed Jun 27 2007 Ben Konrath 3.3.0-0.3.RC4 - Restore ppc64, s390{,x} and sparc{,64} support. - Restore multilib support. esc-1.0.1-5.fc8 --------------- * Tue Jul 17 2007 Jack Magne - 1.0.1-5 - Further fixes to the diagnostics logging. * Wed Jun 20 2007 Jack Magne - 1.0.1-4 - Fixes to the diagnostics log files and esc error messages. * Thu Apr 26 2007 Jack Magne - 1.0.1-3 - Many UI usability fixes. evolution-data-server-1.11.5-2.fc8 ---------------------------------- * Tue Jul 17 2007 Matthew Barnes - 1.11.5-2.fc8 - Add patch for RH bug #243296 (fix LDAP configuration). gnome-sharp-2.16.0-3.fc8 ------------------------ * Tue Jul 17 2007 Xavier Lamien < lxtnow[at]gmail.com > - 2.16.0-3 - Fixed gtkhtml dependency version [bug #247831] guile-5:1.8.2-1.fc8 ------------------- * Tue Jul 17 2007 Miroslav Lichvar - 5:1.8.2-1 - update to 1.8.2 - remove dot from -devel summary, convert goops.info to UTF-8 hdhomerun-0.0-0.3.20070716.fc8 ------------------------------ * Tue Jul 17 2007 Jarod Wilson 0.0-0.3.20070716 - Update to 20070716 release hplip-2.7.6-8.fc8 ----------------- * Tue Jul 17 2007 Tim Waugh 2.7.6-8 - Fixed hp-toolbox desktop file (bug #248560). hunspell-1.1.8-1.fc8 -------------------- * Tue Jul 17 2007 Caolan McNamara - 1.1.8-1 - latest version kbibtex-0.1.5.52-10.fc7 ----------------------- * Mon Jul 09 2007 Christian Nolte - 0.1.5.52-10 - Updated to latest upstream version kexec-tools-1.101-74.fc8 ------------------------ * Tue Jul 17 2007 Neil Horman - 1.101-74.fc8 - Fix up add_buff to retry locate_hole on segment overlap (bz 247989) lynx-2.8.6-4.fc8 ---------------- * Tue Jul 17 2007 Ivana Varekova - 2.8.6-4 - remove default-colors option openct-0.6.12-1.fc8 ------------------- * Tue Jul 17 2007 Ville Skytt?? - 0.6.12-1 - 0.6.12. - Add Default-Start and Default-Stop to init script. openhpi-2.8.1-3.fc8 ------------------- * Tue Jul 17 2007 Phil Knirsch - 2.8.1-3 - Fixed a bug where the snmp_bc plugin didn't work in IBM BC (#247280) opensc-0.11.3-1.fc8 ------------------- * Tue Jul 17 2007 Ville Skytt?? - 0.11.3-1 - 0.11.3. * Sat Jun 30 2007 Ville Skytt?? - 0.11.3-0.1.pre2 - 0.11.3-pre2. oprofile-0.9.3-1.fc8 -------------------- * Tue Jul 17 2007 Will Cohen - 0.9.3-1 - Rebase on 0.9.3 release. - Disable xen patch until fixed. perl-Compress-Raw-Bzip2-2.005-2.fc8 ----------------------------------- perl-Compress-Raw-Zlib-2.005-2.fc8 ---------------------------------- perl-DBD-Pg-1.49-4.fc8 ---------------------- * Tue Jul 17 2007 Robin Norwood - 1.49-4 - Fix summary perl-IO-Compress-Base-2.005-2.fc8 --------------------------------- * Tue Jul 17 2007 Robin Norwood - 2.005-2 - Bump release to beat F-7 version perl-IO-Compress-Bzip2-2.005-2.fc8 ---------------------------------- perl-IO-Compress-Zlib-2.005-2.fc8 --------------------------------- pykickstart-1.5-1.fc8 --------------------- * Tue Jul 17 2007 Chris Lumens 1.5-1 - Fix traceback when calling preprocessKickstart. * Tue Jul 17 2007 Chris Lumens 1.4-1 - Add methods to handle the %ksappend directive. - Fix ignoredisk --disks. shorewall-3.4.5-1.fc8 --------------------- * Tue Jul 17 2007 Robert Marcano - 3.4.5-1 - Update to upstream 3.4.5 uw-imap-2006j-2.fc8 ------------------- * Tue Jul 17 2007 Rex Dieter 2006j-2 - imap-2006j2 vnc-4.1.2-19.fc8 ---------------- * Tue Jul 17 2007 Adam Tkac 4.1.2-19.fc8 - initscript is ready for parallel booting (#247092) Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) dkms - 2.0.16-1.fc7.noarch requires kernel-devel eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) fuse - 2.6.5-2.fc8.ppc64 requires kernel >= 0:2.6.14 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 pcmciautils - 014-9.fc8.ppc64 requires kernel >= 0:2.6.12-1.1411_FC5 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) systemtap - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) varnish - 1.0.4-2.fc8.ppc64 requires kernel >= 0:2.6.0 vpnc - 0.4.0-2.fc7.ppc64 requires kernel >= 0:2.4 xorg-x11-drv-nouveau - 2.1.2-1.fc8.ppc64 requires kernel-drm-nouveau = 0:6 From jos at xos.nl Wed Jul 18 10:04:38 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 18 Jul 2007 12:04:38 +0200 Subject: python-lxml version Message-ID: <200707181004.l6IA4cf21359@xos037.xos.nl> Hi, Is there a technical reason why python-lxml in rawhide is still at version 1.1.2? 1.2 came out in February, and in the meantime 1.3 and 1.3.1 (very recently) were released too. Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From pvrabec at redhat.com Wed Jul 18 10:20:13 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 18 Jul 2007 12:20:13 +0200 Subject: rsyslog is in F8 Message-ID: <469DE95D.8080006@redhat.com> Hi folks, rsyslog was just built in rawhide. It obsoletes sysklogd, so sysklogd in not running anymore and is erased after update. Note, that rsyslog won't start automatically. You need to do #service rsyslog start,(or restart the box). This problem should be solved by anaconda during upgrade from FC->F8. sysklogd config files syslog.conf, sysconfig/syslog are renamed to rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog is replaced. Have fun with enhanced system logging daemon. It provides many interesting features. See upstream for more details, http://www.rsyslog.com/ From sundaram at fedoraproject.org Wed Jul 18 10:20:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 15:50:22 +0530 Subject: rsyslog is in F8 In-Reply-To: <469DE95D.8080006@redhat.com> References: <469DE95D.8080006@redhat.com> Message-ID: <469DE966.6040109@fedoraproject.org> Peter Vrabec wrote: > Hi folks, > > rsyslog was just built in rawhide. > > It obsoletes sysklogd, so sysklogd in not running anymore and is erased > after update. Note, that rsyslog won't start automatically. You need to > do #service rsyslog start,(or restart the box). This problem should be > solved by anaconda during upgrade from FC->F8. What happens if I upgrade using yum? Rahul From tmraz at redhat.com Wed Jul 18 10:34:13 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 18 Jul 2007 12:34:13 +0200 Subject: rsyslog is in F8 In-Reply-To: <469DE966.6040109@fedoraproject.org> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> Message-ID: <1184754853.18158.0.camel@perun.kabelta.loc> On Wed, 2007-07-18 at 15:50 +0530, Rahul Sundaram wrote: > Peter Vrabec wrote: > > Hi folks, > > > > rsyslog was just built in rawhide. > > > > It obsoletes sysklogd, so sysklogd in not running anymore and is erased > > after update. Note, that rsyslog won't start automatically. You need to > > do #service rsyslog start,(or restart the box). This problem should be > > solved by anaconda during upgrade from FC->F8. > > What happens if I upgrade using yum? You won't have running system log daemon until you restart the system or run service rsyslog start manually. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From wolfy at nobugconsulting.ro Wed Jul 18 10:47:51 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jul 2007 13:47:51 +0300 Subject: rsyslog is in F8 In-Reply-To: <1184754853.18158.0.camel@perun.kabelta.loc> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> Message-ID: <469DEFD7.5030209@nobugconsulting.ro> Tomas Mraz wrote: > On Wed, 2007-07-18 at 15:50 +0530, Rahul Sundaram wrote: > >> Peter Vrabec wrote: >> >>> Hi folks, >>> >>> rsyslog was just built in rawhide. >>> >>> It obsoletes sysklogd, so sysklogd in not running anymore and is erased >>> after update. Note, that rsyslog won't start automatically. You need to >>> do #service rsyslog start,(or restart the box). This problem should be >>> solved by anaconda during upgrade from FC->F8. >>> >> What happens if I upgrade using yum? >> > > You won't have running system log daemon until you restart the system or > run service rsyslog start manually. > I'd say that since sysklogd is erased, rsylogd should be automatically enabled and started. Yes, I know the packaging recommendations, but I think that in this case an exception should be accepted. Manuel From pvrabec at redhat.com Wed Jul 18 11:20:55 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 18 Jul 2007 13:20:55 +0200 Subject: rsyslog is in F8 In-Reply-To: <469DEFD7.5030209@nobugconsulting.ro> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> Message-ID: <469DF797.2010305@redhat.com> Manuel Wolfshant wrote: > Tomas Mraz wrote: >> On Wed, 2007-07-18 at 15:50 +0530, Rahul Sundaram wrote: >> >>> Peter Vrabec wrote: >>> >>>> Hi folks, >>>> >>>> rsyslog was just built in rawhide. >>>> >>>> It obsoletes sysklogd, so sysklogd in not running anymore and is erased >>>> after update. Note, that rsyslog won't start automatically. You need to >>>> do #service rsyslog start,(or restart the box). This problem should be >>>> solved by anaconda during upgrade from FC->F8. >>>> >>> What happens if I upgrade using yum? >>> >> >> You won't have running system log daemon until you restart the system or >> run service rsyslog start manually. >> > I'd say that since sysklogd is erased, rsylogd should be automatically > enabled and started. Yes, I know the packaging recommendations, but I > think that in this case an exception should be accepted. I agree, but I don't know any nice and secure way we can do it. Since we replace sysklogd in rawhide and rsyslogd will be installed during fresh F8 installation I don't see this is a big problem. From wolfy at nobugconsulting.ro Wed Jul 18 11:27:48 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jul 2007 14:27:48 +0300 Subject: rsyslog is in F8 In-Reply-To: <469DF797.2010305@redhat.com> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> Message-ID: <469DF934.2050706@nobugconsulting.ro> Peter Vrabec wrote: > >>>>> It obsoletes sysklogd, so sysklogd in not running anymore and is erased >>>>> after update. Note, that rsyslog won't start automatically. You need to >>>>> do #service rsyslog start,(or restart the box). This problem should be >>>>> solved by anaconda during upgrade from FC->F8. >>>>> >>>>> >>>> What happens if I upgrade using yum? >>>> >>>> >>> You won't have running system log daemon until you restart the system or >>> run service rsyslog start manually. >>> >>> >> I'd say that since sysklogd is erased, rsylogd should be automatically >> enabled and started. Yes, I know the packaging recommendations, but I >> think that in this case an exception should be accepted. >> > > I agree, but I don't know any nice and secure way we can do it. shipping an /etc/init.d/rsyslog with default options set to enabled + service rsyslog start in %post is not OK ? > Since we replace sysklogd in rawhide and rsyslogd will be installed during fresh > F8 installation I don't see this is a big problem. You make the assumption that rawhide users will know about the replacement and activate rsyslogd manually. I bet most of them will blindly do yum -y update and cry afterwards. Do not assume that they are subscribed to fedora mailing lists. Most of them are not. Or at least almost none of those I personally know in the RLUG community, to be more correct. From nicu_fedora at nicubunu.ro Wed Jul 18 11:36:11 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 18 Jul 2007 14:36:11 +0300 Subject: rsyslog is in F8 In-Reply-To: <469DF934.2050706@nobugconsulting.ro> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> Message-ID: <469DFB2B.5020800@nicubunu.ro> Manuel Wolfshant wrote: > Peter Vrabec wrote: >> Since we replace sysklogd in rawhide and rsyslogd will be installed >> during fresh >> F8 installation I don't see this is a big problem. > You make the assumption that rawhide users will know about the > replacement and activate rsyslogd manually. I bet most of them will > blindly do yum -y update and > cry afterwards. Do not assume that they are subscribed to fedora mailing > lists. Most of them are not. Or at least almost none of those I > personally know in the RLUG community, to be more correct. I don't see this as a huge problem, this is rawhide, it it expected to kill your cat and eat your goldfish and from time to time it will even upgrade some components (kernel etc.) requiring you a reboot. PS: usually, I would have not interfered in this thread, but you baited me with the RLUG reference :p -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From rjones at redhat.com Wed Jul 18 11:39:43 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 18 Jul 2007 12:39:43 +0100 Subject: inkscape in rawhide segfaults immediately on start up In-Reply-To: <469DAA8C.4060005@poolshark.org> References: <469CD60B.8040009@redhat.com> <469DAA8C.4060005@poolshark.org> Message-ID: <469DFBFF.9070801@redhat.com> Denis Leroy wrote: > Richard W.M. Jones wrote: >> I haven't looked into this in great detail yet, but I wonder if this >> is a known problem? There is no bugzilla that I can find and it's a >> complete show-stopper so I can't imagine how it got past even the most >> minimal test. > > Works here, what version of glib2 and glibmm24 do you have installed ? > I'll make sure to push a rebuild before we hit f8t1. Thanks everyone for replying. I've reproduced this on two different x86-64 machines, both F7 up to date, so I opened a bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248700 Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From pvrabec at redhat.com Wed Jul 18 11:56:20 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 18 Jul 2007 13:56:20 +0200 Subject: rsyslog is in F8 In-Reply-To: <469DF934.2050706@nobugconsulting.ro> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> Message-ID: <469DFFE4.8070106@redhat.com> Manuel Wolfshant wrote: > Peter Vrabec wrote: >> >>>>>> It obsoletes sysklogd, so sysklogd in not running anymore and is >>>>>> erased >>>>>> after update. Note, that rsyslog won't start automatically. You >>>>>> need to >>>>>> do #service rsyslog start,(or restart the box). This problem >>>>>> should be >>>>>> solved by anaconda during upgrade from FC->F8. >>>>>> >>>>> What happens if I upgrade using yum? >>>>> >>>> You won't have running system log daemon until you restart the >>>> system or >>>> run service rsyslog start manually. >>>> >>> I'd say that since sysklogd is erased, rsylogd should be automatically >>> enabled and started. Yes, I know the packaging recommendations, but I >>> think that in this case an exception should be accepted. >>> >> >> I agree, but I don't know any nice and secure way we can do it. > shipping an /etc/init.d/rsyslog with default options set to enabled + > service rsyslog start in %post is not OK ? No, it not :-(. service rsyslog start will always start rsyslog, but we need to start rsyslog only when sysklogd run before. >> Since we replace sysklogd in rawhide and rsyslogd will be installed >> during fresh >> F8 installation I don't see this is a big problem. > You make the assumption that rawhide users will know about the > replacement and activate rsyslogd manually. I bet most of them will > blindly do yum -y update and > cry afterwards. Do not assume that they are subscribed to fedora mailing > lists. Most of them are not. Or at least almost none of those I > personally know in the RLUG community, to be more correct. > From kzak at redhat.com Wed Jul 18 12:09:05 2007 From: kzak at redhat.com (Karel Zak) Date: Wed, 18 Jul 2007 14:09:05 +0200 Subject: F8: remove rdev(8), ramdisk(8), vidmode(8) and rootflags(8) Message-ID: <20070718120905.GD3181@petra.dvoda.cz> I'd like to remove: rdev(8), ramdisk(8), vidmode(8) and rootflags(8) from Fedora 8. The commands seem obsolete and i386 specific. Comments & suggestion? Karel -- Karel Zak From wolfy at nobugconsulting.ro Wed Jul 18 12:15:28 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jul 2007 15:15:28 +0300 Subject: rsyslog is in F8 In-Reply-To: <469DFFE4.8070106@redhat.com> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <469DFFE4.8070106@redhat.com> Message-ID: <469E0460.9080909@nobugconsulting.ro> Peter Vrabec wrote: > > No, it not :-(. service rsyslog start will always start rsyslog, but we > need to start rsyslog only when sysklogd run before. Well, then how about %pre if ( enabled syslog && running sysklog) then touch /tmp/someflag %post if -f /tmp/someflag then chkconfig --enable 35 rsyslog as for if enabled -> chkconfig : chkconfig --list syslog | awk '{print $5,$7}' | ..... if running: service syslog status | grep running > I don't see this as a huge problem, this is rawhide, it it expected to > kill your cat and eat your goldfish and from time to time it will even > upgrade some components (kernel etc.) requiring you a reboot. Why kill fishes if a couple of bash lines would preserve them for your piranha ? From skvidal at linux.duke.edu Wed Jul 18 12:10:23 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 08:10:23 -0400 Subject: rsyslog is in F8 In-Reply-To: <469DE95D.8080006@redhat.com> References: <469DE95D.8080006@redhat.com> Message-ID: <1184760623.606.109.camel@cutter> On Wed, 2007-07-18 at 12:20 +0200, Peter Vrabec wrote: > Hi folks, > > rsyslog was just built in rawhide. > > It obsoletes sysklogd, so sysklogd in not running anymore and is erased > after update. Note, that rsyslog won't start automatically. You need to > do #service rsyslog start,(or restart the box). This problem should be > solved by anaconda during upgrade from FC->F8. > > sysklogd config files syslog.conf, sysconfig/syslog are renamed to > rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog > is replaced. > > I was looking at the package of rsyslog: why do you apply a patch to rename the daemons from syslogd and klogd to 'rklogd' and 'rsyslogd'? If sysklogd is being replaced by the obsoletes in this package - why name this one differently? And have your patches made it upstream? I'm not sure why we should have any patches applied to it, at all, in fedora. Rainer has been extremely responsive in getting things corrected. Finally, we have to have the daemon auto-start. People will 'yum update' from f7 to f8 and in the scenario you've provided they will not have a running syslog daemon in the vast majority of the cases. That's a problem. -sv From mike at miketc.com Wed Jul 18 12:21:22 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 18 Jul 2007 07:21:22 -0500 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> Message-ID: <1184761282.4571.2.camel@scrappy.miketc.com> On Wed, 2007-07-18 at 14:18 +0530, Debarshi 'Rishi' Ray wrote: > There is a package manager named Opium (Optimal Package > Install/Uninstall Manager) already. However there seems to be no > package named Opium in either Debian or Fedora. > > If 'Opium' is a problem, can we go for some deviation of it which can > still be pronounced as 'Opium'? eg., Opyum -- Offline Package manager > using YUM. After all Pirut is a deviation of Pirate. :-) I looked but have forgotten what all your software would be able to do, but if it does things offline, I"m sure it does them ONline as well? So why does offline need to be the head name/letter of the name? Why not just make up a very cool name for it? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From fedora at leemhuis.info Wed Jul 18 12:26:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Jul 2007 14:26:08 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? Message-ID: <469E06E0.9070304@leemhuis.info> Hi, Fedorablog.de started a new service called "repowatch" as beta. It gives a repo overview as webpages (and rss feed as well) similar to that from repoview. See http://www.fedorablog.de/archives/309-Repowatch-gestartet.html for announcement and http://repowatch.fedorablog.de/ for the data. That brought me to the question: what are our plans for a webinterface for packages? We had repoview in the past for Core and Extras, but that was dropped with the merge (likely due to "not much time, not critical/not important enough). Will we get it back? Or will Fedora just ignore the issue and leave that service to external groups? Or will the package database help somewhat in this regard? CU thl From alan at redhat.com Wed Jul 18 12:35:36 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 18 Jul 2007 08:35:36 -0400 Subject: F8: remove rdev(8), ramdisk(8), vidmode(8) and rootflags(8) In-Reply-To: <20070718120905.GD3181@petra.dvoda.cz> References: <20070718120905.GD3181@petra.dvoda.cz> Message-ID: <20070718123536.GA17819@devserv.devel.redhat.com> On Wed, Jul 18, 2007 at 02:09:05PM +0200, Karel Zak wrote: > > I'd like to remove: > > rdev(8), ramdisk(8), vidmode(8) and rootflags(8) > > from Fedora 8. The commands seem obsolete and i386 specific. > > Comments & suggestion? Looks sensible to me From pvrabec at redhat.com Wed Jul 18 12:48:21 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 18 Jul 2007 14:48:21 +0200 Subject: rsyslog is in F8 In-Reply-To: <1184760623.606.109.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> Message-ID: <469E0C15.6090103@redhat.com> seth vidal wrote: > On Wed, 2007-07-18 at 12:20 +0200, Peter Vrabec wrote: >> Hi folks, >> >> rsyslog was just built in rawhide. >> >> It obsoletes sysklogd, so sysklogd in not running anymore and is erased >> after update. Note, that rsyslog won't start automatically. You need to >> do #service rsyslog start,(or restart the box). This problem should be >> solved by anaconda during upgrade from FC->F8. >> >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog >> is replaced. >> >> > > I was looking at the package of rsyslog: why do you apply a patch to > rename the daemons from syslogd and klogd to 'rklogd' and 'rsyslogd'? If > sysklogd is being replaced by the obsoletes in this package - why name > this one differently? because package name is rsyslog. The patch will be excluded in next release, since it was accepted by upstream. > > And have your patches made it upstream? I'm not sure why we should have > any patches applied to it, at all, in fedora. Rainer has been extremely > responsive in getting things corrected. > > Finally, we have to have the daemon auto-start. People will 'yum update' > from f7 to f8 and in the scenario you've provided they will not have a > running syslog daemon in the vast majority of the cases. That's a > problem. > > -sv > > From skvidal at linux.duke.edu Wed Jul 18 12:41:29 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 08:41:29 -0400 Subject: rsyslog is in F8 In-Reply-To: <469E0C15.6090103@redhat.com> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <469E0C15.6090103@redhat.com> Message-ID: <1184762489.606.111.camel@cutter> On Wed, 2007-07-18 at 14:48 +0200, Peter Vrabec wrote: > > I was looking at the package of rsyslog: why do you apply a patch to > > rename the daemons from syslogd and klogd to 'rklogd' and 'rsyslogd'? If > > sysklogd is being replaced by the obsoletes in this package - why name > > this one differently? > because package name is rsyslog. The patch will be excluded in next > release, since it was accepted by upstream. Yes, but the upstream makefile creates them as syslogd and klogd. Since we try to follow upstream as much as possible - what's the reason for the change in the binary name? -sv From pvrabec at redhat.com Wed Jul 18 13:02:21 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 18 Jul 2007 15:02:21 +0200 Subject: rsyslog is in F8 In-Reply-To: <1184762489.606.111.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <469E0C15.6090103@redhat.com> <1184762489.606.111.camel@cutter> Message-ID: <469E0F5D.1060404@redhat.com> seth vidal wrote: > On Wed, 2007-07-18 at 14:48 +0200, Peter Vrabec wrote: >>> I was looking at the package of rsyslog: why do you apply a patch to >>> rename the daemons from syslogd and klogd to 'rklogd' and 'rsyslogd'? If >>> sysklogd is being replaced by the obsoletes in this package - why name >>> this one differently? >> because package name is rsyslog. The patch will be excluded in next >> release, since it was accepted by upstream. > > Yes, but the upstream makefile creates them as syslogd and klogd. http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/Makefile.am?revision=1.10&view=markup > Since > we try to follow upstream as much as possible - what's the reason for > the change in the binary name? > > -sv > > From hughsient at gmail.com Wed Jul 18 13:04:45 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 18 Jul 2007 14:04:45 +0100 Subject: Video and Keymap Quirks In-Reply-To: <645d17210707171413y714c5c27v4fee195887ba621d@mail.gmail.com> References: <1184058738.2249.16.camel@work> <46936DFC.4090904@hhs.nl> <1184067618.2249.84.camel@work> <46937CFA.4050808@hhs.nl> <645d17210707171402j7e768b4bqb935b83e4b187057@mail.gmail.com> <20070717170817.32e798cc@localhost.localdomain> <645d17210707171413y714c5c27v4fee195887ba621d@mail.gmail.com> Message-ID: <1184763885.7425.3.camel@work> On Tue, 2007-07-17 at 22:13 +0100, Jonathan Underwood wrote: > You'd think so, wouldn't you. I am not sure how much power is drawn > from the keyboard, probably very little. There must be some reason why > this button is there though. :) It's not a trivial amount of power. I can't remember the numbers, but you've got to remember you need to keep the intermediate hubs alive to keep the end device powered up. You probably don't want to keep any usb device alive when suspended. Richard. From icon at fedoraproject.org Wed Jul 18 13:12:07 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 18 Jul 2007 09:12:07 -0400 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <469E06E0.9070304@leemhuis.info> References: <469E06E0.9070304@leemhuis.info> Message-ID: On 7/18/07, Thorsten Leemhuis wrote: > That brought me to the question: what are our plans for a webinterface > for packages? We had repoview in the past for Core and Extras, but that > was dropped with the merge (likely due to "not much time, not > critical/not important enough). Will we get it back? Or will Fedora just > ignore the issue and leave that service to external groups? Or will the > package database help somewhat in this regard? I'm finishing up a rewrite of repoview that should dramatically improve the speed aspect. One of the advantages of repoview is that it generates static pages and thus doesn't require any "engine" to view the repository. Its major downside in current version is that it has to regenerate all the pages to see if they have changed, hence times 5000 packages, it took a Very Long Time for even minor changes to the repositories. New version does state-tracking, so small repository changes take only a couple of seconds to run, which should improve things dramatically. It's also rsync-friendly and only modifies the pages that have actually changed. I have it mostly finished, and only have to finish up a few things before releasing 0.6. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From kengert at redhat.com Wed Jul 18 13:24:46 2007 From: kengert at redhat.com (Kai Engert) Date: Wed, 18 Jul 2007 15:24:46 +0200 Subject: gecko-devel: rebuild or not to rebuild? Message-ID: <469E149E.1000001@redhat.com> We'll soon publish updated RPMs for a Firefox security release. The new version 2.0.0.5 will go into F-7 and devel. Please prepare to rebuild if you depend on gecko-devel. For FC-6 it will be a backport of patches, no new version number. So you should not need to rebuild. Thanks, Kai From debarshi.ray at gmail.com Wed Jul 18 13:39:16 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 18 Jul 2007 19:09:16 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <1184761282.4571.2.camel@scrappy.miketc.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> <1184761282.4571.2.camel@scrappy.miketc.com> Message-ID: <3170f42f0707180639r146ef78cj4df89bcb6a9207f5@mail.gmail.com> > I looked but have forgotten what all your software would be able to do, "This program is meant to enable users who do not have a viable network connection to manage their packages, ie. install new ones and update existing ones, through the standard package management framework used in Fedora. If you are interested then you can read more about it at https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay " > but if it does things offline, I"m sure it does them ONline as well? No it is not meant for online uses. That part is well served by Pirut. After all, the Offline Package Manager shares a lot of GUI and backend code with Pirut. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From fedora at ml.shredzone.de Wed Jul 18 13:39:35 2007 From: fedora at ml.shredzone.de (=?ISO-8859-15?Q?Richard_K=F6rber?=) Date: Wed, 18 Jul 2007 15:39:35 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? Message-ID: <469E1817.7050809@ml.shredzone.de> Thorsten Leemhuis wrote: > That brought me to the question: what are our plans for a webinterface > for packages? We had repoview in the past for Core and Extras, but that > was dropped with the merge (likely due to "not much time, not > critical/not important enough). Will we get it back? Or will Fedora just > ignore the issue and leave that service to external groups? Or will the > package database help somewhat in this regard? To avoid misunderstandings, I want to point out that repowatch is NOT meant to be a replacement for repoview. In fact it is even prepared to link directly into a repoview's package description. Unfortunately there are none yet for FC7. :) My primary goal for repowatch was to watch several repositories simultaneously, and give reports about packages that have been recently added or removed from a repository. A nice side effect is the possibility to online search for packages. The drawback of repowatch is that it requires a web server and a database, while the static pages of repoview can be used anywhere, even on a DVD. Best Regards -- Richard K?rber From katzj at redhat.com Wed Jul 18 13:37:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 18 Jul 2007 09:37:51 -0400 Subject: rsyslog is in F8 In-Reply-To: <469DF934.2050706@nobugconsulting.ro> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> Message-ID: <1184765871.9488.4.camel@localhost.localdomain> On Wed, 2007-07-18 at 14:27 +0300, Manuel Wolfshant wrote: > Peter Vrabec wrote: > >> I'd say that since sysklogd is erased, rsylogd should be automatically > >> enabled and started. Yes, I know the packaging recommendations, but I > >> think that in this case an exception should be accepted. > > > > I agree, but I don't know any nice and secure way we can do it. > shipping an /etc/init.d/rsyslog with default options set to enabled + > service rsyslog start in %post is not OK ? Starting a service in %post is not in at all okay. It can cause all sorts of havoc when installing systems, creating live images, init'ing chroots for building in, ... Jeremy From jeff at ocjtech.us Wed Jul 18 13:46:32 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 18 Jul 2007 08:46:32 -0500 Subject: python-lxml version In-Reply-To: <200707181004.l6IA4cf21359@xos037.xos.nl> References: <200707181004.l6IA4cf21359@xos037.xos.nl> Message-ID: <1184766392.4503.3.camel@lt21223.campus.dmacc.edu> On Wed, 2007-07-18 at 12:04 +0200, Jos Vos wrote: > Hi, > > Is there a technical reason why python-lxml in rawhide is still > at version 1.1.2? 1.2 came out in February, and in the meantime > 1.3 and 1.3.1 (very recently) were released too. I've had a bug open on this for a while: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245690 1.3.2 is out as well... 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 wolfy at nobugconsulting.ro Wed Jul 18 13:55:49 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 18 Jul 2007 16:55:49 +0300 Subject: rsyslog is in F8 In-Reply-To: <1184765871.9488.4.camel@localhost.localdomain> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> Message-ID: <469E1BE5.3030207@nobugconsulting.ro> Jeremy Katz wrote: > On Wed, 2007-07-18 at 14:27 +0300, Manuel Wolfshant wrote: > >> Peter Vrabec wrote: >> >>>> I'd say that since sysklogd is erased, rsylogd should be automatically >>>> enabled and started. Yes, I know the packaging recommendations, but I >>>> think that in this case an exception should be accepted. >>>> >>> I agree, but I don't know any nice and secure way we can do it. >>> >> shipping an /etc/init.d/rsyslog with default options set to enabled + >> service rsyslog start in %post is not OK ? >> > > Starting a service in %post is not in at all okay. It can cause all > sorts of havoc when installing systems, creating live images, init'ing > chroots for building in, ... > Generally speaking, yes. But in this case we are speaking about sysklogd's replacement. And sysklogd IS (was..) already enabled by default. manuel From jeff at ocjtech.us Wed Jul 18 14:00:54 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 18 Jul 2007 09:00:54 -0500 Subject: rsyslog is in F8 In-Reply-To: <1184760623.606.109.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> Message-ID: <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> On Wed, 2007-07-18 at 08:10 -0400, seth vidal wrote: > > Finally, we have to have the daemon auto-start. People will 'yum update' > from f7 to f8 and in the scenario you've provided they will not have a > running syslog daemon in the vast majority of the cases. That's a > problem. After a 'yum update' from F7 to F8 you'll need to reboot anyway to pick up the new kernel and to get everything to use the new shared libraries. 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 leemhuis.info Wed Jul 18 14:01:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Jul 2007 16:01:53 +0200 Subject: rsyslog is in F8 In-Reply-To: <1184765871.9488.4.camel@localhost.localdomain> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> Message-ID: <469E1D51.2020208@leemhuis.info> On 18.07.2007 15:37, Jeremy Katz wrote: > On Wed, 2007-07-18 at 14:27 +0300, Manuel Wolfshant wrote: >> Peter Vrabec wrote: >>>> I'd say that since sysklogd is erased, rsylogd should be automatically >>>> enabled and started. Yes, I know the packaging recommendations, but I >>>> think that in this case an exception should be accepted. >>> I agree, but I don't know any nice and secure way we can do it. >> shipping an /etc/init.d/rsyslog with default options set to enabled + >> service rsyslog start in %post is not OK ? > Starting a service in %post is not in at all okay. It can cause all > sorts of havoc when installing systems, creating live images, init'ing > chroots for building in, ... But shouldn't it be safe to start if the daemon (or the predecessor in this case) was running already? That's what other scripts do iirc. CU thl From katzj at redhat.com Wed Jul 18 14:00:52 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 18 Jul 2007 10:00:52 -0400 Subject: rsyslog is in F8 In-Reply-To: <469E1BE5.3030207@nobugconsulting.ro> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1BE5.3030207@nobugconsulting.ro> Message-ID: <1184767252.9488.8.camel@localhost.localdomain> On Wed, 2007-07-18 at 16:55 +0300, Manuel Wolfshant wrote: > Jeremy Katz wrote: > > On Wed, 2007-07-18 at 14:27 +0300, Manuel Wolfshant wrote: > >> Peter Vrabec wrote: > >> > >>>> I'd say that since sysklogd is erased, rsylogd should be automatically > >>>> enabled and started. Yes, I know the packaging recommendations, but I > >>>> think that in this case an exception should be accepted. > >>>> > >>> I agree, but I don't know any nice and secure way we can do it. > >>> > >> shipping an /etc/init.d/rsyslog with default options set to enabled + > >> service rsyslog start in %post is not OK ? > >> > > > > Starting a service in %post is not in at all okay. It can cause all > > sorts of havoc when installing systems, creating live images, init'ing > > chroots for building in, ... > > > Generally speaking, yes. But in this case we are speaking about > sysklogd's replacement. And sysklogd IS (was..) already enabled by default. Sure, having the options set to enabled and doing chkconfig --add is fine. Actually _starting_ the service when it's installed isn't. Jeremy From skvidal at linux.duke.edu Wed Jul 18 13:57:54 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 18 Jul 2007 09:57:54 -0400 Subject: rsyslog is in F8 In-Reply-To: <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> Message-ID: <1184767074.606.130.camel@cutter> On Wed, 2007-07-18 at 09:00 -0500, Jeffrey C. Ollie wrote: > On Wed, 2007-07-18 at 08:10 -0400, seth vidal wrote: > > > > Finally, we have to have the daemon auto-start. People will 'yum update' > > from f7 to f8 and in the scenario you've provided they will not have a > > running syslog daemon in the vast majority of the cases. That's a > > problem. > > After a 'yum update' from F7 to F8 you'll need to reboot anyway to pick > up the new kernel and to get everything to use the new shared libraries. > yes, and if the daemon does not default to 'enabled' w/chkconfig then you won't have it on, even after a reboot. -sv From katzj at redhat.com Wed Jul 18 14:04:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 18 Jul 2007 10:04:45 -0400 Subject: rsyslog is in F8 In-Reply-To: <469E1D51.2020208@leemhuis.info> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1D51.2020208@leemhuis.info> Message-ID: <1184767485.9488.13.camel@localhost.localdomain> On Wed, 2007-07-18 at 16:01 +0200, Thorsten Leemhuis wrote: > On 18.07.2007 15:37, Jeremy Katz wrote: > > On Wed, 2007-07-18 at 14:27 +0300, Manuel Wolfshant wrote: > >> Peter Vrabec wrote: > >>>> I'd say that since sysklogd is erased, rsylogd should be automatically > >>>> enabled and started. Yes, I know the packaging recommendations, but I > >>>> think that in this case an exception should be accepted. > >>> I agree, but I don't know any nice and secure way we can do it. > >> shipping an /etc/init.d/rsyslog with default options set to enabled + > >> service rsyslog start in %post is not OK ? > > Starting a service in %post is not in at all okay. It can cause all > > sorts of havoc when installing systems, creating live images, init'ing > > chroots for building in, ... > > But shouldn't it be safe to start if the daemon (or the predecessor in > this case) was running already? That's what other scripts do iirc. Daemons do a condrestart in their %post, not a start. I guess you could conceivably do something kind of painful like if service sysklogd status == running service sysklogd stop service rsyslog start But I'm not 100% certain that the ordering of package install/remove on an obsolete makes this even feasible Jeremy From tmraz at redhat.com Wed Jul 18 14:10:41 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 18 Jul 2007 16:10:41 +0200 Subject: rsyslog is in F8 In-Reply-To: <1184767074.606.130.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> Message-ID: <1184767841.18158.4.camel@perun.kabelta.loc> On Wed, 2007-07-18 at 09:57 -0400, seth vidal wrote: > On Wed, 2007-07-18 at 09:00 -0500, Jeffrey C. Ollie wrote: > > On Wed, 2007-07-18 at 08:10 -0400, seth vidal wrote: > > > > > > Finally, we have to have the daemon auto-start. People will 'yum update' > > > from f7 to f8 and in the scenario you've provided they will not have a > > > running syslog daemon in the vast majority of the cases. That's a > > > problem. > > > > After a 'yum update' from F7 to F8 you'll need to reboot anyway to pick > > up the new kernel and to get everything to use the new shared libraries. > > > > yes, and if the daemon does not default to 'enabled' w/chkconfig then > you won't have it on, even after a reboot. But it will default to 'enabled' w/chkconfig. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From katzj at redhat.com Wed Jul 18 14:09:02 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 18 Jul 2007 10:09:02 -0400 Subject: rsyslog is in F8 In-Reply-To: <1184767074.606.130.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> Message-ID: <1184767742.9488.19.camel@localhost.localdomain> On Wed, 2007-07-18 at 09:57 -0400, seth vidal wrote: > On Wed, 2007-07-18 at 09:00 -0500, Jeffrey C. Ollie wrote: > > On Wed, 2007-07-18 at 08:10 -0400, seth vidal wrote: > > > Finally, we have to have the daemon auto-start. People will 'yum update' > > > from f7 to f8 and in the scenario you've provided they will not have a > > > running syslog daemon in the vast majority of the cases. That's a > > > problem. > > > > After a 'yum update' from F7 to F8 you'll need to reboot anyway to pick > > up the new kernel and to get everything to use the new shared libraries. > > yes, and if the daemon does not default to 'enabled' w/chkconfig then > you won't have it on, even after a reboot. It's set to default to enabled... Jeremy From mmcgrath at redhat.com Wed Jul 18 14:12:13 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 18 Jul 2007 09:12:13 -0500 Subject: rsyslog is in F8 In-Reply-To: <1184767074.606.130.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> Message-ID: <469E1FBD.8020408@redhat.com> seth vidal wrote: > On Wed, 2007-07-18 at 09:00 -0500, Jeffrey C. Ollie wrote: > > > yes, and if the daemon does not default to 'enabled' w/chkconfig then > you won't have it on, even after a reboot. > Maybe we should create an upgrade script this time around? -Mike From jeff at ocjtech.us Wed Jul 18 14:11:20 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 18 Jul 2007 09:11:20 -0500 Subject: rsyslog is in F8 In-Reply-To: <1184767074.606.130.camel@cutter> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> Message-ID: <1184767880.4503.12.camel@lt21223.campus.dmacc.edu> On Wed, 2007-07-18 at 09:57 -0400, seth vidal wrote: > On Wed, 2007-07-18 at 09:00 -0500, Jeffrey C. Ollie wrote: > > On Wed, 2007-07-18 at 08:10 -0400, seth vidal wrote: > > > > > > Finally, we have to have the daemon auto-start. People will 'yum update' > > > from f7 to f8 and in the scenario you've provided they will not have a > > > running syslog daemon in the vast majority of the cases. That's a > > > problem. > > > > After a 'yum update' from F7 to F8 you'll need to reboot anyway to pick > > up the new kernel and to get everything to use the new shared libraries. > > yes, and if the daemon does not default to 'enabled' w/chkconfig then > you won't have it on, even after a reboot. Some folks were talking about having "service rsyslog start" in %post, I assumed that's what you were talking about - at least that's what I thought you meant by "auto-start". 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 jkeating at redhat.com Wed Jul 18 14:16:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 18 Jul 2007 10:16:43 -0400 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: References: <469E06E0.9070304@leemhuis.info> Message-ID: <20070718101643.0a9fa5ca@localhost.localdomain> On Wed, 18 Jul 2007 09:12:07 -0400 "Konstantin Ryabitsev" wrote: > New version does state-tracking, so small repository changes take only > a couple of seconds to run, which should improve things dramatically. > It's also rsync-friendly and only modifies the pages that have > actually changed. > > I have it mostly finished, and only have to finish up a few things > before releasing 0.6. Once it's released, I'll happily spend some time to get it re-integrated into our release processes, like in mash/pungi/whatever. Maybe it could even be integrated into a createrepo call? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at miketc.com Wed Jul 18 14:22:36 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 18 Jul 2007 09:22:36 -0500 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <3170f42f0707180639r146ef78cj4df89bcb6a9207f5@mail.gmail.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> <1184761282.4571.2.camel@scrappy.miketc.com> <3170f42f0707180639r146ef78cj4df89bcb6a9207f5@mail.gmail.com> Message-ID: <1184768556.5589.5.camel@scrappy.miketc.com> On Wed, 2007-07-18 at 19:09 +0530, Debarshi 'Rishi' Ray wrote: > > I looked but have forgotten what all your software would be able to do, > > "This program is meant to enable users who do not have a viable network > connection to manage their packages, ie. install new ones and update > existing ones, through the standard package management framework used > in Fedora. > > If you are interested then you can read more about it at > https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay " > > > but if it does things offline, I"m sure it does them ONline as well? > > No it is not meant for online uses. That part is well served by Pirut. > After all, the Offline Package Manager shares a lot of GUI and backend > code with Pirut. Well, to me then, it doesn't make sense to have two packages, just to work online or offline. Why can't you and the maintainer for pirut combine sources to make it work for online and offline and just configure what you want depending on your circumstance? Actually what I would like to see, is yum or a plugin be able to use an option with yum to disable all repos at once and then maybe can enable local network stuff when needed? Something like below maybe.. yum update --disableallrepos --enablerepo=local-network Guess getting at when something happens and all of a sudden internet is down,but yet you have updates to do and are on local network, instead of yum taking awhile to go through it all not finding stuf, and not having to disable each individual repo, you do it all at once and only enable local stuff or whatever. LOL I think I am way outthinking this. -- Mike Chambers Madisonville, KY "Best little town on Earth!" From mike at miketc.com Wed Jul 18 14:26:20 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 18 Jul 2007 09:26:20 -0500 Subject: rsyslog is in F8 In-Reply-To: <1184767485.9488.13.camel@localhost.localdomain> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1D51.2020208@leemhuis.info> <1184767485.9488.13.camel@localhost.localdomain> Message-ID: <1184768780.5589.9.camel@scrappy.miketc.com> On Wed, 2007-07-18 at 10:04 -0400, Jeremy Katz wrote: > > Daemons do a condrestart in their %post, not a start. > > I guess you could conceivably do something kind of painful like > if service sysklogd status == running > service sysklogd stop > service rsyslog start > > But I'm not 100% certain that the ordering of package install/remove on > an obsolete makes this even feasible rsyslog could still do the condrestart (or restart) couldn't it? I do it (mostly just out of me doing it all the time no matter what) anyway even if the daemon isn't running. It just fails on stop, then ok's on start after it's running. Of course, it wouldn't had been running initially, so above might be mute point anyway? -- Mike Chambers Madisonville, KY "Best little town on Earth!" From jsacco at gnome.org Wed Jul 18 14:34:19 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Wed, 18 Jul 2007 10:34:19 -0400 Subject: 18jul07 rawhide update: eclipse-rcp / icu4j-eclipse conflict Message-ID: <1184769259.2421.1.camel@rt.jesacco.com> See below. -Joseph ========================================================================== transaction Check Error: file /usr/share/eclipse/plugins/com.ibm.icu_3.6.1.v20070417.jar conflicts between attempted installs of icu4j-eclipse-3.6.1-1jpp.2.fc8 and eclipse-rcp-3.3.0-2.fc8 -- jsacco [at] gnome [dot] org From lsof at nodata.co.uk Wed Jul 18 14:51:49 2007 From: lsof at nodata.co.uk (nodata) Date: Wed, 18 Jul 2007 16:51:49 +0200 Subject: rsyslog is in F8 In-Reply-To: <469DFFE4.8070106@redhat.com> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <469DFFE4.8070106@redhat.com> Message-ID: <1184770309.4284.0.camel@sb-home> Am Mittwoch, den 18.07.2007, 13:56 +0200 schrieb Peter Vrabec: > Manuel Wolfshant wrote: > > Peter Vrabec wrote: > >> > >>>>>> It obsoletes sysklogd, so sysklogd in not running anymore and is > >>>>>> erased > >>>>>> after update. Note, that rsyslog won't start automatically. You > >>>>>> need to > >>>>>> do #service rsyslog start,(or restart the box). This problem > >>>>>> should be > >>>>>> solved by anaconda during upgrade from FC->F8. > >>>>>> > >>>>> What happens if I upgrade using yum? > >>>>> > >>>> You won't have running system log daemon until you restart the > >>>> system or > >>>> run service rsyslog start manually. > >>>> > >>> I'd say that since sysklogd is erased, rsylogd should be automatically > >>> enabled and started. Yes, I know the packaging recommendations, but I > >>> think that in this case an exception should be accepted. > >>> > >> > >> I agree, but I don't know any nice and secure way we can do it. > > shipping an /etc/init.d/rsyslog with default options set to enabled + > > service rsyslog start in %post is not OK ? > No, it not :-(. service rsyslog start will always start rsyslog, but we > need to start rsyslog only when sysklogd run before. condrestart or equivalent? > >> Since we replace sysklogd in rawhide and rsyslogd will be installed > >> during fresh > >> F8 installation I don't see this is a big problem. > > You make the assumption that rawhide users will know about the > > replacement and activate rsyslogd manually. I bet most of them will > > blindly do yum -y update and > > cry afterwards. Do not assume that they are subscribed to fedora mailing > > lists. Most of them are not. Or at least almost none of those I > > personally know in the RLUG community, to be more correct. > > > From denis at poolshark.org Wed Jul 18 15:02:36 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 18 Jul 2007 17:02:36 +0200 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <469E149E.1000001@redhat.com> References: <469E149E.1000001@redhat.com> Message-ID: <469E2B8C.9020300@poolshark.org> Kai Engert wrote: > We'll soon publish updated RPMs for a Firefox security release. > The new version 2.0.0.5 will go into F-7 and devel. > Please prepare to rebuild if you depend on gecko-devel. I pushed a candidate for galeon. Could you email the list when you push the firefox candidate to testing/stable ? Looking forward to the very first dual firefox/galeon simultaneous release. thx -denis From th.springer at gmx.net Wed Jul 18 15:14:36 2007 From: th.springer at gmx.net (Thomas Springer) Date: Wed, 18 Jul 2007 17:14:36 +0200 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <1184768556.5589.5.camel@scrappy.miketc.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> <1184761282.4571.2.camel@scrappy.miketc.com> <3170f42f0707180639r146ef78cj4df89bcb6a9207f5@mail.gmail.com> <1184768556.5589.5.camel@scrappy.miketc.com> Message-ID: <469E2E5C.8030906@gmx.net> Mike Chambers schrieb: > > Something like below maybe.. > > yum update --disableallrepos --enablerepo=local-network > yum update --disablerepo=\* --enablerepo=local-network dowsn't work ? Thomas From kengert at redhat.com Wed Jul 18 15:41:03 2007 From: kengert at redhat.com (Kai Engert) Date: Wed, 18 Jul 2007 17:41:03 +0200 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <469E2B8C.9020300@poolshark.org> References: <469E149E.1000001@redhat.com> <469E2B8C.9020300@poolshark.org> Message-ID: <469E348F.10304@redhat.com> Denis Leroy schrieb: > Kai Engert wrote: >> We'll soon publish updated RPMs for a Firefox security release. >> The new version 2.0.0.5 will go into F-7 and devel. >> Please prepare to rebuild if you depend on gecko-devel. > > I pushed a candidate for galeon. Could you email the list when you > push the firefox candidate to testing/stable ? both updates submitted to release team Kai From bpepple at fedoraproject.org Wed Jul 18 15:44:41 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Jul 2007 11:44:41 -0400 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <469E348F.10304@redhat.com> References: <469E149E.1000001@redhat.com> <469E2B8C.9020300@poolshark.org> <469E348F.10304@redhat.com> Message-ID: <1184773481.2790.3.camel@kennedy> On Wed, 2007-07-18 at 17:41 +0200, Kai Engert wrote: > Denis Leroy schrieb: > > Kai Engert wrote: > >> We'll soon publish updated RPMs for a Firefox security release. > >> The new version 2.0.0.5 will go into F-7 and devel. > >> Please prepare to rebuild if you depend on gecko-devel. > > > > I pushed a candidate for galeon. Could you email the list when you > > push the firefox candidate to testing/stable ? > > both updates submitted to release team Is it going to testing first, or directly to stable? /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 vonbrand at inf.utfsm.cl Wed Jul 18 16:13:20 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 18 Jul 2007 12:13:20 -0400 Subject: rsyslog is in F8 In-Reply-To: <469DF934.2050706@nobugconsulting.ro> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> Message-ID: <10800.1184775200@laptop13.inf.utfsm.cl> Manuel Wolfshant wrote: [...] > You make the assumption that rawhide users will know about the > replacement and activate rsyslogd manually. I bet most of them will > blindly do yum -y update and > cry afterwards. Do not assume that they are subscribed to fedora > mailing lists. Most of them are not. Or at least almost none of those > I personally know in the RLUG community, to be more correct. Strange thing, running rawhide and not trying to stay aware of changes. -- 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 mike at miketc.com Wed Jul 18 17:08:07 2007 From: mike at miketc.com (Mike Chambers) Date: Wed, 18 Jul 2007 12:08:07 -0500 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <469E2E5C.8030906@gmx.net> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <469BE944.1010305@fedoraproject.org> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> <1184761282.4571.2.camel@scrappy.miketc.com> <3170f42f0707180639r146ef78cj4df89bcb6a9207f5@mail.gmail.com> <1184768556.5589.5.camel@scrappy.miketc.com> <469E2E5C.8030906@gmx.net> Message-ID: <1184778487.5589.12.camel@scrappy.miketc.com> On Wed, 2007-07-18 at 17:14 +0200, Thomas Springer wrote: > yum update --disablerepo=\* --enablerepo=local-network dowsn't work ? Now why the heck did ya have to go and show me that for? I had a perfectly good idea dang it!! :P (Obviously, didn't know that existed, hrmph) -- Mike Chambers Madisonville, KY "Best little town on Earth!" From bpepple at fedoraproject.org Wed Jul 18 16:46:17 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Jul 2007 12:46:17 -0400 Subject: Plan for tomorrows (20070719) FESCO meeting Message-ID: <1184777177.2790.9.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- License Version - notting, jeremy /topic FESCO-Meeting -- MISC -- Schedule for future branching of CVS - f13 /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 drago01 at gmail.com Wed Jul 18 17:50:19 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 18 Jul 2007 19:50:19 +0200 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <1184773481.2790.3.camel@kennedy> References: <469E149E.1000001@redhat.com> <469E2B8C.9020300@poolshark.org> <469E348F.10304@redhat.com> <1184773481.2790.3.camel@kennedy> Message-ID: <469E52DB.3020802@gmail.com> Brian Pepple wrote: > On Wed, 2007-07-18 at 17:41 +0200, Kai Engert wrote: > >> Denis Leroy schrieb: >> >>> Kai Engert wrote: >>> >>>> We'll soon publish updated RPMs for a Firefox security release. >>>> The new version 2.0.0.5 will go into F-7 and devel. >>>> Please prepare to rebuild if you depend on gecko-devel. >>>> >>> I pushed a candidate for galeon. Could you email the list when you >>> push the firefox candidate to testing/stable ? >>> >> both updates submitted to release team >> > > Is it going to testing first, or directly to stable? > > seems like a security update so it should go to stable From lmacken at redhat.com Wed Jul 18 18:52:31 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 18 Jul 2007 14:52:31 -0400 Subject: Updates: who's allowed to push In-Reply-To: <1184713351.17393.2.camel@shrek.rexursive.com> References: <1184713351.17393.2.camel@shrek.rexursive.com> Message-ID: <20070718185231.GA2786@tomservo> On Wed, Jul 18, 2007 at 09:02:31AM +1000, Bojan Smojver wrote: > I've been trying to get the package maintainer to push an update of > clamav for F7, but I'm guessing he's away ATM. So, in the absence of > package maintainer, who's allowed to push the package (which has already > been built in Koji)? > > This is regarding this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240395 At the moment bodhi is oblivious of {,co-}maintainers, and only knows about who submitted what. So technically you could submit that update if you wanted to. This will change soon when either the package database gets some sort of API for this, or I'll eventually have bodhi parse the owners.list itself. luke From ivazqueznet at gmail.com Wed Jul 18 18:55:31 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 18 Jul 2007 14:55:31 -0400 Subject: Fedora Feature Proposal: Yum Integration Message-ID: <1184784931.4179.4.camel@ignacio.lan> http://fedoraproject.org/wiki/IgnacioVazquezAbrams/YumIntegration This feature will allow apps to install packages "on the fly" as they're needed instead of requiring them to be installed beforehand. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Jul 18 18:55:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Jul 2007 14:55:45 -0400 Subject: Plan for tomorrows (20070719) FESCO meeting In-Reply-To: <1184777177.2790.9.camel@kennedy> References: <1184777177.2790.9.camel@kennedy> Message-ID: <20070718185545.GB21518@nostromo.devel.redhat.com> Brian Pepple (bpepple at fedoraproject.org) said: > > /topic FESCO-Meeting -- MISC -- License Version - notting, jeremy > > /topic FESCO-Meeting -- MISC -- Schedule for future branching of CVS - > f13 > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCo meeting -- Free discussion around Fedora I believe there should be a specific portion of the meeting set aside for working through the current proposed F8 features. Bill From lmacken at redhat.com Wed Jul 18 19:05:22 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 18 Jul 2007 15:05:22 -0400 Subject: bodhi hackery and model changes Message-ID: <20070718190522.GB2786@tomservo> Hey *, So I'm getting ready to migrate our production bodhi instance in the very near future. There are a few things I'd like to polish up first, and I also would like to run by some of the model changes with everyone. Here is a diagram of bodhi's model at the moment: https://hosted.fedoraproject.org/projects/bodhi/attachment/wiki/Design/bodhi-model.png Some of the new stuff in bodhi's model now that isn't present in our production instance: o PackageUpdate's can have any number of PackageBuilds associated with them (the new update form also allows multiple-builds per update). o PackageUpdate and Comment objects now have a 'karma'. Each comment's karma can be either -1/0/1, which is added to its corresponding update upon creation. With this data we can eventually mark updates as stable once they reach a karma of n. o qa_approved will contain the name of the QA person who approved this update and qa_approved_date will contain the timestamp. There's currently no code utilizing this field yet, but that will hopefully change soon. I was thinking we could simply check if a +1 Comment is from a member of the qa_team, then mark the update as qa approved. I have sec_approved{,_date} fields commented out in the code until FESCo approves the mandate for security updates to require approval from the security team. So, if we're going to squeeze in any more fields into the model, now would be the best time to do so. Any comments/suggestions? Also, I recently made it really easy to hack on your own local bodhi instance. I pickled our production database, and threw it in the bodhi mercurial repo; so if you follow the instructions[0] for setting up your own development environment, you can easily populate it with all of our production data to date. You won't be able to push updates, since that requires moving around tags in Koji, but you can still do pretty much everything else. As always, there is much work to be done[1]. luke [0]: http://hosted.fedoraproject.org/projects/bodhi/wiki/Development [1]: http://hosted.fedoraproject.org/projects/bodhi/report/1 From bpepple at fedoraproject.org Wed Jul 18 19:07:56 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Jul 2007 15:07:56 -0400 Subject: Plan for tomorrows (20070719) FESCO meeting In-Reply-To: <20070718185545.GB21518@nostromo.devel.redhat.com> References: <1184777177.2790.9.camel@kennedy> <20070718185545.GB21518@nostromo.devel.redhat.com> Message-ID: <1184785676.2790.17.camel@kennedy> On Wed, 2007-07-18 at 14:55 -0400, Bill Nottingham wrote: > Brian Pepple (bpepple at fedoraproject.org) said: > > > > /topic FESCO-Meeting -- MISC -- License Version - notting, jeremy > > > > /topic FESCO-Meeting -- MISC -- Schedule for future branching of CVS - > > f13 > > > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > > > /topic FESCo meeting -- Free discussion around Fedora > > I believe there should be a specific portion of the meeting set aside for working > through the current proposed F8 features. I'm fine with that. How about using a maximum of 15 minutes each for the first 2 items on the agenda, and setting aside the last 30 minutes of the meeting for feature proposals? /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 notting at redhat.com Wed Jul 18 19:05:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Jul 2007 15:05:39 -0400 Subject: rsyslog is in F8 In-Reply-To: <1184768780.5589.9.camel@scrappy.miketc.com> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1D51.2020208@leemhuis.info> <1184767485.9488.13.camel@localhost.localdomain> <1184768780.5589.9.camel@scrappy.miketc.com> Message-ID: <20070718190539.GD21518@nostromo.devel.redhat.com> Mike Chambers (mike at miketc.com) said: > rsyslog could still do the condrestart (or restart) couldn't it? I do > it (mostly just out of me doing it all the time no matter what) anyway > even if the daemon isn't running. It just fails on stop, then ok's on > start after it's running. Well, condrestart works on the same pid file, so it won't work in this cas.e Bill From Jochen at herr-schmitt.de Wed Jul 18 19:12:31 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 18 Jul 2007 21:12:31 +0200 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <1184784931.4179.4.camel@ignacio.lan> References: <1184784931.4179.4.camel@ignacio.lan> Message-ID: <469E661F.4000509@herr-schmitt.de> Ignacio Vazquez-Abrams schrieb: > http://fedoraproject.org/wiki/IgnacioVazquezAbrams/YumIntegration > > This feature will allow apps to install packages "on the fly" as they're > needed instead of requiring them to be installed beforehand. > > I'm very skeptical about you proposed feature. The installation of a package is a heavy injection on a running system. So I think the installation of a package should only done after the explicit permission of the administrator. But as far as I have understand your project page, you plan that this should works automatically it the application determinate the requirement of a special package. I don't know, if that is a good idea for a feature on upcoming Fedora releases. Best Regards: Jochen Schmitt From notting at redhat.com Wed Jul 18 19:11:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Jul 2007 15:11:29 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <1184784931.4179.4.camel@ignacio.lan> References: <1184784931.4179.4.camel@ignacio.lan> Message-ID: <20070718191129.GF21518@nostromo.devel.redhat.com> Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: > http://fedoraproject.org/wiki/IgnacioVazquezAbrams/YumIntegration > > This feature will allow apps to install packages "on the fly" as they're > needed instead of requiring them to be installed beforehand. Using this for s-c-network seems to be very much a chicken/egg scenario. Bill From jkeating at redhat.com Wed Jul 18 19:15:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 18 Jul 2007 15:15:43 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <469E661F.4000509@herr-schmitt.de> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> Message-ID: <20070718151543.7af10cc6@localhost.localdomain> On Wed, 18 Jul 2007 21:12:31 +0200 Jochen Schmitt wrote: > The installation of a package is a heavy injection on a running > system. So I think the installation of a package should only done > after the explicit permission of the administrator. But as far as I > have understand your project page, you plan that this should works > automatically it the application determinate the requirement of a > special package. IIUC it would be "automatic" in that it launches say pirut to install the missing package, which would prompt you for your root password before continuing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazqueznet at gmail.com Wed Jul 18 19:24:26 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 18 Jul 2007 15:24:26 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070718191129.GF21518@nostromo.devel.redhat.com> References: <1184784931.4179.4.camel@ignacio.lan> <20070718191129.GF21518@nostromo.devel.redhat.com> Message-ID: <1184786666.4179.7.camel@ignacio.lan> On Wed, 2007-07-18 at 15:11 -0400, Bill Nottingham wrote: > Ignacio Vazquez-Abrams (ivazqueznet at gmail.com) said: > > http://fedoraproject.org/wiki/IgnacioVazquezAbrams/YumIntegration > > > > This feature will allow apps to install packages "on the fly" as they're > > needed instead of requiring them to be installed beforehand. > > Using this for s-c-network seems to be very much a chicken/egg scenario. For wired, modem, or PPPoE, sure. But for higher-level things like VPN or bridging it could make sense. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Wed Jul 18 19:25:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 19 Jul 2007 00:55:55 +0530 Subject: Fedora Offline Package Manager (RUM) version 0.0.1 released In-Reply-To: <1184768556.5589.5.camel@scrappy.miketc.com> References: <3170f42f0707160100g696550ddjd14dda471e45a8a3@mail.gmail.com> <3170f42f0707161858u3f503438pf5975f00f6d4bd07@mail.gmail.com> <54281.192.54.193.51.1184657166.squirrel@rousalka.dyndns.org> <3170f42f0707170120q1d0be17aqdf625ebac4079672@mail.gmail.com> <469DBBC9.1040801@rasmil.dk> <3170f42f0707180148u65da9d5fi620acf4130074ba@mail.gmail.com> <1184761282.4571.2.camel@scrappy.miketc.com> <3170f42f0707180639r146ef78cj4df89bcb6a9207f5@mail.gmail.com> <1184768556.5589.5.camel@scrappy.miketc.com> Message-ID: <3170f42f0707181225t737872f3qf4c914bfb9034cfe@mail.gmail.com> > Well, to me then, it doesn't make sense to have two packages, just to > work online or offline. Why can't you and the maintainer for pirut > combine sources to make it work for online and offline and just > configure what you want depending on your circumstance? If you had read https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay you might have noticed that my original intention was to do just what you are saying. However the Pirut maintainer, Jeremy Katz, does not look favourably upon this idea. Having said that both programs do share a lot of code, both for the back-end functioning and the GUI, keeping duplication to a minimum. > Actually what I would like to see, is yum or a plugin be able to use an > option with yum to disable all repos at once and then maybe can enable > local network stuff when needed? > > Something like below maybe.. > > yum update --disableallrepos --enablerepo=local-network Where does 'local-network' come from? Imagine you have a computer which has no network connection at all. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From Jochen at herr-schmitt.de Wed Jul 18 19:35:03 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 18 Jul 2007 21:35:03 +0200 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070718151543.7af10cc6@localhost.localdomain> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> Message-ID: <469E6B67.5080706@herr-schmitt.de> Jesse Keating schrieb: > > IIUC it would be "automatic" in that it launches say pirut to install > the missing package, which would prompt you for your root password > before continuing. > > This sounds ok. But keep in mind, that not all applications are running on X. So a fix link to pirut may be no sense in my mind. Best Regards: Jochen Schmitt From ivazqueznet at gmail.com Wed Jul 18 19:37:30 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 18 Jul 2007 15:37:30 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <469E6B67.5080706@herr-schmitt.de> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <469E6B67.5080706@herr-schmitt.de> Message-ID: <1184787450.4179.8.camel@ignacio.lan> On Wed, 2007-07-18 at 21:35 +0200, Jochen Schmitt wrote: > This sounds ok. But keep in mind, that not all applications are running > on X. > > So a fix link to pirut may be no sense in my mind. This is why the proposal talks about a TUI version of s-i-p. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Wed Jul 18 19:25:52 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 18 Jul 2007 14:25:52 -0500 (CDT) Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <1184787450.4179.8.camel@ignacio.lan> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <469E6B67.5080706@herr-schmitt.de> <1184787450.4179.8.camel@ignacio.lan> Message-ID: <2976.65.192.24.164.1184786752.squirrel@mail.jcomserv.net> > On Wed, 2007-07-18 at 21:35 +0200, Jochen Schmitt wrote: >> This sounds ok. But keep in mind, that not all applications are running >> on X. >> >> So a fix link to pirut may be no sense in my mind. > > This is why the proposal talks about a TUI version of s-i-p. I suppose it could check for DISPLAY, and call yum directly, either in an xterm or not. That way absolutely anyone could use it. > -- > Ignacio Vazquez-Abrams > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From jspaleta at gmail.com Wed Jul 18 19:41:19 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 18 Jul 2007 11:41:19 -0800 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070718151543.7af10cc6@localhost.localdomain> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> Message-ID: <604aa7910707181241w51634abfmc85c57bb0a8f3527@mail.gmail.com> On 7/18/07, Jesse Keating wrote: > IIUC it would be "automatic" in that it launches say pirut to install > the missing package, which would prompt you for your root password > before continuing. Technical question time... how abstract can we realistically make this? Are we talking about a developer needing to make an explicit listing of packages or specific provides per application? Or is this something that can be abstracted so that when a specific library isn't on the system some package install dialog sequence gets fired off? I'm guessing that abstraction really isn't possible here, and its going to be a modest amount of work per tool to get the listings accurate. -jef From ivazqueznet at gmail.com Wed Jul 18 19:45:46 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 18 Jul 2007 15:45:46 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <604aa7910707181241w51634abfmc85c57bb0a8f3527@mail.gmail.com> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <604aa7910707181241w51634abfmc85c57bb0a8f3527@mail.gmail.com> Message-ID: <1184787946.4179.11.camel@ignacio.lan> On Wed, 2007-07-18 at 11:41 -0800, Jeff Spaleta wrote: > On 7/18/07, Jesse Keating wrote: > > IIUC it would be "automatic" in that it launches say pirut to install > > the missing package, which would prompt you for your root password > > before continuing. > > Technical question time... > how abstract can we realistically make this? Are we talking about a > developer needing to make an explicit listing of packages or specific > provides per application? Or is this something that can be abstracted > so that when a specific library isn't on the system some package > install dialog sequence gets fired off? > > I'm guessing that abstraction really isn't possible here, and its > going to be a modest amount of work per tool to get the listings > accurate. The nice thing about s-i-p is that it works *exactly* like yum when resolving, so you can specify right down to the specific file you need and it will find the package and its deps. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Wed Jul 18 19:47:00 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 18 Jul 2007 15:47:00 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <2976.65.192.24.164.1184786752.squirrel@mail.jcomserv.net> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <469E6B67.5080706@herr-schmitt.de> <1184787450.4179.8.camel@ignacio.lan> <2976.65.192.24.164.1184786752.squirrel@mail.jcomserv.net> Message-ID: <1184788020.4179.14.camel@ignacio.lan> On Wed, 2007-07-18 at 14:25 -0500, Jon Ciesla wrote: > > On Wed, 2007-07-18 at 21:35 +0200, Jochen Schmitt wrote: > >> This sounds ok. But keep in mind, that not all applications are running > >> on X. > >> > >> So a fix link to pirut may be no sense in my mind. > > > > This is why the proposal talks about a TUI version of s-i-p. > > I suppose it could check for DISPLAY, and call yum directly, either in an > xterm or not. That way absolutely anyone could use it. yum lacks a hook into userhelper, and there's no reason for this to change. Using yum as a user that can't install isn't an error. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Wed Jul 18 21:14:53 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 19 Jul 2007 02:44:53 +0530 Subject: Fedora Offline Package Manager (RUM) documentation updated Message-ID: <3170f42f0707181414g67c7c939va0d88d57fbe8ccd8@mail.gmail.com> https://fedoraproject.org/wiki/DebarshiRay/rum The documentation for Fedora Offline Package Manager (RUM) version 0.0.1 is now available at the above link. I have added a few new screenshots of the new GUI application to explain how it works. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From poelstra at redhat.com Wed Jul 18 22:34:55 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 18 Jul 2007 15:34:55 -0700 Subject: Plan for tomorrows (20070719) FESCO meeting In-Reply-To: <20070718185545.GB21518@nostromo.devel.redhat.com> References: <1184777177.2790.9.camel@kennedy> <20070718185545.GB21518@nostromo.devel.redhat.com> Message-ID: <469E958F.1030201@redhat.com> Bill Nottingham said the following on 07/18/2007 11:55 AM Pacific Time: > Brian Pepple (bpepple at fedoraproject.org) said: >> /topic FESCO-Meeting -- MISC -- License Version - notting, jeremy >> >> /topic FESCO-Meeting -- MISC -- Schedule for future branching of CVS - >> f13 >> >> /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 >> >> /topic FESCo meeting -- Free discussion around Fedora > > I believe there should be a specific portion of the meeting set aside for working > through the current proposed F8 features. > > Bill > Thanks Bill! You beat me to it. :) I'm working through all of the current wiki pages and pulling together status. I'll send something out later today when I am done that can help drive the discussion in the meeting. John From kwizart at gmail.com Wed Jul 18 23:07:29 2007 From: kwizart at gmail.com (KH KH) Date: Thu, 19 Jul 2007 01:07:29 +0200 Subject: Plan for tomorrows (20070719) FESCO meeting In-Reply-To: <1184777177.2790.9.camel@kennedy> References: <1184777177.2790.9.camel@kennedy> Message-ID: 2007/7/18, Brian Pepple : > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- License Version - notting, jeremy > > /topic FESCO-Meeting -- MISC -- Schedule for future branching of CVS - > f13 > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > Thanks, > /B > -- > Brian Pepple > > http://fedoraproject.org/wiki/BrianPepple > gpg --keyserver pgp.mit.edu --recv-keys 810CC15E > BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Hi! Can we discuss this ? https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00843.html Nicolas (kwizart) From poelstra at redhat.com Thu Jul 19 00:25:41 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 18 Jul 2007 17:25:41 -0700 Subject: F8 Feature Status & FESCo review Message-ID: <469EAF85.9030901@redhat.com> Greetings Feature Owners, We reached our first "feature status update" on 2007-07-15. Thanks to the feature owners who have already updated their pages. If you are the owner of a feature, please update the status if you have not already done so. Since FESCo ratified the feature process (http://fedoraproject.org/wiki/Features/Policy) for F8, as the appointed Feature Wrangler, I've been tidying up the feature wiki pages. When the new process was adopted the intention was to grandfather in (where possible) features that had already been proposed. I have re-factored many feature pages to follow the new format while trying to stay true to original information recorded. I am also maintaining a feature status page of sorts that I am calling the "feature dashboard" that we will try out for the F8 release: http://fedoraproject.org/wiki/Features/Dashboard . I am using this page to keep a current status on which features are ready for FESCo review and those that are not. If your feature is up for review tomorrow, (see the Dashboard) I would encourage you to be present at the FESCo meeting tomorrow in #fedora-meeting (1700 UTC) to answer any questions that may arise. If you cannot be there (I apologize for the short notice) I'll collect questions and follow up with you. Thank you, John From bbbush.yuan at gmail.com Thu Jul 19 01:02:34 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Thu, 19 Jul 2007 09:02:34 +0800 Subject: 18jul07 rawhide update: eclipse-rcp / icu4j-eclipse conflict In-Reply-To: <1184769259.2421.1.camel@rt.jesacco.com> References: <1184769259.2421.1.camel@rt.jesacco.com> Message-ID: <76e72f800707181802h249b2c3ey1a67ae3e290d43cd@mail.gmail.com> 2007/7/18, Joseph Sacco : > See below. > > -Joseph > > ========================================================================== > > transaction Check Error: > file /usr/share/eclipse/plugins/com.ibm.icu_3.6.1.v20070417.jar > conflicts between attempted installs of icu4j-eclipse-3.6.1-1jpp.2.fc8 > and eclipse-rcp-3.3.0-2.fc8 > > -- > jsacco [at] gnome [dot] org > And force install will not work: running eclipse and it will crash at some place in com.ibm.icu, no matter which RPM is installed later. -- bbbush ^_^ From sundaram at fedoraproject.org Thu Jul 19 01:16:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jul 2007 06:46:14 +0530 Subject: F8 Feature Status & FESCo review In-Reply-To: <469EAF85.9030901@redhat.com> References: <469EAF85.9030901@redhat.com> Message-ID: <469EBB5E.10504@fedoraproject.org> John Poelstra wrote: I would encourage you to be present at the FESCo meeting > tomorrow in #fedora-meeting (1700 UTC) to answer any questions that may > arise. If you cannot be there (I apologize for the short notice) I'll > collect questions and follow up with you. Can other people act as proxies for a feature owner? Rahul From jwboyer at jdub.homelinux.org Thu Jul 19 01:38:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 18 Jul 2007 20:38:01 -0500 Subject: Plan for tomorrows (20070719) FESCO meeting In-Reply-To: References: <1184777177.2790.9.camel@kennedy> Message-ID: <1184809081.1475.2.camel@vader.jdub.homelinux.org> On Thu, 2007-07-19 at 01:07 +0200, KH KH wrote: > Hi! > Can we discuss this ? > https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00843.html What would you like to discuss? Do you have a proposal related to the topic? We'd need Chuck present as well. josh From vonbrand at inf.utfsm.cl Thu Jul 19 01:16:59 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 18 Jul 2007 21:16:59 -0400 Subject: F8 Feature Status & FESCo review In-Reply-To: <469EAF85.9030901@redhat.com> References: <469EAF85.9030901@redhat.com> Message-ID: <7130.1184807819@laptop13.inf.utfsm.cl> John Poelstra wrote: > We reached our first "feature status update" on 2007-07-15. Thanks to > the feature owners who have already updated their pages. If you are > the owner of a feature, please update the status if you have not > already done so. Congratulations all around. One thing I miss is the inclusion of TeXlive (instead of the dead teTeX) in Fedora 8. In it targets Fedora 8... [Yes, I know this is a wiki, but I'm not quite sure what the policy on editing here is...] -- 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 sundaram at fedoraproject.org Thu Jul 19 02:33:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jul 2007 08:03:43 +0530 Subject: F8 Feature Status & FESCo review In-Reply-To: <7130.1184807819@laptop13.inf.utfsm.cl> References: <469EAF85.9030901@redhat.com> <7130.1184807819@laptop13.inf.utfsm.cl> Message-ID: <469ECD87.8090609@fedoraproject.org> Horst H. von Brand wrote: > John Poelstra wrote: > >> We reached our first "feature status update" on 2007-07-15. Thanks to >> the feature owners who have already updated their pages. If you are >> the owner of a feature, please update the status if you have not >> already done so. > > Congratulations all around. > > One thing I miss is the inclusion of TeXlive (instead of the dead teTeX) > in Fedora 8. In > it targets Fedora 8... > > [Yes, I know this is a wiki, but I'm not quite sure what the policy on > editing here is...] Policy is http://fedoraproject.org/wiki/WikiEditing. You can edit it. Rahul From sundaram at fedoraproject.org Thu Jul 19 02:36:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jul 2007 08:06:29 +0530 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <469E1817.7050809@ml.shredzone.de> References: <469E1817.7050809@ml.shredzone.de> Message-ID: <469ECE2D.8070600@fedoraproject.org> Richard K?rber wrote: > > My primary goal for repowatch was to watch several repositories > simultaneously, and give reports about packages that have been recently > added or removed from a repository. A nice side effect is the > possibility to online search for packages. You might want to consider having this done as part of the Fedora Project and file a RFR with the infrastructure team. http://fedoraproject.org/wiki/Infrastructure/RFR Rahul From mattdm at mattdm.org Thu Jul 19 05:02:09 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 01:02:09 -0400 Subject: rsyslog is in F8 In-Reply-To: <469E1FBD.8020408@redhat.com> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> <469E1FBD.8020408@redhat.com> Message-ID: <20070719050209.GA18771@jadzia.bu.edu> On Wed, Jul 18, 2007 at 09:12:13AM -0500, Mike McGrath wrote: > >you won't have it on, even after a reboot. > Maybe we should create an upgrade script this time around? plugin. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Lam at Lam.pl Thu Jul 19 05:17:06 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 19 Jul 2007 07:17:06 +0200 Subject: rsyslog is in F8 In-Reply-To: <20070719050209.GA18771@jadzia.bu.edu> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> <469E1FBD.8020408@redhat.com> <20070719050209.GA18771@jadzia.bu.edu> Message-ID: <20070719071706.19c7e7ee@pensja.lam.pl> Dnia 2007-07-19, o godz. 01:02:09 Matthew Miller napisa?(a): > plugin. In case of upgrading FC6 or F7 to F8, the plugin would have to be installed and enabled on every installation of both on FC6 and F7... I say leave it as it is, or, if you're really concerned about it, do a simple echo in %post, like: if service rsyslog status then echo rsyslog is installed, but not running, you may want to start it echo manually, typing: service rsyslog start fi ...or something. This way the text-mode yum upgraders will see it and GUI users aren't real sysadmins needing a logger anyway :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Jul 19 06:08:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Jul 2007 08:08:22 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <469ECE2D.8070600@fedoraproject.org> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> Message-ID: <469EFFD6.2010808@leemhuis.info> On 19.07.2007 04:36, Rahul Sundaram wrote: > Richard K?rber wrote: > >> My primary goal for repowatch was to watch several repositories >> simultaneously, and give reports about packages that have been recently >> added or removed from a repository. A nice side effect is the >> possibility to online search for packages. > > You might want to consider having this done as part of the Fedora > Project and file a RFR with the infrastructure team. > > http://fedoraproject.org/wiki/Infrastructure/RFR +1 And what I'd really like to see in repoview/repowatch/pkgs-db/whatever is a kind of static-url like fedoraproject.org/pacakges/foo which gives some info *for users* about the package in Fedora and links to the latest packages (or its repowatch/repoview/whatever pages that have more details about the packages) for currently supported distributions. Then we could points users to that page and can tell the maintainers of foo "for Fedora packages send your users to fedoraproject.org/packages/foo for further informations" CU thl From poelstra at redhat.com Thu Jul 19 06:16:49 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 18 Jul 2007 23:16:49 -0700 Subject: F8 Feature Status & FESCo review In-Reply-To: <469EBB5E.10504@fedoraproject.org> References: <469EAF85.9030901@redhat.com> <469EBB5E.10504@fedoraproject.org> Message-ID: <469F01D1.10604@redhat.com> Rahul Sundaram wrote: > John Poelstra wrote: > I would encourage you to be present at the FESCo meeting >> tomorrow in #fedora-meeting (1700 UTC) to answer any questions that >> may arise. If you cannot be there (I apologize for the short notice) >> I'll collect questions and follow up with you. > > Can other people act as proxies for a feature owner? > > Rahul > Certainly. That is what I was offering to do :) John From fedora at ml.shredzone.de Thu Jul 19 06:25:52 2007 From: fedora at ml.shredzone.de (=?ISO-8859-15?Q?Richard_K=F6rber?=) Date: Thu, 19 Jul 2007 08:25:52 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <469EFFD6.2010808@leemhuis.info> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> Message-ID: <469F03F0.6090205@ml.shredzone.de> Thorsten Leemhuis wrote: >> You might want to consider having this done as part of the Fedora >> Project and file a RFR with the infrastructure team. > +1 Repowatch is currently some kind of feasibility study. I am rewriting it, to get rid of a few conceptual flaws. When the rewrite is done, I will publish the source under GPL and file a RFR. > fedoraproject.org/pacakges/foo Those showme.php?id=142348 URLs are annoying me too. Human readable links will definitely be a part of the rewrite. Best Regards -- Richard "Shred" K?rber From wolfy at nobugconsulting.ro Thu Jul 19 06:29:24 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 19 Jul 2007 09:29:24 +0300 Subject: rsyslog is in F8 In-Reply-To: <1184768780.5589.9.camel@scrappy.miketc.com> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1D51.2020208@leemhuis.info> <1184767485.9488.13.camel@localhost.localdomain> <1184768780.5589.9.camel@scrappy.miketc.com> Message-ID: <469F04C4.2050700@nobugconsulting.ro> Mike Chambers wrote: > On Wed, 2007-07-18 at 10:04 -0400, Jeremy Katz wrote: > > >> Daemons do a condrestart in their %post, not a start. >> >> I guess you could conceivably do something kind of painful like >> if service sysklogd status == running >> service sysklogd stop >> service rsyslog start >> >> But I'm not 100% certain that the ordering of package install/remove on >> an obsolete makes this even feasible >> > > rsyslog could still do the condrestart (or restart) couldn't it? I do > it (mostly just out of me doing it all the time no matter what) anyway > even if the daemon isn't running. It just fails on stop, then ok's on > start after it's running. > If sysklogd fails on stop it is not necessarily OK to start rsyslog. Maybe the admin decided to try syslog-ng, but did not remove sysklogd. Trying to start rsyslog while syslog-ng would fail. And would be a useless thing to do. Anyway, as it has already been pointed /etc/init.d/rsyslog defaults to enabled (from Peter's message I have understood that the opposite was true and at the time I did not check the sources), so the service will be started after reboot. Seems almost OK to me (except for a potential conflict with other daemons like sysloh-ng, but that's already food for real admins) From sundaram at fedoraproject.org Thu Jul 19 06:30:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Jul 2007 12:00:24 +0530 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <469F03F0.6090205@ml.shredzone.de> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <469F03F0.6090205@ml.shredzone.de> Message-ID: <469F0500.50803@fedoraproject.org> Richard K?rber wrote: > Thorsten Leemhuis wrote: > >>> You might want to consider having this done as part of the Fedora >>> Project and file a RFR with the infrastructure team. >> +1 > > Repowatch is currently some kind of feasibility study. I am rewriting > it, to get rid of a few conceptual flaws. When the rewrite is done, I > will publish the source under GPL and file a RFR. > >> fedoraproject.org/pacakges/foo > > Those showme.php?id=142348 URLs are annoying me too. Human readable > links will definitely be a part of the rewrite. Thank you. Good work. Rahul From kevin.kofler at chello.at Thu Jul 19 09:26:39 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 19 Jul 2007 09:26:39 +0000 (UTC) Subject: Fedora Feature Proposal: Yum Integration References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> Message-ID: Jesse Keating redhat.com> writes: > IIUC it would be "automatic" in that it launches say pirut to install > the missing package, which would prompt you for your root password > before continuing. But what if you are just a regular user who doesn't have the root password? That pretty much limits the use of this feature to administrative programs (which require root anyway). Otherwise users will end up with half-broken apps and no way to fix them without administrator assistance, and admins of any multi-user machine will hate it (when they install something, they expect the dependencies to come with it, not to get a support request a few days later to install XYZ for the feature UVW to work). Kevin Kofler From kanarip at kanarip.com Thu Jul 19 09:39:24 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 19 Jul 2007 11:39:24 +0200 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> Message-ID: <469F314C.8030104@kanarip.com> Kevin Kofler wrote: > Jesse Keating redhat.com> writes: >> IIUC it would be "automatic" in that it launches say pirut to install >> the missing package, which would prompt you for your root password >> before continuing. > > But what if you are just a regular user who doesn't have the root password? > That pretty much limits the use of this feature to administrative programs > (which require root anyway). Otherwise users will end up with half-broken apps > and no way to fix them without administrator assistance, and admins of any > multi-user machine will hate it (when they install something, they expect the > dependencies to come with it, not to get a support request a few days later to > install XYZ for the feature UVW to work). > Half broken apps because of missing dependencies that are needed for "extra features" rather then "core functionality" is just bad programming/app design. It's either a requirement for the app as a whole or a requirement for a feature that the app can just disable/ignore during runtime. Kind regards, Jeroen van Meeuwen -kanarip From kevin.kofler at chello.at Thu Jul 19 10:13:28 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 19 Jul 2007 10:13:28 +0000 (UTC) Subject: Fedora Feature Proposal: Yum Integration References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <469F314C.8030104@kanarip.com> Message-ID: Jeroen van Meeuwen kanarip.com> writes: > Half broken apps because of missing dependencies that are needed for > "extra features" rather then "core functionality" is just bad > programming/app design. But missing those "extra features" is exactly what I call "half broken". I think soft dependencies are a much more admin-friendly way to handle this. Rex Dieter is working on a proposal there: http://fedoraproject.org/wiki/RexDieter/SoftDependencies It'd also have the advantage of not locking users into the yum/pirut/system-install-packages framework if they wish to use apt-rpm or smart instead. And IMHO even a hard dependency is a better approach than a post-install prompt. Disk space is cheap. Kevin Kofler From buildsys at redhat.com Thu Jul 19 10:16:40 2007 From: buildsys at redhat.com (Build System) Date: Thu, 19 Jul 2007 06:16:40 -0400 Subject: rawhide report: 20070719 changes Message-ID: <200707191016.l6JAGeGv016884@porkchop.devel.redhat.com> New package avant-window-navigator Fully customisable dock-like window navigator for GNOME New package avr-libc C library for use with GCC on Atmel AVR microcontrollers New package edac-utils Userspace helper for kernel EDAC drivers New package kde-filesystem KDE filesystem layout New package rsyslog Enhanced system logging and kernel message trapping daemons Updated Packages: authconfig-5.3.15-1.fc8 ----------------------- * Wed Jul 18 2007 Tomas Mraz - 5.3.15-1 - dnsclient fixes by Simo Sorce - add Categories to .desktop file (#245868) - fixed traceback when calling joinDomain (#245374) - disable smart card action setting when gnome-screensaver not installed (#209643) - do not change protocols and services in nsswitch.conf (#236669) autofs-1:5.0.2-6 ---------------- * Wed Jul 18 2007 Ian Kent - 5.0.2-6 - fix wait time resolution in alarm and state queue handlers (bz 247711). binutils-2.17.50.0.17-3 ----------------------- * Wed Jul 18 2007 Roland McGrath - 2.17.50.0.17-3 - fix for ld --build-id bochs-2.3-5.fc8 --------------- * Wed Jul 18 2007 Hans de Goede 2.3-5 - Fix CVE-2007-2893 (bz 241799) centericq-4.21.0-13.fc8 ----------------------- * Thu Jul 19 2007 Lubomir Kundrak - fix CVE-2007-3713 multiple buffer overflows (#247979) * Sun Jun 03 2007 Andreas Bierfert - fix #242344 claws-mail-2.10.0-3.fc8 ----------------------- * Wed Jul 18 2007 Andreas Bierfert - 2.10.0-3 - build against libSM (#248675) * Mon Jul 16 2007 Andreas Bierfert - 2.10.0-2 - add requires for bogofilter (#246125) crossfire-client-1.10.0-2.fc8 ----------------------------- * Tue Jul 17 2007 Wart 1.10.0-2 - Remove unused data directory crossfire-maps-1.10.0-2.fc8 --------------------------- * Wed Jul 11 2007 Wart 1.10.0-2 - Add Requires: on the game server for proper directory ownership cups-1:1.3-0.b1.1.fc8 --------------------- * Wed Jul 18 2007 Tim Waugh 1:1.3-0.b1.1 - 1.3b1. No longer need relro, directed-broadcast, af_unix-auth, or str2109 patches. dhcp-12:3.0.6-2.fc8 ------------------- * Wed Jul 18 2007 Florian La Roche - 12:3.0.6-2 - use a new macro name vendor -> vvendor to not overwrite the RPMTAG_VENDOR setting * Tue Jul 10 2007 David Cantrell - 12:3.0.6-1 - Upgrade to ISC dhcp-3.0.6 - Remove the -TERM option from killproc command (#245317) * Wed Jun 20 2007 David Cantrell - 12:3.0.5-37 - For init script functions, echo new line after OK or FAIL msg (#244956) e2fsprogs-1.40.2-2.fc8 ---------------------- * Wed Jul 18 2007 Eric Sandeen 1.40.2-2 - Fix bug in ext2fs_swap_inode_full() on big-endian boxes * Tue Jul 17 2007 Eric Sandeen 1.40.2-1 - New version 1.40.2 - Fix up warning in badblocks filesystem-2.4.10-1.fc8 ----------------------- * Wed Jul 18 2007 Phil Knirsch 2.4.10-1 - Replaced gtk-doc with gnome (#247276) galeon-2.0.3-10.fc7 ------------------- * Wed Jul 18 2007 Denis Leroy - 2.0.3-10 - Rebuild with gecko-libs 1.8.1.5 gnome-specimen-0.3-1.fc8 ------------------------ * Wed Jul 18 2007 Damien Durand - 0.3-1 - Update to 0.3 hunspell-1.1.8.2-1.fc8 ---------------------- * Wed Jul 18 2007 Caolan McNamara - 1.1.8.2-1 - latest version hunspell-pt-0.20070709-1.fc8 ---------------------------- * Wed Jul 18 2007 Caolan McNamara - 0.20070709-1 - latest pt_PT version kernel-2.6.23-0.30.rc0.git6.fc8 ------------------------------- * Wed Jul 18 2007 John W. Linville - mac80211: avoid deadlock during device shutdown kernel-xen-2.6-2.6.20-2925.12.fc8 --------------------------------- * Tue Jul 17 2007 Eduardo Habkost - Make blkfront module wait for the disk to be added (bug #248462) - Rebase to 2.6.20.14 kexec-tools-1.101-75.fc8 ------------------------ * Wed Jul 18 2007 Neil Horman - 1.101-75.fc8 - Updated fr.po translations (bz 248287) libselinux-2.0.24-2.fc8 ----------------------- * Wed Jul 18 2007 Dan Walsh - 2.0.24-2 - Fix matchpathcon to set default myprintf lucene-0:1.9.1-1jpp.1.fc8 ------------------------- * Tue Jul 17 2007 Ben Konrath 0:1.9.1-1jpp.1 - Disable db sub-package. - Disable generating test report. - Add OSGi manifest. - Obsolete lucene-devel. * Wed Mar 29 2006 Ralph Apel 0:1.9.1-1jpp - Upgrade to 1.9.1 * Tue Apr 26 2005 Ville Skytt?? - 0:1.4.3-2jpp - Add unversioned javadoc dir symlink. - Crosslink with local JDK javadocs. - Convert specfile to UTF-8. - Fix URLs. lvm2-2.02.27-1.fc8 ------------------ * Sat Jul 28 2007 Alasdair Kergon - 2.02.27-1 - Add -f to vgcfgrestore to list metadata backup files. - Add pvdisplay --maps implementation. - Add devices/preferred_names config regex list for displayed device names. - Add vg_mda_count and pv_mda_count columns to reports. - Change cling alloc policy attribute character from 'C' to l'. - Print warnings to stderr instead of stdout. - Fix snapshot cow area deactivation if origin is not active. - Reinitialise internal lvmdiskscan variables when called repeatedly. - Allow keyboard interrupt during user prompts when appropriate. - Fix deactivation code to follow dependencies and remove symlinks. - Fix a segfault in device_is_usable() if a device has no table. - Fix creation and conversion of mirrors with tags. - Add command stub for pvck. - Handle vgsplit of an entire VG as a vgrename. - Fix vgsplit for lvm1 format (set and validate VG name in PVs metadata). - Split metadata areas in vgsplit properly. - Fix and clarify vgsplit error messages. - Update lists of attribute characters in man pages. - Remove unsupported LVM1 options from vgcfgrestore man page. - Update vgcfgrestore man page to show mandatory VG name. - Update vgrename man page to include UUID and be consistent with lvrename. - Add some more debug messages to clvmd startup. - Fix thread race in clvmd. - Make clvmd cope with quorum devices. - Add extra internal error checking to clvmd. - Fix missing lvm_shell symbol in lvm2cmd library. - Move regex functions into libdevmapper. - Add kernel and device-mapper targets versions to lvmdump. - Add /sys/block listings to lvmdump. - Make lvmdump list /dev recursively. - Mark /etc/lvm subdirectories as directories in spec file. m17n-db-1.4.0-1.fc8 ------------------- * Thu Jul 19 2007 Parag Nemade - 1.4.0-1 - Updated to new upstream release 1.4.0 * Wed Jul 18 2007 Jens Petersen - install .pc file under /usr/share/pkgconfig and include it in a new devel subpackage mock-0.7.4-1.fc8 ---------------- * Wed Jul 18 2007 Michael Brown - 0.7.4-1 - return child exit status, so we properly report subcommand failures openvrml-0.16.6-2.fc8 --------------------- * Thu Jun 07 2007 Braden McDaniel - 0.16.6-2 - Updated firefox dependency to 2.0.0.5. pm-utils-0.99.3-9.fc8 --------------------- * Wed Jul 18 2007 Phil Knirsch - 0.99.3-9 - Fixed description to be distribution independant (#247366) python-virtinst-0.200.0-1.fc8 ----------------------------- * Wed Jul 18 2007 Daniel P. Berrange - 0.200.0-1.fc8 - Updated to 0.200.0 - Added virt-clone tool - Added manual pages qt4-4.3.0-9.fc8 --------------- * Sun Jul 15 2007 Rex Dieter 4.3.0-9 - multilib broken: qconfig.h (#248768) - +%_qt4_demosdir,%_qt4_examplesdir - + Qt.pc, provide pkgconfig access to qt4 macros/variables roundup-1.3.3-2.fc8 ------------------- * Thu Jul 19 2007 Paul P. Komkoff Jr - 1.3.3-2 - add dist tag sofia-sip-1.12.6-8.fc8 ---------------------- * Tue Jul 03 2007 Jeffrey C. Ollie - 1.12.6-8 - Disable checks for now, they all pass in local mock builds but fail when built with plague. * Tue Jul 03 2007 Jeffrey C. Ollie - 1.12.6-7 - Enable more debugging output from "make check" trac-0.10.4-1.fc7 ----------------- * Thu May 03 2007 Jeffrey C. Ollie - 0.10.4-1 - Update to 0.10.4 util-linux-2.13-0.52.fc7 ------------------------ * Mon Jul 09 2007 Karel Zak 2.13-0.52 - fix #245578 - login's PAM configuration inits the keyring at an inconvenient time - fix #231532 - "pamconsole" not documented in mount(8) - fix #243930 - translation files exist, but are not being used - fix #228731 - sfdisk doesn't support DM-MP device (add default heads and sectors) - fix #231192 - ipcs is not printing correct values on pLinux - fix #245912 - mount doesn't write the 'loop=...' option in /etc/mtab when mounting a loop device - fix #213253 - "cal -3" generates improperly formatted output wxGlade-0.5-6.fc8 ----------------- * Thu Jul 19 2007 ZC Miao - 0.5-6 - 248795 , patch for launch help docs correctly Broken deps for i386 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.i386 requires libopal.so.0 ScientificPython - 2.6-8.fc8.i386 requires liborte.so.0 eclipse-platform - 1:3.3.0-2.fc8.i386 requires lucene-devel eggdrop - 1.6.18-8.fc7.i386 requires libdns.so.32 galeon - 2.0.3-10.fc7.i386 requires gecko-libs = 0:1.8.1.5 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kst-fits - 1.4.0-3.fc8.i386 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.i386 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.i386 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 openvrml - 0.16.6-2.fc8.i386 requires firefox = 0:2.0.0.5 openvrml-devel - 0.16.6-2.fc8.i386 requires firefox-devel = 0:2.0.0.5 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.i386 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.i386 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.x86_64 requires libopal.so.0()(64bit) ScientificPython - 2.6-8.fc8.x86_64 requires liborte.so.0()(64bit) eclipse-platform - 1:3.3.0-2.fc8.x86_64 requires lucene-devel eggdrop - 1.6.18-8.fc7.x86_64 requires libdns.so.32()(64bit) galeon - 2.0.3-10.fc7.x86_64 requires gecko-libs = 0:1.8.1.5 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump kst-fits - 1.4.0-3.fc8.x86_64 requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.x86_64 requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.x86_64 requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 openvrml - 0.16.6-2.fc8.i386 requires firefox = 0:2.0.0.5 openvrml - 0.16.6-2.fc8.x86_64 requires firefox = 0:2.0.0.5 openvrml-devel - 0.16.6-2.fc8.i386 requires firefox-devel = 0:2.0.0.5 openvrml-devel - 0.16.6-2.fc8.x86_64 requires firefox-devel = 0:2.0.0.5 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) php-eaccelerator - 5.2.2_0.9.5-2.fc7.x86_64 requires php-common = 0:5.2.2 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.x86_64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc requires libopal.so.0 ScientificPython - 2.6-8.fc8.ppc requires liborte.so.0 eclipse-platform - 1:3.3.0-2.fc8.ppc requires lucene-devel eggdrop - 1.6.18-8.fc7.ppc requires libdns.so.32 galeon - 2.0.3-10.fc7.ppc requires gecko-libs = 0:1.8.1.5 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp kst-fits - 1.4.0-3.fc8.ppc requires cfitsio = 0:3.030 lablgl - 1.02-9.fc7.ppc requires labltk = 0:3.09.3 lablgl - 1.02-9.fc7.ppc requires ocaml = 0:3.09.3 lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 openvrml - 0.16.6-2.fc8.ppc64 requires firefox = 0:2.0.0.5 openvrml - 0.16.6-2.fc8.ppc requires firefox = 0:2.0.0.5 openvrml-devel - 0.16.6-2.fc8.ppc64 requires firefox-devel = 0:2.0.0.5 openvrml-devel - 0.16.6-2.fc8.ppc requires firefox-devel = 0:2.0.0.5 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc requires php-common = 0:5.2.2 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- ScientificPython - 2.6-8.fc8.ppc64 requires liborte.so.0()(64bit) ScientificPython - 2.6-8.fc8.ppc64 requires libopal.so.0()(64bit) ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) dkms - 2.0.16-1.fc7.noarch requires kernel-devel eclipse-platform - 1:3.3.0-2.fc8.ppc64 requires lucene-devel eggdrop - 1.6.18-8.fc7.ppc64 requires libdns.so.32()(64bit) fuse - 2.6.5-2.fc8.ppc64 requires kernel >= 0:2.6.14 galeon - 2.0.3-10.fc7.ppc64 requires gecko-libs = 0:1.8.1.5 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kst-fits - 1.4.0-3.fc8.ppc64 requires cfitsio = 0:3.030 openvrml - 0.16.6-2.fc8.ppc64 requires firefox = 0:2.0.0.5 openvrml-devel - 0.16.6-2.fc8.ppc64 requires firefox-devel = 0:2.0.0.5 pcmciautils - 014-9.fc8.ppc64 requires kernel >= 0:2.6.12-1.1411_FC5 php-eaccelerator - 5.2.2_0.9.5-2.fc7.ppc64 requires php-common = 0:5.2.2 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syck-php - 0.55-16.fc8.ppc64 requires php = 0:5.2.2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) systemtap - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) varnish - 1.0.4-2.fc8.ppc64 requires kernel >= 0:2.6.0 vpnc - 0.4.0-2.fc7.ppc64 requires kernel >= 0:2.4 xorg-x11-drv-nouveau - 2.1.2-1.fc8.ppc64 requires kernel-drm-nouveau = 0:6 From mattdm at mattdm.org Thu Jul 19 10:28:43 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 06:28:43 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> Message-ID: <20070719102843.GA8485@jadzia.bu.edu> On Thu, Jul 19, 2007 at 09:26:39AM +0000, Kevin Kofler wrote: > > IIUC it would be "automatic" in that it launches say pirut to install > > the missing package, which would prompt you for your root password > > before continuing. > But what if you are just a regular user who doesn't have the root password? > That pretty much limits the use of this feature to administrative programs > (which require root anyway). Otherwise users will end up with half-broken apps This should be done as configurable policy. In fact, that can be done *now*, with one missing crucial bit -- the concept of limited access to packages in yum. Which we could make a really crack-ridden plugin to deal with.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 19 10:30:29 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 06:30:29 -0400 Subject: rsyslog is in F8 In-Reply-To: <20070719071706.19c7e7ee@pensja.lam.pl> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> <469E1FBD.8020408@redhat.com> <20070719050209.GA18771@jadzia.bu.edu> <20070719071706.19c7e7ee@pensja.lam.pl> Message-ID: <20070719103029.GB8485@jadzia.bu.edu> On Thu, Jul 19, 2007 at 07:17:06AM +0200, Leszek Matok wrote: > > plugin. > In case of upgrading FC6 or F7 to F8, the plugin would have to be installed > and enabled on every installation of both on FC6 and F7... No, just every installation that wants to do a live yum upgrade. That's a considerably simpler case, since presumably they're already keeping their systems up to date with yum. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From devrim at CommandPrompt.com Thu Jul 19 10:33:56 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Thu, 19 Jul 2007 13:33:56 +0300 Subject: Broken dependencies in Fedora 6 - 2007-07-19 In-Reply-To: <20070719100407.21318.97779@extras64.linux.duke.edu> References: <20070719100407.21318.97779@extras64.linux.duke.edu> Message-ID: <1184841236.3057.19.camel@localhost.localdomain> Hi, To whom should I ask for removal of these packages? Regards, Devrim On Thu, 2007-07-19 at 10:04 +0000, Fedora Extras repoclosure wrote: > This is an automated mail created by an experimental script. > Your following packages in the repository contain broken dependencies: > > ====================================================================== > The results in this report consider unreleased updates in the > build-system's needsign-queue! > ====================================================================== > > package: postgis-jdbc - 1.2.0-4.fc6.i386 from fedora-extras-6-i386 > unresolved deps: > postgis = 0:1.2.0-4.fc6 > > package: postgis-jdbc - 1.2.0-4.fc6.ppc from fedora-extras-6-ppc > unresolved deps: > postgis = 0:1.2.0-4.fc6 > > package: postgis-jdbc - 1.2.0-4.fc6.x86_64 from fedora-extras-6-x86_64 > unresolved deps: > postgis = 0:1.2.0-4.fc6 > -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.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 buildsys at fedoraproject.org Thu Jul 19 10:50:16 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Jul 2007 06:50:16 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-19 Message-ID: <20070719105016.E4CAC152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 11 NEW avr-libc-1.4.6-4.fc6 : C library for use with GCC on Atmel AVR microcontrollers compat-libosip2-2.2.2-13.fc6 NEW edac-utils-0.9-6.fc6 : Userspace helper for kernel EDAC drivers gnome-applet-sensors-1.8.1-1.fc6 gnome-specimen-0.3-1.fc6 gscan2pdf-0.9.14-1.fc6 orage-4.4.1-2.fc6 perl-Text-Aspell-0.08-1.fc6 NEW R-BufferedMatrix-1.0.1-5.fc6 : A matrix data storage object held in temporary files shorewall-3.4.5-1.fc6 wxGlade-0.5-6.fc6 Changes in Fedora Extras 6: avr-libc-1.4.6-4.fc6 -------------------- * Tue Jul 17 2007 Hans de Goede 1.4.6-4 - Gzip manpages - Make manpages %doc - Install -docs documentation in same dir as the main package docs - Change License field from GPL to BSD (oops) compat-libosip2-2.2.2-13.fc6 ---------------------------- * Tue Jul 17 2007 Jeffrey C. Ollie - 2.2.2-13 - Remove provides libosip2-devel edac-utils-0.9-6.fc6 -------------------- * Tue Jul 17 2007 Aristeu Rozanski 0.9-6 - Building for FC6 package * Mon Jul 09 2007 Aristeu Rozanski 0.9-5 - Fixed start/stop message, missing echo - Fixed status command to use edac-util gnome-applet-sensors-1.8.1-1.fc6 -------------------------------- * Sun Jul 15 2007 Hans de Goede 1.8.1-1 - New upstream release 1.8.1 (fixes bz 235655, 190509) - Add gtk-icon-update-cache to post scripts (fixes bz 206529) - Pass proper directory for omf files to scrollkeeper-update in post script - Initialize sensors low and high tresholds from libsensors settings - Various specfile cleanups gnome-specimen-0.3-1.fc6 ------------------------ * Wed Jul 18 2007 Damien Durand - 0.3-1 - Update to 0.3 gscan2pdf-0.9.14-1.fc6 ---------------------- * Wed Jul 11 2007 Bernard Johnson - 0 9.14-1 - v 0.9.14 orage-4.4.1-2.fc6 ----------------- * Wed Jul 04 2007 Kevin Fenzi - 4.4.1-2 - Fix category in desktop file (fixes #243601) * Wed Apr 11 2007 Kevin Fenzi - 4.4.1-1 - Update to 4.4.1 perl-Text-Aspell-0.08-1.fc6 --------------------------- * Mon Jul 16 2007 Jerry James - 0.08-1 - Update to 0.08 R-BufferedMatrix-1.0.1-5.fc6 ---------------------------- * Wed Jul 11 2007 Pingou 1.0.1-5 - Change in the files section to fit the guidelines * Wed Jul 11 2007 Pingou 1.0.1-4 - Change in the spec to remove the %{__**} form in the macro * Tue Jul 10 2007 Pingou 1.0.1-3 - Change in post and postun to fit the packaging guidelines - Change in the prep section to fit the guidelines * Thu Jul 05 2007 Pingou 1.0.1-2 - Fix install include * Mon Jul 02 2007 Pingou 1.0.1-1 - initial package for Fedora shorewall-3.4.5-1.fc6 --------------------- * Tue Jul 17 2007 Robert Marcano - 3.4.5-1 - Update to upstream 3.4.5 wxGlade-0.5-6.fc6 ----------------- * Thu Jul 19 2007 ZC Miao - 0.5-6 - 248795 , patch for launch help docs correctly * Mon Apr 16 2007 ZC Miao - 0.5-5 - update to fix EVR problem For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From kanarip at kanarip.com Thu Jul 19 11:02:25 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 19 Jul 2007 13:02:25 +0200 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <469F314C.8030104@kanarip.com> Message-ID: <469F44C1.6020603@kanarip.com> Kevin Kofler wrote: > Jeroen van Meeuwen kanarip.com> writes: >> Half broken apps because of missing dependencies that are needed for >> "extra features" rather then "core functionality" is just bad >> programming/app design. > > But missing those "extra features" is exactly what I call "half broken". > Aha, I thought the 'broken' part implied buttons that do not respond and options that are in the --usage/--help but don't do anything (and the like) ;-) > I think soft dependencies are a much more admin-friendly way to handle this. > Rex Dieter is working on a proposal there: > http://fedoraproject.org/wiki/RexDieter/SoftDependencies +1 > It'd also have the advantage of not locking users into the > yum/pirut/system-install-packages framework if they wish to use apt-rpm or > smart instead. > Whatever other application a (super)user may install does not limit the features we could add to whatever we choose to be a system's default. apt-rpm and smart in this case would just not happily do soft deps. No big deal. And if they do, they may have no policy option. Again, no big deal. > And IMHO even a hard dependency is a better approach than a post-install > prompt. Disk space is cheap. > True, disk space is cheap, and for some parts of the world, that applies to bandwidth too. I also have to agree on that, under certain circumstances, hard deps are better. However that isn't mutually exclusive with soft deps. If soft deps for a package are 'listed' (in RPMDB?) and some file from the package requests a soft dep to be installed I presume a superuser could set something like a policy which allows or disallows the automated installation of the soft dep, without requiring the user to gain superuser privileges. That same policy could include 'follow', 'ask' or 'ignore' so that when the admin yum installs foo soft depending on bar, it could either automagically follow, ask or ignore. Kind regards, Jeroen van Meeuwen -kanarip From gilboad at gmail.com Thu Jul 19 11:11:24 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 19 Jul 2007 14:11:24 +0300 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <469DDEA4.2040104@fedoraproject.org> References: <1184663992.21133.15.camel@pc-notebook> <1184714900.8695.9.camel@pc-notebook> <1184750927.4382.20.camel@gilboa-work-dev.localdomain> <469DDEA4.2040104@fedoraproject.org> Message-ID: <1184843484.24758.0.camel@gilboa-work-dev.localdomain> On Wed, 2007-07-18 at 15:04 +0530, Rahul Sundaram wrote: > Gilboa Davara wrote: > > >> [1] http://fedoraproject.org/wiki/Artwork/NodokaTheme > > > > Are you going to upstream it? > > Once upstream it should be easier to find someone in the KDE side of > > things to create a similar-looking-KDE-port. > > What do you mean by upstreaming it? This is a theme that requires it's > own engine. Essentially Fedora *is* upstream here. > > Rahul ... Create a project site, promote it,etc. In short, making it a non-Fedora specific project. - Gilboa From skvidal at linux.duke.edu Thu Jul 19 11:52:13 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 19 Jul 2007 07:52:13 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070719102843.GA8485@jadzia.bu.edu> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> Message-ID: <1184845933.606.196.camel@cutter> On Thu, 2007-07-19 at 06:28 -0400, Matthew Miller wrote: > On Thu, Jul 19, 2007 at 09:26:39AM +0000, Kevin Kofler wrote: > > > IIUC it would be "automatic" in that it launches say pirut to install > > > the missing package, which would prompt you for your root password > > > before continuing. > > But what if you are just a regular user who doesn't have the root password? > > That pretty much limits the use of this feature to administrative programs > > (which require root anyway). Otherwise users will end up with half-broken apps > > This should be done as configurable policy. In fact, that can be done *now*, > with one missing crucial bit -- the concept of limited access to packages > in yum. Which we could make a really crack-ridden plugin to deal with.... > 'the concept of limited access to packages in yum'? What does that mean? I'm not sure I understand the usage here and so I'm not sure where/how it would work as a plugin. -sv From mattdm at mattdm.org Thu Jul 19 12:08:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 08:08:02 -0400 Subject: rsyslog is in F8 In-Reply-To: <20070719071706.19c7e7ee@pensja.lam.pl> References: <469DE95D.8080006@redhat.com> <1184760623.606.109.camel@cutter> <1184767254.4503.8.camel@lt21223.campus.dmacc.edu> <1184767074.606.130.camel@cutter> <469E1FBD.8020408@redhat.com> <20070719050209.GA18771@jadzia.bu.edu> <20070719071706.19c7e7ee@pensja.lam.pl> Message-ID: <20070719120802.GA16637@jadzia.bu.edu> On Thu, Jul 19, 2007 at 07:17:06AM +0200, Leszek Matok wrote: > echo in %post, like: > if service rsyslog status > then > echo rsyslog is installed, but not running, you may want to start it > echo manually, typing: service rsyslog start > fi > ...or something. This way the text-mode yum upgraders will see it and GUI > users aren't real sysadmins needing a logger anyway :) Turns out this isn't necessary, because it sort of does this by itself: (1/1): rsyslog-1.17.0-1.f 100% |=========================| 91 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: rsyslog [2/2]warning: /etc/rsyslog.conf created as /etc/rsyslog.conf.rpmnew warning: /etc/sysconfig/rsyslog created as /etc/sysconfig/rsyslog.rpmnew Installing: rsyslog ######################### [2/2] warning: /etc/syslog.conf saved as /etc/syslog.conf.rpmsave Traceback (most recent call last): File "/usr/lib/python2.5/logging/handlers.py", line 665, in emit self._connect_unixsocket(self.address) File "/usr/lib/python2.5/logging/handlers.py", line 605, in _connect_unixsocket self.socket.connect(address) File "", line 1, in connect error: (2, 'No such file or directory') Removing : sysklogd ######################### [3/2] Installed: rsyslog.i386 0:1.17.0-1.fc8 Complete! :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 19 12:25:29 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 08:25:29 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <1184845933.606.196.camel@cutter> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> Message-ID: <20070719122529.GA16818@jadzia.bu.edu> On Thu, Jul 19, 2007 at 07:52:13AM -0400, seth vidal wrote: > > > But what if you are just a regular user who doesn't have the root > > > password? That pretty much limits the use of this feature to > > > administrative programs (which require root anyway). Otherwise users > > > will end up with half-broken apps > > This should be done as configurable policy. In fact, that can be done > > *now*, with one missing crucial bit -- the concept of limited access to > > packages in yum. Which we could make a really crack-ridden plugin to > > deal with.... > 'the concept of limited access to packages in yum'? > What does that mean? I'm not sure I understand the usage here and so I'm > not sure where/how it would work as a plugin. For many systems, it'd be handy for users to be able to autheneticate with their own passwords, and then with those credentials add and remove *user level* software from known repositories with valid GPG keys, but still require root (or wheel group membership) to add or (and especially) remove system level software. That's useful -- but, as mentioned, kinda crack-ridden. (Partly, of course, because the distinction between user level and system level is very blurry.) Right now, it's trivially easy to make it so you can run yum with your own credentials -- but it's not limited in any way. Doing this the right way (perhaps with oddjob) would be a bit of work, but doing it the easy but less secure way -- run as root, check for limitations -- could be done with a plugin. As a first cut for policy 1) users can't do anything that would cause a member of the Core or Base groups to be removed 2) can add and remove packages from a list of groups like GNOME Desktop Environment, Games and Entertainment, etc., as long as it doesn't conflict with #1 3) can't do anything else Perhaps the list of protected-from-removal packages would need to be expanded, but that's the basic idea. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Jul 19 12:25:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 08:25:55 -0400 Subject: Broken dependencies in Fedora 6 - 2007-07-19 In-Reply-To: <1184841236.3057.19.camel@localhost.localdomain> References: <20070719100407.21318.97779@extras64.linux.duke.edu> <1184841236.3057.19.camel@localhost.localdomain> Message-ID: <20070719082555.4ff450b4@ender> On Thu, 19 Jul 2007 13:33:56 +0300 "Devrim G?ND?Z" wrote: > To whom should I ask for removal of these packages? http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Jul 19 12:36:24 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 08:36:24 -0400 Subject: rsyslog is in F8 In-Reply-To: <469DE95D.8080006@redhat.com> References: <469DE95D.8080006@redhat.com> Message-ID: <20070719123624.GA20033@jadzia.bu.edu> On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: > sysklogd config files syslog.conf, sysconfig/syslog are renamed to > rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog > is replaced. Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage of rsyslog over syslog-ng? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kanarip at kanarip.com Thu Jul 19 12:45:11 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 19 Jul 2007 14:45:11 +0200 Subject: rsyslog is in F8 In-Reply-To: <20070719123624.GA20033@jadzia.bu.edu> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> Message-ID: <469F5CD7.10700@kanarip.com> Matthew Miller wrote: > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog >> is replaced. > > Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage > of rsyslog over syslog-ng? > A little late in the discussion but I had to read the entire thread before asking this: Why does rsyslogd have to obsolete syslogd? Kind regards, Jeroen van Meeuwen -kanarip From martin.sourada at seznam.cz Thu Jul 19 12:50:21 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Thu, 19 Jul 2007 14:50:21 +0200 Subject: [New Feature Proposition]: Nodoka Theme In-Reply-To: <1184843484.24758.0.camel@gilboa-work-dev.localdomain> References: <1184663992.21133.15.camel@pc-notebook> <1184714900.8695.9.camel@pc-notebook> <1184750927.4382.20.camel@gilboa-work-dev.localdomain> <469DDEA4.2040104@fedoraproject.org> <1184843484.24758.0.camel@gilboa-work-dev.localdomain> Message-ID: <1184849421.8695.17.camel@pc-notebook> On Thu, 2007-07-19 at 13:11 +0200, Gilboa Davara wrote: > On Wed, 2007-07-18 at 15:04 +0530, Rahul Sundaram wrote: > ... Create a project site, promote it,etc. > In short, making it a non-Fedora specific project. > > - Gilboa > As for that Fedora could be upstream IMHO (e.g. Smolt is upstreamed by Fedora as well and it's present in some other distros as well). I saw that on today's FESCO meeting among the Nodoka Theme feature approval will be discussed (among other things) so I'll wait for the result (and I hope I'll have time to attend the meeting personally, but so far it seems that I will not). Then I request a hosting space for it on fedora hosted (if the meeting would be successful enough to convince me I'll have a chance of approval) or somewhere else (e.g. on sourceforge.net). Martin -------------- next part -------------- A non-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 Jul 19 13:21:56 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 09:21:56 -0400 Subject: rsyslog is in F8 In-Reply-To: <469F5CD7.10700@kanarip.com> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F5CD7.10700@kanarip.com> Message-ID: <20070719132156.GA23866@jadzia.bu.edu> On Thu, Jul 19, 2007 at 02:45:11PM +0200, Jeroen van Meeuwen wrote: > Why does rsyslogd have to obsolete syslogd? That's easy -- because it does. The original syslogd is no longer in development. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Thu Jul 19 13:50:33 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 19 Jul 2007 09:50:33 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070719122529.GA16818@jadzia.bu.edu> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> Message-ID: <1184853033.606.208.camel@cutter> On Thu, 2007-07-19 at 08:25 -0400, Matthew Miller wrote: > For many systems, it'd be handy for users to be able to autheneticate with > their own passwords, and then with those credentials add and remove *user > level* software from known repositories with valid GPG keys, but still > require root (or wheel group membership) to add or (and especially) remove > system level software. That's useful -- but, as mentioned, kinda > crack-ridden. (Partly, of course, because the distinction between user level > and system level is very blurry.) blurry? no it's completely non-existent. :) > Right now, it's trivially easy to make it so you can run yum with your own > credentials -- but it's not limited in any way. Doing this the right way > (perhaps with oddjob) would be a bit of work, but doing it the easy but less > secure way -- run as root, check for limitations -- could be done with a > plugin. > > As a first cut for policy > > 1) users can't do anything that would cause a member of the Core or Base > groups to be removed > 2) can add and remove packages from a list of groups like GNOME Desktop > Environment, Games and Entertainment, etc., as long as it doesn't > conflict with #1 > 3) can't do anything else > > Perhaps the list of protected-from-removal packages would need to be > expanded, but that's the basic idea. This feels pretty scary. We'd constantly be moving the line to accommodate varying levels of paranoia - and we'd have a big list we'd have to keep current to make sure it wasn't outdated. -sv From pvrabec at redhat.com Thu Jul 19 14:06:27 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Thu, 19 Jul 2007 16:06:27 +0200 Subject: rsyslog is in F8 In-Reply-To: <20070719123624.GA20033@jadzia.bu.edu> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> Message-ID: <469F6FE3.6010605@redhat.com> Matthew Miller wrote: > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog >> is replaced. > > Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage > of rsyslog over syslog-ng? Hmmm, It use rsyslog.conf. cp syslog.conf rsyslog.conf is done, because we want to keep and use previous configuration. Or do you want your custom configuration be dropped and replaced by default one? :-) > From mattdm at mattdm.org Thu Jul 19 14:38:45 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 10:38:45 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <1184853033.606.208.camel@cutter> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> Message-ID: <20070719143845.GA29978@jadzia.bu.edu> On Thu, Jul 19, 2007 at 09:50:33AM -0400, seth vidal wrote: > > system level software. That's useful -- but, as mentioned, kinda > > crack-ridden. (Partly, of course, because the distinction between user > > level and system level is very blurry.) > blurry? no it's completely non-existent. :) There's at least a whole lot of overlap. :) > This feels pretty scary. We'd constantly be moving the line to > accommodate varying levels of paranoia - and we'd have a big list we'd > have to keep current to make sure it wasn't outdated. Maybe just a simple list of white-listed packages, then. If this were done, I'd think the default Fedora config should be very very conservative (and, also, the entire feature off), but having that infrastructure there could be very helpful for controlled environments. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 19 14:39:32 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 19 Jul 2007 10:39:32 -0400 Subject: rsyslog is in F8 In-Reply-To: <469F6FE3.6010605@redhat.com> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F6FE3.6010605@redhat.com> Message-ID: <20070719143932.GB29978@jadzia.bu.edu> On Thu, Jul 19, 2007 at 04:06:27PM +0200, Peter Vrabec wrote: > Hmmm, It use rsyslog.conf. > cp syslog.conf rsyslog.conf is done, because we want to keep and use Oh, I see. My misunderstanding. > previous configuration. Or do you want your custom configuration be > dropped and replaced by default one? :-) Not badly, no. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kanarip at kanarip.com Thu Jul 19 14:50:30 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 19 Jul 2007 16:50:30 +0200 Subject: rsyslog is in F8 In-Reply-To: <20070719132156.GA23866@jadzia.bu.edu> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F5CD7.10700@kanarip.com> <20070719132156.GA23866@jadzia.bu.edu> Message-ID: <469F7A36.80606@kanarip.com> Matthew Miller wrote: > On Thu, Jul 19, 2007 at 02:45:11PM +0200, Jeroen van Meeuwen wrote: >> Why does rsyslogd have to obsolete syslogd? > > That's easy -- because it does. The original syslogd is no longer in > development. > Right, I figured it would be something like syslogd being discontinued. On the other hand, it's been reasonably quiet for like 6 years. Please don't understand me wrong here, I do get the idea of why Fedora has to replace sysklogd for another package in whatever it releases and maintains. +1 to that. Nonetheless, my stupid question was about why it has to, immediately, explicitly, obsolete sysklogd, leaving "no" choice to continue using sysklogd. Do they conflict if only installed on the same system, in a way that can't be fixed? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Thu Jul 19 14:58:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 10:58:41 -0400 Subject: Fedora 8 Test 1 Freeze in 5 days Message-ID: <20070719105841.659dfa97@localhost.localdomain> That's right, it's about to get a lot colder in here. The Freeze date is set for July 24th, http://fedoraproject.org/wiki/Releases/8/Schedule To accomplish the freeze, we'll be following our existing policy: http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy And for a more overview of what a freeze is please see http://fedoraproject.org/wiki/ReleaseEngineering/Overview#head-f1ce962de535354f76b5103bac7be2d22c9a9045 At this time, the release engineering team will be working hard to resolve the current broken deps and conflicts and upgrade paths issues. Therefor your packages may wind up getting updated by us if you haven't gotten to them yet. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From tibbs at math.uh.edu Thu Jul 19 15:42:33 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Jul 2007 10:42:33 -0500 Subject: F8 Feature Status & FESCo review In-Reply-To: <7130.1184807819@laptop13.inf.utfsm.cl> References: <469EAF85.9030901@redhat.com> <7130.1184807819@laptop13.inf.utfsm.cl> Message-ID: >>>>> "HH" == Horst H von Brand writes: HH> One thing I miss is the inclusion of TeXlive (instead of the dead HH> teTeX) in Fedora 8. Someone who cares about this should really consider reviewing the package, then. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242416 - J< From cra at WPI.EDU Thu Jul 19 16:14:26 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 19 Jul 2007 12:14:26 -0400 Subject: rsyslog is in F8 In-Reply-To: <469F6FE3.6010605@redhat.com> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F6FE3.6010605@redhat.com> Message-ID: <20070719161426.GA6932@angus.ind.WPI.EDU> On Thu, Jul 19, 2007 at 04:06:27PM +0200, Peter Vrabec wrote: > Matthew Miller wrote: > > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: > >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to > >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog > >> is replaced. > > > > Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage > > of rsyslog over syslog-ng? > Hmmm, It use rsyslog.conf. > cp syslog.conf rsyslog.conf is done, because we want to keep and use > previous configuration. Or do you want your custom configuration be > dropped and replaced by default one? :-) For rsyslog to be a drop in replacement, it should use the same config file named the same in the same location IMO. From dominik at greysector.net Thu Jul 19 17:20:34 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 19 Jul 2007 19:20:34 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <469EFFD6.2010808@leemhuis.info> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> Message-ID: <20070719172034.GC10761@ryvius.pekin.waw.pl> On Thursday, 19 July 2007 at 08:08, Thorsten Leemhuis wrote: > > > On 19.07.2007 04:36, Rahul Sundaram wrote: > > Richard K?rber wrote: > > > >> My primary goal for repowatch was to watch several repositories > >> simultaneously, and give reports about packages that have been recently > >> added or removed from a repository. A nice side effect is the > >> possibility to online search for packages. > > > > You might want to consider having this done as part of the Fedora > > Project and file a RFR with the infrastructure team. > > > > http://fedoraproject.org/wiki/Infrastructure/RFR > > +1 > > And what I'd really like to see in repoview/repowatch/pkgs-db/whatever > is a kind of static-url like > > fedoraproject.org/pacakges/foo > > which gives some info *for users* about the package in Fedora and links > to the latest packages (or its repowatch/repoview/whatever pages that > have more details about the packages) for currently supported distributions. > > Then we could points users to that page and can tell the maintainers of > foo "for Fedora packages send your users to > fedoraproject.org/packages/foo for further informations" Exactly. Not to mention every other major distro has something like that. I felt a bit ashamed when I had to tell upstream that we don't have it when asked for a package URL. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From joshkel at gmail.com Thu Jul 19 17:27:19 2007 From: joshkel at gmail.com (Josh Kelley) Date: Thu, 19 Jul 2007 13:27:19 -0400 Subject: Disabling brp-strip for mock builds? In-Reply-To: References: <97cbd1a90707160909u1282f4b4sfd326b41600a5a5d@mail.gmail.com> Message-ID: <97cbd1a90707191027u1a98a09fpab154b776f46aa51@mail.gmail.com> On 7/16/07, Kevin Kofler wrote: > Josh Kelley gmail.com> writes: > > What do I need to do to properly disable brp-strip for mock builds? > > Does something like this work? > %define __os_install_post %(echo '%{__os_install_post}' | > sed -e 's!/usr/lib/rpm/[^/]*/?brp-strip %{__strip}!!g') Thank you for the suggestion. I had trouble getting it to work, although I think that that may have been user error on my part; I ended up copying Dag Wieers' approach from his acroread.spec file: %define __spec_install_post /usr/lib/rpm/brp-compress || : %define debug_package %{nil} That appears to work fine. Josh Kelley From jkeating at redhat.com Thu Jul 19 17:39:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 13:39:57 -0400 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <20070719172034.GC10761@ryvius.pekin.waw.pl> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> Message-ID: <20070719133957.51aeb748@localhost.localdomain> On Thu, 19 Jul 2007 19:20:34 +0200 "Dominik 'Rathann' Mierzejewski" wrote: > Exactly. Not to mention every other major distro has something like > that. I felt a bit ashamed when I had to tell upstream that we don't > have it when asked for a package URL. We have something close. You can view kojiweb anonymously and search for the package. The url is an ugly url, but it works. Not all /that/ informative, but is somewhat. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Jul 19 18:58:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 19 Jul 2007 14:58:04 -0400 Subject: rsyslog is in F8 In-Reply-To: <20070719161426.GA6932@angus.ind.WPI.EDU> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F6FE3.6010605@redhat.com> <20070719161426.GA6932@angus.ind.WPI.EDU> Message-ID: <1184871484.606.221.camel@cutter> On Thu, 2007-07-19 at 12:14 -0400, Chuck Anderson wrote: > On Thu, Jul 19, 2007 at 04:06:27PM +0200, Peter Vrabec wrote: > > Matthew Miller wrote: > > > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: > > >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to > > >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog > > >> is replaced. > > > > > > Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage > > > of rsyslog over syslog-ng? > > Hmmm, It use rsyslog.conf. > > cp syslog.conf rsyslog.conf is done, because we want to keep and use > > previous configuration. Or do you want your custom configuration be > > dropped and replaced by default one? :-) > > For rsyslog to be a drop in replacement, it should use the same config > file named the same in the same location IMO. OR it doesn't obsolete sysklogd. one or the other. -sv From linux_4ever at yahoo.com Thu Jul 19 20:48:05 2007 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 19 Jul 2007 13:48:05 -0700 (PDT) Subject: rsyslog is in F8 In-Reply-To: <20070719161426.GA6932@angus.ind.WPI.EDU> Message-ID: <776275.35493.qm@web51504.mail.re2.yahoo.com> >> Hmmm, It use rsyslog.conf. >> cp syslog.conf rsyslog.conf is done, because we want to keep and use >> previous configuration. Or do you want your custom configuration be >> dropped and replaced by default one? :-) > >For rsyslog to be a drop in replacement, it should use the same config >file named the same in the same location IMO. It was supposed to. I had created a file option in /etc/sysconfig/rsyslog that could be set so you could choose one or the other...that seems to have been dropped. The problem that we faced is that removing sysklogd causes syslog.conf to be renamed to syslog.conf.rpmsave...so we have to look for that file and rename it if the configuration file does not exist. The basic theory was supposed to be: 1) if neither syslog.conf or syslog.conf.rpmsave exist, modify /etc/sysconfig/rsyslog use rsyslog.conf 2) if syslog.conf doesn't exist and syslog.conf.rpmsave exists, rename it to syslog.conf. /etc/sysconfig/rsyslog defaults to syslog.conf so no change needed 3) use the config file option -f in the initscript to choose syslog.conf or rsyslog.conf which comes from /etc/sysconfig/rsyslog -Steve ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From greno at verizon.net Thu Jul 19 21:45:38 2007 From: greno at verizon.net (Gerry Reno) Date: Thu, 19 Jul 2007 17:45:38 -0400 Subject: resize2fs Message-ID: <469FDB82.6000203@verizon.net> Can all 2.6 kernels handle doing 'resize2fs' on a mounted (online) ext3 filesystem? From denis at poolshark.org Thu Jul 19 22:58:24 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 20 Jul 2007 00:58:24 +0200 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <469E149E.1000001@redhat.com> References: <469E149E.1000001@redhat.com> Message-ID: <469FEC90.1060903@poolshark.org> Kai Engert wrote: > We'll soon publish updated RPMs for a Firefox security release. > The new version 2.0.0.5 will go into F-7 and devel. > Please prepare to rebuild if you depend on gecko-devel. Yay for firefox update with no broken deps!!! From tmz at pobox.com Thu Jul 19 23:15:18 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 19 Jul 2007 19:15:18 -0400 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <469FEC90.1060903@poolshark.org> References: <469E149E.1000001@redhat.com> <469FEC90.1060903@poolshark.org> Message-ID: <20070719231518.GG22182@psilocybe.teonanacatl.org> Denis Leroy wrote: > Kai Engert wrote: >> We'll soon publish updated RPMs for a Firefox security release. >> The new version 2.0.0.5 will go into F-7 and devel. >> Please prepare to rebuild if you depend on gecko-devel. > > Yay for firefox update with no broken deps!!! https://bugzilla.redhat.com/248846 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Succumb to natural tendencies. Be hateful and boring. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From denis at poolshark.org Thu Jul 19 23:19:14 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 19 Jul 2007 16:19:14 -0700 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <20070719231518.GG22182@psilocybe.teonanacatl.org> References: <469E149E.1000001@redhat.com> <469FEC90.1060903@poolshark.org> <20070719231518.GG22182@psilocybe.teonanacatl.org> Message-ID: <469FF172.2070405@poolshark.org> Todd Zullinger wrote: > Denis Leroy wrote: >> Kai Engert wrote: >>> We'll soon publish updated RPMs for a Firefox security release. >>> The new version 2.0.0.5 will go into F-7 and devel. >>> Please prepare to rebuild if you depend on gecko-devel. >> Yay for firefox update with no broken deps!!! > > https://bugzilla.redhat.com/248846 now you just ruined my good mood... From tmz at pobox.com Thu Jul 19 23:31:05 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 19 Jul 2007 19:31:05 -0400 Subject: gecko-devel: rebuild or not to rebuild? In-Reply-To: <469FF172.2070405@poolshark.org> References: <469E149E.1000001@redhat.com> <469FEC90.1060903@poolshark.org> <20070719231518.GG22182@psilocybe.teonanacatl.org> <469FF172.2070405@poolshark.org> Message-ID: <20070719233105.GH22182@psilocybe.teonanacatl.org> Denis Leroy wrote: > now you just ruined my good mood... And for that I'm sorry. The good news is there appears to have been only one broken dep. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I advise you to go on living solely to enrage those who are paying your annuities. It is the only pleasure I have left. -- Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From lamont at gurulabs.com Thu Jul 19 23:40:13 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 19 Jul 2007 17:40:13 -0600 Subject: resize2fs In-Reply-To: <469FDB82.6000203@verizon.net> References: <469FDB82.6000203@verizon.net> Message-ID: <200707191740.17985.lamont@gurulabs.com> On Thursday 19 July 2007 03:45pm, Gerry Reno wrote: > Can all 2.6 kernels handle doing 'resize2fs' on a mounted (online) ext3 > filesystem? No. The kernels shipped with RHEL4 and FC4 are the first ones that can do online resizing of ext3 filesystems, but only if that filesystem was created using mke2fs (or mkfs or mkfs.ext3) that came with those releases. Back then, the command to do online resizing was ext2online (which would only work on ext3 filesystems, not ext2). For FC6, that command was removed and the functionality was brought into the resize2fs command, instead. RHEL5 is the first RHEL release with that version of resize2fs. I do not know (I've never bothered to test) if the newer resize2fs can do online resizing of ext2 filesystems or not. I tend to think it unlikely, but I haven't actually tested it. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Thu Jul 19 23:48:12 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 19 Jul 2007 19:48:12 -0400 Subject: How to best report repo problems like unsigned or wrongly signed packages? Message-ID: <20070719234812.GI22182@psilocybe.teonanacatl.org> Hey all, Someone on the fedora-list pointed out a problem with the latest cups packages for FC6. They're signed with the rawhide gpg key. I reported this in bugzilla[1], but I'm not sure that's the best way to get the info to the right eyes. I don't think that the maintainer is going to be able to fix the problem directly, so bugzilla is just an extra step in getting the problem resolved. I tried to CC rel-eng at fedoraproject.org, but bugzilla balked at that idea. What's the proper way to report such problems? Should it be submitted to the infrastructure ticket system? [1] https://bugzilla.redhat.com/248975 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First, God created idiots. That was just for practice. Then He created school boards. -- Mark Twain -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From eric.moret at epita.fr Thu Jul 19 23:55:26 2007 From: eric.moret at epita.fr (Eric Moret) Date: Thu, 19 Jul 2007 16:55:26 -0700 Subject: paprefs review request Message-ID: Hello all, PulseAudio is the new sound server that will replace esd in Fedora8. http://fedoraproject.org/wiki/Releases/FeaturePulseaudio PulseAudio Preferences (paprefs) is a simple GTK based configuration dialog for the PulseAudio sound server. The package itself needs a review. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222374 Spec URL: ftp://ftp.zouric.com/public/paprefs.spec SRPM URL: ftp://ftp.zouric.com/public/paprefs-0.9.5-1.src.rpm Please spend a few minutes reviewing it and log any comment to the above bugs. Thanks, __ Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Jul 20 00:09:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 20:09:43 -0400 Subject: How to best report repo problems like unsigned or wrongly signed packages? In-Reply-To: <20070719234812.GI22182@psilocybe.teonanacatl.org> References: <20070719234812.GI22182@psilocybe.teonanacatl.org> Message-ID: <20070719200943.45248499@ender> On Thu, 19 Jul 2007 19:48:12 -0400 Todd Zullinger wrote: > Someone on the fedora-list pointed out a problem with the latest cups > packages for FC6. They're signed with the rawhide gpg key. I > reported this in bugzilla[1], but I'm not sure that's the best way to > get the info to the right eyes. I don't think that the maintainer is > going to be able to fix the problem directly, so bugzilla is just an > extra step in getting the problem resolved. I tried to CC > rel-eng at fedoraproject.org, but bugzilla balked at that idea. > > What's the proper way to report such problems? Should it be submitted > to the infrastructure ticket system? > > [1] https://bugzilla.redhat.com/248975 Gah, that's my fault. Just reassign the bug to me and I'll sort it out when I get into the office tomorrow. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmz at pobox.com Fri Jul 20 00:26:10 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 19 Jul 2007 20:26:10 -0400 Subject: How to best report repo problems like unsigned or wrongly signed packages? In-Reply-To: <20070719200943.45248499@ender> References: <20070719234812.GI22182@psilocybe.teonanacatl.org> <20070719200943.45248499@ender> Message-ID: <20070720002610.GJ22182@psilocybe.teonanacatl.org> Jesse Keating wrote: > Gah, that's my fault. Just reassign the bug to me and I'll sort it > out when I get into the office tomorrow. Done. Not that this could or would ever happen again... but hypothetically, if it did is there a better way to make sure it gets to you or whomever is crazy^Wlucky enough to have your job? ;) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I used to think the brain was the most advanced part of the body. Then I realized, look what's telling me that. -- Emo Phillips -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 20 00:33:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 19 Jul 2007 20:33:25 -0400 Subject: How to best report repo problems like unsigned or wrongly signed packages? In-Reply-To: <20070720002610.GJ22182@psilocybe.teonanacatl.org> References: <20070719234812.GI22182@psilocybe.teonanacatl.org> <20070719200943.45248499@ender> <20070720002610.GJ22182@psilocybe.teonanacatl.org> Message-ID: <20070719203325.4b3f7c0b@ender> On Thu, 19 Jul 2007 20:26:10 -0400 Todd Zullinger wrote: > Done. Not that this could or would ever happen again... but > hypothetically, if it did is there a better way to make sure it gets > to you or whomever is crazy^Wlucky enough to have your job? ;) For lack of a better method right now, just mailing rel-eng at fedoraproject.org would suffice. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Fri Jul 20 01:29:25 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 19 Jul 2007 21:29:25 -0400 Subject: F8 Feature Status & FESCo review In-Reply-To: <469EAF85.9030901@redhat.com> References: <469EAF85.9030901@redhat.com> Message-ID: <1184894965.3121.4.camel@localhost.localdomain> On Wed, 2007-07-18 at 17:25 -0700, John Poelstra wrote: > Greetings Feature Owners, > > We reached our first "feature status update" on 2007-07-15. Thanks to the feature owners who have already updated their pages. If you are the owner of a feature, please update the status if you have not already done so. > > Since FESCo ratified the feature process (http://fedoraproject.org/wiki/Features/Policy) for F8, as the appointed Feature Wrangler, I've been tidying up the feature wiki pages. When the new process was adopted the intention was to grandfather in (where possible) features that had already been proposed. I have re-factored many feature pages to follow the new format while trying to stay true to original information recorded. > > I am also maintaining a feature status page of sorts that I am calling the "feature dashboard" that we will try out for the F8 release: http://fedoraproject.org/wiki/Features/Dashboard . I am using this page to keep a current status on which features are ready for FESCo review and those that are not. If your feature is up for review tomorrow, (see the Dashboard) I would encourage you to be present at the FESCo meeting tomorrow in #fedora-meeting (1700 UTC) to answer any questions that may arise. If you cannot be there (I apologize for the short notice) I'll collect questions and follow up with you. > Most of the desktop team is at Guadec in Birmingham today, with pretty flaky network connectivity, so I don't expect us to be able to update the feature proposals or be present at the meeting. From thomas.swan at gmail.com Fri Jul 20 03:15:52 2007 From: thomas.swan at gmail.com (Thomas Swan) Date: Thu, 19 Jul 2007 22:15:52 -0500 Subject: rsyslog is in F8 In-Reply-To: <20070719161426.GA6932@angus.ind.WPI.EDU> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F6FE3.6010605@redhat.com> <20070719161426.GA6932@angus.ind.WPI.EDU> Message-ID: On 7/19/07, Chuck Anderson wrote: > > On Thu, Jul 19, 2007 at 04:06:27PM +0200, Peter Vrabec wrote: > > Matthew Miller wrote: > > > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: > > >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to > > >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d > /syslog > > >> is replaced. > > > > > > Hey, uh, doesn't changing to using rsyslog.conf remove the major > advantage > > > of rsyslog over syslog-ng? > > Hmmm, It use rsyslog.conf. > > cp syslog.conf rsyslog.conf is done, because we want to keep and use > > previous configuration. Or do you want your custom configuration be > > dropped and replaced by default one? :-) > > For rsyslog to be a drop in replacement, it should use the same config > file named the same in the same location IMO. I agree here. Most people expect restarting syslog to be either /etc/init.d/syslogd restart or service syslogd restart. I think if you are going obsolete the old syslog here, and this is a one-for-one, drop-in replacement, keeping the same service names and the same configuration file should follow POLS. The process itself is compiled as syslogd per the upstream package. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petersen at redhat.com Fri Jul 20 04:47:47 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 20 Jul 2007 14:47:47 +1000 Subject: unfiled merge reviews In-Reply-To: <469C540C.2020005@redhat.com> References: <469C540C.2020005@redhat.com> Message-ID: <46A03E73.2090906@redhat.com> Jens Petersen ????????: > I am aware of a number of i18n (input method) related packages without > merge reviews (anthy, libchewing, m17n-db, and m17n-lib). There are > surely more in the distro. Should merge review bugs be opened for them? (Some old reviews exist for m17n-db (#169919), m17n-lib (#169922), and libchewing (#166472), but this is also true of scim-m17n and scim-chewing though they have new merge reviews too.) Jens From fedora at leemhuis.info Fri Jul 20 05:28:42 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 20 Jul 2007 07:28:42 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <20070719133957.51aeb748@localhost.localdomain> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> Message-ID: <46A0480A.5000404@leemhuis.info> On 19.07.2007 19:39, Jesse Keating wrote: > On Thu, 19 Jul 2007 19:20:34 +0200 > "Dominik 'Rathann' Mierzejewski" wrote: > [...] > The url is an ugly url, but it works. Not all /that/ > informative, but is somewhat. Hehe, I feared that someone would come up with this hack, and that's why I made two "*" around the "for users" (?) in my mail Rathann replied to, as koji is not sufficient for users IMHO and not something where we normally should point users to. CU thl (?) the text was: "And what I'd really like to see in repoview/repowatch/pkgs-db/whatever is a kind of static-url like fedoraproject.org/pacakges/foo which gives some info *for users* about the package in Fedora and links to the latest packages (or its repowatch/repoview/whatever pages that have more details about the packages) for currently supported distributions." From drago01 at gmail.com Fri Jul 20 06:32:25 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 20 Jul 2007 08:32:25 +0200 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070719122529.GA16818@jadzia.bu.edu> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> Message-ID: <46A056F9.9070400@gmail.com> Matthew Miller wrote: > On Thu, Jul 19, 2007 at 07:52:13AM -0400, seth vidal wrote: > >>>> But what if you are just a regular user who doesn't have the root >>>> password? That pretty much limits the use of this feature to >>>> administrative programs (which require root anyway). Otherwise users >>>> will end up with half-broken apps >>>> >>> This should be done as configurable policy. In fact, that can be done >>> *now*, with one missing crucial bit -- the concept of limited access to >>> packages in yum. Which we could make a really crack-ridden plugin to >>> deal with.... >>> >> 'the concept of limited access to packages in yum'? >> What does that mean? I'm not sure I understand the usage here and so I'm >> not sure where/how it would work as a plugin. >> > > For many systems, it'd be handy for users to be able to autheneticate with > their own passwords, and then with those credentials add and remove *user > level* software from known repositories with valid GPG keys, but still > require root (or wheel group membership) to add or (and especially) remove > system level software. That's useful -- but, as mentioned, kinda > crack-ridden. (Partly, of course, because the distinction between user level > and system level is very blurry.) > > Right now, it's trivially easy to make it so you can run yum with your own > credentials -- but it's not limited in any way. Doing this the right way > (perhaps with oddjob) would be a bit of work, but doing it the easy but less > secure way -- run as root, check for limitations -- could be done with a > plugin. > > As a first cut for policy > > 1) users can't do anything that would cause a member of the Core or Base > groups to be removed > 2) can add and remove packages from a list of groups like GNOME Desktop > Environment, Games and Entertainment, etc., as long as it doesn't > conflict with #1 > 3) can't do anything else > > Perhaps the list of protected-from-removal packages would need to be > expanded, but that's the basic idea. > > > > thats what policykit is for... From laroche at redhat.com Fri Jul 20 06:42:21 2007 From: laroche at redhat.com (Florian La Roche) Date: Fri, 20 Jul 2007 08:42:21 +0200 Subject: Presto: what happened to it? In-Reply-To: <1184691215.6534.5.camel@localhost.localdomain> References: <1184688237.3732.5.camel@sb-home> <1184691215.6534.5.camel@localhost.localdomain> Message-ID: <20070720064221.GA6522@dudweiler.stuttgart.redhat.com> > So the short answer is, we're working on it and it's currently being > tracked as a proposed feature for Fedora 8[1] I've added a reference to edelta: http://www.diku.dk/~jacobg/edelta/ This gives GNU licensed code for better integration into existing code if that is desired. regards, Florian La Roche From tmraz at redhat.com Fri Jul 20 09:26:23 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 20 Jul 2007 11:26:23 +0200 Subject: rsyslog is in F8 In-Reply-To: <776275.35493.qm@web51504.mail.re2.yahoo.com> References: <776275.35493.qm@web51504.mail.re2.yahoo.com> Message-ID: <1184923583.10041.27.camel@perun.kabelta.loc> On Thu, 2007-07-19 at 13:48 -0700, Steve G wrote: > >> Hmmm, It use rsyslog.conf. > >> cp syslog.conf rsyslog.conf is done, because we want to keep and use > >> previous configuration. Or do you want your custom configuration be > >> dropped and replaced by default one? :-) > > > >For rsyslog to be a drop in replacement, it should use the same config > >file named the same in the same location IMO. > > It was supposed to. I had created a file option in /etc/sysconfig/rsyslog that > could be set so you could choose one or the other...that seems to have been > dropped. > > The problem that we faced is that removing sysklogd causes syslog.conf to be > renamed to syslog.conf.rpmsave...so we have to look for that file and rename it > if the configuration file does not exist. > > The basic theory was supposed to be: > > 1) if neither syslog.conf or syslog.conf.rpmsave exist, modify > /etc/sysconfig/rsyslog use rsyslog.conf > 2) if syslog.conf doesn't exist and syslog.conf.rpmsave exists, rename it to > syslog.conf. /etc/sysconfig/rsyslog defaults to syslog.conf so no change needed > 3) use the config file option -f in the initscript to choose syslog.conf or > rsyslog.conf which comes from /etc/sysconfig/rsyslog Please no, this is ugly to have in some situations rsyslog using syslog.conf and in others rsyslog.conf. There are advantages and disadvantages on both sides either keeping the old config/init script names or using the new with 'r'. We choose the second one and that's it. We would be just facing other issues if we choose the first one. (e.g. Why package named rsyslog uses config file syslog.conf. Or why I cannot install both rsyslog and old sysklogd for testing purposes (with --force). And surely there are others.) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dtimms at iinet.net.au Fri Jul 20 09:43:25 2007 From: dtimms at iinet.net.au (David Timms) Date: Fri, 20 Jul 2007 19:43:25 +1000 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <20070719133957.51aeb748@localhost.localdomain> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> Message-ID: <46A083BD.8030902@iinet.net.au> Jesse Keating wrote: > On Thu, 19 Jul 2007 19:20:34 +0200 > "Dominik 'Rathann' Mierzejewski" wrote: > >> Exactly. Not to mention every other major distro has something like >> that. I felt a bit ashamed when I had to tell upstream that we don't >> have it when asked for a package URL. > > We have something close. You can view kojiweb anonymously and search > for the package. The url is an ugly url, but it works. Not all /that/ > informative, but is somewhat. Is there any particular limitations of what would be useful / allowed if the devel by Shred is to be hosted by fedora infrastructure. Best to get that sorted out before a rewrite... Having played slightly with django on python, I found pretty urls easily available. Does turbogears make that stuff easy as well ? DaveT. From kzak at redhat.com Fri Jul 20 09:59:37 2007 From: kzak at redhat.com (Karel Zak) Date: Fri, 20 Jul 2007 11:59:37 +0200 Subject: rsyslog is in F8 In-Reply-To: <1184923583.10041.27.camel@perun.kabelta.loc> References: <776275.35493.qm@web51504.mail.re2.yahoo.com> <1184923583.10041.27.camel@perun.kabelta.loc> Message-ID: <20070720095937.GA3060@localhost.localdomain> On Fri, Jul 20, 2007 at 11:26:23AM +0200, Tomas Mraz wrote: > On Thu, 2007-07-19 at 13:48 -0700, Steve G wrote: > > The basic theory was supposed to be: > > > > 1) if neither syslog.conf or syslog.conf.rpmsave exist, modify > > /etc/sysconfig/rsyslog use rsyslog.conf > > 2) if syslog.conf doesn't exist and syslog.conf.rpmsave exists, rename it to > > syslog.conf. /etc/sysconfig/rsyslog defaults to syslog.conf so no change needed > > 3) use the config file option -f in the initscript to choose syslog.conf or > > rsyslog.conf which comes from /etc/sysconfig/rsyslog over engineering, not transparent solution Please, keep the distribution simple and readable. We have ReleaseNotes where you can inform people about the change. You don't have to play this game with [r]syslog.conf. > Please no, this is ugly to have in some situations rsyslog using > syslog.conf and in others rsyslog.conf. Yes, especially with some magic switch somewhere in /etc/sysconfig/... > There are advantages and disadvantages on both sides either keeping the > old config/init script names or using the new with 'r'. We choose the > second one and that's it. We would be just facing other issues if we > choose the first one. (e.g. Why package named rsyslog uses config file > syslog.conf. Or why I cannot install both rsyslog and old sysklogd for > testing purposes (with --force). And surely there are others.) +1 Karel -- Karel Zak From buildsys at redhat.com Fri Jul 20 10:13:19 2007 From: buildsys at redhat.com (Build System) Date: Fri, 20 Jul 2007 06:13:19 -0400 Subject: rawhide report: 20070720 changes Message-ID: <200707201013.l6KADJLP002995@porkchop.devel.redhat.com> New package fityk Non-linear curve fitting and data analysis New package qt4-theme-quarticurve Unofficial port of the Bluecurve widget theme to Qt 4 Removed package lablgl Removed package sysklogd Updated Packages: ScientificPython-2.6-9.fc8 -------------------------- * Thu Jul 19 2007 Jesse Keating 2.6-9 - Rebuild for new openmpi anaconda-11.3.0.8-1 ------------------- * Thu Jul 19 2007 Chris Lumens 11.3.0.8-1 - Mark iSCSI root with _netdev mount option (markmc AT redhat DOT com, - Support multiple bind mounts when reading /etc/fstab (#246424). - Support ISOs being on the root partition to upgrade (#244002). - Improve error reporting when mounting swap (#248558). - Add support for labeling FAT filesystems (pjones). - Make x86 machines using EFI use /boot/efi and mark as bootable (pjones). - Lots of partition initialization cleanups (pjones). - Don't generate two errors for SCSI devices with > 15 partitions (pjones). cfv-1.18.1-3.fc8 ---------------- cpio-2.9-1.1.fc8 ---------------- * Thu Jul 19 2007 Radek Brich 2.9-1.1 - fix spec, rebuild * Thu Jul 19 2007 Radek Brich 2.9-1 - update to 2.9, GPLv3 cracklib-2.8.10-1 ----------------- * Thu Jul 19 2007 Nalin Dahyabhai - 2.8.10-1 - update to 2.8.10 cups-1:1.3-0.b1.2.fc8 --------------------- * Thu Jul 19 2007 Tim Waugh 1:1.3-0.b1.2 - Build requires avahi-compat-libdns_sd-devel. Applied patch to fix build against avahi (bug #245824). - Build requires krb5-devel. * Wed Jul 18 2007 Tim Waugh 1:1.3-0.b1.1 - 1.3b1. No longer need relro, directed-broadcast, af_unix-auth, or str2109 patches. * Fri Jul 13 2007 Tim Waugh 1:1.2.12-1 - 1.2.12. No longer need adminutil or str2408 patches. eggdrop-1.6.18-9.fc8 -------------------- * Thu Jul 19 2007 Jesse Keating 1.6.18-9 - Rebuild for new bind evolution-sharp-0.13.1-1.fc8 ---------------------------- * Thu Jul 19 2007 Matthew Barnes - 0.13.1-1.fc8 - Update to 0.13.1 * Fri Jun 29 2007 Matthew Barnes - 0.13-2.fc8 - Add alpha to ExclusiveArch (RH bug #246204). * Tue Jun 19 2007 Matthew Barnes - 0.13-1.fc8 - Update to 0.13 firefox-2.0.0.5-2.fc8 --------------------- * Wed Jul 18 2007 Kai Engert - 2.0.0.5-2 - Update to 2.0.0.5 firstboot-1.4.35-4.fc8 ---------------------- * Thu Jul 19 2007 Chris Lumens - 1.4.35-4 - Audit init script return codes and LSB header (#246925). gedit-1:2.19.2-2.fc8 -------------------- * Thu Jul 19 2007 Jeremy Katz - 1:2.19.2-2 - fix requires to be on pygtksoureview kernel-2.6.23-0.35.rc0.git6.fc8 ------------------------------- * Thu Jul 19 2007 John W. Linville - Update git-wireless-dev.patch * Wed Jul 18 2007 John W. Linville - mac80211: avoid deadlock during device shutdown * Mon Jul 16 2007 John W. Linville - Update git-wireless-dev.patch kexec-tools-1.101-76.fc8 ------------------------ * Thu Jul 19 2007 Neil Horman - 1.101-76.fc8 - Fix mkdumprd to suppress informative messages (bz 248797) knetworkmanager-0.1-0.10.svn20070719.fc8 ---------------------------------------- krb5-1.6.2-1.fc8 ---------------- * Tue Jul 17 2007 Nalin Dahyabhai 1.6.2-1 - update to 1.6.2 - add "buildrequires: texinfo-tex" to get texi2pdf * Wed Jun 27 2007 Nalin Dahyabhai 1.6.1-8 - incorporate fixes for MITKRB5-SA-2007-004 (CVE-2007-2442,CVE-2007-2443) and MITKRB5-SA-2007-005 (CVE-2007-2798) * Mon Jun 25 2007 Nalin Dahyabhai 1.6.1-7 - reintroduce missing %postun for the non-split_workstation case kst-1.4.0-4.fc8 --------------- * Thu Jul 19 2007 Jesse Keating - 1.3.0-4 - Rebuild for new cfitsio kvm-31-1.fc8 ------------ * Thu Jul 19 2007 Jeremy Katz - 31-1 - update to kvm-31 libgpg-error-1.5-1 ------------------ * Thu Jul 19 2007 Nalin Dahyabhai - 1.5-1 - update to 1.5 libmcrypt-2.5.8-1.fc8 --------------------- * Thu Jul 19 2007 Tom "spot" Callaway 2.5.8-1 - bump to 2.5.8 - proper quoting fixed upstream, patch1 obsolete libnetfilter_conntrack-0.0.80-1.fc8 ----------------------------------- * Thu Jul 19 2007 Paul P. Komkoff Jr - 0.0.80-1 - new upstream version libtiff-3.8.2-8.fc8 ------------------- * Thu Jul 19 2007 Tom Lane 3.8.2-8 - Restore static library to distribution, in a separate -static subpackage Resolves: #219905 - Don't apply multilib header hack to unrecognized architectures Resolves: #233091 - Remove documentation for programs we don't ship Resolves: #205079 Related: #185145 lm_sensors-2.10.4-1.fc8 ----------------------- * Thu Jul 19 2007 Hans de Goede - 2.10.4-1 - New upstream release 2.10.4 - Drop upstreamed patches 4, 5, 7 and 8 - Drop no longer need patch 3 - Move libsensors.3 manpage to -devel sub-package - Move sensord.8 manpage to -sensord sub-package - Switch from ExclusiveArch: alph ix86 x86_64, to ExcludeArch: s390 s390x, so that we get build on ppc, arm, etc. too. (bz 181037 amongst others) m17n-lib-1.4.0-1.fc8 -------------------- * Thu Jul 19 2007 Parag Nemade - 1.4.0-1 - Updated to new upstream release 1.4.0 mcrypt-2.6.6-1.fc8 ------------------ * Thu Jul 19 2007 Tom "spot" Callaway 2.6.6-1 - bump to 2.6.6 - destdir patch obsoleted upstream nginx-0.5.28-1.fc8 ------------------ * Wed Jul 18 2007 Jeremy Hinegardner - 0.5.28-1 - Update to 0.5.28 nss_ldap-256-1 -------------- * Thu Jul 19 2007 Nalin Dahyabhai - 256-1 - update to nss_ldap 256, pam_ldap 184 pam_krb5-2.2.14-2 ----------------- * Tue Jul 17 2007 Nalin Dahyabhai - 2.2.14-2 - rebuild * Fri Jul 13 2007 Nalin Dahyabhai - 2.2.14-1 - update to 2.2.14 * Thu Jul 12 2007 Nalin Dahyabhai - update to 2.2.13 pam_passwdqc-1.0.4-1 -------------------- * Thu Jul 19 2007 Nalin Dahyabhai - 1.0.4-1 - update to 1.0.4 perl-File-MMagic-XS-0.09002-1.fc8.1 ----------------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.09002-1.1 - BR: perl(Test::More) perl-Object-Realize-Later-0.18-1.fc8 ------------------------------------ php-eaccelerator-1:0.9.5.1-2 ---------------------------- * Thu Jul 19 2007 Jesse Keating 1:0.9.5.1-2 - Rebuild for new php * Fri Jun 22 2007 Matthias Saou 1:0.9.5.1-1 - Update to 0.9.5.1. - Major spec file cleanup, based on current PHP packaging guidelines. - Set Epoch to 1, since the proper versionning is lower than previously :-( - Remove two upstreamed patches (php52fix and trac187). - Use sed instead of perl for the config file changes. - No longer use dist because we want to use the same package on F-n and n+1. php-pear-1:1.6.1-1.fc8 ---------------------- * Thu Jul 19 2007 Remi Collet 1:1.6.1-1 - update to PEAR-1.6.1 and Console_Getopt-1.2.3 pirut-1.3.9-1.fc8 ----------------- * Thu Jul 19 2007 Jeremy Katz - 1.3.9-1 - Fix cd installer (#242857) - Drop legacy symlink (#238118) - Show uninstalled arches of packages in the list (#247343) - Make puplet more robust to yum-updatesd restarting pykickstart-1.5-2.fc8 --------------------- * Thu Jul 19 2007 Chris Lumens 1.5-2 - Require rhpl (#248953). python-paramiko-1.7.1-2.fc8 --------------------------- * Thu Jul 19 2007 Jeffrey C. Ollie - 1.7.1-2 - Bump rev * Thu Jul 19 2007 Jeffrey C. Ollie - 1.7.1-1 - Update to 1.7.1 redhat-lsb-3.1-15.f8 -------------------- * Wed Jul 18 2007 Lawrence - 3.1-15.f8 - Resolved: #239842 - /lib/lsb/init-functions shall use aliases but not functions - forward port the patch from 3.1-12.3.EL which fix #217566, #233530, #240916 rhpl-0.209-1 ------------ * Thu Jul 19 2007 Chris Lumens 0.209-1 - Don't traceback on keyboard maps that we don't support (#246766). seamonkey-1.1.3-2.fc8 --------------------- * Fri Jul 20 2007 Kai Engert - 1.1.3-2 - SeaMonkey 1.1.3 selinux-policy-3.0.3-1.fc8 -------------------------- * Tue Jul 17 2007 Dan Walsh 3.0.2-9 - Allow execution of gconf syck-0.55-17.fc8 ---------------- * Thu Jul 19 2007 Jesse Keating - 0.55-17 - Rebuild against new PHP, again. tasks-0.10-1.fc8 ---------------- * Thu Jul 19 2007 Dan Young - 0.10-1 - New upstream release tcpreplay-3.1.1-1.fc8 --------------------- * Fri Jul 20 2007 Bojan Smojver - 3.1.1-1 - bump up to 3.1.1 - drop the patch for libpcap.so detection, fixed upstream tzdata-2007f-1.fc7 ------------------ * Wed May 09 2007 Petr Machata - 2007f-1 - Upstream 2007f - New Zealand is extending DST, starting later this year. - Haiti no longer observes DST. - The Turks and Caicos switch at 02:00, not at 00:00, and have adopted US DST rules. udev-113-5.fc8 -------------- * Thu Jul 19 2007 Harald Hoyer - 113-5 - kernel changed subsystem name from usb_device to usb_endpoint, corrected the rule (#248916) Broken deps for i386 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 blam - 1.8.3-4.fc8.i386 requires firefox = 0:2.0.0.4 chmsee - 1.0.0-0.19.beta2.fc8.i386 requires firefox = 0:2.0.0.4 devhelp - 0.15-1.fc8.i386 requires gecko-libs = 0:1.8.1.4 eclipse-platform - 1:3.3.0-2.fc8.i386 requires lucene-devel epiphany - 2.19.5-1.fc8.i386 requires gecko-libs = 0:1.8.1.4 epiphany-devel - 2.19.5-1.fc8.i386 requires gecko-devel = 0:1.8.1.4 epiphany-extensions - 2.19.2-5.i386 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.i386 requires sysklogd gnome-python2-gtkmozembed - 2.19.1-2.fc8.i386 requires firefox = 0:2.0.0.4 gtkmozembedmm - 1.4.2.cvs20060817-11.fc7.1.i386 requires gecko-libs = 0:1.8.1.4 kazehakase - 0.4.7-3.fc8.i386 requires firefox = 0:2.0.0.4 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE lablgtk - 2.6.0-7.fc7.i386 requires ocaml = 0:3.09.3 liferea - 1.2.20-1.fc8.i386 requires firefox = 0:2.0.0.4 maxima-runtime-sbcl - 5.12.0-3.fc8.i386 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-gui - 3.2-2.i386 requires setools = 0:3.2-2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 yelp - 2.18.1-4.fc8.i386 requires gecko-libs = 0:1.8.1.4 Broken deps for x86_64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.x86_64 requires firefox = 0:2.0.0.4 blam - 1.8.3-4.fc8.x86_64 requires firefox = 0:2.0.0.4 chmsee - 1.0.0-0.19.beta2.fc8.x86_64 requires firefox = 0:2.0.0.4 devhelp - 0.15-1.fc8.x86_64 requires gecko-libs = 0:1.8.1.4 devhelp - 0.15-1.fc8.i386 requires gecko-libs = 0:1.8.1.4 eclipse-platform - 1:3.3.0-2.fc8.x86_64 requires lucene-devel epiphany - 2.19.5-1.fc8.x86_64 requires gecko-libs = 0:1.8.1.4 epiphany-devel - 2.19.5-1.fc8.i386 requires gecko-devel = 0:1.8.1.4 epiphany-devel - 2.19.5-1.fc8.x86_64 requires gecko-devel = 0:1.8.1.4 epiphany-extensions - 2.19.2-5.x86_64 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.x86_64 requires sysklogd gnome-python2-gtkmozembed - 2.19.1-2.fc8.x86_64 requires firefox = 0:2.0.0.4 gtkmozembedmm - 1.4.2.cvs20060817-11.fc7.1.i386 requires gecko-libs = 0:1.8.1.4 gtkmozembedmm - 1.4.2.cvs20060817-11.fc7.1.x86_64 requires gecko-libs = 0:1.8.1.4 kazehakase - 0.4.7-3.fc8.x86_64 requires firefox = 0:2.0.0.4 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump lablgtk - 2.6.0-7.fc7.x86_64 requires ocaml = 0:3.09.3 liferea - 1.2.20-1.fc8.x86_64 requires firefox = 0:2.0.0.4 maxima-runtime-sbcl - 5.12.0-3.fc8.x86_64 requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 setools-devel - 3.2-2.i386 requires setools = 0:3.2-2 setools-devel - 3.2-2.x86_64 requires setools = 0:3.2-2 setools-gui - 3.2-2.x86_64 requires setools = 0:3.2-2 syncekonnector - 0.3.2-2.fc8.i386 requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.i386 requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.i386 requires libmultisynk.so.0 syncekonnector - 0.3.2-2.fc8.x86_64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.x86_64 requires libmultisynk.so.0()(64bit) tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) yelp - 2.18.1-4.fc8.x86_64 requires gecko-libs = 0:1.8.1.4 Broken deps for ppc ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc requires firefox = 0:2.0.0.4 blam - 1.8.3-4.fc8.ppc requires firefox = 0:2.0.0.4 chmsee - 1.0.0-0.19.beta2.fc8.ppc requires firefox = 0:2.0.0.4 devhelp - 0.15-1.fc8.ppc requires gecko-libs = 0:1.8.1.4 devhelp - 0.15-1.fc8.ppc64 requires gecko-libs = 0:1.8.1.4 eclipse-platform - 1:3.3.0-2.fc8.ppc requires lucene-devel epiphany - 2.19.5-1.fc8.ppc requires gecko-libs = 0:1.8.1.4 epiphany-devel - 2.19.5-1.fc8.ppc requires gecko-devel = 0:1.8.1.4 epiphany-devel - 2.19.5-1.fc8.ppc64 requires gecko-devel = 0:1.8.1.4 epiphany-extensions - 2.19.2-5.ppc requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.ppc requires sysklogd glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-python2-gtkmozembed - 2.19.1-2.fc8.ppc requires firefox = 0:2.0.0.4 gtkmozembedmm - 1.4.2.cvs20060817-11.fc7.1.ppc requires gecko-libs = 0:1.8.1.4 gtkmozembedmm - 1.4.2.cvs20060817-11.fc7.1.ppc64 requires gecko-libs = 0:1.8.1.4 kazehakase - 0.4.7-3.fc8.ppc requires firefox = 0:2.0.0.4 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp lablgtk - 2.6.0-7.fc7.ppc requires ocaml = 0:3.09.3 liferea - 1.2.20-1.fc8.ppc requires firefox = 0:2.0.0.4 maxima-runtime-sbcl - 5.12.0-3.fc8.ppc requires sbcl = 0:1.0.6 openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 setools-devel - 3.2-2.ppc requires setools = 0:3.2-2 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc requires setools = 0:3.2-2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc requires libksync.so.1 syncekonnector - 0.3.2-2.fc8.ppc requires libkonnector.so.0 syncekonnector - 0.3.2-2.fc8.ppc requires libmultisynk.so.0 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 yelp - 2.18.1-4.fc8.ppc requires gecko-libs = 0:1.8.1.4 Broken deps for ppc64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 ardour - 0.99.3-8.fc7.ppc64 requires liblrdf.so.2()(64bit) chmsee - 1.0.0-0.19.beta2.fc8.ppc64 requires firefox = 0:2.0.0.4 devhelp - 0.15-1.fc8.ppc64 requires gecko-libs = 0:1.8.1.4 dkms - 2.0.16-1.fc7.noarch requires kernel-devel eclipse-platform - 1:3.3.0-2.fc8.ppc64 requires lucene-devel epiphany - 2.19.5-1.fc8.ppc64 requires gecko-libs = 0:1.8.1.4 epiphany-devel - 2.19.5-1.fc8.ppc64 requires gecko-devel = 0:1.8.1.4 epiphany-extensions - 2.19.2-5.ppc64 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.ppc64 requires sysklogd fuse - 2.6.5-2.fc8.ppc64 requires kernel >= 0:2.6.14 glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 gnome-python2-gtkmozembed - 2.19.1-2.fc8.ppc64 requires firefox = 0:2.0.0.4 gtkmozembedmm - 1.4.2.cvs20060817-11.fc7.1.ppc64 requires gecko-libs = 0:1.8.1.4 kazehakase - 0.4.7-3.fc8.ppc64 requires firefox = 0:2.0.0.4 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump liferea - 1.2.20-1.fc8.ppc64 requires firefox = 0:2.0.0.4 pcmciautils - 014-9.fc8.ppc64 requires kernel >= 0:2.6.12-1.1411_FC5 python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display rosegarden4 - 1.4.0-1.fc7.ppc64 requires liblrdf.so.2()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 setools-devel - 3.2-2.ppc64 requires setools = 0:3.2-2 setools-gui - 3.2-2.ppc64 requires setools = 0:3.2-2 syncekonnector - 0.3.2-2.fc8.ppc64 requires libkonnector.so.0()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libksync.so.1()(64bit) syncekonnector - 0.3.2-2.fc8.ppc64 requires libmultisynk.so.0()(64bit) systemtap - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.ppc64 requires kernel >= 0:2.6.9-11 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) varnish - 1.0.4-2.fc8.ppc64 requires kernel >= 0:2.6.0 vpnc - 0.4.0-2.fc7.ppc64 requires kernel >= 0:2.4 xorg-x11-drv-nouveau - 2.1.2-1.fc8.ppc64 requires kernel-drm-nouveau = 0:6 yelp - 2.18.1-4.fc8.ppc64 requires gecko-libs = 0:1.8.1.4 From fedora at ml.shredzone.de Fri Jul 20 10:37:41 2007 From: fedora at ml.shredzone.de (=?ISO-8859-1?Q?Richard_K=F6rber?=) Date: Fri, 20 Jul 2007 12:37:41 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <46A083BD.8030902@iinet.net.au> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> Message-ID: <46A09075.20405@ml.shredzone.de> David Timms wrote: > Is there any particular limitations of what would be useful / allowed if > the devel by Shred is to be hosted by fedora infrastructure. Repowatch is written in Java. All I need is a Tomcat, a database and a cronjob. And maybe an Apache that forwards the requests to Tomcat. > Best to get that sorted out before a rewrite... The rewrite is done independently of the Fedora hosting. Of course I'd love to see repowatch running under fedoraproject.org, but if Fedora should decide not to host it, I would keep on hosting it on my server. Best Regards -- Richard "Shred" K?rber From mattdm at mattdm.org Fri Jul 20 10:40:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 Jul 2007 06:40:34 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <46A056F9.9070400@gmail.com> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <46A056F9.9070400@gmail.com> Message-ID: <20070720104034.GA29500@jadzia.bu.edu> On Fri, Jul 20, 2007 at 08:32:25AM +0200, dragoran wrote: > >Right now, it's trivially easy to make it so you can run yum with your > >own credentials -- but it's not limited in any way. Doing this the right > >way (perhaps with oddjob) would be a bit of work, but doing it the easy > >but less secure way -- run as root, check for limitations -- could be > >done with a plugin. [...] > thats what policykit is for... Well, yes, that's one of several ways to accomplish the "right now, it's trivially easy" part. But it doesn't do anything magic to solve the hard part. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Jul 20 10:42:48 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 Jul 2007 06:42:48 -0400 Subject: rsyslog is in F8 In-Reply-To: <1184923583.10041.27.camel@perun.kabelta.loc> References: <776275.35493.qm@web51504.mail.re2.yahoo.com> <1184923583.10041.27.camel@perun.kabelta.loc> Message-ID: <20070720104248.GB29500@jadzia.bu.edu> On Fri, Jul 20, 2007 at 11:26:23AM +0200, Tomas Mraz wrote: > second one and that's it. We would be just facing other issues if we > choose the first one. (e.g. Why package named rsyslog uses config file > syslog.conf. Or why I cannot install both rsyslog and old sysklogd for > testing purposes (with --force). And surely there are others.) I dunno. These "other issues" aren't terribly crippling with programs like mlocate -- an analogous situation. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Fri Jul 20 11:49:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jul 2007 07:49:48 -0400 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <46A09075.20405@ml.shredzone.de> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> <46A09075.20405@ml.shredzone.de> Message-ID: <20070720074948.5ad80f77@ender> On Fri, 20 Jul 2007 12:37:41 +0200 "Richard K?rber" wrote: > Repowatch is written in Java. All I need is a Tomcat, a database and a > cronjob. And maybe an Apache that forwards the requests to Tomcat. Please god no. If there is anything I'd like to see in Fedora Infrastructure /less/ than php, it would be java. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at ml.shredzone.de Fri Jul 20 12:00:13 2007 From: fedora at ml.shredzone.de (=?UTF-8?B?UmljaGFyZCBLw7ZyYmVy?=) Date: Fri, 20 Jul 2007 14:00:13 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <20070720074948.5ad80f77@ender> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> <46A09075.20405@ml.shredzone.de> <20070720074948.5ad80f77@ender> Message-ID: <46A0A3CD.1000905@ml.shredzone.de> Jesse Keating wrote: > Please god no. If there is anything I'd like to see in Fedora > Infrastructure /less/ than php, it would be java. I agree about PHP... This is actually why I am rewriting the frontend. But what is it exactly that troubles you about Java? Best Regards -- Richard "Shred" K?rber From jkeating at redhat.com Fri Jul 20 12:06:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jul 2007 08:06:06 -0400 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <46A0A3CD.1000905@ml.shredzone.de> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> <46A09075.20405@ml.shredzone.de> <20070720074948.5ad80f77@ender> <46A0A3CD.1000905@ml.shredzone.de> Message-ID: <20070720080606.3e321926@ender> On Fri, 20 Jul 2007 14:00:13 +0200 "Richard K?rber" wrote: > I agree about PHP... This is actually why I am rewriting the frontend. > But what is it exactly that troubles you about Java? The JVM, and how you always wind up needing a different jvm for each application. And every bug you have to update the base OS for, you /also/ have to update each and every jvm for as well, since it duplicates most things from the base os. Just ask any seasoned sysadmin that has more than a few Java apps in production what fun the last timezone data update was. In past experiences, jvm performance has been very poor, especially after the second or third one is spun up. There is little to no love in the Fedora Infrastructure team for Java based applications, so I would expect a lot of pushback on using such a thing in production. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at ml.shredzone.de Fri Jul 20 12:31:51 2007 From: fedora at ml.shredzone.de (=?UTF-8?B?UmljaGFyZCBLw7ZyYmVy?=) Date: Fri, 20 Jul 2007 14:31:51 +0200 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <20070720080606.3e321926@ender> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> <46A09075.20405@ml.shredzone.de> <20070720074948.5ad80f77@ender> <46A0A3CD.1000905@ml.shredzone.de> <20070720080606.3e321926@ender> Message-ID: <46A0AB37.7060608@ml.shredzone.de> Jesse Keating wrote: > There is little to no love in the Fedora Infrastructure team for Java > based applications, so I would expect a lot of pushback on using such a > thing in production. I am doing Java for more than ten years now. And to be honest, I am too tired to start another Java is too slow/bloated/unstable discussion. I've heard them all. And I still believe in this platform. Anyhow, if I understand you right, there is little to no chance for me to get a positive result out of a RFR. So I better save my time for more productive things. Best Regards -- Richard "Shred" K?rber From vonbrand at inf.utfsm.cl Thu Jul 19 15:51:34 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 19 Jul 2007 11:51:34 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070719143845.GA29978@jadzia.bu.edu> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> <20070719143845.GA29978@jadzia.bu.edu> Message-ID: <17196.1184860294@laptop13.inf.utfsm.cl> Matthew Miller wrote: > On Thu, Jul 19, 2007 at 09:50:33AM -0400, seth vidal wrote: > > > system level software. That's useful -- but, as mentioned, kinda > > > crack-ridden. (Partly, of course, because the distinction between user > > > level and system level is very blurry.) > > blurry? no it's completely non-existent. :) > There's at least a whole lot of overlap. :) Nope. If it has to be installed/configured/managed by root, it is system software, regardless of it being the kernel or a game. The stuff in $HOME is yours to mess around with. To think otherwise is creating a whole new landscape of operating system... and that can't be handled by just "OK, let's install by default under the control of Joe R. User", there has to be a _lot_ more thought behind it. > > This feels pretty scary. We'd constantly be moving the line to > > accommodate varying levels of paranoia - and we'd have a big list we'd > > have to keep current to make sure it wasn't outdated. > Maybe just a simple list of white-listed packages, then. If this were done, > I'd think the default Fedora config should be very very conservative (and, > also, the entire feature off), but having that infrastructure there could be > very helpful for controlled environments. Exactly the other way around. In a controlled environment, you could give the root password (or a suitably restricted sudo(1) entry) to assorted users, or require users to contact the sysadmin to install stuff. If you are thinking about the machines in a lab, the /very last/ thing you want is different configurations because on each machine a random user, way back, ran some program with unusual flags, and didn't note that this meant installing some gunk. So this /can/ be handled locally (fully respecting the local level of paranoia and configuration consistency requirements) right now with a bit of work. -- 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 ndbecker2 at gmail.com Fri Jul 20 13:14:21 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 20 Jul 2007 09:14:21 -0400 Subject: http://koji.fedoraproject.org/koji/login Message-ID: I'm trying to follow instructions for fedora-packager-setup.sh. I imported cert into konqueror, but I get: An error occurred while loading http://koji.fedoraproject.org/koji/login: Could not connect to host koji.fedoraproject.org. From jkeating at redhat.com Fri Jul 20 13:26:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jul 2007 09:26:09 -0400 Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <46A0AB37.7060608@ml.shredzone.de> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> <46A09075.20405@ml.shredzone.de> <20070720074948.5ad80f77@ender> <46A0A3CD.1000905@ml.shredzone.de> <20070720080606.3e321926@ender> <46A0AB37.7060608@ml.shredzone.de> Message-ID: <20070720092609.41486d00@localhost.localdomain> On Fri, 20 Jul 2007 14:31:51 +0200 "Richard K?rber" wrote: > Anyhow, if I understand you right, there is little to no chance for me > to get a positive result out of a RFR. So I better save my time for > more productive things. I wouldn't say that. All I'm giving is my own opinion. One that I know is somewhat shared by a few people in the Infrastructure team. However I am not the entire team, nor do I speak for the entire team. All I'm doing is stating my opinions that I've developed over the years of dealing with java applications and hosting java services. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ndbecker2 at gmail.com Fri Jul 20 13:25:26 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 20 Jul 2007 09:25:26 -0400 Subject: How do I update my package? Message-ID: I maintain a few packages. Where are instructions for updating my packages? (Sorry for stupid question, but it's been a while and I've forgotten how - and my time is limited) From jkeating at redhat.com Fri Jul 20 13:31:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 20 Jul 2007 09:31:49 -0400 Subject: How do I update my package? In-Reply-To: References: Message-ID: <20070720093149.37cffe7e@localhost.localdomain> On Fri, 20 Jul 2007 09:25:26 -0400 Neal Becker wrote: > I maintain a few packages. Where are instructions for updating my > packages? (Sorry for stupid question, but it's been a while and I've > forgotten how - and my time is limited) http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Fri Jul 20 13:36:12 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 20 Jul 2007 13:36:12 +0000 (UTC) Subject: http://koji.fedoraproject.org/koji/login References: Message-ID: Neal Becker gmail.com> writes: > I'm trying to follow instructions for fedora-packager-setup.sh. > > I imported cert into konqueror, but I get: > > An error occurred while loading http://koji.fedoraproject.org/koji/login: > Could not connect to host koji.fedoraproject.org. 2 things there: * You have to use https, not http. * You need to tell Konqueror to send the certificate to koji.fedoraproject.org, the default is not sending certs. Under: Encryption / Authentication / Host authentication click New, enter koji.fedoraproject.org for "Host:" and pick the certificate you just imported for "Certificate:", then OK the dialog. Kevin Kofler From rdieter at math.unl.edu Fri Jul 20 13:35:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 20 Jul 2007 08:35:21 -0500 Subject: http://koji.fedoraproject.org/koji/login References: Message-ID: Neal Becker wrote: > I'm trying to follow instructions for fedora-packager-setup.sh. > > I imported cert into konqueror, but I get: > > An error occurred while loading http://koji.fedoraproject.org/koji/login: > Could not connect to host koji.fedoraproject.org. Appears to be a konq-ism, I get that too. firefox worksforme. -- Rex From jonathan.underwood at gmail.com Fri Jul 20 13:38:51 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 14:38:51 +0100 Subject: Automating pam_keyring... In-Reply-To: <1184709558.6008.5.camel@legolas.felicity-group.com> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> Message-ID: <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> On 17/07/07, Gawain Lynch wrote: > It is not particularly elegant as such but I made a package based on > code from this page that Works for Me... > http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases To my very pleasant surprise, the updated seahorse packages that Seth just pushed to updates-testing actually takes care of the integration of gnome-keyring and ssh-agent seemlessly. I encourage all interested parties to try this (it's just a yum install seahorse away). J. From kevin.kofler at chello.at Fri Jul 20 13:40:07 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 20 Jul 2007 13:40:07 +0000 (UTC) Subject: http://koji.fedoraproject.org/koji/login References: Message-ID: Rex Dieter math.unl.edu> writes: > Appears to be a konq-ism, I get that too. firefox worksforme. It works for me in Konqueror with the setup I posted in this thread: > * You have to use https, not http. > * You need to tell Konqueror to send the certificate to > koji.fedoraproject.org, the default is not sending certs. Under: > Encryption / Authentication / Host authentication > click New, enter koji.fedoraproject.org for "Host:" and pick the certificate > you just imported for "Certificate:", then OK the dialog. Kevin Kofler From skvidal at linux.duke.edu Fri Jul 20 13:49:25 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 20 Jul 2007 09:49:25 -0400 Subject: Automating pam_keyring... In-Reply-To: <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> Message-ID: <1184939365.18238.0.camel@cutter> On Fri, 2007-07-20 at 14:38 +0100, Jonathan Underwood wrote: > On 17/07/07, Gawain Lynch wrote: > > It is not particularly elegant as such but I made a package based on > > code from this page that Works for Me... > > http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases > > To my very pleasant surprise, the updated seahorse packages that Seth > just pushed to updates-testing actually takes care of the integration > of gnome-keyring and ssh-agent seemlessly. I encourage all interested > parties to try this (it's just a yum install seahorse away). Good! I'm glad they're working for you. Are they ready to go to final update? -sv From bpepple at fedoraproject.org Fri Jul 20 13:54:01 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 20 Jul 2007 09:54:01 -0400 Subject: FESCo Meeting Summary for 2007-07-19 Message-ID: <1184939641.2826.0.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Kevin Fenzi (nirik) * Warren Togami (warren) * Tom Callaway (spot) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * Rex Dieter (rdieter) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Jeremy Katz (jeremy) === Absent === * Christian Iseli (c4chris) == Summary == === License Version Tags === * Looong discussion on how to track the license versions for packages. Discussed possible solutions for this, but no consensus reached. === New Feature Proposals Approvals === * http://fedoraproject.org/wiki/Releases/Features/NodokaTheme - FESCo approved this feature with the caveat that the Art team must also acknowledge their approval. * http://fedoraproject.org/wiki/Releases/FeatureKDE4 - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeaturePresto - FESCo tabled this approval until the various other parties (infrastructure, etc) have signed off on this. * http://fedoraproject.org/wiki/Releases/FeatureRsyslog - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureXULRunner - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureBluetooth - FESCo approved this proposal. === PackageDB === * abadger - "I finished up the koji sync script. Only a pkgdb CLI client for cvsadmins to add and update remains. Half done with that." For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070719 Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 Fri Jul 20 13:54:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 20 Jul 2007 15:54:15 +0200 (CEST) Subject: Web-Interface for packages in Fedora: repoview, repowatch, something else? In-Reply-To: <20070720092609.41486d00@localhost.localdomain> References: <469E1817.7050809@ml.shredzone.de> <469ECE2D.8070600@fedoraproject.org> <469EFFD6.2010808@leemhuis.info> <20070719172034.GC10761@ryvius.pekin.waw.pl> <20070719133957.51aeb748@localhost.localdomain> <46A083BD.8030902@iinet.net.au> <46A09075.20405@ml.shredzone.de> <20070720074948.5ad80f77@ender> <46A0A3CD.1000905@ml.shredzone.de> <20070720080606.3e321926@ender> <46A0AB37.7060608@ml.shredzone.de> <20070720092609.41486d00@localhost.localdomain> Message-ID: <2360.192.54.193.51.1184939655.squirrel@rousalka.dyndns.org> Le Ven 20 juillet 2007 15:26, Jesse Keating a ?crit : > I wouldn't say that. All I'm giving is my own opinion. One that I > know is somewhat shared by a few people in the Infrastructure team. > However I am not the entire team, nor do I speak for the entire team. > All I'm doing is stating my opinions that I've developed over the > years of dealing with java applications and hosting java services. IMHO as soon as we get a working FLOSS JDK the various Red Hat/JBoss Java groups need to do get together a few days with Red Hat/Fedora distro/Infrastructure team representatives and hash up how Fedora/Red Hat Java can be made sysadmin-friendly. Java is a big part of Red Hat future server-side and every Red Hat corporate customer is hitting the same problems as the Fedora Infrastructure Team (only there are so many filters between corporate sysadmins and Red Hat I'm not sure the problems are reported accurately). The alternative is not python or ruby taking over the world but many server apps going .Net/windows (now microsoft managed to create a decent server stack at last). -- Nicolas Mailhot From bpepple at fedoraproject.org Fri Jul 20 13:54:01 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 20 Jul 2007 09:54:01 -0400 Subject: FESCo Meeting Summary for 2007-07-19 Message-ID: <1184939641.2826.0.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Kevin Fenzi (nirik) * Warren Togami (warren) * Tom Callaway (spot) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * Rex Dieter (rdieter) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Jeremy Katz (jeremy) === Absent === * Christian Iseli (c4chris) == Summary == === License Version Tags === * Looong discussion on how to track the license versions for packages. Discussed possible solutions for this, but no consensus reached. === New Feature Proposals Approvals === * http://fedoraproject.org/wiki/Releases/Features/NodokaTheme - FESCo approved this feature with the caveat that the Art team must also acknowledge their approval. * http://fedoraproject.org/wiki/Releases/FeatureKDE4 - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeaturePresto - FESCo tabled this approval until the various other parties (infrastructure, etc) have signed off on this. * http://fedoraproject.org/wiki/Releases/FeatureRsyslog - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureXULRunner - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureBluetooth - FESCo approved this proposal. === PackageDB === * abadger - "I finished up the koji sync script. Only a pkgdb CLI client for cvsadmins to add and update remains. Half done with that." For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070719 Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 rdieter at math.unl.edu Fri Jul 20 14:12:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 20 Jul 2007 09:12:14 -0500 Subject: http://koji.fedoraproject.org/koji/login References: Message-ID: Kevin Kofler wrote: > Neal Becker gmail.com> writes: >> I'm trying to follow instructions for fedora-packager-setup.sh. >> >> I imported cert into konqueror, but I get: >> >> An error occurred while loading http://koji.fedoraproject.org/koji/login: >> Could not connect to host koji.fedoraproject.org. > > 2 things there: > * You have to use https, not http. > * You need to tell Konqueror to send the certificate to > koji.fedoraproject.org, the default is not sending certs. Under: > Encryption / Authentication / Host authentication > click New, enter koji.fedoraproject.org for "Host:" and pick the > certificate you just imported for "Certificate:", then OK the dialog. that did the trick, thanks! -- Rex From mattdm at mattdm.org Fri Jul 20 14:27:01 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 Jul 2007 10:27:01 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <17196.1184860294@laptop13.inf.utfsm.cl> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> <20070719143845.GA29978@jadzia.bu.edu> <17196.1184860294@laptop13.inf.utfsm.cl> Message-ID: <20070720142701.GA14247@jadzia.bu.edu> On Thu, Jul 19, 2007 at 11:51:34AM -0400, Horst H. von Brand wrote: > > > blurry? no it's completely non-existent. :) > > There's at least a whole lot of overlap. :) > Nope. If it has to be installed/configured/managed by root, it is system > software, regardless of it being the kernel or a game. The stuff in > $HOME is yours to mess around with. You mean "by root", or "by a process with root privileges"? Because that's a whole different question. > To think otherwise is creating a whole new landscape of operating > system... and that can't be handled by just "OK, let's install of packages> by default under the control of Joe R. User", there has to > be a _lot_ more thought behind it. "Foo kind of packages" from an approved repository of cryptographically-signed rpms. > Exactly the other way around. In a controlled environment, you could > give the root password (or a suitably restricted sudo(1) entry) to > assorted users, or require users to contact the sysadmin to install > stuff. If you are thinking about the machines in a lab, the /very last/ > thing you want is different configurations because on each machine a > random user, way back, ran some program with unusual flags, and didn't > note that this meant installing some gunk. I'm thinking more about individual machines deployed on desktop systems where the users want some control but are not sysadmins. For stuff like the above, why bother the admin? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Thu Jul 19 18:45:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Jul 2007 14:45:00 -0400 Subject: NOTE: Please publicize any license changes to your packages Message-ID: <20070719184500.GC20184@nostromo.devel.redhat.com> The Fedora Engineering Steering Committee would like to remind maintainers that a license change in a package is a very serious event - it has as many, if not more, implications for related packages as ABI changes do. Therefore, if your package changes license, even if it just changes the license version, it is required that you announce it, whether on this list or fedora-devel-list. Note that any license change to a more restrictive license or license version may affect the legality of portions of Fedora as a whole; ergo, FESCo reserves the right to block upgrades of packages to versions with new licenses to ensure the legal distribution of Fedora. Please contact FESCo if you have any questions. Bill _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From vonbrand at inf.utfsm.cl Fri Jul 20 14:54:16 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 20 Jul 2007 10:54:16 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070720142701.GA14247@jadzia.bu.edu> References: <1184784931.4179.4.camel@ignacio.lan> <469E661F.4000509@herr-schmitt.de> <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> <20070719143845.GA29978@jadzia.bu.edu> <17196.1184860294@laptop13.inf.utfsm.cl> <20070720142701.GA14247@jadzia.bu.edu> Message-ID: <11166.1184943256@laptop13.inf.utfsm.cl> Matthew Miller wrote: > On Thu, Jul 19, 2007 at 11:51:34AM -0400, Horst H. von Brand wrote: > > > > blurry? no it's completely non-existent. :) > > > There's at least a whole lot of overlap. :) > > Nope. If it has to be installed/configured/managed by root, it is system > > software, regardless of it being the kernel or a game. The stuff in > > $HOME is yours to mess around with. > You mean "by root", or "by a process with root privileges"? Because that's a > whole different question. No, it isn't. Not really. > > To think otherwise is creating a whole new landscape of operating > > system... and that can't be handled by just "OK, let's install > of packages> by default under the control of Joe R. User", there has to > > be a _lot_ more thought behind it. > > "Foo kind of packages" from an approved repository of > cryptographically-signed rpms. Checked by whom for sanity? Who decides which ones can be installed and which ones can't (e.g., chat style applications are banned here, other places will disallow all games, ...)? If the user decides freely, she's root for all purposes. If there is any policy on what to install and what not, she can't be allowed to install stuff, period. Besides, you very well can set up a sudo(1) entry that allows Jane R. User to run *only* yum with designated repositories. I just fail to see why such (local policy) has to be integrated into the system, when it is not universally required (or even wanted). Remember: Unix philosophy is having tools that do one thing, and do it well. Leave the infinite combinations in the capable hands of the user. > > Exactly the other way around. In a controlled environment, you could > > give the root password (or a suitably restricted sudo(1) entry) to > > assorted users, or require users to contact the sysadmin to install > > stuff. If you are thinking about the machines in a lab, the /very last/ > > thing you want is different configurations because on each machine a > > random user, way back, ran some program with unusual flags, and didn't > > note that this meant installing some gunk. > I'm thinking more about individual machines deployed on desktop systems > where the users want some control but are not sysadmins. For stuff like the > above, why bother the admin? Give them the root password. Set up sudo(1). Managing a computer isn't trivial, if the users don't know how to do it right, better keep their hands in the pockets. Random stuff installed by (well-meaning) users or random passers-by caused inmense grief here with Windows, until we just gave the users restricted accounts. -- 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 jakub at redhat.com Fri Jul 20 15:02:28 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 20 Jul 2007 11:02:28 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070719184500.GC20184@nostromo.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> Message-ID: <20070720150228.GL2063@devserv.devel.redhat.com> On Thu, Jul 19, 2007 at 02:45:00PM -0400, Bill Nottingham wrote: > The Fedora Engineering Steering Committee would like to remind maintainers > that a license change in a package is a very serious event - it has as many, > if not more, implications for related packages as ABI changes do. > > Therefore, if your package changes license, even if it just changes the > license version, it is required that you announce it, whether on this list > or fedora-devel-list. > > Note that any license change to a more restrictive license or license > version may affect the legality of portions of Fedora as a whole; ergo, > FESCo reserves the right to block upgrades of packages to versions with > new licenses to ensure the legal distribution of Fedora. BTW, shouldn't we start changing License: tags in packages for *GPL packages, so that it include the exact version? E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. Jakub From mattdm at mattdm.org Fri Jul 20 15:05:43 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 20 Jul 2007 11:05:43 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <11166.1184943256@laptop13.inf.utfsm.cl> References: <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> <20070719143845.GA29978@jadzia.bu.edu> <17196.1184860294@laptop13.inf.utfsm.cl> <20070720142701.GA14247@jadzia.bu.edu> <11166.1184943256@laptop13.inf.utfsm.cl> Message-ID: <20070720150543.GA16618@jadzia.bu.edu> On Fri, Jul 20, 2007 at 10:54:16AM -0400, Horst H. von Brand wrote: > > > Nope. If it has to be installed/configured/managed by root, it is system > > > software, regardless of it being the kernel or a game. The stuff in > > > $HOME is yours to mess around with. > > You mean "by root", or "by a process with root privileges"? Because that's a > > whole different question. > No, it isn't. Not really. Sure it is, because the later can be controlled by policy. > > "Foo kind of packages" from an approved repository of > > cryptographically-signed rpms. > Checked by whom for sanity? Who decides which ones can be installed and Fedora. > which ones can't (e.g., chat style applications are banned here, other > places will disallow all games, ...)? If the user decides freely, she's > root for all purposes. If there is any policy on what to install and > what not, she can't be allowed to install stuff, period. Hence the ability to define policy. But can you elaborate more on "root for all purposes"? I'm not aware of any programs in Fedora which, when installed, make a user root. Barring any security holes, of couse. One still wouldn't be able to start or configure services without further authorization. > Besides, you very well can set up a sudo(1) entry that allows Jane > R. User to run *only* yum with designated repositories. I just fail to If you're limiting to installation, sure. But more fine-grained control than repository level might be desirable. > see why such (local policy) has to be integrated into the system, when > it is not universally required (or even wanted). Remember: Unix > philosophy is having tools that do one thing, and do it well. Leave the > infinite combinations in the capable hands of the user. This is a good argument *for* the idea. > Managing a computer isn't trivial, if the users don't know how to do it > right, better keep their hands in the pockets. Random stuff installed by > (well-meaning) users or random passers-by caused inmense grief here with > Windows, until we just gave the users restricted accounts. Users can currently install whatever random stuff they want in their home directories. They can build their own local versions of network clients and then fail to upgrade them to fix security flaws. Much better to allow them to install selected programs from the official Fedora repository. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ndbecker2 at gmail.com Fri Jul 20 15:19:39 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 20 Jul 2007 11:19:39 -0400 Subject: help make build Message-ID: I got through updating devel. Now I go to F-7 directory, and I'm stuck: make tag cvs tag -c uncrustify-0_35-1_fc7 ? .build-0.35-1.fc7.log ? uncrustify-0.35 ? uncrustify-0.35-1.fc7.src.rpm ? uncrustify-0.35.tgz ? x86_64 ERROR: Tag uncrustify-0_35-1_fc7 has been already created. The following tags have been created so far uncrustify-0_30-1:devel:nbecker:1167579422 uncrustify-0_30-1_fc7:devel:nbecker:1167851084 uncrustify-0_30-1_fc5:FC-5:nbecker:1167851116 uncrustify-0_30-1_fc6:FC-6:nbecker:1167851121 uncrustify-0_35-1_fc8:devel:nbecker:1184943650 uncrustify-0_35-1_fc7:F-7:nbecker:1184944278 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 [nbecker at nbecker4 F-7]$ make build uncrustify.spec not tagged with tag uncrustify-0_35-1_fc7 make: *** [build-check] Error 1 From andy at warmcat.com Fri Jul 20 15:21:07 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 20 Jul 2007 16:21:07 +0100 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070720150228.GL2063@devserv.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> Message-ID: <46A0D2E3.2040306@warmcat.com> Somebody in the thread at some point said: > BTW, shouldn't we start changing License: tags in packages for *GPL > packages, so that it include the exact version? > E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, > LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. There is a whole subject here... distributors of GPL2 "or later" have the opportunity to specify the terms they are distributing it on. For example, it is a legit option AIUI to specify that you are giving people GPL2 "or later" stuff under specifically GPL2 terms. -Andy From jwboyer at jdub.homelinux.org Fri Jul 20 15:22:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 20 Jul 2007 10:22:06 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070720150228.GL2063@devserv.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> Message-ID: <1184944926.3735.5.camel@weaponx.rchland.ibm.com> On Fri, 2007-07-20 at 11:02 -0400, Jakub Jelinek wrote: > On Thu, Jul 19, 2007 at 02:45:00PM -0400, Bill Nottingham wrote: > > The Fedora Engineering Steering Committee would like to remind maintainers > > that a license change in a package is a very serious event - it has as many, > > if not more, implications for related packages as ABI changes do. > > > > Therefore, if your package changes license, even if it just changes the > > license version, it is required that you announce it, whether on this list > > or fedora-devel-list. > > > > Note that any license change to a more restrictive license or license > > version may affect the legality of portions of Fedora as a whole; ergo, > > FESCo reserves the right to block upgrades of packages to versions with > > new licenses to ensure the legal distribution of Fedora. > > BTW, shouldn't we start changing License: tags in packages for *GPL > packages, so that it include the exact version? > E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, > LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. We're working on something like that, yes. See the FESCo meeting minutes that Brian sent out today. josh From chris.stone at gmail.com Fri Jul 20 15:23:50 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Jul 2007 08:23:50 -0700 Subject: =?utf-8?q?WTF=E2=81=88_ShowOnlyIn=3DGNOME?= Message-ID: Why are tons of apps setting ShowOnlyIn=GNOME; in their .desktop file? This does not bode well for KDE users. # grep -i onlyshowin /usr/share/applications/*.desktop|grep -i gnome|wc -l 63 Sixty-Three apps which I have installed are only showing up in GNOME!! What the hell for??? Is Fedora *trying* to cripple KDE or what? I dont see a single application using ShowOnlyIn=KDE From jwboyer at jdub.homelinux.org Fri Jul 20 15:24:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 20 Jul 2007 10:24:58 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <46A0D2E3.2040306@warmcat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> <46A0D2E3.2040306@warmcat.com> Message-ID: <1184945098.3735.8.camel@weaponx.rchland.ibm.com> On Fri, 2007-07-20 at 16:21 +0100, Andy Green wrote: > Somebody in the thread at some point said: > > > BTW, shouldn't we start changing License: tags in packages for *GPL > > packages, so that it include the exact version? > > E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, > > LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. > > There is a whole subject here... distributors of GPL2 "or later" have > the opportunity to specify the terms they are distributing it on. For > example, it is a legit option AIUI to specify that you are giving people > GPL2 "or later" stuff under specifically GPL2 terms. Not really. If you have "or later" then someone can take the source code and redistribute it under GPLv3. The "or later" is an additional permission that is granted and you can't just go take that away without removing all references to it. Even then, someone can just take an older release and use that. josh From bpepple at fedoraproject.org Fri Jul 20 15:26:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 20 Jul 2007 11:26:32 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070720150228.GL2063@devserv.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> Message-ID: <1184945192.2826.1.camel@kennedy> On Fri, 2007-07-20 at 11:02 -0400, Jakub Jelinek wrote: > On Thu, Jul 19, 2007 at 02:45:00PM -0400, Bill Nottingham wrote: > > The Fedora Engineering Steering Committee would like to remind maintainers > > that a license change in a package is a very serious event - it has as many, > > if not more, implications for related packages as ABI changes do. > > > > Therefore, if your package changes license, even if it just changes the > > license version, it is required that you announce it, whether on this list > > or fedora-devel-list. > > > > Note that any license change to a more restrictive license or license > > version may affect the legality of portions of Fedora as a whole; ergo, > > FESCo reserves the right to block upgrades of packages to versions with > > new licenses to ensure the legal distribution of Fedora. > > BTW, shouldn't we start changing License: tags in packages for *GPL > packages, so that it include the exact version? > E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, > LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. Not yet. FESCo is currently working on how we want to handle this. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 rdieter at math.unl.edu Fri Jul 20 15:31:21 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 20 Jul 2007 10:31:21 -0500 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME References: Message-ID: Christopher Stone wrote: > Why are tons of apps setting ShowOnlyIn=GNOME; in their .desktop file? ... > Is Fedora *trying* to cripple KDE or what? I'd assume many of those are warranted, but likely not all. I'd also assume not malice, but just not knowing better. bugzilla cases of finding items should aren't (or shouldn't be) gnome-specific. > I dont see a single application using ShowOnlyIn=KDE In fairness, there are at least a few, look in /usr/share/applications/kde/*.desktop -- Rex From alan at redhat.com Fri Jul 20 15:32:38 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 20 Jul 2007 11:32:38 -0400 Subject: WTF??? ShowOnlyIn=GNOME In-Reply-To: References: Message-ID: <20070720153238.GA30005@devserv.devel.redhat.com> On Fri, Jul 20, 2007 at 08:23:50AM -0700, Christopher Stone wrote: > # grep -i onlyshowin /usr/share/applications/*.desktop|grep -i gnome|wc -l > 63 > > Sixty-Three apps which I have installed are only showing up in GNOME!! > What the hell for????????? People may just be coping an example without thought. If they are wrong (eg KDE apps with no gnome equivalent) then file bugs against them From tmz at pobox.com Fri Jul 20 15:38:40 2007 From: tmz at pobox.com (Todd Zullinger) Date: Fri, 20 Jul 2007 11:38:40 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: Message-ID: <20070720153840.GQ22182@psilocybe.teonanacatl.org> Christopher Stone wrote: > Why are tons of apps setting ShowOnlyIn=GNOME; in their .desktop file? > > This does not bode well for KDE users. > > # grep -i onlyshowin /usr/share/applications/*.desktop|grep -i gnome|wc -l > 63 You're not catching the kde folder with your grep there. Try it like this and maybe your feelings will change: $ grep -rli 'onlyshowin=kde' /usr/share/applications/ | wc -l 145 $ grep -rli 'onlyshowin=gnome' /usr/share/applications/ | wc -l 56 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Time may be a great healer, but it's a lousy beautician. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From notting at redhat.com Fri Jul 20 15:35:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 20 Jul 2007 11:35:55 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070720150228.GL2063@devserv.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> Message-ID: <20070720153555.GA26336@nostromo.devel.redhat.com> Jakub Jelinek (jakub at redhat.com) said: > BTW, shouldn't we start changing License: tags in packages for *GPL > packages, so that it include the exact version? > E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, > LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. This is currently a task for the Packaging committee to standardize. Bill From andy at warmcat.com Fri Jul 20 15:40:02 2007 From: andy at warmcat.com (Andy Green) Date: Fri, 20 Jul 2007 16:40:02 +0100 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1184945098.3735.8.camel@weaponx.rchland.ibm.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> <46A0D2E3.2040306@warmcat.com> <1184945098.3735.8.camel@weaponx.rchland.ibm.com> Message-ID: <46A0D752.80905@warmcat.com> Somebody in the thread at some point said: > Not really. If you have "or later" then someone can take the source > code and redistribute it under GPLv3. The "or later" is an additional > permission that is granted and you can't just go take that away without > removing all references to it. Even then, someone can just take an > older release and use that. Sure, it doesn't affect the recipient's rights. But if a future version of the GPL includes stronger demands on the distributor, specifying the actual version of the rules under which you provided it will become attractive real fast. Nothing actually stops GPL v26 including unthinkable things someone might demand you live up to. -Andy From somlo at cmu.edu Fri Jul 20 15:52:15 2007 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Fri, 20 Jul 2007 11:52:15 -0400 Subject: Trading reviews ? Message-ID: <20070720155215.GA30036@hedwig.net.cmu.edu> Anyone running Fedora on a Mac laptop interested in reviewing my pbbuttonsd submission (bugzilla # 246368) ? It has some overlap with apmd, but the main highlights are that it runs both on ppc and intel, and controls the light sensors, and display and keyboard backlight... Thanks, Gabriel From notting at redhat.com Fri Jul 20 15:55:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 20 Jul 2007 11:55:39 -0400 Subject: Trading reviews ? In-Reply-To: <20070720155215.GA30036@hedwig.net.cmu.edu> References: <20070720155215.GA30036@hedwig.net.cmu.edu> Message-ID: <20070720155539.GB26910@nostromo.devel.redhat.com> Gabriel L. Somlo (somlo at cmu.edu) said: > Anyone running Fedora on a Mac laptop interested in reviewing my > pbbuttonsd submission (bugzilla # 246368) ? > > It has some overlap with apmd, but the main highlights are that it > runs both on ppc and intel, and controls the light sensors, and > display and keyboard backlight... Why isn't this integrated in HAL? Bill From vonbrand at inf.utfsm.cl Fri Jul 20 16:09:30 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 20 Jul 2007 12:09:30 -0400 Subject: Fedora Feature Proposal: Yum Integration In-Reply-To: <20070720150543.GA16618@jadzia.bu.edu> References: <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> <20070719143845.GA29978@jadzia.bu.edu> <17196.1184860294@laptop13.inf.utfsm.cl> <20070720142701.GA14247@jadzia.bu.edu> <11166.1184943256@laptop13.inf.utfsm.cl> <20070720150543.GA16618@jadzia.bu.edu> Message-ID: <14677.1184947770@laptop13.inf.utfsm.cl> Matthew Miller wrote: > On Fri, Jul 20, 2007 at 10:54:16AM -0400, Horst H. von Brand wrote: > > > > Nope. If it has to be installed/configured/managed by root, it is system > > > > software, regardless of it being the kernel or a game. The stuff in > > > > $HOME is yours to mess around with. > > > You mean "by root", or "by a process with root privileges"? Because that's a > > > whole different question. > > No, it isn't. Not really. > > Sure it is, because the later can be controlled by policy. You lost me there. > > > "Foo kind of packages" from an approved repository of > > > cryptographically-signed rpms. > > Checked by whom for sanity? Who decides which ones can be installed and > Fedora. Again, how do you enforce "games are out", "no graphical applications on this server", "nothing that allows people to chat"? It isn't exactly Fedora policy (and if it was, what makes you think it will stay forever?). [...] > > Besides, you very well can set up a sudo(1) entry that allows Jane > > R. User to run *only* yum with designated repositories. I just fail to > > If you're limiting to installation, sure. But more fine-grained control than > repository level might be desirable. If you need a flexible policy, have a human do it. Not everything can be automated (or if it can, is worth the trouble). > > see why such (local policy) has to be integrated into the system, when > > it is not universally required (or even wanted). Remember: Unix > > philosophy is having tools that do one thing, and do it well. Leave the > > infinite combinations in the capable hands of the user. > This is a good argument *for* the idea. I don't see how. You *can* do it today, with a bit of work on /your/ side if you need it. No need to load down my machine (where that is most unwellcome) with it. > > Managing a computer isn't trivial, if the users don't know how to do it > > right, better keep their hands in the pockets. Random stuff installed by > > (well-meaning) users or random passers-by caused inmense grief here with > > Windows, until we just gave the users restricted accounts. > Users can currently install whatever random stuff they want in their home > directories. They can build their own local versions of network clients and > then fail to upgrade them to fix security flaws. Much better to allow them > to install selected programs from the official Fedora repository. And said security flaws will only afect them, not the whole system; while security flaws in willy-nilly installed stuff affects everybody (yes, even Fedora-blessed software has had its share of security problems). One of the basic guidelines when securing a system is to keep it as simple as possible, i.e., install only what is required, and keep a strict control over what is happening. Anything else ends with the sysadmin in a padded cell. -- 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 limb at jcomserv.net Fri Jul 20 16:06:10 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 20 Jul 2007 11:06:10 -0500 (CDT) Subject: help make build In-Reply-To: References: Message-ID: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> > I got through updating devel. Now I go to F-7 directory, and I'm stuck: > > make tag > cvs tag -c uncrustify-0_35-1_fc7 > ? .build-0.35-1.fc7.log > ? uncrustify-0.35 > ? uncrustify-0.35-1.fc7.src.rpm > ? uncrustify-0.35.tgz > ? x86_64 > ERROR: Tag uncrustify-0_35-1_fc7 has been already created. > The following tags have been created so far > uncrustify-0_30-1:devel:nbecker:1167579422 > uncrustify-0_30-1_fc7:devel:nbecker:1167851084 > uncrustify-0_30-1_fc5:FC-5:nbecker:1167851116 > uncrustify-0_30-1_fc6:FC-6:nbecker:1167851121 > uncrustify-0_35-1_fc8:devel:nbecker:1184943650 > uncrustify-0_35-1_fc7:F-7:nbecker:1184944278 > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > [nbecker at nbecker4 F-7]$ make build > uncrustify.spec not tagged with tag uncrustify-0_35-1_fc7 > make: *** [build-check] Error 1 Odd. [limb at fawkes F-7]$ diff sources ../devel/sources 1c1 < 3c242519de3d12f7b916b560366c1aa8 uncrustify-0.30.tgz --- > f8e23ad439a2d44e0101ff337407fbaf uncrustify-0.35.tgz This might be a good time make sure you've committed everything for the new version, then run "TAG_OPTS=-F make tag". Jon > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From sundaram at fedoraproject.org Fri Jul 20 16:25:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 20 Jul 2007 21:55:43 +0530 Subject: =?utf-8?q?WTF=E2=81=88_ShowOnlyIn=3DGNOME?= In-Reply-To: References: Message-ID: <46A0E207.4060500@fedoraproject.org> Christopher Stone wrote: > Why are tons of apps setting ShowOnlyIn=GNOME; in their .desktop file? > > This does not bode well for KDE users. > > # grep -i onlyshowin /usr/share/applications/*.desktop|grep -i gnome|wc -l > 63 > > Sixty-Three apps which I have installed are only showing up in GNOME!! > > What the hell for??? > > Is Fedora *trying* to cripple KDE or what? No. Why do you want assume malice for potential bugs? > > I dont see a single application using ShowOnlyIn=KDE That's because you are looking in the wrong folder. Next time, try and be less melodramatic. Rahul From hughsient at gmail.com Fri Jul 20 16:23:49 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 20 Jul 2007 17:23:49 +0100 Subject: Trading reviews ? In-Reply-To: <20070720155215.GA30036@hedwig.net.cmu.edu> References: <20070720155215.GA30036@hedwig.net.cmu.edu> Message-ID: <1184948629.4702.8.camel@work> On Fri, 2007-07-20 at 11:52 -0400, Gabriel L. Somlo wrote: > Anyone running Fedora on a Mac laptop interested in reviewing my > pbbuttonsd submission (bugzilla # 246368) ? Isn't pbbuttonsd obsolete now? > It has some overlap with apmd Yup, and HAL (does ppbuttonsd even run with HAL polling the same hardware?). It also breaks spectacularly with fast user switching and is PPC specific. I'm trying really hard to remove the product and architecture specific daemons such as tpd and pmud as in my opinion they do not fit the modern user-centric session experience. > but the main highlights are that it > runs both on ppc and intel, and controls the light sensors, and > display and keyboard backlight... You can use gnome-power-manager, guidance-power-manager or kpowersave for this. I don't think it's a problem having ppbuttonsd in the fedora repo, just in my opinion nobody should need to use it. Hardware should "just work" from the base install IMO. Richard. From che666 at gmail.com Fri Jul 20 16:30:45 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 20 Jul 2007 18:30:45 +0200 Subject: feature proposal: NetworkManager umts plugin Message-ID: Hello to you! Actually in my eyes it would make perfect sense to have a networkmanager umts plugin because the current ppp support just doesent provide the required functionality to provide proper umts functionality integration. What it is essentially missing is: * the showing of signal strenght and * the possibility to scan for and * switch to different providers as well as * maybe some configuration option to either track the spent time in a defined timeframe and/or * the used up bandwidth. opinions welcome! regards, Rudolf Kastl From jonathan.underwood at gmail.com Fri Jul 20 16:32:34 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 17:32:34 +0100 Subject: Automating pam_keyring... In-Reply-To: <1184939365.18238.0.camel@cutter> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> <1184939365.18238.0.camel@cutter> Message-ID: <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> On 20/07/07, seth vidal wrote: > Good! I'm glad they're working for you. Are they ready to go to final > update? Well, I've been using it for a day or so without problems. The only thing I did notice is when clicking on the applet, I see this message at the bottom of the popup box: Warning: Your system is not configured to cache passphrases in secure memory. I suspect this is about keys being stored in memory that can be swapped out - I am not sure we have the infrastructure in place to do anything about that yet, though? J. From skvidal at linux.duke.edu Fri Jul 20 16:48:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 20 Jul 2007 12:48:21 -0400 Subject: Automating pam_keyring... In-Reply-To: <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> <1184939365.18238.0.camel@cutter> <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> Message-ID: <1184950101.18238.4.camel@cutter> On Fri, 2007-07-20 at 17:32 +0100, Jonathan Underwood wrote: > On 20/07/07, seth vidal wrote: > > Good! I'm glad they're working for you. Are they ready to go to final > > update? > > Well, I've been using it for a day or so without problems. The only > thing I did notice is when clicking on the applet, I see this message > at the bottom of the popup box: > > Warning: Your system is not configured to cache passphrases in secure memory. > > I suspect this is about keys being stored in memory that can be > swapped out - I am not sure we have the infrastructure in place to do > anything about that yet, though? yah - that's the same message gpg occasionally barks about. -sv From notting at redhat.com Fri Jul 20 16:44:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 20 Jul 2007 12:44:51 -0400 Subject: Automating pam_keyring... In-Reply-To: <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> References: <46730322.6020400@poolshark.org> <20070717102340.43fe40e7@localhost.localdomain> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> <1184939365.18238.0.camel@cutter> <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> Message-ID: <20070720164451.GD26910@nostromo.devel.redhat.com> Jonathan Underwood (jonathan.underwood at gmail.com) said: > Warning: Your system is not configured to cache passphrases in secure > memory. > > I suspect this is about keys being stored in memory that can be > swapped out - I am not sure we have the infrastructure in place to do > anything about that yet, though? Well, it's just using mlock(). Why is it getting that error, though - is it trying to allocate more than the current default? Bill From ndbecker2 at gmail.com Fri Jul 20 16:47:37 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 20 Jul 2007 12:47:37 -0400 Subject: help make build References: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> Message-ID: OK, I'm completely lost: Jon Ciesla wrote: > "TAG_OPTS=-F make tag". TAG_OPTS=-F make tag cvs tag -F -c uncrustify-0_35-1_fc7 ? .build-0.35-1.fc7.log ? uncrustify-0.35 ? uncrustify-0.35-1.fc7.src.rpm ? uncrustify-0.35.tgz ? x86_64 cvs tag: Tagging . Tagged with: uncrustify-0_35-1_fc7 [nbecker at nbecker4 F-7]$ cvs diff ? .build-0.35-1.fc7.log ? uncrustify-0.35 ? uncrustify-0.35-1.fc7.src.rpm ? uncrustify-0.35.tgz ? x86_64 cvs diff: Diffing . [nbecker at nbecker4 F-7]$ make build Created task: 71717 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=71717 Watching tasks (this may be safely interrupted)... 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7): free 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7): free -> open (xenbuilder2.fedora.redhat.com) 71719 buildSRPMFromCVS (F-7:uncrustify-0_35-1_fc7): open (xenbuilder4.fedora.phx.redhat.com) 71719 buildSRPMFromCVS (F-7:uncrustify-0_35-1_fc7): open (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: Error building SRPM 0 free 1 open 0 done 1 failed 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7): open (xenbuilder2.fedora.redhat.com) -> FAILED: BuildError: Error building SRPM 0 free 0 open 0 done 2 failed 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7) failed make: *** [koji] Error 1 From limb at jcomserv.net Fri Jul 20 16:42:39 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 20 Jul 2007 11:42:39 -0500 (CDT) Subject: help make build In-Reply-To: References: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> Message-ID: <9891.65.192.24.164.1184949759.squirrel@mail.jcomserv.net> > OK, I'm completely lost: > > Jon Ciesla wrote: > >> "TAG_OPTS=-F make tag". > TAG_OPTS=-F make tag > cvs tag -F -c uncrustify-0_35-1_fc7 > ? .build-0.35-1.fc7.log > ? uncrustify-0.35 > ? uncrustify-0.35-1.fc7.src.rpm > ? uncrustify-0.35.tgz > ? x86_64 > cvs tag: Tagging . > Tagged with: uncrustify-0_35-1_fc7 > > [nbecker at nbecker4 F-7]$ cvs diff > ? .build-0.35-1.fc7.log > ? uncrustify-0.35 > ? uncrustify-0.35-1.fc7.src.rpm > ? uncrustify-0.35.tgz > ? x86_64 > cvs diff: Diffing . > [nbecker at nbecker4 F-7]$ make build > Created task: 71717 > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=71717 > Watching tasks (this may be safely interrupted)... > 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7): free > 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7): free > -> open (xenbuilder2.fedora.redhat.com) > 71719 buildSRPMFromCVS (F-7:uncrustify-0_35-1_fc7): open > (xenbuilder4.fedora.phx.redhat.com) > 71719 buildSRPMFromCVS (F-7:uncrustify-0_35-1_fc7): open > (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: Error > building SRPM > 0 free 1 open 0 done 1 failed > 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7): open > (xenbuilder2.fedora.redhat.com) -> FAILED: BuildError: Error building SRPM > 0 free 0 open 0 done 2 failed > > 71717 build (dist-fc7-updates-candidate, F-7:uncrustify-0_35-1_fc7) failed > make: *** [koji] Error 1 Based on the build log, I'd say the sources file isn't updated in cvs. See: [limb at fawkes cvs]$ cvs update uncrustify/ Enter passphrase for key '/home/limb/.ssh/id_dsa': cvs update: Updating uncrustify cvs update: Updating uncrustify/F-7 cvs update: Updating uncrustify/FC-5 cvs update: Updating uncrustify/FC-6 cvs update: Updating uncrustify/common cvs update: Updating uncrustify/devel [limb at fawkes cvs]$ cd uncrustify/F-7/ [limb at fawkes F-7]$ ls branch CVS Makefile sources uncrustify.spec [limb at fawkes F-7]$ cat sources 3c242519de3d12f7b916b560366c1aa8 uncrustify-0.30.tgz Copy it from the devel branch, cvs commit, then re-run TAG_OPTS=-F make tag, etc. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From dlutter at redhat.com Fri Jul 20 17:14:51 2007 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 20 Jul 2007 10:14:51 -0700 Subject: rsyslog is in F8 In-Reply-To: <20070719161426.GA6932@angus.ind.WPI.EDU> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F6FE3.6010605@redhat.com> <20070719161426.GA6932@angus.ind.WPI.EDU> Message-ID: <1184951691.14806.9.camel@galia.watzmann.net> On Thu, 2007-07-19 at 12:14 -0400, Chuck Anderson wrote: > On Thu, Jul 19, 2007 at 04:06:27PM +0200, Peter Vrabec wrote: > > Matthew Miller wrote: > > > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: > > >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to > > >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog > > >> is replaced. > > > > > > Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage > > > of rsyslog over syslog-ng? > > Hmmm, It use rsyslog.conf. > > cp syslog.conf rsyslog.conf is done, because we want to keep and use > > previous configuration. Or do you want your custom configuration be > > dropped and replaced by default one? :-) > > For rsyslog to be a drop in replacement, it should use the same config > file named the same in the same location IMO. That change also means that anybody who has automated management of their syslog configuration must modify their scripts to take those changes into account (and if they run F7 machines at the same time, do some ugly logic) It would be much gentler if rsyslogd would initially use the exact same files as sysklogd and let users shuffle things around when they are ready for that transition. David From jonathan.underwood at gmail.com Fri Jul 20 17:15:57 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 18:15:57 +0100 Subject: Automating pam_keyring... In-Reply-To: <20070720164451.GD26910@nostromo.devel.redhat.com> References: <46730322.6020400@poolshark.org> <469D15F3.4040609@uni-x.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> <1184939365.18238.0.camel@cutter> <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> <20070720164451.GD26910@nostromo.devel.redhat.com> Message-ID: <645d17210707201015y3e95b7c4v77e829aff685034b@mail.gmail.com> On 20/07/07, Bill Nottingham wrote: > Jonathan Underwood (jonathan.underwood at gmail.com) said: > > Warning: Your system is not configured to cache passphrases in secure > > memory. > > > > I suspect this is about keys being stored in memory that can be > > swapped out - I am not sure we have the infrastructure in place to do > > anything about that yet, though? > > Well, it's just using mlock(). Why is it getting that error, though - is > it trying to allocate more than the current default? > Am not sure how I would tell? I am seeing that message even though no PGP keys are cached, only an ssh one is. I am not sure if ssh-agent keeps keys in mlock'ed memory or not. From somlo at cmu.edu Fri Jul 20 17:16:47 2007 From: somlo at cmu.edu (Gabriel L. Somlo) Date: Fri, 20 Jul 2007 13:16:47 -0400 Subject: Trading reviews ? In-Reply-To: <20070720155539.GB26910@nostromo.devel.redhat.com> References: <20070720160004.421CE73A81@hormel.redhat.com> Message-ID: <20070720171647.GB30036@hedwig.net.cmu.edu> > Bill Nottingham wrote: > > pbbuttonsd submission (bugzilla # 246368) ? > > > Why isn't this integrated in HAL? Wasn't aware of that -- just checked, and there's some mention of 'Macbook backlight' in their recent change logs. If by that they mean keyboard backlight on macbooks, I hope it also works on the older ppc hardware. May be worth waiting for it to just show up in HAL, then... :) Gabriel From jonathan.underwood at gmail.com Fri Jul 20 17:19:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 20 Jul 2007 18:19:19 +0100 Subject: Automating pam_keyring... In-Reply-To: <645d17210707201015y3e95b7c4v77e829aff685034b@mail.gmail.com> References: <46730322.6020400@poolshark.org> <20070717152326.510c5e77@ender> <469D1E6E.5040404@uni-x.org> <20070717162124.5014a7e2@localhost.localdomain> <1184709558.6008.5.camel@legolas.felicity-group.com> <645d17210707200638y2fa52389wf71c411fa1ac812a@mail.gmail.com> <1184939365.18238.0.camel@cutter> <645d17210707200932n3a8a98fck1fac5fb9192ac70c@mail.gmail.com> <20070720164451.GD26910@nostromo.devel.redhat.com> <645d17210707201015y3e95b7c4v77e829aff685034b@mail.gmail.com> Message-ID: <645d17210707201019j1677f742od3ec61d7640cf5e7@mail.gmail.com> On 20/07/07, Jonathan Underwood wrote: > On 20/07/07, Bill Nottingham wrote: > > Jonathan Underwood (jonathan.underwood at gmail.com) said: > > > Warning: Your system is not configured to cache passphrases in secure > > > memory. > > > > > > I suspect this is about keys being stored in memory that can be > > > swapped out - I am not sure we have the infrastructure in place to do > > > anything about that yet, though? > > > > Well, it's just using mlock(). Why is it getting that error, though - is > > it trying to allocate more than the current default? > > > > Am not sure how I would tell? I am seeing that message even though no > PGP keys are cached, only an ssh one is. I am not sure if ssh-agent > keeps keys in mlock'ed memory or not. > Yes, as I suspected looking at /proc/pid/status of the ssh-agent, I see: VmLck: 0 kB and so ssh-agent isn't using mlock'd memory, which is probably what seahorse is grumbling about. [As an aside, I wonder if that constitutes a security hole in ssh-agent]. J. From dan at danny.cz Fri Jul 20 17:16:30 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Fri, 20 Jul 2007 19:16:30 +0200 Subject: help make build In-Reply-To: References: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> Message-ID: <1184951790.4169.1.camel@eagle.danny.cz> Neal Becker p??e v P? 20. 07. 2007 v 12:47 -0400: > OK, I'm completely lost: > > Jon Ciesla wrote: > > > "TAG_OPTS=-F make tag". > TAG_OPTS=-F make tag > cvs tag -F -c uncrustify-0_35-1_fc7 > ? .build-0.35-1.fc7.log > ? uncrustify-0.35 > ? uncrustify-0.35-1.fc7.src.rpm > ? uncrustify-0.35.tgz > ? x86_64 > cvs tag: Tagging . > Tagged with: uncrustify-0_35-1_fc7 > > [nbecker at nbecker4 F-7]$ cvs diff > ? .build-0.35-1.fc7.log > ? uncrustify-0.35 > ? uncrustify-0.35-1.fc7.src.rpm > ? uncrustify-0.35.tgz > ? x86_64 > cvs diff: Diffing . Did you "make new-sources FILES=uncrustify-0.35.tgz"? It looks like that you don't have the upstream sources on the build server. Dan From skvidal at linux.duke.edu Fri Jul 20 17:21:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 20 Jul 2007 13:21:00 -0400 Subject: rsyslog is in F8 In-Reply-To: <1184951691.14806.9.camel@galia.watzmann.net> References: <469DE95D.8080006@redhat.com> <20070719123624.GA20033@jadzia.bu.edu> <469F6FE3.6010605@redhat.com> <20070719161426.GA6932@angus.ind.WPI.EDU> <1184951691.14806.9.camel@galia.watzmann.net> Message-ID: <1184952061.18238.7.camel@cutter> On Fri, 2007-07-20 at 10:14 -0700, David Lutterkort wrote: > On Thu, 2007-07-19 at 12:14 -0400, Chuck Anderson wrote: > > On Thu, Jul 19, 2007 at 04:06:27PM +0200, Peter Vrabec wrote: > > > Matthew Miller wrote: > > > > On Wed, Jul 18, 2007 at 12:20:13PM +0200, Peter Vrabec wrote: > > > >> sysklogd config files syslog.conf, sysconfig/syslog are renamed to > > > >> rsyslog.conf, sysconfig/rsyslog and used by rsyslog. logrotate.d/syslog > > > >> is replaced. > > > > > > > > Hey, uh, doesn't changing to using rsyslog.conf remove the major advantage > > > > of rsyslog over syslog-ng? > > > Hmmm, It use rsyslog.conf. > > > cp syslog.conf rsyslog.conf is done, because we want to keep and use > > > previous configuration. Or do you want your custom configuration be > > > dropped and replaced by default one? :-) > > > > For rsyslog to be a drop in replacement, it should use the same config > > file named the same in the same location IMO. > > That change also means that anybody who has automated management of > their syslog configuration must modify their scripts to take those > changes into account (and if they run F7 machines at the same time, do > some ugly logic) > > It would be much gentler if rsyslogd would initially use the exact same > files as sysklogd and let users shuffle things around when they are > ready for that transition. > as a zany idea: f8 -> rsyslog is included, does not obsolete sysklogd, will use syslog.conf if it exists. throws up a warning if it is present and sysklogd is installed, too when it runs. f9 -> rsyslog obsoletes sysklogd a transition period is such a crazy thing :) -sv From limb at jcomserv.net Fri Jul 20 17:10:03 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 20 Jul 2007 12:10:03 -0500 (CDT) Subject: help make build In-Reply-To: <1184951790.4169.1.camel@eagle.danny.cz> References: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> <1184951790.4169.1.camel@eagle.danny.cz> Message-ID: <34489.65.192.24.164.1184951403.squirrel@mail.jcomserv.net> > Neal Becker p????e v P?? 20. 07. 2007 v 12:47 -0400: >> OK, I'm completely lost: >> >> Jon Ciesla wrote: >> >> > "TAG_OPTS=-F make tag". >> TAG_OPTS=-F make tag >> cvs tag -F -c uncrustify-0_35-1_fc7 >> ? .build-0.35-1.fc7.log >> ? uncrustify-0.35 >> ? uncrustify-0.35-1.fc7.src.rpm >> ? uncrustify-0.35.tgz >> ? x86_64 >> cvs tag: Tagging . >> Tagged with: uncrustify-0_35-1_fc7 >> >> [nbecker at nbecker4 F-7]$ cvs diff >> ? .build-0.35-1.fc7.log >> ? uncrustify-0.35 >> ? uncrustify-0.35-1.fc7.src.rpm >> ? uncrustify-0.35.tgz >> ? x86_64 >> cvs diff: Diffing . > > Did you "make new-sources FILES=uncrustify-0.35.tgz"? > It looks like that you don't have the upstream sources on the build > server. He has them committed in the devel branch, so copying the sources file and committing it should work, assuming he did the above in devel. Which I assumed. You did, Neal, right? Jon > > Dan > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From linux_4ever at yahoo.com Fri Jul 20 17:27:32 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 20 Jul 2007 10:27:32 -0700 (PDT) Subject: rsyslog is in F8 In-Reply-To: <1184951691.14806.9.camel@galia.watzmann.net> Message-ID: <638379.60603.qm@web51504.mail.re2.yahoo.com> >It would be much gentler if rsyslogd would initially use the exact same >files as sysklogd and let users shuffle things around when they are >ready for that transition. That is exactly the reason I was suggesting the CONFIG_FILE variable in /etc/sysconfig/rsyslog. -Steve ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From vivekl at redhat.com Fri Jul 20 17:33:26 2007 From: vivekl at redhat.com (Vivek Lakshmanan) Date: Fri, 20 Jul 2007 13:33:26 -0400 Subject: Trading reviews ? In-Reply-To: <20070720171647.GB30036@hedwig.net.cmu.edu> References: <20070720160004.421CE73A81@hormel.redhat.com> <20070720171647.GB30036@hedwig.net.cmu.edu> Message-ID: <1184952806.4595.12.camel@spook> On Fri, 2007-07-20 at 13:16 -0400, Gabriel L. Somlo wrote: > > Bill Nottingham wrote: > > > pbbuttonsd submission (bugzilla # 246368) ? > > > > > Why isn't this integrated in HAL? > > Wasn't aware of that -- just checked, and there's some mention of > 'Macbook backlight' in their recent change logs. If by that they mean > keyboard backlight on macbooks, I hope it also works on the older ppc > hardware. > May be worth waiting for it to just show up in HAL, then... :) > The features you mentioned are indeed part of HAL. However, there seems to be a (packaging?) bug in the F7 HAL which would enable these controls (atleast for an intel MacBook Pro I tried this on). See bug #247481 for details. Thanks, Vivek -------------- next part -------------- A non-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 Fri Jul 20 17:35:56 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 20 Jul 2007 10:35:56 -0700 Subject: SCM SIG Meeting Message-ID: <1184952956.30158.61.camel@localhost.localdomain> There will be an SCM SIG meeting on Thursday, July, 26, 2007 @ 19:00 UTC on the #fedora-meeting IRC channel. We will discuss requirements for implementing exploded trees. The idea is to make a list of features that are needed from exploded trees and what pitfalls must be avoided to make them viable. Then a team of interested people can create an implementation to decide if it's viable to create an exploded tree repo or if we should take the more minimal step of implementing the current repo in a distributed SCM. If you cannot attend but want to make sure that a feature or pitfall gets attention, please add it to the agenda: http://fedoraproject.org/wiki/Infrastructure/SCMSig/Agenda -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 Lam at Lam.pl Fri Jul 20 17:48:32 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 20 Jul 2007 19:48:32 +0200 Subject: rsyslog is in F8 In-Reply-To: <1184923583.10041.27.camel@perun.kabelta.loc> References: <776275.35493.qm@web51504.mail.re2.yahoo.com> <1184923583.10041.27.camel@perun.kabelta.loc> Message-ID: <20070720194832.2c07c96d@pensja.lam.pl> Dnia 2007-07-20, o godz. 11:26:23 Tomas Mraz napisa?(a): > e.g. Why package named rsyslog uses config file > syslog.conf. Okay. Now, why does package named "samba" use config file named "smb.conf" instead of "samba.conf"? Another example is package named "sysklogd" using "syslog.conf" instead of "sysklokd.conf" (2 letter difference). Can't you see, how hollow your argument is? People expect the config to be "syslog.conf", if it's only in "syslog.conf" format, no matter, what the package name is this week. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From benny+usenet at amorsen.dk Fri Jul 20 18:45:29 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Fri, 20 Jul 2007 20:45:29 +0200 Subject: Fedora Feature Proposal: Yum Integration References: <20070718151543.7af10cc6@localhost.localdomain> <20070719102843.GA8485@jadzia.bu.edu> <1184845933.606.196.camel@cutter> <20070719122529.GA16818@jadzia.bu.edu> <1184853033.606.208.camel@cutter> <20070719143845.GA29978@jadzia.bu.edu> <17196.1184860294@laptop13.inf.utfsm.cl> <20070720142701.GA14247@jadzia.bu.edu> <11166.1184943256@laptop13.inf.utfsm.cl> <20070720150543.GA16618@jadzia.bu.edu> <14677.1184947770@laptop13.inf.utfsm.cl> Message-ID: >>>>> "HHvB" == Horst H von Brand writes: HHvB> One of the basic guidelines when securing a system is to keep it HHvB> as simple as possible, i.e., install only what is required, and HHvB> keep a strict control over what is happening. Anything else ends HHvB> with the sysadmin in a padded cell. As long as users have the ability to make their own programs (and this is REALLY hard to deny someone on Unix), you have lost that particular battle anyway. I have to say I really like the idea of letting non-root install software. Packages which do not touch anything in /etc and have no suid bits should be safe. Those rules do not cover all possible holes -- e.g. a package could have a file /bin/man which did nasty things, in the hope that someone privileged eventually reads a man page. Nevertheless, deliberately malicious packages should be stopped by the Fedora package review. /Benny From sundaram at fedoraproject.org Fri Jul 20 18:47:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 21 Jul 2007 00:17:57 +0530 Subject: rsyslog is in F8 In-Reply-To: <20070720194832.2c07c96d@pensja.lam.pl> References: <776275.35493.qm@web51504.mail.re2.yahoo.com> <1184923583.10041.27.camel@perun.kabelta.loc> <20070720194832.2c07c96d@pensja.lam.pl> Message-ID: <46A1035D.5010509@fedoraproject.org> Leszek Matok wrote: > Dnia 2007-07-20, o godz. 11:26:23 Tomas Mraz napisa?(a): > >> e.g. Why package named rsyslog uses config file >> syslog.conf. > Okay. Now, why does package named "samba" use config file named "smb.conf" > instead of "samba.conf"? > > Another example is package named "sysklogd" using "syslog.conf" instead of > "sysklokd.conf" (2 letter difference). Can't you see, how hollow your argument > is? People expect the config to be "syslog.conf", if it's only in > "syslog.conf" format, no matter, what the package name is this week. Not really. Rsyslog might switch a new format in the future. Look in the upstream list archives for details. Rahul From Lam at Lam.pl Fri Jul 20 19:02:04 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 20 Jul 2007 21:02:04 +0200 Subject: rsyslog is in F8 In-Reply-To: <46A1035D.5010509@fedoraproject.org> References: <776275.35493.qm@web51504.mail.re2.yahoo.com> <1184923583.10041.27.camel@perun.kabelta.loc> <20070720194832.2c07c96d@pensja.lam.pl> <46A1035D.5010509@fedoraproject.org> Message-ID: <20070720210204.08513649@pensja.lam.pl> Dnia 2007-07-21, o godz. 00:17:57 Rahul Sundaram napisa?(a): > Not really. Rsyslog might switch a new format in the future. Look in the > upstream list archives for details. Are they willing to forcibly break compatibility with previous versions? Aren't they going to provide a nice path of upgrade (a converter, accepting both formats)? Is it going to happen before F8? If all three answers are "no", then I don't see any reason to rename syslog.conf. If any of the first two answers is "yes", many of us won't see any reason to really obsolete sysklogd with rsyslog instead of syslog-ng or anything other. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From howard at cohtech.com Fri Jul 20 19:06:41 2007 From: howard at cohtech.com (Howard Wilkinson) Date: Fri, 20 Jul 2007 20:06:41 +0100 Subject: Fedora 7 kickstart problem with rebuilt Everything image Message-ID: <46A107C1.8020801@cohtech.com> We routinely rebuild systems from a kickstart driven facility we have built. This uses a Fedora image - in this case fedora 7 Everything with the updates merged in. We have run into 2 problems with this as opposed to the original release image. First the version of yum available in updates currently is incompatible with the version of anaconda. The problem is that this version of yum does not create the headers directory and anaconda assumes it will exist. anaconda-11.2.0.66-1.i386.rpm yum-3.2.1-1.fc7 To get round this we have reverted to yum-3.2.0-1.fc7.noarch.rpm for now but will probably try out the development releases of anaconda and yum next week. More worrying is a problem with dependencies in building the kernel initrd images. The newly built Everything regime has the latest kernel - kernel-2.6.21-1.3228.fc7 - as available from updates. But when the kickstart install runs the mkinitrd cannot find /sbin/mdadm as the mdadm package is not a dependency of the kernel (and should not be for all builds but ....[1]) This has the effect of allowing the build to complete but when the system reboots LVM cannot find the logical volume groups because the raid has not started. /We build our systems with mirrored boot partitions on /dev/md0 and mirrored /dev/md1 on the remainder of the disc with logical volumes on this portion of the disc including the root partition. Hence the problem above.[1]/ To get round this we are rebuilding the kernel to require the mdadm package - but this is really not what we should be doing. Somewhere in the RPM, YUM, Anaconda, regime we need to be able to specify that mdadm (and lvm2) needs to be installed prior to the kernel installation, only for our particular configurations not in general. Any ideas anybody? -- Howard Wilkinson Phone: +44(20)76907075 Coherent Technology Limited Fax: 23 Northampton Square, Mobile: +44(7980)639379 United Kingdom, EC1V 0HL Email: howard at cohtech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Fri Jul 20 19:45:04 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 20 Jul 2007 14:45:04 -0500 Subject: SCM SIG Meeting In-Reply-To: <1184952956.30158.61.camel@localhost.localdomain> References: <1184952956.30158.61.camel@localhost.localdomain> Message-ID: <1184960704.3735.14.camel@weaponx.rchland.ibm.com> On Fri, 2007-07-20 at 10:35 -0700, Toshio Kuratomi wrote: > There will be an SCM SIG meeting on Thursday, July, 26, 2007 @ 19:00 UTC > on the #fedora-meeting IRC channel. We will discuss requirements for > implementing exploded trees. The idea is to make a list of features > that are needed from exploded trees and what pitfalls must be avoided to > make them viable. Then a team of interested people can create an > implementation to decide if it's viable to create an exploded tree repo > or if we should take the more minimal step of implementing the current > repo in a distributed SCM. So the decision that we need exploded trees is a forgone conclusion? josh From a.badger at gmail.com Fri Jul 20 20:00:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 20 Jul 2007 13:00:35 -0700 Subject: SCM SIG Meeting In-Reply-To: <1184960704.3735.14.camel@weaponx.rchland.ibm.com> References: <1184952956.30158.61.camel@localhost.localdomain> <1184960704.3735.14.camel@weaponx.rchland.ibm.com> Message-ID: <1184961635.30158.96.camel@localhost.localdomain> On Fri, 2007-07-20 at 14:45 -0500, Josh Boyer wrote: > On Fri, 2007-07-20 at 10:35 -0700, Toshio Kuratomi wrote: > > There will be an SCM SIG meeting on Thursday, July, 26, 2007 @ 19:00 UTC > > on the #fedora-meeting IRC channel. We will discuss requirements for > > implementing exploded trees. The idea is to make a list of features > > that are needed from exploded trees and what pitfalls must be avoided to > > make them viable. Then a team of interested people can create an > > implementation to decide if it's viable to create an exploded tree repo > > or if we should take the more minimal step of implementing the current > > repo in a distributed SCM. > > So the decision that we need exploded trees is a forgone conclusion? > No. The conclusion that exploded trees offer features we would like is a foregone conclusion. The decision of whether we can address all the pitfalls of doing exploded trees by designing the SCM repo correctly is not. This meeting is to identify pitfalls and features so we can try and design an exploded tree repo that addresses all the concerns. That gives us a better basis for deciding whether it's worthwhile to implement it in our next generation repository. If we run up against seven huge concerns that we just can't work around, then it will be clear we need to abandon the idea. If we manage to solve all of them, then it would be strongly recommended to do it. If we can't solve one or two minor concerns but manage to solve the rest then we'll have an accurate list of pros and cons to present about exploded trees. -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 dimi at lattica.com Fri Jul 20 20:13:18 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 20 Jul 2007 16:13:18 -0400 Subject: Fedora & Sound: an excercise in frustration Message-ID: <1184962398.3195.20.camel@dimi.lattica.com> Guys, The sound situation is appalling: since FC6, my sounds stops/starts working with pretty much _every_ kernel update! Don't worry, the steady state is that it's not working. It will start working for a short lived kernel version, but people are diligently working to fix it back to its non-working state. Hardware (bog standard): [root at dimi ~]# lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) Software: Standard FC6, now F7 Symptoms: system-config-soundcard doesn't recognize the card, it will not even list it. FC6 was off/on, which the last kernel being on. Then I updated to F7, goodbye sound! I tried everything, nothing helped. No errors, logs, etc. Previous kernel somehow worked, it took me by surprise since I though it will be a cold day in hell before I see sound working. But I was happy nonetheless. Now the 3228 kernel fixed it again, its no longer recognized. What gives?!? I've been using Linux since 1996, and I can say I've never had a more frustrating, aggravating, nerve shattering experience. Never before have I encountered so much flakiness! -- Dimi Paun Lattica, Inc. From debarshi.ray at gmail.com Fri Jul 20 21:39:34 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 21 Jul 2007 03:09:34 +0530 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184962398.3195.20.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> Message-ID: <3170f42f0707201439s38f3644tba6298df96ef42d2@mail.gmail.com> I am on a Fedora 7 system, running the latest kernel-2.6.21-1.3228.fc7 from updates, with a small mix of Rawhide packages thrown in. Whenever I play a song or a movie I get a constant high frequency monotonous note alongwith the expected soundtrack. [root at ginger ~]# lspci ... ... 04:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller ... [root at ginger ~]# lsmod Module Size Used by video 21065 0 snd_hda_intel 24409 2 snd_hda_codec 202689 1 snd_hda_intel snd_seq_dummy 7877 0 snd_seq_oss 33345 0 snd_seq_midi_event 11073 1 snd_seq_oss snd_seq 50353 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 11853 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 43489 0 snd_mixer_oss 19393 2 snd_pcm_oss snd_pcm 74565 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_timer 24773 2 snd_seq,snd_pcm snd 53189 11 snd_hda_intel,snd_hda_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer fw_ohci 19649 0 serio_raw 10821 0 edac_mc 27665 1 k8_edac soundcore 11553 2 snd fw_core 42625 1 fw_ohci usblp 17345 0 snd_page_alloc 13769 2 snd_hda_intel,snd_pcm pcspkr 7105 0 ... [root at ginger ~]# Worth filing a bug, or am I making a mistake? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tbrinkman at sbcglobal.net Fri Jul 20 21:10:31 2007 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Fri, 20 Jul 2007 16:10:31 -0500 Subject: Fedora & Sound: an excd chipercise in frustration In-Reply-To: <1184962398.3195.20.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> Message-ID: <200707201610.32162.tbrinkman@sbcglobal.net> On Friday 20 July 2007 03:13:18 pm Dimi Paun wrote: > Hardware (bog standard): > [root at dimi ~]# lspci | grep -i audio > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD > Audio Controller (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) Mine, is a new T61 laptop usin the ad1984 snd chip. > Software: > Standard FC6, now F7 This is the -devel list. You want users for past 'standard' releases. > What gives?!? Probly alsa... do some googlin. OTOH, my T61 is current rawhide. I believe the correct driver is in modprobe.conf alias snd-card-0 snd-hda-intel options snd-card-0 index=0 options snd-hda-intel index=0 options snd-hda-intel model=thinkpad # I added this From googlin, it appears all that is needed is an alsa update to >= rc4 to support ad1984. Rawhide is alsa-lib-1.0.14-0.4.rc3.fc7 alsa-utils-1.0.14-0.7.rc2.fc7 Any chance of an alsa update before the F8 freeze? TIA -- Tom Brinkman Corpus Christi, Texas From bojan at rexursive.com Sat Jul 21 00:43:48 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 21 Jul 2007 00:43:48 +0000 (UTC) Subject: SCM SIG Meeting References: <1184952956.30158.61.camel@localhost.localdomain> <1184960704.3735.14.camel@weaponx.rchland.ibm.com> <1184961635.30158.96.camel@localhost.localdomain> Message-ID: Toshio Kuratomi gmail.com> writes: > No. The conclusion that exploded trees offer features we would like is > a foregone conclusion. Is there a doc in Fedora wiki that explains what those features are? -- Bojan From darth_linux at ameritech.net Fri Jul 20 21:35:39 2007 From: darth_linux at ameritech.net (eah) Date: Fri, 20 Jul 2007 17:35:39 -0400 Subject: Qt4 RPMs broken? Message-ID: <200707201735.40344.darth_linux@ameritech.net> Hello all, I'm trying to integrate Eclipse and Qt4. I'm running Fedora 6 and the stock RPMs of Qt4. When Eclipse prompts me for the install directory of Qt4, I notice the Qt4 includes and binaries are not in the same directory tree. qmake-qt4 -query QT_INSTALL_PREFIX reports /usr/lib64/qt4, but it only contains bin, demos, doc (*), examples, LICENSE.GPL, mkspecs, and plugins. The Qt4 includes are in /usr/include. (*) doc is a link to /usr/share/doc/qt, but should point to /usr/share/doc/qt4. Can this (has this) be resolved? thanks, eah (Eric Hartwell) From kevin.kofler at chello.at Sat Jul 21 02:42:38 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 21 Jul 2007 02:42:38 +0000 (UTC) Subject: Qt4 RPMs broken? References: <200707201735.40344.darth_linux@ameritech.net> Message-ID: eah ameritech.net> writes: > I'm trying to integrate Eclipse and Qt4. I'm running Fedora 6 and the stock > RPMs of Qt4. When Eclipse prompts me for the install directory of Qt4, I > notice the Qt4 includes and binaries are not in the same directory tree. > qmake-qt4 -query QT_INSTALL_PREFIX reports /usr/lib64/qt4, but it only > contains bin, demos, doc (*), examples, LICENSE.GPL, mkspecs, and > plugins. The Qt4 includes are in /usr/include. This is called "complying to the FHS", not "broken". It's entirely intentional. > (*) doc is a link to /usr/share/doc/qt, but should point > to /usr/share/doc/qt4. That one sounds like a bug. Are you sure about that? It points to ../../share/doc/qt4 here (qt4-4.3.0-8.fc7). > Can this (has this) be resolved? There's nothing to resolve here (except possibly the doc symlink). If the packaging breaks the Qt Eclipse integration, complain to Trolltech, there's nothing we can do about it until/unless they release the source code for that. Kevin Kofler From darth_linux at ameritech.net Sat Jul 21 03:43:34 2007 From: darth_linux at ameritech.net (eah) Date: Fri, 20 Jul 2007 23:43:34 -0400 Subject: Qt4 RPMs broken? In-Reply-To: References: <200707201735.40344.darth_linux@ameritech.net> Message-ID: <200707202343.34817.darth_linux@ameritech.net> On Friday 20 July 2007 22:42:38 Kevin Kofler wrote: > > (*) doc is a link to /usr/share/doc/qt, but should point > > to /usr/share/doc/qt4. > > That one sounds like a bug. Are you sure about that? It points > to ../../share/doc/qt4 here (qt4-4.3.0-8.fc7). > > Kevin Kofler yep, i'm sure. but i did notice that updated version is qt4-4.3.0-2.fc6. maybe it's something that was fixed in the minor release(s) between -2 and -8.... ? thanks, eah From kevin.kofler at chello.at Sat Jul 21 04:09:12 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 21 Jul 2007 04:09:12 +0000 (UTC) Subject: Qt4 RPMs broken? References: <200707201735.40344.darth_linux@ameritech.net> <200707202343.34817.darth_linux@ameritech.net> Message-ID: eah ameritech.net> writes: > yep, i'm sure. but i did notice that updated version is qt4-4.3.0-2.fc6. > maybe it's something that was fixed in the minor release(s) between -2 > and -8.... ? I just checked the changelog and yes, this was fixed in 4.3.0-8. Kevin Kofler From josef at toxicpanda.com Sat Jul 21 04:21:41 2007 From: josef at toxicpanda.com (Josef Bacik) Date: Sat, 21 Jul 2007 00:21:41 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184962398.3195.20.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> Message-ID: <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> On 7/20/07, Dimi Paun wrote: > Guys, > > The sound situation is appalling: since FC6, my sounds stops/starts > working with pretty much _every_ kernel update! Don't worry, the > steady state is that it's not working. It will start working for a > short lived kernel version, but people are diligently working to > fix it back to its non-working state. > > Hardware (bog standard): > [root at dimi ~]# lspci | grep -i audio > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) > > Software: > Standard FC6, now F7 > > Symptoms: > system-config-soundcard doesn't recognize the card, it will not even > list it. FC6 was off/on, which the last kernel being on. Then I > updated to F7, goodbye sound! I tried everything, nothing helped. > No errors, logs, etc. Previous kernel somehow worked, it took me > by surprise since I though it will be a cold day in hell before I > see sound working. But I was happy nonetheless. Now the 3228 kernel > fixed it again, its no longer recognized. > Which kernel was it working in? Can you boot back into that kernel and have it work? If so will you send the dmesg from the kernel where it works and the kernel where it doesn't work, as well as lspci -n. Thanks, Josef From chris.stone at gmail.com Sat Jul 21 04:33:17 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Jul 2007 21:33:17 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070720153840.GQ22182@psilocybe.teonanacatl.org> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> Message-ID: On 7/20/07, Todd Zullinger wrote: > Christopher Stone wrote: > > Why are tons of apps setting ShowOnlyIn=GNOME; in their .desktop file? > > > > This does not bode well for KDE users. > > > > # grep -i onlyshowin /usr/share/applications/*.desktop|grep -i gnome|wc -l > > 63 > > You're not catching the kde folder with your grep there. Try it like > this and maybe your feelings will change: > > $ grep -rli 'onlyshowin=kde' /usr/share/applications/ | wc -l > 145 > > $ grep -rli 'onlyshowin=gnome' /usr/share/applications/ | wc -l > 56 Oops you are right. But I still don't understand why all these apps are classified as show only in KDE/GNOME. Surely you can run an app like kate in GNOME, or banshee in KDE. Can we please rethink this and remove some of these OnlyShowIns? From davej at redhat.com Sat Jul 21 04:55:19 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 21 Jul 2007 00:55:19 -0400 Subject: Fwd: Re: film at 11: kernel update breaks udev. Message-ID: <20070721045519.GB19314@redhat.com> Argh. So why _are_ we doing our own special rules instead of using the upstream ones ? This isn't the only time I've run into something like this with udev. Dave -- http://www.codemonkey.org.uk -------------- next part -------------- An embedded message was scrubbed... From: "Kay Sievers" Subject: Re: film at 11: kernel update breaks udev. Date: Sat, 21 Jul 2007 04:20:57 +0200 Size: 15214 URL: From dimi at lattica.com Sat Jul 21 04:59:56 2007 From: dimi at lattica.com (Dimi Paun) Date: Sat, 21 Jul 2007 00:59:56 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> Message-ID: <1184993996.3224.18.camel@dimi.lattica.com> On Sat, 2007-07-21 at 00:21 -0400, Josef Bacik wrote: > Which kernel was it working in? Can you boot back into that kernel > and have it work? I'm not even sure what kernel that was, yum seems to have gotten rid of it already. But since I run an up-to-date Fedora, that shouldn't be hard to determine. I know 3228 broke it, which kernel was before it? But beyond that, the reason I post to this list is that I feel this is a deep problem that has to be looked at. I've been using Red Hat since version 4, and the last Fedoras have been more flaky than any other. I could not, in good faith, recommend it to anyone -- they'd just start hating Linux, and feel disgusted. It seems to me that a large part of what a desktop is good for this days is: * web: Firebug stopped working for me mysteriously with no indication. Hours spent looking at the problem were just a waste of time (resolved itself a few days ago) * email: see my previous posts about the hell I went through with evolution (thing are good now in F7). * sound: completely and utterly broken for me. At least in the old days you would labour to get it to work, and then it worked. Now, it will magically start/stop working with no indication WTF it did so. * office: another nightmare, as it stopped working more than a month ago, again without indication, warning, or error. strace, google, irc#, bugzilla were of no help whatsoever. You would start an app, and it would silently exit a few seconds later. Could not generate invoices, open attachments, it was terrible. Why did it take so long to fix such an important bug? All these are showstopper bugs -- people's workflow/businesses/use of the computer depend on them, in a very fundamental way. What good is the computer to most people if the above don't work? Why are we so carelessly pushing out updates (that the user will automagically get) that breaks the above? It is the first time in the last 10 years that I really started to doubt that I can depend n my Linux box for anything important. In fact, it is the first time in that timeframe that I've actually turned to my Windows box for essential things that I have always done on Linux. Horrible. -- Dimi Paun Lattica, Inc. From rdieter at math.unl.edu Sat Jul 21 05:03:06 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 21 Jul 2007 00:03:06 -0500 Subject: Qt4 RPMs broken? References: <200707201735.40344.darth_linux@ameritech.net> <200707202343.34817.darth_linux@ameritech.net> Message-ID: eah wrote: > On Friday 20 July 2007 22:42:38 Kevin Kofler wrote: > >> > (*) doc is a link to /usr/share/doc/qt, but should point >> > to /usr/share/doc/qt4. >> >> That one sounds like a bug. Are you sure about that? It points >> to ../../share/doc/qt4 here (qt4-4.3.0-8.fc7). \ > yep, i'm sure. but i did notice that updated version is qt4-4.3.0-2.fc6. > maybe it's something that was fixed in the minor release(s) between -2 and > -8.... ? Yep: * Thu Jul 05 2007 Rex Dieter 4.3.0-8 - fix %%_qt4_prefix/doc symlink There have been a few other fixes since then too... maybe an update is in order. -- Rex From j.w.r.degoede at hhs.nl Sat Jul 21 05:24:29 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 21 Jul 2007 07:24:29 +0200 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184993996.3224.18.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> Message-ID: <46A1988D.5090705@hhs.nl> Dimi Paun wrote: > On Sat, 2007-07-21 at 00:21 -0400, Josef Bacik wrote: >> Which kernel was it working in? Can you boot back into that kernel >> and have it work? > > I'm not even sure what kernel that was, yum seems to have gotten rid > of it already. But since I run an up-to-date Fedora, that shouldn't > be hard to determine. I know 3228 broke it, which kernel was before it? > > But beyond that, the reason I post to this list is that I feel this > is a deep problem that has to be looked at. I've been using Red Hat > since version 4, and the last Fedoras have been more flaky than any > other. > As a Fedora developer I'm sorry to hear that Fedora is not working well for you. We would really like to fix this, but we need good quality input for this. As much as your sound not working may suck, sending inflametory mails to the list doesn't help much. Please file a bug against bugzilla, including which kernel worked and which didn't, and lspci -vvn on both. As for your other problems, the same goes please file bugs with as much detail as possible and reproduction instructions. Most Fedora developers are very busy, so your bugs may not get the attention they warrant, but the chance of developers keeping your mails (with incomplete description) to later take a look at the problem is 0. Thanks & Regards, Hans From rc040203 at freenet.de Sat Jul 21 05:27:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Jul 2007 07:27:54 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070720153555.GA26336@nostromo.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070720150228.GL2063@devserv.devel.redhat.com> <20070720153555.GA26336@nostromo.devel.redhat.com> Message-ID: <1184995675.5613.134.camel@mccallum.corsepiu.local> On Fri, 2007-07-20 at 11:35 -0400, Bill Nottingham wrote: > Jakub Jelinek (jakub at redhat.com) said: > > BTW, shouldn't we start changing License: tags in packages for *GPL > > packages, so that it include the exact version? > > E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later, > > LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc. > > This is currently a task for the Packaging committee to standardize. FPC several times discussed this issue. The result had been us voting against using versioned licenses, because a) we consider the License-tag to be "informative" and not to be a legal statement nor to have a legally binding effect. b) we considered it inapplicable and to introduce too much overhead/bureaucracy, because in general, there are too many "un-numbered" variations of licenses around. Ralf From sundaram at fedoraproject.org Sat Jul 21 05:28:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 21 Jul 2007 10:58:21 +0530 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184993996.3224.18.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> Message-ID: <46A19975.8000206@fedoraproject.org> Dimi Paun wrote: > All these are showstopper bugs -- people's workflow/businesses/use of > the computer depend on them, in a very fundamental way. What good is > the computer to most people if the above don't work? Why are we so > carelessly pushing out updates (that the user will automagically get) > that breaks the above? In all these rants, I didn't see any bugzilla reports. Have you filed any? Rahul From rc040203 at freenet.de Sat Jul 21 05:30:02 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Jul 2007 07:30:02 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070719184500.GC20184@nostromo.devel.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> Message-ID: <1184995803.5613.137.camel@mccallum.corsepiu.local> On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote: > The Fedora Engineering Steering Committee would like to remind maintainers > that a license change in a package is a very serious event - it has as many, > if not more, implications for related packages as ABI changes do. > > Therefore, if your package changes license, even if it just changes the > license version, it is required that you announce it, whether on this list > or fedora-devel-list. Yet more bureaucrazy. > Please contact FESCo if you have any questions. So, the new FESCo is going to act as the "Fedora License Police" Sorry, but I can't deny to consider this development unhelpful. Ralf From jspaleta at gmail.com Sat Jul 21 06:32:03 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 20 Jul 2007 22:32:03 -0800 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1184995803.5613.137.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> Message-ID: <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> On 7/20/07, Ralf Corsepius wrote: > So, the new FESCo is going to act as the "Fedora License Police" Always so negative. I'd personally like to think of it more as a Licensing Neighborhood Watch Program. The goal here is to make sure that maintainers who are depending on other packages such as libraries aren't blind-sided by a licensing change that causes some sort of licensing violation. Trust me, we don't want to have to deal with a licensing problem after the fact. Nobody wants to end up in a situation where someone has to drop the hammer and take a decisive corrective action to hot fix an existing licensing problem. We minimize the chance of such things by communicating amongst ourselves as maintainers when licensing changes occur. At the end of the day all maintainers are responsible for knowing the licensing issues surrounding the distribution and linking of the packages they maintain.. but there's an incentive for everyone to be neighborly and make sure that licensing changes for packages are being communicated to other maintainers that need to know about it before those changes enter into the common repository of software. Unless as a community we are prepared to support narrowing what we allow in to exactly one version of one license there is going to have to be an in-house pro-active effort to watch for potential problems in the license arena. If you're not happy with FESCO playing the role of 'good cop' in this affair you might be significantly less thrilled with my oscar worthy performance as 'bad cop.' -jef"I shot a baby moose standing no futher than 6 feet away from me in my yard yesterday. It shot it with a Nikon D200, through my front window..several seconds after i peed my pants from the shock of opening the window blinds to stare into the eyes of the large pony-ish form in my yard"spaleta. From dimi at lattica.com Sat Jul 21 06:32:27 2007 From: dimi at lattica.com (Dimi Paun) Date: Sat, 21 Jul 2007 02:32:27 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <46A19975.8000206@fedoraproject.org> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> <46A19975.8000206@fedoraproject.org> Message-ID: <1184999548.3224.40.camel@dimi.lattica.com> On Sat, 2007-07-21 at 10:58 +0530, Rahul Sundaram wrote: > In all these rants, I didn't see any bugzilla reports. Have you filed > any? Yes, of course I did. But if you look closely at my rants, you will see that this is not a simple bug, it's deep process problem that would get lost in a series of meaningless bugs. Take the sound problem. I did file a report. I was told to wait for the next alsa update. I did. Then it worked. Then it didn't. What would be the point of such reports if the same regression keeps coming back? I can file a few bug reports, but it's completely irrational to expect me to do the same thing over and over again at great pain for me when the same bugs keeps being reintroduced. It's a waste of time on all sides. It's a process problem, having untold number of frustrated users flood bugzilla with reports every update is not the answer. This is why I believe this is a more appropriate forum. It is -devel after all... -- Dimi Paun Lattica, Inc. From andy at smile.org.ua Sat Jul 21 06:49:37 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Sat, 21 Jul 2007 09:49:37 +0300 Subject: WTF??? ShowOnlyIn=GNOME In-Reply-To: References: Message-ID: <20070721064937.GA15731@serv.smile.org.ua> Hi Christopher Stone! On Fri, Jul 20, 2007 at 08:23:50AM -0700, Christopher Stone wrote next: > What the hell for????????? Some words about not KDE nor Gnome. This 'only show in ...' provides inconvenient behaviour in the Xfce DE. I should like to use as many as possible KDE's applications under Xfce, but can't in easy way (w/o any additional work. Now I'm running their via Alt+F2 shortkey). P.S. Is here maintainer of the Xfce packages? May be you could clearify this. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From rc040203 at freenet.de Sat Jul 21 07:36:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Jul 2007 09:36:34 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> Message-ID: <1185003394.5613.143.camel@mccallum.corsepiu.local> On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > On 7/20/07, Ralf Corsepius wrote: > > So, the new FESCo is going to act as the "Fedora License Police" > > Always so negative. Well, why should I change my opinion on something which had been repeatedly discussed to death (E.g. on FPC meetings) and which I consider to be "silly and naive"? Seems to me as if any new FESCo is going to commit the same beginner's mistakes others had been trapped into before. Ralf From buildsys at fedoraproject.org Sat Jul 21 08:45:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 Jul 2007 04:45:21 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-21 Message-ID: <20070721084522.01251152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 12 bochs-2.3-5.fc6 centericq-4.21.0-11.fc6 cfv-1.18.1-3.fc6 chmsee-1.0.0-0.22.beta2.fc6 fedora-ds-base-1.1.0-0.3.20070720.fc6 NEW fityk-0.8.1-9.fc6 : Non-linear curve fitting and data analysis perl-File-MMagic-XS-0.09002-1.fc6 perl-Taint-Runtime-0.03-1.fc6 QuantLib-0.8.1-1.fc6 seamonkey-1.0.9-2.fc6 NEW vtk-5.0.3-18.2.fc6 : The Visualization Toolkit - A high level 3D visualization library wine-0.9.41-1.fc6 Changes in Fedora Extras 6: bochs-2.3-5.fc6 --------------- * Wed Jul 18 2007 Hans de Goede 2.3-5 - Fix CVE-2007-2893 (bz 241799) centericq-4.21.0-11.fc6 ----------------------- * Thu Jul 19 2007 Andreas Bierfert - 4.21.0-11 - fix CVE-2007-3713 multiple buffer overflows (#247979) with help from Lubomir Kundrak cfv-1.18.1-3.fc6 ---------------- * Thu Jul 19 2007 Manuel Wolfshant - 1.18.1-3 - Preserve timestamps chmsee-1.0.0-0.22.beta2.fc6 --------------------------- * Sat Jul 21 2007 bbbush - 1.0.0-0.22.beta2 - fix desktop file fedora-ds-base-1.1.0-0.3.20070720.fc6 ------------------------------------- * Fri Jul 20 2007 Rich Megginson - 1.1.0-0.3.20070720 - Added Requires for perldap, cyrus sasl plugins - Removed template-migrate* files - Added perl module directory - Removed install.inf - setup-ds.pl can now easily generate one * Mon Jun 18 2007 Nathan Kinder - 1.1.0-0.2.20070320 - added requires for mozldap-tools * Tue Mar 20 2007 Rich Megginson - 1.1.0-0.1.20070320 - update to latest sources - added migrateTo11 to allow migrating instances from 1.0.x to 1.1 - ldapi support - fixed pam passthru plugin ENTRY method fityk-0.8.1-9.fc6 ----------------- * Thu Jul 19 2007 John Pye 0.8.1-9 - First import to Fedora package management system * Sun Jun 24 2007 John Pye 0.8.1-8 - Remove 'INSTALL' - Remove 'tips.txt', kepts 'fityk_tips.txt' * Sun Jun 24 2007 John Pye 0.8.1-7 - Taking suggestions from Mamoru Tasaka: - Removing unneeded install steps - Removing "LDFLAGS='-s'"; can't recall why it was there... - Fixing timestamps with 'install -p' - Remove mime-database update * Sun Jun 24 2007 John Pye 0.8.1-6 - fixing for build on Mandrive 2006 - added missing dependencies following testing on openSUSE Build Service perl-File-MMagic-XS-0.09002-1.fc6 --------------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.09002-1 - hate hate hate perl versioning perl-Taint-Runtime-0.03-1.fc6 ----------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.03-1 - bump to 0.03 QuantLib-0.8.1-1.fc6 -------------------- * Tue Jul 10 2007 Tom "spot" Callaway 0.8.1-1 - bump to 0.8.1 seamonkey-1.0.9-2.fc6 --------------------- * Fri Jul 20 2007 Kai Engert - 1.0.9-2 - Add a patch to stick with gecko version 1.8.0.12 - Update to latest snapshot of Mozilla 1.8.0 branch - Include patches for Mozilla bugs 379245, 384925, 178993, 381300 (+382686), 358594 (+380933), 382532 (+382503) vtk-5.0.3-18.2.fc6 ------------------ * Mon May 28 2007 Axel Thimm - 5.0.3-18 - Move headers to %{_includedir}/vtk. - Remove executable bit from sources. wine-0.9.41-1.fc6 ----------------- * Mon Jul 16 2007 Andreas Bierfert - 0.9.41-1 - version upgrade For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Sat Jul 21 09:37:44 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 21 Jul 2007 04:37:44 -0500 Subject: NOTE: Please publicize any license changes to your packages References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: >> On 7/20/07, Ralf Corsepius wrote: >> > So, the new FESCo is going to act as the "Fedora License Police" >> >> Always so negative. > > Well, why should I change my opinion on something which had been > repeatedly discussed to death (E.g. on FPC meetings) and which I > consider to be "silly and naive"? And that was before GPLv3 was released, mind you... -- Rex From hughsient at gmail.com Sat Jul 21 09:39:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 21 Jul 2007 10:39:19 +0100 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <20070721045519.GB19314@redhat.com> References: <20070721045519.GB19314@redhat.com> Message-ID: <1185010759.2414.16.camel@work> On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: > > Argh. So why _are_ we doing our own special rules instead > of using the upstream ones ? This isn't the only time I've > run into something like this with udev. Our udev is about 100x times slower than upstream... Richard. From fedora at leemhuis.info Sat Jul 21 11:05:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 21 Jul 2007 13:05:49 +0200 Subject: chkconfig stat level: lots of services in the 90s (was: Re: rpms/cups/devel cups.init,1.12,1.13 cups.spec,1.346,1.347) In-Reply-To: <200707201444.l6KEiiYL021289@cvs-int.fedora.redhat.com> References: <200707201444.l6KEiiYL021289@cvs-int.fedora.redhat.com> Message-ID: <46A1E88D.60201@leemhuis.info> Hi, noticed below commit and started to wonder: why do we have so many services with start-levels between 90 and 99? On my F7 machine there seems to be at least 6 services which anlone use the level 98 (see below as well) -- and lots of them start after readahead_later, which is, if I understood readahead_later correctly, not what we want. Is it time for somebody to just take a look at the mess ^w^w all the init script we ship, take a look at the interdependencies and reorder some of them and use the whole space between 0 and 99 more sanely (maybe we should track it in the wiki -- not sure)? Or is that unneeded with the "FCNewInit" stuff on the horizon? Cu thl On 20.07.2007 16:44, Tim Waugh (twaugh) wrote: > Author: twaugh > > Update of /cvs/pkgs/rpms/cups/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21269 > > Modified Files: > cups.init cups.spec > Log Message: > * Fri Jul 20 2007 Tim Waugh 1:1.3-0.b1.3 > - Change initscript start level to 98, to start after avahi but before > haldaemon. > > > > Index: cups.init > =================================================================== > RCS file: /cvs/pkgs/rpms/cups/devel/cups.init,v > retrieving revision 1.12 > retrieving revision 1.13 > diff -u -r1.12 -r1.13 > --- cups.init 12 Jun 2007 09:25:14 -0000 1.12 > +++ cups.init 20 Jul 2007 14:44:12 -0000 1.13 > @@ -6,7 +6,7 @@ > # > # Linux chkconfig stuff: > # > -# chkconfig: 2345 56 10 > +# chkconfig: 2345 98 10 > # description: Startup/shutdown script for the Common UNIX \ > # Printing System (CUPS). > # > [...] $ grep 'chkconfig:' /etc/init.d/* | awk '{print $4" -- "$1 }' | sort -n 0 -- microcode_ctl:# 4 -- readahead_early:# 05 -- kudzu:# 06 -- cpuspeed:# 08 -- ip6tables:# 08 -- iptables:# 9 -- capi:# 9 -- isdn:# 10 -- network:# 11 -- auditd:# 11 -- netplugd:# 12 -- restorecond:# 12 -- syslog:# 12 -- wpa_supplicant:# 13 -- irqbalance:# 13 -- mcstrans:# 13 -- multipathd:# 13 -- rpcbind:# 13 -- setroubleshoot:# 14 -- nfslock:# 15 -- mdmonitor:# 16 -- btseed:# 16 -- bttrack:# 18 -- rpcidmapd:# 19 -- rpcgssd:# 19 -- rpcsvcgssd:# 22 -- messagebus:# 25 -- bluetooth:# 25 -- netfs:# 25 -- pcscd:# 26 -- dund:# 26 -- hidd:# 26 -- pand:# 27 -- winbind:# 27 -- ypbind:# 28 -- autofs:# 29 -- lirc:# 30 -- nscd:# 41 -- rdisc:# 45 -- irda:# 47 -- ipsec:# 50 -- hplip:# 50 -- netconsole:# 55 -- sshd:# 56 -- cups:# 58 -- ntpd:# 60 -- nfs:# 78 -- spamassassin:# 80 -- postfix:# 85 -- gpm:# 85 -- httpd:# 87 -- alsasound:# 87 -- hsqldb:# 88 -- nasd:# 90 -- ConsoleKit:# 90 -- crond:# 90 -- psacct:# 90 -- smolt:# 90 -- xfs:# 91 -- vncserver:# 95 -- anacron:# 95 -- saslauthd:# 96 -- readahead_later:# 97 -- dhcdbd:# 97 -- yum-updatesd:# 98 -- avahi-daemon:# 98 -- avahi-dnsconfd:# 98 -- cups-config-daemon:# 98 -- haldaemon:# 98 -- NetworkManager:# 98 -- NetworkManagerDispatcher:# 99 -- firstboot:# 99 -- smartd:# From buildsys at redhat.com Sat Jul 21 11:24:38 2007 From: buildsys at redhat.com (Build System) Date: Sat, 21 Jul 2007 07:24:38 -0400 Subject: rawhide report: 20070721 changes Message-ID: <200707211124.l6LBOcLn031605@porkchop.devel.redhat.com> New package apr-api-docs Apache Portable Runtime API documentation New package perl-Callback Object interface for function callbacks New package vtk The Visualization Toolkit - A high level 3D visualization library Removed package syncekonnector Removed package lablgtk Removed package desktop-printing Updated Packages: QuantLib-0.8.1-1.fc8 -------------------- * Tue Jul 10 2007 Tom "spot" Callaway 0.8.1-1 - bump to 0.8.1 autofs-1:5.0.2-7 ---------------- * Fri Jul 20 2007 Ian Kent - 5.0.2-7 - fix handling of quoted slash alone (bz 248943). bash-3.2-12.fc8 --------------- * Fri Jul 20 2007 Tim Waugh 3.2-12 - Quote environment variables in the post scriptlet to prevent upgrade failures (bug #249005). * Thu Jul 05 2007 Tim Waugh 3.2-11 - Patchlevel 17 (bug #241647). * Wed Jul 04 2007 Tim Waugh 3.2-10 - Clarification in the ulimit man page (bug #220657). blam-1.8.3-5.fc8 ---------------- * Wed Jul 18 2007 Peter Gordon - 1.8.3-5 - Rebuild for newer Gecko libraries (Firefox 2.0.0.5) - Depend on the gecko-libs and gecko-devel virtuals, instead of querying RPM at build-time (Thanks to Chris Aillon for the fix.) - Alphabetize dependencies, and other minor aesthetic-only spec changes. chmsee-1.0.0-0.22.beta2.fc8 --------------------------- * Sat Jul 21 2007 bbbush - 1.0.0-0.22.beta2 - fix desktop file * Sun Apr 15 2007 bbbush - 1.0.0-0.17.beta2 - update to beta2 - use pkg-config to find gecko, don't use RPATH - add "auto detect charset" to option dialog for those HTML with no encoding - add popup for URL links - add "zoom in/out" button * Sat Mar 24 2007 Yijun Yuan - 1.0.0-0.12.beta - update for firefox 1.5.0.12 and 2.0.0.3 codeblocks-1.0-0.25.20070718svn4280.fc8 --------------------------------------- * Thu Jul 19 2007 Dan Horak 1.0-0.25.20070718svn4280 - update to revision 4280 - added missing ldconfig call for the contrib subpackage - fix permissions for source files cups-1:1.3-0.b1.4.fc8 --------------------- * Fri Jul 20 2007 Tim Waugh 1:1.3-0.b1.4 - Better error checking in the LSPP patch (bug #231522). * Fri Jul 20 2007 Tim Waugh 1:1.3-0.b1.3 - Change initscript start level to 98, to start after avahi but before haldaemon. - The devel sub-package requires krb5-devel. cyphesis-0.5.13-1.fc8 --------------------- * Tue Jul 17 2007 Wart 0.5.13-1 - Update to 0.5.13 deluge-0.5.2.90-1.fc8 --------------------- * Fri Jul 20 2007 Peter Gordon - 0.5.2.90-1 - Update to new upstream release candidate (0.5.3 RC1) - Drop stale persistence fix patch (applied upstream): - fix-persistence-upgrade-rhbz_247927.patch devhelp-0.15-2.fc8 ------------------ * Fri Jul 20 2007 Kai Engert - 0.15-2.fc8 - Rebuild against newer gecko eclipse-1:3.3.0-3.fc8 --------------------- * Wed Jul 18 2007 Ben Konrath 3.3.0-3 - Add links for lucene and lucene.analysis. - Remove icu4j symlink from /usr/share/eclipse/plugins. - Resolves: #248749. * Mon Jul 16 2007 Ben Konrath 3.3.0-2 - Fix dep in rcp sub-package. - Add Alpha support. - Link to commons-logging.jar - Resolves: #248359. * Fri Jun 29 2007 Ben Konrath 3.3.0-1 - 3.3. em8300-0.16.3-0.1.rc2.fc8 ------------------------- * Fri Jul 20 2007 Ville Skytt?? - 0.16.3-0.1.rc2 - 0.16.3-rc2. epiphany-2.19.5-2.fc8 --------------------- * Fri Jul 20 2007 Kai Engert - 2.19.5-2 - Rebuild against newer gecko * Tue Jul 10 2007 Matthias Clasen 2.19.5-1 - Update to 2.19.5 * Fri May 25 2007 Christopher Aillon 2.19.2-2 - Rebuild against newer gecko fedora-ds-base-1.1.0-0.3.20070720.fc8 ------------------------------------- * Fri Jul 20 2007 Rich Megginson - 1.1.0-0.3.20070720 - Added Requires for perldap, cyrus sasl plugins - Removed template-migrate* files - Added perl module directory - Removed install.inf - setup-ds.pl can now easily generate one * Mon Jun 18 2007 Nathan Kinder - 1.1.0-0.2.20070320 - added requires for mozldap-tools ghostscript-8.60-0.svn8117.2.fc8 -------------------------------- * Mon Jul 16 2007 Tim Waugh 8.60-0.r8112.2 - Own %{_libdir}/ghostscript (bug #246026). gkrellm-2.2.10-3.fc8 -------------------- * Fri Jul 20 2007 Hans de Goede 2.2.10-3 - Rebuild, including libsensors support on ppc and ppc64 as lm_sensors is available there now. * Wed Nov 08 2006 Hans de Goede 2.2.10-2 - Add special case for via 686 volt sensors (bug 213304) * Tue Oct 31 2006 Hans de Goede 2.2.10-1 - New upstream release 2.2.10 - Drop integrated lmsensors and sysfs sensors patches gnome-applet-sensors-1.8.1-2.fc8 -------------------------------- * Fri Jul 20 2007 Hans de Goede 1.8.1-2 - Rebuild, including building on ppc and ppc64 as lm_sensors is available there now (bz 181037) gnome-doc-utils-0.10.3-3.fc8 ---------------------------- * Fri Jul 20 2007 Jesse Keating - 0.10.3-3 - Don't require yelp for now gnome-python2-extras-2.19.1-3.fc8 --------------------------------- * Thu Jul 19 2007 Matthew Barnes - 2.19.1-3.fc8 - Rebuild against firefox-2.0.0.5. gtkmozembedmm-1.4.2.cvs20060817-13.fc8 -------------------------------------- * Fri Jul 20 2007 Jesse Keating - 1.4.2.cvs20060817-13 - rebuild against gecko-libs 1.8.1.5 - Extend path arch patch to ppc64 as well * Wed Mar 28 2007 Ha??kel Gu??mar - 1.4.2.cvs20060817-10 - rebuild against gecko-libs 1.8.1.3 * Wed Mar 14 2007 Ha??kel Gu??mar - 1.4.2.cvs20060817-9 - rebuild against Firefox 2.0.0.2 (gecko 1.8.1.2) hplip-2.7.6-9.fc8 ----------------- * Fri Jul 20 2007 Tim Waugh 2.7.6-9 - Remove hplip service on upgrade. - Updated selinux-policy conflict for bug #249014. - Fixed the udev rules file (bug #248740, bug #249025). jakarta-commons-el-0:1.0-8jpp.1.fc8 ----------------------------------- * Wed Jul 11 2007 Ben Konrath - 0:1.0-8jpp.1 - Add eclipse-manifest patch. From Fernando Nasser : - Specify source 1.4 due to use of enum as identifier kazehakase-0.4.7-5.fc8 ---------------------- * Mon Jun 18 2007 Mamoru Tasaka - 0.4.7-5 - Rebuild against new gecko engine kde-filesystem-3.5-9 -------------------- * Thu Jul 19 2007 Rex Dieter 3.5-9 - +%_datadir/{sounds,templates/.source,wallpapers} kdelibs-6:3.5.7-13.fc8 ---------------------- * Wed Jul 18 2007 Rex Dieter - 6:3.5.7-13 - build fails against cups-1.3 (#248717) - incorporate kdelibs3 bits (not enabled... yet) * Wed Jul 18 2007 Rex Dieter - 6:3.5.7-10 - +Requires: kde-filesystem kernel-2.6.23-0.41.rc0.git14.fc8 -------------------------------- * Fri Jul 20 2007 John W. Linville - Update git-wireless-dev.patch (rt2x00 update) * Fri Jul 20 2007 Dave Jones - 2.6.22-git14 * Thu Jul 19 2007 John W. Linville - Update git-wireless-dev.patch kernel-xen-2.6-2.6.20-2925.13.fc8 --------------------------------- * Fri Jul 20 2007 Eduardo Habkost - Update xen patch to xen 3.1.0 - Remove old network checksum patches. They should be already included in the xen patch ksensors-0.7.3-9.fc8 -------------------- * Fri Jul 20 2007 Ville Skytt?? - 0.7.3-9 - Sync Exclu(de|sive)Arch with new lm_sensors (#249060). libgnomeui-2.19.0-2.fc8 ----------------------- * Fri Jul 20 2007 Jesse Keating 0 2.19.0-2 - Don't require yelp (RH #249000) liblrdf-0.4.0-11.fc7 -------------------- * Fri Jul 20 2007 Callum Lerwick 0.4.0-11 - Bump to build on ppc64, bug #247583. liferea-1.2.20-2.fc8 -------------------- * Wed Jul 18 2007 Brian Pepple - 1.2.20-2 - Rebuild for new gecko-libs 1.8.1.5. linuxwacom-0.7.6.4-3.fc8 ------------------------ * Fri Jul 20 2007 Aristeu Rozanski 0.7.6.4-3.fc7 - adding missing dependency * Fri Jul 20 2007 Aristeu Rozanski 0.7.6.4-2.fc7 - updated udev rules (BUS -> SUBSYSTEM, SYSFS -> ATTR) (BZ#246847) * Tue Mar 27 2007 Aristeu Rozanski 0.7.6.4-1.fc7 - Update to 0.7.6-4. - add unowned directory to list (BZ#233877) - updated 60-wacom.rules with newer udev rules. man-pages-2.63-2.fc8 -------------------- * Fri Jul 20 2007 Ivana Varekova - 2.63-2 - Resolves: #248655 add getent patch (thanks Ville Skytt??) * Fri Jul 20 2007 Ivana Varekova - 2.63-1 - update to 2.63 * Tue Jun 26 2007 Ivana Varekova - 2.55-3 - remove ncsa_auth.8 maxima-5.12.0-5.fc8 ------------------- * Fri Jul 20 2007 Rex Dieter 5.12.0-5 - disable clisp/ppc, still awol (#166347) - respin for sblc-1.0.7 * Thu Jul 12 2007 Rex Dieter 5.12.0-4 - enable clisp/ppc (#166347) - revert koji hack. openhpi-2.8.1-4.fc8 ------------------- * Fri Jul 20 2007 Phil Knirsch - 2.8.1-4 - Fix for hpipower segfaulting when using -b option out of range (#247279) openldap-2.3.34-7.fc8 --------------------- * Fri Jul 20 2007 Jan Safranek 2.3.34-7.fc8 - MigrationTools-47 integrated openoffice.org-1:2.2.1-18.6.fc8 ------------------------------- * Thu Jul 19 2007 Caolan McNamara - 1:2.2.1-18.6 - FC-8 Test 1 Candidate - Resolves: rhbz#247781 openoffice.org-2.2.1.ooo79481.sw.rowordcount.patch - better page counting for titlepage dialog perl-Parse-RecDescent-1.94-6.fc8 -------------------------------- * Fri Jul 20 2007 Robin Norwood - 1.94-6.fc8 - Bring fixes from EPEL build into F8 - Fix minor specfile issues - Package the docs as well * Wed Jul 12 2006 Jesse Keating - 1.94-5.2.1 - rebuild * Fri Feb 03 2006 Jason Vas Dias - 1.94-5.2 - rebuild for new perl-5.8.8 policycoreutils-2.0.22-6.fc8 ---------------------------- * Fri Jul 20 2007 Dan Walsh 2.0.22-6 - Clean up spec file python-nose-0.10.0-0.1.a2.fc8 ----------------------------- * Wed Jun 20 2007 Luke Macken 0.10.0-0.1.a2 - 0.10.0a2 rpm-4.4.2.1-0.5.rc3 ------------------- * Fri Jul 20 2007 Panu Matilainen 4.4.2.1-0.5.rc3 - require logrotate (#248629) - allow checking for pending signals from python (#181434) - add hook to python for cleaning up on unclean exit (#245389) * Mon Jul 09 2007 Panu Matilainen 4.4.2.1-0.4.rc3 - 4.4.2.1-rc3 * Wed Jul 04 2007 Panu Matilainen 4.4.2.1-0.4.rc2 - 4.4.2.1-rc2 rsyslog-1.17.1-1.fc8 -------------------- * Fri Jul 20 2007 Peter Vrabec 1.17.1-1 - upstream bug fix release - include html docs (#248712) - make "-r" option compatible with sysklogd config (248982) sane-backends-1.0.18-9.fc8 -------------------------- * Fri Jul 20 2007 Nils Philippsen - 1.0.18-9 - don't tweak device names in device configuration files anymore (obsolete) - let udev rules cope with SUBSYSTEM=="usb" (#244444) - tweak-udev-rules patch is udev-098 patch now seahorse-1.0.1-7.fc8 -------------------- * Fri Jul 20 2007 Seth Vidal - disable gedit plugin in rawhide, for now :( * Tue Jun 26 2007 Seth Vidal - update to 1.0.1 * Sun Aug 13 2006 Seth Vidal - re-enable gedit - update to 0.8.1 selinux-policy-3.0.3-3.fc8 -------------------------- * Fri Jul 20 2007 Dan Walsh 3.0.3-3 - Allow cups to use generic usb - fix inetd to be able to run random apps (git) * Thu Jul 19 2007 Dan Walsh 3.0.3-2 - Add proper contexts for rsyslogd * Thu Jul 19 2007 Dan Walsh 3.0.3-1 - Fixes for xguest policy setools-3.2-3 ------------- * Fri Jul 20 2007 Dan Walsh 3.2-3 - Move to Tresys spec file system-config-httpd-5:1.4.4-1.fc8 --------------------------------- * Fri Jul 20 2007 Phil Knirsch 1.4.4-1 - Removed obsolete apacheconf.pot file - Fixed small bug in acinclude.m4 thunderbird-2.0.0.5-1.fc7 ------------------------- * Fri Jul 20 2007 Kai Engert - 2.0.0.5-1 - 2.0.0.5 udev-113-6.fc8 -------------- * Fri Jul 20 2007 Harald Hoyer - 113-6 - kernel does not provide usb_device anymore, corrected the rules (#248916) uncrustify-0.35-1.fc8 --------------------- xfce4-sensors-plugin-0.10.0-5.fc8 --------------------------------- * Fri Jul 20 2007 Christoph Wickert - 0.10.0-5 - Build for ppc(64) as lm_sensors is available on these architectures now. * Thu May 17 2007 Christoph Wickert - 0.10.0-4 - ExcludeArch ppc64 yelp-2.18.1-5.fc8 ----------------- * Fri Jul 20 2007 Kai Engert - 2.18.1-5 - Rebuild against newer gecko yum-3.2.2-1.fc8 --------------- * Fri Jul 20 2007 Seth Vidal - 3.2.2 - disable unused installonlyn plugin - set installonly_limit to '2' * Tue Jul 10 2007 James Bowes - 3.2.1-2 - defattr, buldarch, and macro suggestions from the merge review * Thu Jun 21 2007 Seth Vidal - 3.2.1-1 - bump to 3.2.1 Broken deps for i386 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 epiphany-extensions - 2.19.2-5.i386 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.i386 requires sysklogd kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 Democracy - 0.9.5.1-10.fc8.x86_64 requires firefox = 0:2.0.0.4 epiphany-extensions - 2.19.2-5.x86_64 requires gecko-libs = 0:1.8.1.4 epiphany-extensions - 2.19.2-5.i386 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.i386 requires sysklogd fcron - 3.0.3-1.fc8.x86_64 requires sysklogd kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc requires firefox = 0:2.0.0.4 Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 epiphany-extensions - 2.19.2-5.ppc requires gecko-libs = 0:1.8.1.4 epiphany-extensions - 2.19.2-5.ppc64 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.ppc requires sysklogd fcron - 3.0.3-1.fc8.ppc64 requires sysklogd glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 epiphany-extensions - 2.19.2-5.ppc64 requires gecko-libs = 0:1.8.1.4 fcron - 3.0.3-1.fc8.ppc64 requires sysklogd glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From fedora at camperquake.de Sat Jul 21 11:27:51 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 21 Jul 2007 13:27:51 +0200 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <1185010759.2414.16.camel@work> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> Message-ID: <20070721132751.1d062b9d@lain.camperquake.de> Moin. On Sat, 21 Jul 2007 10:39:19 +0100, Richard Hughes wrote > On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: > > > > Argh. So why _are_ we doing our own special rules instead > > of using the upstream ones ? This isn't the only time I've > > run into something like this with udev. > > Our udev is about 100x times slower than upstream... Unless I am missing something that is not a satisfactory answer :) From rc040203 at freenet.de Sat Jul 21 11:46:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 21 Jul 2007 13:46:36 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> Message-ID: <1185018397.5613.190.camel@mccallum.corsepiu.local> On Sat, 2007-07-21 at 04:37 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > >> On 7/20/07, Ralf Corsepius wrote: > >> > So, the new FESCo is going to act as the "Fedora License Police" > >> > >> Always so negative. > > > > Well, why should I change my opinion on something which had been > > repeatedly discussed to death (E.g. on FPC meetings) and which I > > consider to be "silly and naive"? > > And that was before GPLv3 was released, mind you... A fact which doesn't matter at all 1. Actually, the GPL case is a comparatively simple case, because it's widely used. The situations rendering such "license tagging" absurd are the "not so far spread" and "exotic" licenses, which * FESCO will never be able to handle due to lack of legal knowledge. * RPM's license-tag will not be able to handle without a "license tag" registry/Fedora license tag administration office. 2. Package maintainers are supposed to check their packages for license compatibility. Otherwise Fedora will need a "licensing police". 3. We did cover GPLv3 in our discussions on FPC meetings. Ralf From josef at toxicpanda.com Sat Jul 21 12:55:52 2007 From: josef at toxicpanda.com (Josef Bacik) Date: Sat, 21 Jul 2007 08:55:52 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184999548.3224.40.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> <46A19975.8000206@fedoraproject.org> <1184999548.3224.40.camel@dimi.lattica.com> Message-ID: <1b7401870707210555l67850bf0xcca04b1190d17670@mail.gmail.com> On 7/21/07, Dimi Paun wrote: > On Sat, 2007-07-21 at 10:58 +0530, Rahul Sundaram wrote: > > In all these rants, I didn't see any bugzilla reports. Have you filed > > any? > > Yes, of course I did. But if you look closely at my rants, you will see > that this is not a simple bug, it's deep process problem that would get > lost in a series of meaningless bugs. > > Take the sound problem. I did file a report. I was told to wait for the > next alsa update. I did. Then it worked. Then it didn't. What would be > the point of such reports if the same regression keeps coming back? > > I can file a few bug reports, but it's completely irrational to expect > me to do the same thing over and over again at great pain for me when > the same bugs keeps being reintroduced. It's a waste of time on all > sides. > > It's a process problem, having untold number of frustrated users flood > bugzilla with reports every update is not the answer. This is why I > believe this is a more appropriate forum. It is -devel after all... > This isn't necessarily a Fedora problem, after all the only thing we do is package up whats out there and ship it, so if things break its because upstream breaks. This is one of the drawbacks of fedora, its a moving target therefore things are likely to go a little wrong. If you are looking for serious stability you will probably want to stick with RHEL (or centos if you don't want to spend the money). Fedora is constantly evolving, and personally to me as a developer thats awesome, because it means there's always something to fix. It sounds like you just want something that works, which is a completely valid and understandable position. Unfortunately because we are constantly changing often times the response you get will be "wait until we update this package and try it again." It's helpfull to note the package versions of things when they fix your problem, so when you update to a new package and something breaks, you can report it to bugzilla with "package b worked fine, package a screws my box" and that way if there isn't an update in the pipeline, we have a decent place to start in order to give good instructions on moving forward. I'm sorry you've had such a frustrating experience with Fedora, but the fact of the matter is that we do not have the wide variety of hardware available in order to thoroughly test Fedora on every conceivable setup, that is why we have our test releases, so people can test them and file bugs and we can get things addressed before we release. I think it would be very valuable if you could run those tests, I know for a fact that the ICH8 driver is constantly changing, so you have a unique bit of hardware that would be valuable to be tested with for the upcoming release. Thank you, Josef From acbk at zeelandnet.nl Sat Jul 21 15:14:43 2007 From: acbk at zeelandnet.nl (Henk Breimer) Date: Sat, 21 Jul 2007 17:14:43 +0200 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184962398.3195.20.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> Message-ID: <20070721171443.401162c1@pietro.localdomain> On Fri, 20 Jul 2007 16:13:18 -0400 Dimi Paun wrote: > Guys, > > The sound situation is appalling: since FC6, my sounds stops/starts > working with pretty much _every_ kernel update! Don't worry, the > steady state is that it's not working. It will start working for a > short lived kernel version, but people are diligently working to > fix it back to its non-working state. > > Hardware (bog standard): > [root at dimi ~]# lspci | grep -i audio > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD > Audio Controller (rev 02) > Works here ;Intel mb,F7 [net at pietro ~]$ uname -a Linux pietro.localdomain 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [net at pietro ~]$ sudo /sbin/lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) system-config-soundcard recognizes the soundcard; music plays etc Alsa, -mixer problem? Good luck Henk From jwboyer at jdub.homelinux.org Sat Jul 21 13:54:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Jul 2007 08:54:21 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185018397.5613.190.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <1185018397.5613.190.camel@mccallum.corsepiu.local> Message-ID: <20070721085421.7b7ab064@vader.jdub.homelinux.org> On Sat, 21 Jul 2007 13:46:36 +0200 Ralf Corsepius wrote: > On Sat, 2007-07-21 at 04:37 -0500, Rex Dieter wrote: > > Ralf Corsepius wrote: > > > > > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > > >> On 7/20/07, Ralf Corsepius wrote: > > >> > So, the new FESCo is going to act as the "Fedora License > > >> > Police" > > >> > > >> Always so negative. > > > > > > Well, why should I change my opinion on something which had been > > > repeatedly discussed to death (E.g. on FPC meetings) and which I > > > consider to be "silly and naive"? > > > > And that was before GPLv3 was released, mind you... > A fact which doesn't matter at all Yes, it does. GPLv3 and GPLv2 are incompatible. We are simply trying to make sure we don't inadvertently commit a GPL violation. josh From naheemzaffar at gmail.com Sat Jul 21 14:04:49 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 21 Jul 2007 15:04:49 +0100 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> Message-ID: <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> You will have to work on a case by case basis, filing bugs where needed. Some applications would only be sane in a specific environment. As an example, Gnome should have a link to Nautilus for file management, KDE to Konqueror (or whatever they have got in KDE 4. Dolphin?). From lsof at nodata.co.uk Sat Jul 21 14:23:07 2007 From: lsof at nodata.co.uk (nodata) Date: Sat, 21 Jul 2007 16:23:07 +0200 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184999548.3224.40.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> <46A19975.8000206@fedoraproject.org> <1184999548.3224.40.camel@dimi.lattica.com> Message-ID: <1185027787.3420.0.camel@sb-home> Am Samstag, den 21.07.2007, 02:32 -0400 schrieb Dimi Paun: > On Sat, 2007-07-21 at 10:58 +0530, Rahul Sundaram wrote: > > In all these rants, I didn't see any bugzilla reports. Have you filed > > any? > > Yes, of course I did. url please. From dimi at lattica.com Sat Jul 21 14:59:37 2007 From: dimi at lattica.com (Dimi Paun) Date: Sat, 21 Jul 2007 10:59:37 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1185027787.3420.0.camel@sb-home> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> <46A19975.8000206@fedoraproject.org> <1184999548.3224.40.camel@dimi.lattica.com> <1185027787.3420.0.camel@sb-home> Message-ID: <1185029977.3224.58.camel@dimi.lattica.com> On Sat, 2007-07-21 at 16:23 +0200, nodata wrote: > url please. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216056 But what's the use? Notice how much work I put into reporting the bug properly, and what did I get? "Go try the latest ALSA" Well gee, thanks! I could have done do without the bug report! Not even a binary RPMs was provided to test (which for me is a showstopper as I keep my system strictly rpm-based). A complete waste of time that report. Not even sure what the purpose of these reports is when the canned answer we get is: * bug report # please? followed right away (after bug is filed) by: * go bother upstream, we just package this thing An infallible 1-2 that leaves the report feeling hopeless and with a distinct impression of massive time wastage. And even if I did all the work of getting latest ALSA and compiling it, and testing it, etc. what would have been the use when a week later it broke again?!? And again, and again, and again, etc ... It seemed to me that nobody really cared about working sound, so why do all the song and dance, just to have something to fill my time with? This is asking way too much from users. How much time, energy, and patience do we expect them to have? -- Dimi Paun Lattica, Inc. From chris.stone at gmail.com Sat Jul 21 16:18:00 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 21 Jul 2007 09:18:00 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> Message-ID: On 7/21/07, Naheem Zaffar wrote: > You will have to work on a case by case basis, filing bugs where needed. > > Some applications would only be sane in a specific environment. As an > example, Gnome should have a link to Nautilus for file management, KDE > to Konqueror (or whatever they have got in KDE 4. Dolphin?). I do not understand this logic. Why do we assume GNOME users will only use Nautilus, and KDE users will only use Konqueror? Is is so much a stretch of the imagination to think that a KDE user might actually want to run Nautilus (or vice versa)? From chris.stone at gmail.com Sat Jul 21 16:25:27 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 21 Jul 2007 09:25:27 -0700 Subject: WTF??? ShowOnlyIn=GNOME In-Reply-To: <20070721064937.GA15731@serv.smile.org.ua> References: <20070721064937.GA15731@serv.smile.org.ua> Message-ID: On 7/20/07, Andy Shevchenko wrote: > Hi Christopher Stone! > > On Fri, Jul 20, 2007 at 08:23:50AM -0700, Christopher Stone wrote next: > > > What the hell for????????? > Some words about not KDE nor Gnome. This 'only show in ...' provides > inconvenient behaviour in the Xfce DE. I should like to use as many as > possible KDE's applications under Xfce, but can't in easy way (w/o any > additional work. Now I'm running their via Alt+F2 shortkey). Indeed. Thanks for bringing up this very valid point. From maillinglists at lonecoder.net Sat Jul 21 16:36:37 2007 From: maillinglists at lonecoder.net (Tarek W.) Date: Sat, 21 Jul 2007 17:36:37 +0100 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> Message-ID: <9103ca1c0707210936y29990975rec489a53164da2fb@mail.gmail.com> Hi guys, On 7/21/07, Christopher Stone wrote: > On 7/21/07, Naheem Zaffar wrote: > > You will have to work on a case by case basis, filing bugs where needed. > > > > Some applications would only be sane in a specific environment. As an > > example, Gnome should have a link to Nautilus for file management, KDE > > to Konqueror (or whatever they have got in KDE 4. Dolphin?). > > I do not understand this logic. Why do we assume GNOME users will > only use Nautilus, and KDE users will only use Konqueror? > > Is is so much a stretch of the imagination to think that a KDE user > might actually want to run Nautilus (or vice versa)? I think the adopted approach is better. If I am in Gnome, launching Konqueror will run several KDE dependencies (like ARTS maybe? can't remember what exactly) and they will stay running last time I checked. If I were not a power user, I would rather be shielded from that situation and enjoy better performance. If I were a power user, I would disable showonlyin as needed. Tarek > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From a.badger at gmail.com Sat Jul 21 17:58:09 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 21 Jul 2007 10:58:09 -0700 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185018397.5613.190.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <1185018397.5613.190.camel@mccallum.corsepiu.local> Message-ID: On 7/21/07, Ralf Corsepius wrote: > On Sat, 2007-07-21 at 04:37 -0500, Rex Dieter wrote: > > Ralf Corsepius wrote: > > > > > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > > >> On 7/20/07, Ralf Corsepius wrote: > > >> > So, the new FESCo is going to act as the "Fedora License Police" > > >> > > >> Always so negative. > > > > > > Well, why should I change my opinion on something which had been > > > repeatedly discussed to death (E.g. on FPC meetings) and which I > > > consider to be "silly and naive"? > > > > And that was before GPLv3 was released, mind you... > A fact which doesn't matter at all > > > 1. Actually, the GPL case is a comparatively simple case, because it's > widely used. > > The situations rendering such "license tagging" absurd are the "not so > far spread" and "exotic" licenses, which > * FESCO will never be able to handle due to lack of legal knowledge. > * RPM's license-tag will not be able to handle without a "license tag" > registry/Fedora license tag administration office. > > 2. Package maintainers are supposed to check their packages for license > compatibility. Otherwise Fedora will need a "licensing police". > > 3. We did cover GPLv3 in our discussions on FPC meetings. I tend to agree that the problem is going to lie in the more exotic licenses. I think it would be *relatively* easy to mandate specifying GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+, (And is there an LGPLv2.1 as well?). (License proliferation, anyone?) But going further in the License tag is going to be descending into madness. I'll wait for spot's proposal before jumping the gun on what I believe to be practical. I have a question that I would like answered before the Packaging Meeting that will help clarify some things for me: Who is the target audience of this information? The FPC decided not to establish guidelines WRT License tags (other than being accurate) before because the target audience was end-users and we decided that end users should never take the license tag as authoritative. If the target audience is internal developers, then the tag remains a hint. -Toshio From nphilipp at redhat.com Sat Jul 21 19:46:11 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 21 Jul 2007 21:46:11 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> Message-ID: <1185047171.4340.7.camel@gibraltar.stuttgart.redhat.com> On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > -jef"I shot a baby moose standing no futher than 6 feet away from me > in my yard yesterday. It shot it with a Nikon D200, through my front > window..several seconds after i peed my pants from the shock of > opening the window blinds to stare into the eyes of the large pony-ish > form in my yard"spaleta. I want to see that. The baby moose that is, not Jef peeing his pants ;-). 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 nphilipp at redhat.com Sat Jul 21 19:48:59 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 21 Jul 2007 21:48:59 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1184995803.5613.137.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> Message-ID: <1185047340.4340.11.camel@gibraltar.stuttgart.redhat.com> On Sat, 2007-07-21 at 07:30 +0200, Ralf Corsepius wrote: > On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote: > > The Fedora Engineering Steering Committee would like to remind maintainers > > that a license change in a package is a very serious event - it has as many, > > if not more, implications for related packages as ABI changes do. > > > > Therefore, if your package changes license, even if it just changes the > > license version, it is required that you announce it, whether on this list > > or fedora-devel-list. > Yet more bureaucrazy. > > > Please contact FESCo if you have any questions. > So, the new FESCo is going to act as the "Fedora License Police" > > Sorry, but I can't deny to consider this development unhelpful. FESCo felt the need to codify something which should be a matter of common courtesy. I wonder why that's the case (no I don't really). I for my part find this very helpful because it works against some lib or other dependency drawn away from under my feet due to a non-announced licence change. 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 jwboyer at jdub.homelinux.org Sat Jul 21 19:52:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Jul 2007 14:52:25 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185003394.5613.143.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> Message-ID: <20070721145225.397852ff@vader.jdub.homelinux.org> On Sat, 21 Jul 2007 09:36:34 +0200 Ralf Corsepius wrote: > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > > On 7/20/07, Ralf Corsepius wrote: > > > So, the new FESCo is going to act as the "Fedora License Police" > > > > Always so negative. > > Well, why should I change my opinion on something which had been > repeatedly discussed to death (E.g. on FPC meetings) and which I > consider to be "silly and naive"? > > Seems to me as if any new FESCo is going to commit the same beginner's > mistakes others had been trapped into before. I'd like to point out this mandate came from the Board. FESCo did not start this on their own, they were told to do it. josh From jwboyer at jdub.homelinux.org Sat Jul 21 19:53:13 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Jul 2007 14:53:13 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185047340.4340.11.camel@gibraltar.stuttgart.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <1185047340.4340.11.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20070721145313.38906d47@vader.jdub.homelinux.org> On Sat, 21 Jul 2007 21:48:59 +0200 Nils Philippsen wrote: > On Sat, 2007-07-21 at 07:30 +0200, Ralf Corsepius wrote: > > On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote: > > > The Fedora Engineering Steering Committee would like to remind > > > maintainers that a license change in a package is a very serious > > > event - it has as many, if not more, implications for related > > > packages as ABI changes do. > > > > > > Therefore, if your package changes license, even if it just > > > changes the license version, it is required that you announce it, > > > whether on this list or fedora-devel-list. > > Yet more bureaucrazy. > > > > > Please contact FESCo if you have any questions. > > So, the new FESCo is going to act as the "Fedora License Police" > > > > Sorry, but I can't deny to consider this development unhelpful. > > FESCo felt the need to codify something which should be a matter of The Board felt the need. FESCo is just trying to figure out how to do that. josh From nphilipp at redhat.com Sat Jul 21 19:58:09 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 21 Jul 2007 21:58:09 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070721145313.38906d47@vader.jdub.homelinux.org> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <1185047340.4340.11.camel@gibraltar.stuttgart.redhat.com> <20070721145313.38906d47@vader.jdub.homelinux.org> Message-ID: <1185047889.4340.16.camel@gibraltar.stuttgart.redhat.com> On Sat, 2007-07-21 at 14:53 -0500, Josh Boyer wrote: > On Sat, 21 Jul 2007 21:48:59 +0200 > Nils Philippsen wrote: > > > On Sat, 2007-07-21 at 07:30 +0200, Ralf Corsepius wrote: > > > On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote: > > > > The Fedora Engineering Steering Committee would like to remind > > > > maintainers that a license change in a package is a very serious > > > > event - it has as many, if not more, implications for related > > > > packages as ABI changes do. > > > > > > > > Therefore, if your package changes license, even if it just > > > > changes the license version, it is required that you announce it, > > > > whether on this list or fedora-devel-list. > > > Yet more bureaucrazy. > > > > > > > Please contact FESCo if you have any questions. > > > So, the new FESCo is going to act as the "Fedora License Police" > > > > > > Sorry, but I can't deny to consider this development unhelpful. > > > > FESCo felt the need to codify something which should be a matter of > > The Board felt the need. FESCo is just trying to figure out how to do > that. Whoever did it ;-) felt the need to do it and I think with reason. 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 martin.sourada at seznam.cz Sat Jul 21 22:04:15 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 22 Jul 2007 00:04:15 +0200 Subject: Vacation Message-ID: <1185055455.8695.40.camel@pc-notebook> Hi, I am going on a vacation for a week. I'll return at next Sunday or sooner. I'll have no internet access there. I maintain gxine a xine-plugin packages, both without ACL, so if any problem arise, feel free to fix it. As for the Nodoka theme[1], Daniel Geiger wrote he's going to do some work on it; and I have submitted two package reviews [2][3] for that, so if there is someone interested in reviewing them I'll reply to your questions as soon as I'm back. Thanks, Martin References: [1] http://fedoraproject.org/wiki/Releases/Features/NodokaTheme [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248163 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248516 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Sat Jul 21 22:34:52 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 21 Jul 2007 23:34:52 +0100 Subject: Vacation In-Reply-To: <1185055455.8695.40.camel@pc-notebook> References: <1185055455.8695.40.camel@pc-notebook> Message-ID: <1185057292.1462.20.camel@work> (Other lists snipped) On Sun, 2007-07-22 at 00:04 +0200, Martin Sourada wrote: > I am going on a vacation for a week. Not to sound harsh, but I'm not sure this is on-topic (nor interesting) for the majority of a development mailing list. Richard. From j.w.r.degoede at hhs.nl Sat Jul 21 23:58:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 22 Jul 2007 01:58:44 +0200 Subject: Vacation In-Reply-To: <1185057292.1462.20.camel@work> References: <1185055455.8695.40.camel@pc-notebook> <1185057292.1462.20.camel@work> Message-ID: <46A29DB4.5060401@hhs.nl> Richard Hughes wrote: > (Other lists snipped) > > On Sun, 2007-07-22 at 00:04 +0200, Martin Sourada wrote: >> I am going on a vacation for a week. > > Not to sound harsh, but I'm not sure this is on-topic (nor interesting) > for the majority of a development mailing list. > Erm, he is trying to let other Fedora developers know that he will be unreachable for a while, and giving others permission to jump in and fix any grave bugs in his packages, should the need arise. How is this _not_ development related?? Regards, Hans From wart at kobold.org Sun Jul 22 00:15:49 2007 From: wart at kobold.org (Wart) Date: Sat, 21 Jul 2007 17:15:49 -0700 Subject: rsyslog is in F8 In-Reply-To: <1184767485.9488.13.camel@localhost.localdomain> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1D51.2020208@leemhuis.info> <1184767485.9488.13.camel@localhost.localdomain> Message-ID: <46A2A1B5.2080305@kobold.org> Jeremy Katz wrote: > On Wed, 2007-07-18 at 16:01 +0200, Thorsten Leemhuis wrote: >> On 18.07.2007 15:37, Jeremy Katz wrote: >>> On Wed, 2007-07-18 at 14:27 +0300, Manuel Wolfshant wrote: >>>> Peter Vrabec wrote: >>>>>> I'd say that since sysklogd is erased, rsylogd should be automatically >>>>>> enabled and started. Yes, I know the packaging recommendations, but I >>>>>> think that in this case an exception should be accepted. >>>>> I agree, but I don't know any nice and secure way we can do it. >>>> shipping an /etc/init.d/rsyslog with default options set to enabled + >>>> service rsyslog start in %post is not OK ? >>> Starting a service in %post is not in at all okay. It can cause all >>> sorts of havoc when installing systems, creating live images, init'ing >>> chroots for building in, ... >> But shouldn't it be safe to start if the daemon (or the predecessor in >> this case) was running already? That's what other scripts do iirc. > > Daemons do a condrestart in their %post, not a start. I suppose this should now be 'try-restart' to conform with the LSB specification? http://fedoraproject.org/wiki/FCNewInit/Initscripts --Wart From markg85 at gmail.com Sun Jul 22 01:04:56 2007 From: markg85 at gmail.com (Mark) Date: Sun, 22 Jul 2007 03:04:56 +0200 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1185029977.3224.58.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <1b7401870707202121n7624c26dh1e76ee2c6f27541f@mail.gmail.com> <1184993996.3224.18.camel@dimi.lattica.com> <46A19975.8000206@fedoraproject.org> <1184999548.3224.40.camel@dimi.lattica.com> <1185027787.3420.0.camel@sb-home> <1185029977.3224.58.camel@dimi.lattica.com> Message-ID: <6e24a8e80707211804m340b2c07w50be3f84893eb8c7@mail.gmail.com> [root at localhost ~]# lspci | grep Audio 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) [root at localhost ~]# I'm using the exact same audio card. no problems here except with pidgin.. i don't have audio in there but all other apps are working fine. This is the kernel that i run (latest F7 kernel): 2.6.22.1-27.fc7 All other apps are just the latest in the F7 repo. and audio was working for me on all the kernels that where in F7. 2007/7/21, Dimi Paun : > On Sat, 2007-07-21 at 16:23 +0200, nodata wrote: > > url please. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216056 > > But what's the use? Notice how much work I put into reporting > the bug properly, and what did I get? > "Go try the latest ALSA" > Well gee, thanks! I could have done do without the bug report! > Not even a binary RPMs was provided to test (which for me is a > showstopper as I keep my system strictly rpm-based). > > A complete waste of time that report. Not even sure what the > purpose of these reports is when the canned answer we get is: > * bug report # please? > followed right away (after bug is filed) by: > * go bother upstream, we just package this thing > An infallible 1-2 that leaves the report feeling hopeless and > with a distinct impression of massive time wastage. > > And even if I did all the work of getting latest ALSA and > compiling it, and testing it, etc. what would have been the > use when a week later it broke again?!? And again, and again, > and again, etc ... It seemed to me that nobody really cared > about working sound, so why do all the song and dance, just > to have something to fill my time with? > > This is asking way too much from users. How much time, energy, > and patience do we expect them to have? > > -- > Dimi Paun > Lattica, Inc. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From markg85 at gmail.com Sun Jul 22 01:16:39 2007 From: markg85 at gmail.com (Mark) Date: Sun, 22 Jul 2007 03:16:39 +0200 Subject: rawhide report: 20070721 changes In-Reply-To: <200707211124.l6LBOcLn031605@porkchop.devel.redhat.com> References: <200707211124.l6LBOcLn031605@porkchop.devel.redhat.com> Message-ID: <6e24a8e80707211816g1d2b386bu1314f3df9e387fd8@mail.gmail.com> just wondering.. Alot of packages have fc8 in there name.. Why is that? shouldn't it be f8? 2007/7/21, Build System : > New package apr-api-docs > Apache Portable Runtime API documentation > > New package perl-Callback > Object interface for function callbacks > > New package vtk > The Visualization Toolkit - A high level 3D visualization library > > > Removed package syncekonnector > > Removed package lablgtk > > Removed package desktop-printing > > Updated Packages: > > QuantLib-0.8.1-1.fc8 > -------------------- > * Tue Jul 10 2007 Tom "spot" Callaway 0.8.1-1 > - bump to 0.8.1 > > autofs-1:5.0.2-7 > ---------------- > * Fri Jul 20 2007 Ian Kent - 5.0.2-7 > - fix handling of quoted slash alone (bz 248943). > > bash-3.2-12.fc8 > --------------- > * Fri Jul 20 2007 Tim Waugh 3.2-12 > - Quote environment variables in the post scriptlet to prevent upgrade > failures (bug #249005). > > * Thu Jul 05 2007 Tim Waugh 3.2-11 > - Patchlevel 17 (bug #241647). > > * Wed Jul 04 2007 Tim Waugh 3.2-10 > - Clarification in the ulimit man page (bug #220657). > > blam-1.8.3-5.fc8 > ---------------- > * Wed Jul 18 2007 Peter Gordon - 1.8.3-5 > - Rebuild for newer Gecko libraries (Firefox 2.0.0.5) > - Depend on the gecko-libs and gecko-devel virtuals, instead of querying RPM > at build-time (Thanks to Chris Aillon for the fix.) > - Alphabetize dependencies, and other minor aesthetic-only spec changes. > > chmsee-1.0.0-0.22.beta2.fc8 > --------------------------- > * Sat Jul 21 2007 bbbush - 1.0.0-0.22.beta2 > - fix desktop file > > * Sun Apr 15 2007 bbbush - 1.0.0-0.17.beta2 > - update to beta2 > - use pkg-config to find gecko, don't use RPATH > - add "auto detect charset" to option dialog for those HTML with no encoding > - add popup for URL links > - add "zoom in/out" button > > * Sat Mar 24 2007 Yijun Yuan - 1.0.0-0.12.beta > - update for firefox 1.5.0.12 and 2.0.0.3 > > codeblocks-1.0-0.25.20070718svn4280.fc8 > --------------------------------------- > * Thu Jul 19 2007 Dan Horak 1.0-0.25.20070718svn4280 > - update to revision 4280 > - added missing ldconfig call for the contrib subpackage > - fix permissions for source files > > cups-1:1.3-0.b1.4.fc8 > --------------------- > * Fri Jul 20 2007 Tim Waugh 1:1.3-0.b1.4 > - Better error checking in the LSPP patch (bug #231522). > > * Fri Jul 20 2007 Tim Waugh 1:1.3-0.b1.3 > - Change initscript start level to 98, to start after avahi but before > haldaemon. > - The devel sub-package requires krb5-devel. > > cyphesis-0.5.13-1.fc8 > --------------------- > * Tue Jul 17 2007 Wart 0.5.13-1 > - Update to 0.5.13 > > deluge-0.5.2.90-1.fc8 > --------------------- > * Fri Jul 20 2007 Peter Gordon - 0.5.2.90-1 > - Update to new upstream release candidate (0.5.3 RC1) > - Drop stale persistence fix patch (applied upstream): > - fix-persistence-upgrade-rhbz_247927.patch > > devhelp-0.15-2.fc8 > ------------------ > * Fri Jul 20 2007 Kai Engert - 0.15-2.fc8 > - Rebuild against newer gecko > > eclipse-1:3.3.0-3.fc8 > --------------------- > * Wed Jul 18 2007 Ben Konrath 3.3.0-3 > - Add links for lucene and lucene.analysis. > - Remove icu4j symlink from /usr/share/eclipse/plugins. > - Resolves: #248749. > > * Mon Jul 16 2007 Ben Konrath 3.3.0-2 > - Fix dep in rcp sub-package. > - Add Alpha support. > - Link to commons-logging.jar > - Resolves: #248359. > > * Fri Jun 29 2007 Ben Konrath 3.3.0-1 > - 3.3. > > em8300-0.16.3-0.1.rc2.fc8 > ------------------------- > * Fri Jul 20 2007 Ville Skytt? - 0.16.3-0.1.rc2 > - 0.16.3-rc2. > > epiphany-2.19.5-2.fc8 > --------------------- > * Fri Jul 20 2007 Kai Engert - 2.19.5-2 > - Rebuild against newer gecko > > * Tue Jul 10 2007 Matthias Clasen 2.19.5-1 > - Update to 2.19.5 > > * Fri May 25 2007 Christopher Aillon 2.19.2-2 > - Rebuild against newer gecko > > fedora-ds-base-1.1.0-0.3.20070720.fc8 > ------------------------------------- > * Fri Jul 20 2007 Rich Megginson - 1.1.0-0.3.20070720 > - Added Requires for perldap, cyrus sasl plugins > - Removed template-migrate* files > - Added perl module directory > - Removed install.inf - setup-ds.pl can now easily generate one > > * Mon Jun 18 2007 Nathan Kinder - 1.1.0-0.2.20070320 > - added requires for mozldap-tools > > ghostscript-8.60-0.svn8117.2.fc8 > -------------------------------- > * Mon Jul 16 2007 Tim Waugh 8.60-0.r8112.2 > - Own %{_libdir}/ghostscript (bug #246026). > > gkrellm-2.2.10-3.fc8 > -------------------- > * Fri Jul 20 2007 Hans de Goede 2.2.10-3 > - Rebuild, including libsensors support on ppc and ppc64 as lm_sensors is > available there now. > > * Wed Nov 08 2006 Hans de Goede 2.2.10-2 > - Add special case for via 686 volt sensors (bug 213304) > > * Tue Oct 31 2006 Hans de Goede 2.2.10-1 > - New upstream release 2.2.10 > - Drop integrated lmsensors and sysfs sensors patches > > gnome-applet-sensors-1.8.1-2.fc8 > -------------------------------- > * Fri Jul 20 2007 Hans de Goede 1.8.1-2 > - Rebuild, including building on ppc and ppc64 as lm_sensors is available > there now (bz 181037) > > gnome-doc-utils-0.10.3-3.fc8 > ---------------------------- > * Fri Jul 20 2007 Jesse Keating - 0.10.3-3 > - Don't require yelp for now > > gnome-python2-extras-2.19.1-3.fc8 > --------------------------------- > * Thu Jul 19 2007 Matthew Barnes - 2.19.1-3.fc8 > - Rebuild against firefox-2.0.0.5. > > gtkmozembedmm-1.4.2.cvs20060817-13.fc8 > -------------------------------------- > * Fri Jul 20 2007 Jesse Keating - 1.4.2.cvs20060817-13 > - rebuild against gecko-libs 1.8.1.5 > - Extend path arch patch to ppc64 as well > > * Wed Mar 28 2007 Ha?kel Gu?mar - 1.4.2.cvs20060817-10 > - rebuild against gecko-libs 1.8.1.3 > > * Wed Mar 14 2007 Ha?kel Gu?mar - 1.4.2.cvs20060817-9 > - rebuild against Firefox 2.0.0.2 (gecko 1.8.1.2) > > hplip-2.7.6-9.fc8 > ----------------- > * Fri Jul 20 2007 Tim Waugh 2.7.6-9 > - Remove hplip service on upgrade. > - Updated selinux-policy conflict for bug #249014. > - Fixed the udev rules file (bug #248740, bug #249025). > > jakarta-commons-el-0:1.0-8jpp.1.fc8 > ----------------------------------- > * Wed Jul 11 2007 Ben Konrath - 0:1.0-8jpp.1 > - Add eclipse-manifest patch. > From Fernando Nasser : > - Specify source 1.4 due to use of enum as identifier > > kazehakase-0.4.7-5.fc8 > ---------------------- > * Mon Jun 18 2007 Mamoru Tasaka - 0.4.7-5 > - Rebuild against new gecko engine > > kde-filesystem-3.5-9 > -------------------- > * Thu Jul 19 2007 Rex Dieter 3.5-9 > - +%_datadir/{sounds,templates/.source,wallpapers} > > kdelibs-6:3.5.7-13.fc8 > ---------------------- > * Wed Jul 18 2007 Rex Dieter - 6:3.5.7-13 > - build fails against cups-1.3 (#248717) > - incorporate kdelibs3 bits (not enabled... yet) > > * Wed Jul 18 2007 Rex Dieter - 6:3.5.7-10 > - +Requires: kde-filesystem > > kernel-2.6.23-0.41.rc0.git14.fc8 > -------------------------------- > * Fri Jul 20 2007 John W. Linville > - Update git-wireless-dev.patch (rt2x00 update) > > * Fri Jul 20 2007 Dave Jones > - 2.6.22-git14 > > * Thu Jul 19 2007 John W. Linville > - Update git-wireless-dev.patch > > kernel-xen-2.6-2.6.20-2925.13.fc8 > --------------------------------- > * Fri Jul 20 2007 Eduardo Habkost > - Update xen patch to xen 3.1.0 > - Remove old network checksum patches. They should be > already included in the xen patch > > ksensors-0.7.3-9.fc8 > -------------------- > * Fri Jul 20 2007 Ville Skytt? - 0.7.3-9 > - Sync Exclu(de|sive)Arch with new lm_sensors (#249060). > > libgnomeui-2.19.0-2.fc8 > ----------------------- > * Fri Jul 20 2007 Jesse Keating 0 2.19.0-2 > - Don't require yelp (RH #249000) > > liblrdf-0.4.0-11.fc7 > -------------------- > * Fri Jul 20 2007 Callum Lerwick 0.4.0-11 > - Bump to build on ppc64, bug #247583. > > liferea-1.2.20-2.fc8 > -------------------- > * Wed Jul 18 2007 Brian Pepple - 1.2.20-2 > - Rebuild for new gecko-libs 1.8.1.5. > > linuxwacom-0.7.6.4-3.fc8 > ------------------------ > * Fri Jul 20 2007 Aristeu Rozanski 0.7.6.4-3.fc7 > - adding missing dependency > > * Fri Jul 20 2007 Aristeu Rozanski 0.7.6.4-2.fc7 > - updated udev rules (BUS -> SUBSYSTEM, SYSFS -> ATTR) (BZ#246847) > > * Tue Mar 27 2007 Aristeu Rozanski 0.7.6.4-1.fc7 > - Update to 0.7.6-4. > - add unowned directory to list (BZ#233877) > - updated 60-wacom.rules with newer udev rules. > > man-pages-2.63-2.fc8 > -------------------- > * Fri Jul 20 2007 Ivana Varekova - 2.63-2 > - Resolves: #248655 > add getent patch (thanks Ville Skytt?) > > * Fri Jul 20 2007 Ivana Varekova - 2.63-1 > - update to 2.63 > > * Tue Jun 26 2007 Ivana Varekova - 2.55-3 > - remove ncsa_auth.8 > > maxima-5.12.0-5.fc8 > ------------------- > * Fri Jul 20 2007 Rex Dieter 5.12.0-5 > - disable clisp/ppc, still awol (#166347) > - respin for sblc-1.0.7 > > * Thu Jul 12 2007 Rex Dieter 5.12.0-4 > - enable clisp/ppc (#166347) > - revert koji hack. > > openhpi-2.8.1-4.fc8 > ------------------- > * Fri Jul 20 2007 Phil Knirsch - 2.8.1-4 > - Fix for hpipower segfaulting when using -b option out of range (#247279) > > openldap-2.3.34-7.fc8 > --------------------- > * Fri Jul 20 2007 Jan Safranek 2.3.34-7.fc8 > - MigrationTools-47 integrated > > openoffice.org-1:2.2.1-18.6.fc8 > ------------------------------- > * Thu Jul 19 2007 Caolan McNamara - 1:2.2.1-18.6 > - FC-8 Test 1 Candidate > - Resolves: rhbz#247781 openoffice.org-2.2.1.ooo79481.sw.rowordcount.patch > - better page counting for titlepage dialog > > perl-Parse-RecDescent-1.94-6.fc8 > -------------------------------- > * Fri Jul 20 2007 Robin Norwood - 1.94-6.fc8 > - Bring fixes from EPEL build into F8 > - Fix minor specfile issues > - Package the docs as well > > * Wed Jul 12 2006 Jesse Keating - 1.94-5.2.1 > - rebuild > > * Fri Feb 03 2006 Jason Vas Dias - 1.94-5.2 > - rebuild for new perl-5.8.8 > > policycoreutils-2.0.22-6.fc8 > ---------------------------- > * Fri Jul 20 2007 Dan Walsh 2.0.22-6 > - Clean up spec file > > python-nose-0.10.0-0.1.a2.fc8 > ----------------------------- > * Wed Jun 20 2007 Luke Macken 0.10.0-0.1.a2 > - 0.10.0a2 > > rpm-4.4.2.1-0.5.rc3 > ------------------- > * Fri Jul 20 2007 Panu Matilainen 4.4.2.1-0.5.rc3 > - require logrotate (#248629) > - allow checking for pending signals from python (#181434) > - add hook to python for cleaning up on unclean exit (#245389) > > * Mon Jul 09 2007 Panu Matilainen 4.4.2.1-0.4.rc3 > - 4.4.2.1-rc3 > > * Wed Jul 04 2007 Panu Matilainen 4.4.2.1-0.4.rc2 > - 4.4.2.1-rc2 > > rsyslog-1.17.1-1.fc8 > -------------------- > * Fri Jul 20 2007 Peter Vrabec 1.17.1-1 > - upstream bug fix release > - include html docs (#248712) > - make "-r" option compatible with sysklogd config (248982) > > sane-backends-1.0.18-9.fc8 > -------------------------- > * Fri Jul 20 2007 Nils Philippsen - 1.0.18-9 > - don't tweak device names in device configuration files anymore (obsolete) > - let udev rules cope with SUBSYSTEM=="usb" (#244444) > - tweak-udev-rules patch is udev-098 patch now > > seahorse-1.0.1-7.fc8 > -------------------- > * Fri Jul 20 2007 Seth Vidal > - disable gedit plugin in rawhide, for now :( > > * Tue Jun 26 2007 Seth Vidal > - update to 1.0.1 > > * Sun Aug 13 2006 Seth Vidal > - re-enable gedit > - update to 0.8.1 > > selinux-policy-3.0.3-3.fc8 > -------------------------- > * Fri Jul 20 2007 Dan Walsh 3.0.3-3 > - Allow cups to use generic usb > - fix inetd to be able to run random apps (git) > > * Thu Jul 19 2007 Dan Walsh 3.0.3-2 > - Add proper contexts for rsyslogd > > * Thu Jul 19 2007 Dan Walsh 3.0.3-1 > - Fixes for xguest policy > > setools-3.2-3 > ------------- > * Fri Jul 20 2007 Dan Walsh 3.2-3 > - Move to Tresys spec file > > system-config-httpd-5:1.4.4-1.fc8 > --------------------------------- > * Fri Jul 20 2007 Phil Knirsch 1.4.4-1 > - Removed obsolete apacheconf.pot file > - Fixed small bug in acinclude.m4 > > thunderbird-2.0.0.5-1.fc7 > ------------------------- > * Fri Jul 20 2007 Kai Engert - 2.0.0.5-1 > - 2.0.0.5 > > udev-113-6.fc8 > -------------- > * Fri Jul 20 2007 Harald Hoyer - 113-6 > - kernel does not provide usb_device anymore, > corrected the rules (#248916) > > uncrustify-0.35-1.fc8 > --------------------- > > xfce4-sensors-plugin-0.10.0-5.fc8 > --------------------------------- > * Fri Jul 20 2007 Christoph Wickert - 0.10.0-5 > - Build for ppc(64) as lm_sensors is available on these architectures now. > > * Thu May 17 2007 Christoph Wickert - 0.10.0-4 > - ExcludeArch ppc64 > > yelp-2.18.1-5.fc8 > ----------------- > * Fri Jul 20 2007 Kai Engert - 2.18.1-5 > - Rebuild against newer gecko > > yum-3.2.2-1.fc8 > --------------- > * Fri Jul 20 2007 Seth Vidal > - 3.2.2 > - disable unused installonlyn plugin > - set installonly_limit to '2' > > * Tue Jul 10 2007 James Bowes - 3.2.1-2 > - defattr, buldarch, and macro suggestions from the merge review > > * Thu Jun 21 2007 Seth Vidal - 3.2.1-1 > - bump to 3.2.1 > > Broken deps for i386 > ---------------------------------------------------------- > Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 > epiphany-extensions - 2.19.2-5.i386 requires gecko-libs = 0:1.8.1.4 > fcron - 3.0.3-1.fc8.i386 requires sysklogd > kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 > kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 > kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE > openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > osgal - 20060903-3.fc7.i386 requires libosg.so.1 > osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 > tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 > vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 > vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 > xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 > > > > Broken deps for x86_64 > ---------------------------------------------------------- > Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 > Democracy - 0.9.5.1-10.fc8.x86_64 requires firefox = 0:2.0.0.4 > epiphany-extensions - 2.19.2-5.x86_64 requires gecko-libs = 0:1.8.1.4 > epiphany-extensions - 2.19.2-5.i386 requires gecko-libs = 0:1.8.1.4 > fcron - 3.0.3-1.fc8.i386 requires sysklogd > fcron - 3.0.3-1.fc8.x86_64 requires sysklogd > kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.x86_64 requires kernel-x86_64 = 0:2.6.22-8.fc8 > kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8 > kmod-em8300-PAE - 0.16.3-0.1.rc1.2.6.22_8.fc8.i686 requires kernel-i686 = 0:2.6.22-8.fc8PAE > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 > kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 > kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE > kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump > openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) > openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) > osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) > osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 > osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 > osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 > osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 > osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 > osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 > osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.i386 requires libosgText.so.1 > osgal - 20060903-3.fc7.i386 requires libosg.so.1 > osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 > osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) > osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) > ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 > ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 > tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) > tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 > vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 > vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 > vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 > vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 > xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 > xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) > > > > Broken deps for ppc > ---------------------------------------------------------- > Democracy - 0.9.5.1-10.fc8.ppc requires firefox = 0:2.0.0.4 > Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 > epiphany-extensions - 2.19.2-5.ppc requires gecko-libs = 0:1.8.1.4 > epiphany-extensions - 2.19.2-5.ppc64 requires gecko-libs = 0:1.8.1.4 > fcron - 3.0.3-1.fc8.ppc requires sysklogd > fcron - 3.0.3-1.fc8.ppc64 requires sysklogd > glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 > kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 > kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8 > kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump > kmod-em8300-smp - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc requires kernel-ppc = 0:2.6.22-8.fc8smp > openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 > osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 > osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 > osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 > osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 > osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 > osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 > osgal - 20060903-3.fc7.ppc requires libosgText.so.1 > osgal - 20060903-3.fc7.ppc requires libosg.so.1 > osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 > osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 > ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 > ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 > tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 > tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) > vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 > vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 > vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 > vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 > xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 > > > > Broken deps for ppc64 > ---------------------------------------------------------- > Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 > epiphany-extensions - 2.19.2-5.ppc64 requires gecko-libs = 0:1.8.1.4 > fcron - 3.0.3-1.fc8.ppc64 requires sysklogd > glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 > kmod-em8300 - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8 > kmod-em8300-kdump - 0.16.3-0.1.rc1.2.6.22_8.fc8.ppc64 requires kernel-ppc64 = 0:2.6.22-8.fc8kdump > python-vcpx - 0.9.28-3.fc8.noarch requires darcs > resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display > ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 > tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) > vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 > vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jwboyer at jdub.homelinux.org Sun Jul 22 01:41:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Jul 2007 20:41:16 -0500 Subject: Vacation In-Reply-To: <1185057292.1462.20.camel@work> References: <1185055455.8695.40.camel@pc-notebook> <1185057292.1462.20.camel@work> Message-ID: <20070721204116.15ee7ed0@vader.jdub.homelinux.org> On Sat, 21 Jul 2007 23:34:52 +0100 Richard Hughes wrote: > (Other lists snipped) > > On Sun, 2007-07-22 at 00:04 +0200, Martin Sourada wrote: > > I am going on a vacation for a week. > > Not to sound harsh, but I'm not sure this is on-topic (nor > interesting) for the majority of a development mailing list. It is. He's telling us that he'll be gone and we can fix bugs if they show up. josh From jwboyer at jdub.homelinux.org Sun Jul 22 01:42:44 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 21 Jul 2007 20:42:44 -0500 Subject: rawhide report: 20070721 changes In-Reply-To: <6e24a8e80707211816g1d2b386bu1314f3df9e387fd8@mail.gmail.com> References: <200707211124.l6LBOcLn031605@porkchop.devel.redhat.com> <6e24a8e80707211816g1d2b386bu1314f3df9e387fd8@mail.gmail.com> Message-ID: <20070721204244.615a8355@vader.jdub.homelinux.org> On Sun, 22 Jul 2007 03:16:39 +0200 Mark wrote: > just wondering.. Alot of packages have fc8 in there name.. Why is > that? shouldn't it be f8? No. This has been asked a lot. It stands for "fedora collection" now. josh From seg at haxxed.com Sun Jul 22 03:35:50 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 21 Jul 2007 22:35:50 -0500 Subject: kernel-2.6.22.1-27.fc7.x86_64 won't boot on eMachines m6805 / Arima W720-K8 Message-ID: <1185075350.25858.122.camel@localhost.localdomain> Anyone else got an eMachines m68xx, aka Arima W720-K8? Kernel 2.6.22.1-27.fc7.x86_64 just goes into an endless reboot loop on mine. Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Jul 22 06:44:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Jul 2007 08:44:10 +0200 Subject: Vacation In-Reply-To: <20070721204116.15ee7ed0@vader.jdub.homelinux.org> References: <1185055455.8695.40.camel@pc-notebook> <1185057292.1462.20.camel@work> <20070721204116.15ee7ed0@vader.jdub.homelinux.org> Message-ID: <46A2FCBA.1030403@leemhuis.info> On 22.07.2007 03:41, Josh Boyer wrote: > On Sat, 21 Jul 2007 23:34:52 +0100 > Richard Hughes wrote: >> (Other lists snipped) >> On Sun, 2007-07-22 at 00:04 +0200, Martin Sourada wrote: >>> I am going on a vacation for a week. Have a nice vacation Martin! And please don't take the rest of the mail personal, I just try to outline a general problem. You did nothing wrong. >> Not to sound harsh, but I'm not sure this is on-topic (nor >> interesting) for the majority of a development mailing list. > It is. He's telling us that he'll be gone and we can fix bugs if they > show up. Well, we currently have 432 members in cvs extras afaics -- let's that each of them on average is about 2 times a year away for longer time periods (some more, some less). That would mean if each of them would write such a mail we'd get two to three each day. Would that be a big help? I don't think so as one quickly would get lost in the noise. Even now those mails are IMHO not a big help if there is nobody watching bugzilla for the one that's on vacation. The much better solution IMHO would be to encourage co-maintainership more, to make sure each package has at least two owners (or better three or more in case of important packages). Then somebody that heads for vacation can send all his comaintainers a mail "I'm afk from foo to bar" and they can handle quickly if a new important bug hits bugzilla (which currently likely nobody would notice). Just my 2 cent. CU knurd P.S.: Yes, there was the plan to encourage comaintainership more after the comaintainership policy was ratified by FESCo months ago; but we wanted to wait for the PackageDB, which is still not in place... From rc040203 at freenet.de Sun Jul 22 06:58:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 22 Jul 2007 08:58:19 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <1185018397.5613.190.camel@mccallum.corsepiu.local> Message-ID: <1185087500.10535.22.camel@mccallum.corsepiu.local> On Sat, 2007-07-21 at 10:58 -0700, Toshio Kuratomi wrote: > On 7/21/07, Ralf Corsepius wrote: > > On Sat, 2007-07-21 at 04:37 -0500, Rex Dieter wrote: > > > Ralf Corsepius wrote: > > > > > > > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > > > >> On 7/20/07, Ralf Corsepius wrote: > > > >> > So, the new FESCo is going to act as the "Fedora License Police" > > > >> > > > >> Always so negative. > > > > > > > > Well, why should I change my opinion on something which had been > > > > repeatedly discussed to death (E.g. on FPC meetings) and which I > > > > consider to be "silly and naive"? > > > > > > And that was before GPLv3 was released, mind you... > > A fact which doesn't matter at all > > > > > > 1. Actually, the GPL case is a comparatively simple case, because it's > > widely used. > > > > The situations rendering such "license tagging" absurd are the "not so > > far spread" and "exotic" licenses, which > > * FESCO will never be able to handle due to lack of legal knowledge. > > * RPM's license-tag will not be able to handle without a "license tag" > > registry/Fedora license tag administration office. > > > > 2. Package maintainers are supposed to check their packages for license > > compatibility. Otherwise Fedora will need a "licensing police". > > > > 3. We did cover GPLv3 in our discussions on FPC meetings. > > I tend to agree that the problem is going to lie in the more exotic > licenses. I think it would be *relatively* easy to mandate specifying > GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+, (And > is there an LGPLv2.1 as well?). ... and these are by far not all variants of the [L]GPLv2 ;) Consider e.g. the "GPLv2 w/ " and the "dual licensed cases". Also consider the impact on backporting patches against GPLv3'd versions of a package to their GPLv2(+) predecessors. E.g. the GCC project currently is discussing the legal impact of back-porting upstream (==GPLv3) changes to older releases (e.g. gcc-4.2) and/or vendor forks/branches (such as Apple's GCC or RH's). Also, though the FSF has a GPL* compatibility matrix, they don't provide much help for other licenses' compatibility. I.e. at least I consider the implications of GPLv3'd run-time packages on packages being licensed differently to be widely unclear at this point in time. To put it differently: To which extend is the old "GPL* vs. free-license compatibility list" still valid? > (License proliferation, anyone?) But > going further in the License tag is going to be descending into > madness. That's what I wanted to express - There lies madness and insanity inside of the license tagging. > I'll wait for spot's proposal before jumping the gun on what > I believe to be practical. IMO, it needs to be a copyright-specialized lawyer to be able to clarify the situation. Neither the FPC, FAB nor FESCo are able to handle such situations. > I have a question that I would like answered before the Packaging > Meeting that will help clarify some things for me: Who is the target > audience of this information? The FPC decided not to establish > guidelines WRT License tags (other than being accurate) before because > the target audience was end-users and we decided that end users should > never take the license tag as authoritative. If the target audience > is internal developers, then the tag remains a hint. IMO, the rpm license tag is both: informative to end-users and a hint to developers. Active developers will have to carefully check a package "they use" or "derive their works from" in any case. Ralf From frank-buettner at gmx.net Sun Jul 22 07:11:08 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 22 Jul 2007 09:11:08 +0200 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry Message-ID: <46A3030C.3020401@gmx.net> Where can I find some more infos how to add an new gid to http://fedoraproject.org/wiki/PackageUserRegistry ? Thanks Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Sun Jul 22 07:20:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 12:50:58 +0530 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry In-Reply-To: <46A3030C.3020401@gmx.net> References: <46A3030C.3020401@gmx.net> Message-ID: <46A3055A.5020007@fedoraproject.org> Frank B?ttner wrote: > Where can I find some more infos how to add an new gid to > http://fedoraproject.org/wiki/PackageUserRegistry ? > http://fedoraproject.org/wiki/PackageUserCreation linked from the wiki page. Rahul From frank-buettner at gmx.net Sun Jul 22 07:29:00 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 22 Jul 2007 09:29:00 +0200 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry In-Reply-To: <46A3055A.5020007@fedoraproject.org> References: <46A3030C.3020401@gmx.net> <46A3055A.5020007@fedoraproject.org> Message-ID: <46A3073C.5030202@gmx.net> Rahul Sundaram schrieb: > Frank B?ttner wrote: >> Where can I find some more infos how to add an new gid to >> http://fedoraproject.org/wiki/PackageUserRegistry ? >> > > http://fedoraproject.org/wiki/PackageUserCreation linked from the wiki > page. > > Rahul > This have I found to, but it only describe how to add this feature to an spec file. And not how to add the entry to this list. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From sundaram at fedoraproject.org Sun Jul 22 07:51:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 13:21:10 +0530 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry In-Reply-To: <46A3073C.5030202@gmx.net> References: <46A3030C.3020401@gmx.net> <46A3055A.5020007@fedoraproject.org> <46A3073C.5030202@gmx.net> Message-ID: <46A30C6E.2010300@fedoraproject.org> Frank B?ttner wrote: > Rahul Sundaram schrieb: >> Frank B?ttner wrote: >>> Where can I find some more infos how to add an new gid to >>> http://fedoraproject.org/wiki/PackageUserRegistry ? >>> >> http://fedoraproject.org/wiki/PackageUserCreation linked from the wiki >> page. >> >> Rahul >> > > This have I found to, but it only describe how to add this feature to an > spec file. And not how to add the entry to this list. Just edit the wiki page? or did I not understand the question? Rahul From frank-buettner at gmx.net Sun Jul 22 08:02:05 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 22 Jul 2007 10:02:05 +0200 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry In-Reply-To: <46A30C6E.2010300@fedoraproject.org> References: <46A3030C.3020401@gmx.net> <46A3055A.5020007@fedoraproject.org> <46A3073C.5030202@gmx.net> <46A30C6E.2010300@fedoraproject.org> Message-ID: <46A30EFD.3040207@gmx.net> Rahul Sundaram schrieb: > Frank B?ttner wrote: >> Rahul Sundaram schrieb: >>> Frank B?ttner wrote: >>>> Where can I find some more infos how to add an new gid to >>>> http://fedoraproject.org/wiki/PackageUserRegistry ? >>>> >>> http://fedoraproject.org/wiki/PackageUserCreation linked from the wiki >>> page. >>> >>> Rahul >>> >> >> This have I found to, but it only describe how to add this feature to an >> spec file. And not how to add the entry to this list. > > Just edit the wiki page? or did I not understand the question? > > Rahul > I can do it, but I thing there will be another mechanism to do this. Or must I only simple modify the wiki page? Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Sun Jul 22 08:04:24 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Jul 2007 11:04:24 +0300 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry In-Reply-To: <46A3030C.3020401@gmx.net> References: <46A3030C.3020401@gmx.net> Message-ID: <200707221104.24629.ville.skytta@iki.fi> On Sunday 22 July 2007, Frank B?ttner wrote: > Where can I find some more infos how to add an new gid to > http://fedoraproject.org/wiki/PackageUserRegistry ? By the way, this particular case requires someone familiar with LDAP/NIS to have a look at the justification for the static gid. The discussion is at https://bugzilla.redhat.com/220767 and I'm having trouble believing that a static gid would be actually needed in this case. From sundaram at fedoraproject.org Sun Jul 22 08:20:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 13:50:10 +0530 Subject: how to add an an gid to http://fedoraproject.org/wiki/PackageUserRegistry In-Reply-To: <46A30EFD.3040207@gmx.net> References: <46A3030C.3020401@gmx.net> <46A3055A.5020007@fedoraproject.org> <46A3073C.5030202@gmx.net> <46A30C6E.2010300@fedoraproject.org> <46A30EFD.3040207@gmx.net> Message-ID: <46A3133A.2080706@fedoraproject.org> Frank B?ttner wrote: > Rahul Sundaram schrieb: >> Frank B?ttner wrote: >>> Rahul Sundaram schrieb: >>>> Frank B?ttner wrote: >>>>> Where can I find some more infos how to add an new gid to >>>>> http://fedoraproject.org/wiki/PackageUserRegistry ? >>>>> >>>> http://fedoraproject.org/wiki/PackageUserCreation linked from the wiki >>>> page. >>>> >>>> Rahul >>>> >>> This have I found to, but it only describe how to add this feature to an >>> spec file. And not how to add the entry to this list. >> Just edit the wiki page? or did I not understand the question? >> >> Rahul >> > > I can do it, but I thing there will be another mechanism to do this. > Or must I only simple modify the wiki page? Afaik, yes. Rahul From aph at redhat.com Sun Jul 22 09:14:29 2007 From: aph at redhat.com (Andrew Haley) Date: Sun, 22 Jul 2007 10:14:29 +0100 Subject: Vacation In-Reply-To: <46A29DB4.5060401@hhs.nl> References: <1185055455.8695.40.camel@pc-notebook> <1185057292.1462.20.camel@work> <46A29DB4.5060401@hhs.nl> Message-ID: <18083.8181.856663.332684@zebedee.pink> Hans de Goede writes: > Richard Hughes wrote: > > (Other lists snipped) > > > > On Sun, 2007-07-22 at 00:04 +0200, Martin Sourada wrote: > >> I am going on a vacation for a week. > > > > Not to sound harsh, but I'm not sure this is on-topic (nor interesting) > > for the majority of a development mailing list. > > > > Erm, he is trying to let other Fedora developers know that he will be > unreachable for a while, and giving others permission to jump in and fix any > grave bugs in his packages, should the need arise. > > How is this _not_ development related?? It may be develoopment related, but that's not the point. It doesn't scale. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From buildsys at redhat.com Sun Jul 22 10:22:20 2007 From: buildsys at redhat.com (Build System) Date: Sun, 22 Jul 2007 06:22:20 -0400 Subject: rawhide report: 20070722 changes Message-ID: <200707221022.l6MAMKAU019279@porkchop.devel.redhat.com> New package pwsafe A unix commandline program that manages encrypted password databases Updated Packages: anjuta-1:2.2.0-2.fc8 -------------------- * Sat Jul 21 2007 Matej Cepl - 1:2.2.0-2 - Exclude architecutre ppc64 * Fri Jul 20 2007 Matej Cepl - 1:2.2.0-1 - fix unnecessary /usr/share/doc/anjuta and its content and %doc * Fri Jul 20 2007 Matej Cepl - 1:2.2.0-0.1 - Scratch build of new upstream version. bluez-hcidump-1.37-1.fc8 ------------------------ * Sat Jul 21 2007 David Woodhouse - 1.37-1 - update to bluez-hcidump 1.37 bluez-libs-3.12-1.fc8 --------------------- * Sat Jul 21 2007 David Woodhouse - 3.12-1 - Update to bluez-libs 3.12 * Sat May 26 2007 Bastien Nocera - 3.11-1 - Update to bluez-libs 3.11 * Tue Jan 30 2007 David Woodhouse 3.9-1 - Update to bluez-libs 3.9 bluez-utils-3.12-1.fc8 ---------------------- * Sat Jul 21 2007 David Woodhouse 3.12-1 - Update to bluez-utils 3.12 - Fix reference dev-up script in pand.1 (#213984) - Include API docs (#241480) * Fri Jun 01 2007 Bastien Nocera - 3.11-2 - Add upstream patch to list discovered printer devices in the CUPS backend * Sat May 26 2007 Bastien Nocera - 3.11-1 - Update to bluez-utils 3.11 - Move the cups backend to its expected location (#237482) - Remove merged input patch - Make sure the echo, input and serial services are installed cairomm-1.4.2-1.fc8 ------------------- * Fri Jul 20 2007 Rick L Vinyard Jr - 1.4.2-1 - New upstream release - Changed install to preserve timestamps - Removed mv of docs/reference and include files directly ctapi-common-1.1-1.fc8 ---------------------- * Sat Jul 21 2007 Frank B??ttner - 1.1-1 - set version to 1.1 so that other packages can require it * Sat Jul 21 2007 Frank B??ttner - 1.0-5 - fix for #220767 all users that will use card readers must be in the new group cardusers. ctapi-cyberjack-3.0.2-2.fc8 --------------------------- * Sat Jul 21 2007 Frank B??ttner - 3.0.2-2 - fix the old "only root can use the reader" problem * Sat Jul 21 2007 Frank B??ttner - 3.0.2-1 - update to 3.0.2 * Sat Jun 23 2007 Frank B??ttner - 3.0.0-3.fc8 - disable PC/SC part for EL4 em8300-kmod-0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8 ---------------------------------------------------- * Sat Jul 21 2007 Ville Skytt?? - 0.16.3-0.6.rc2 - Restore ExclusiveArch, build for kernel 2.6.23-0.41.rc0.git14.fc8. * Sat Jul 21 2007 Ville Skytt?? - 0.16.3-0.5.rc2 - 0.16.3-rc2. - Test build without ExclusiveArch for kernel 2.6.23-0.35.rc0.git6.fc8. epiphany-extensions-2.19.5-1 ---------------------------- * Sat Jul 21 2007 Peter Gordon - 2.19.5-1 - Update to new upstream release (2.19.5), which contains significant Epilicious updates and improved filterset.g syncing support in the AdBlocker extension. - Build against the new Gecko release (Firefox 2.0.0.5) gnome-games-1:2.19.4-3.fc8 -------------------------- * Sat Jul 21 2007 Hans de Goede - 1:2.19.4-3 - Don't build a private copy of gnuchess, instead require gnuchess (bz 215110) - Rename / rebrand Gnometris to GnomeFallingBlocks, so that it stays clear of the Tetris trademark, and include it (bz 238651) - Don't own dirs under /usr/share/icons/hicolor, instead add Requires: hicolor-icon-theme - Cleanup handling of with_card and with_tali defines using --enable-omitgames hwbrowser-0.34-1.fc8 -------------------- * Sat Jul 21 2007 Nils Philippsen - 0.34-1 - Use Hg for tagging - use bzipped tarballs - remove obsolete kontrol-panel related stuff - don't run configure anymore - check for incoming changes before creating archive * Wed Jul 18 2007 Nils Philippsen - un-auto-foo - more CVS -> Hg cleanup jd-1.9.5-2.svn1195.fc8.1 ------------------------ * Sun Jul 22 2007 Mamoru Tasaka - 1.9.5-2.svn1195 - svn 1195 kazehakase-0.4.7-7.svn3227.fc8 ------------------------------ * Thu Jun 21 2007 Mamoru Tasaka - 0.4.7-7.svn3227 - Try svn 3227 to drop GLib patch kdebase-6:3.5.7-12.fc8 ---------------------- * Fri Jul 20 2007 Rex Dieter - 6:3.5.7-12 - fix unpackaged files * Fri Jul 20 2007 Rex Dieter - 6:3.5.7-9 - %ifnarch s390 s390x: BR: lm_sensors * Thu Jul 19 2007 Rex Dieter - 6:3.5.7-7 - omit dirs owned by kde-filesystem kernel-2.6.23-0.43.rc0.git16.fc8 -------------------------------- * Sat Jul 21 2007 Dave Jones - 2.6.22-git16 * Sat Jul 21 2007 Roland McGrath - Update linux-2.6-elf-core-sysctl.patch * Fri Jul 20 2007 John W. Linville - Update git-wireless-dev.patch (rt2x00 update) leafpad-0.8.11-1.fc8 -------------------- * Fri Jul 20 2007 Ignacio Vazquez-Abrams 0.8.11-1 - Upstream update piklab-0.14.2-4.fc8 ------------------- * Sat Jul 21 2007 Alain Portal 0.14.2-4 - Remove QT from Categories * Sat Jul 21 2007 Alain Portal 0.14.2-3 - Update Source1 to change the usb udev rules. Fix #249029 rpm-4.4.2.1-0.6.rc3 ------------------- * Sat Jul 21 2007 Panu Matilainen 4.4.2.1-0.6.rc3 - dont mess up python exit codes * Fri Jul 20 2007 Panu Matilainen 4.4.2.1-0.5.rc3 - require logrotate (#248629) - allow checking for pending signals from python (#181434) - add hook to python for cleaning up on unclean exit (#245389) * Mon Jul 09 2007 Panu Matilainen 4.4.2.1-0.4.rc3 - 4.4.2.1-rc3 sqlite-3.4.1-1.fc8 ------------------ * Sat Jul 21 2007 Paul Nasrat - 3.4.1-1 - Update to 3.4.1 * Sun Jun 24 2007 Paul Nasrat - 3.4.0-2 - Disable load for now (#245486) * Tue Jun 19 2007 Paul Nasrat - 3.4.0-1 - Update to 3.4.0 sylpheed-2.4.4-1 ---------------- * Sat Jul 21 2007 Michael Schwendt - 2.4.4-1 - Update to 2.4.4. Broken deps for i386 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.i386 requires sysklogd kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.x86_64 requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.x86_64 requires sysklogd kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.ppc requires sysklogd glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.ppc64 requires sysklogd glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From lsof at nodata.co.uk Sun Jul 22 10:34:16 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 22 Jul 2007 12:34:16 +0200 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> Message-ID: <1185100456.4543.2.camel@sb-home> Am Samstag, den 21.07.2007, 09:18 -0700 schrieb Christopher Stone: > On 7/21/07, Naheem Zaffar wrote: > > You will have to work on a case by case basis, filing bugs where needed. > > > > Some applications would only be sane in a specific environment. As an > > example, Gnome should have a link to Nautilus for file management, KDE > > to Konqueror (or whatever they have got in KDE 4. Dolphin?). > > I do not understand this logic. Why do we assume GNOME users will > only use Nautilus, and KDE users will only use Konqueror? Of course Gnome users might want to use Konqueror, and they are free to do so. But if they know what Konqueror is, then they know how to add a launcher to their panel. The alternative is what Suse has - a disasterous hard-to-use clutter of menu items. From lsof at nodata.co.uk Sun Jul 22 10:37:02 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 22 Jul 2007 12:37:02 +0200 Subject: Vacation In-Reply-To: <1185055455.8695.40.camel@pc-notebook> References: <1185055455.8695.40.camel@pc-notebook> Message-ID: <1185100622.4543.6.camel@sb-home> Am Sonntag, den 22.07.2007, 00:04 +0200 schrieb Martin Sourada: > Hi, > > I am going on a vacation for a week. I'll return at next Sunday or > sooner. I'll have no internet access there. I maintain gxine a > xine-plugin packages, both without ACL, so if any problem arise, feel > free to fix it. As for the Nodoka theme[1], Daniel Geiger wrote he's > going to do some work on it; and I have submitted two package reviews > [2][3] for that, so if there is someone interested in reviewing them > I'll reply to your questions as soon as I'm back. > > Thanks, > Martin > > References: > [1] http://fedoraproject.org/wiki/Releases/Features/NodokaTheme > [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248163 > [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248516 > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Please update http://fedoraproject.org/wiki/Vacation and ignore the other replies. Thanks. From drago01 at gmail.com Sun Jul 22 11:07:19 2007 From: drago01 at gmail.com (dragoran) Date: Sun, 22 Jul 2007 13:07:19 +0200 Subject: =?utf-8?q?WTF=E2=81=88_ShowOnlyIn=3DGNOME?= In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> Message-ID: <46A33A67.1040800@gmail.com> Christopher Stone wrote: > On 7/21/07, Naheem Zaffar wrote: >> You will have to work on a case by case basis, filing bugs where needed. >> >> Some applications would only be sane in a specific environment. As an >> example, Gnome should have a link to Nautilus for file management, KDE >> to Konqueror (or whatever they have got in KDE 4. Dolphin?). > > I do not understand this logic. Why do we assume GNOME users will > only use Nautilus, and KDE users will only use Konqueror? > Konqueror is a bad example because its a webbrowser too and already listed under applications->internet. From valent.turkovic at gmail.com Sun Jul 22 14:02:16 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 22 Jul 2007 16:02:16 +0200 Subject: the most serious bug in F7 I found so far... In-Reply-To: <20070715144809.GA3070@free.fr> References: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> <20070715144809.GA3070@free.fr> Message-ID: <64b14b300707220702u74f93bddud89b7602d978608d@mail.gmail.com> On 7/15/07, Patrice Dumas wrote: > On Sun, Jul 15, 2007 at 03:43:19PM +0200, Valent Turkovic wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246593 > > > > This is the most serious bug I found in Fedora 7 so please look at it > > and tell me what more info you need of me. > > This list is not for bug reporting, except when bugs need attention from > the community, which doesn't seems to be the case for that bug. To me it seams like this bug is really appropriate for this list because it needs devel attention. It is THE most serious bug I have encontered with Fedora 7 and my subjective feeling is that nobody has even looked at it and that is being ignored. Please look at this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246593 Thank you. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From hughsient at gmail.com Sun Jul 22 14:15:39 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 22 Jul 2007 15:15:39 +0100 Subject: the most serious bug in F7 I found so far... In-Reply-To: <64b14b300707220702u74f93bddud89b7602d978608d@mail.gmail.com> References: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> <20070715144809.GA3070@free.fr> <64b14b300707220702u74f93bddud89b7602d978608d@mail.gmail.com> Message-ID: <1185113739.2455.13.camel@work> On Sun, 2007-07-22 at 16:02 +0200, Valent Turkovic wrote: > It is THE most serious bug I have encontered with Fedora 7 and my > subjective feeling is that nobody has even looked at it and that is > being ignored. Welcome to open source. Maybe you can get your money back? Seriously, if you want _immediate_ response from engineering people to fix a specific bug then you probably ought to buy a RHEL subscription or some other supported vendor product. For this sort of bug you will need to debug the problem a little more, try to reproduce on other hardware and try to find the specific way that this can be reproduced. If you then approach upstream development teams then the issue is likely to be fixed much quicker (in my experience). Posting on a fedora-development mailing list isn't going to get things fixed any quicker. Richard From skvidal at linux.duke.edu Sun Jul 22 14:50:59 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 22 Jul 2007 10:50:59 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070721145225.397852ff@vader.jdub.homelinux.org> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> Message-ID: <1185115860.2408.2.camel@cutter> On Sat, 2007-07-21 at 14:52 -0500, Josh Boyer wrote: > On Sat, 21 Jul 2007 09:36:34 +0200 > Ralf Corsepius wrote: > > > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: > > > On 7/20/07, Ralf Corsepius wrote: > > > > So, the new FESCo is going to act as the "Fedora License Police" > > > > > > Always so negative. > > > > Well, why should I change my opinion on something which had been > > repeatedly discussed to death (E.g. on FPC meetings) and which I > > consider to be "silly and naive"? > > > > Seems to me as if any new FESCo is going to commit the same beginner's > > mistakes others had been trapped into before. > > I'd like to point out this mandate came from the Board. FESCo did not > start this on their own, they were told to do it. A couple of more items on this decision: 1. we're not looking for things to be programming-api-perfect when it comes to license specification in the License: tag. 2. We want to make it easier to do a global query to look for certain things: ie: license X Requires a package which is license Y - these two are incompatible and we need to deal with that. Now, we're not expecting perfection, but it should be started. -sv From valent.turkovic at gmail.com Sun Jul 22 15:02:00 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 22 Jul 2007 17:02:00 +0200 Subject: CD/DVD cataloging software In-Reply-To: <1184606483.4145.28.camel@eagle.danny.cz> References: <1184606483.4145.28.camel@eagle.danny.cz> Message-ID: <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> On 7/16/07, Dan Hor?k wrote: > Hello, > > I have spend this weekend with looking for a software that will > catalogue content of CDs and DVDs (I want to know what file is on which > CD/DVD). My requirements were simple - work current Fedora (>=6) and > automagicly use the disc name when storing the content. As > > name version platform current use disc > Fedora name > gtktalog 1.0.4 C/gtk1 no ? > gwhere 0.2.3 C/gtk1,gtk2 no* yes > CdCat 1.01b C/qt no* no > gnomecatalog 0.2.1 Python/gtk no ? > cdcollect 0.6.0 Mono no ? > > * = can read content of the folder where the disc is mounted > > The main problem is that these softs are looking for CD/DVDs into a > fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as > it uses gnome-mount which uses HAL. Also most of them are dead or almost > dead projects. > > As a result I have chosen gwhere for my usage. It required not so much > effort to make it build and then work. You can find it at > http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project > looks quite promising, but I don't know how to integrate scanning of > gnome-mounted (using HAL) discs. > > When some other solution exists (Beagle?), please let me know. > > > Dan Horak > > -- > Fedora maintainer: TinyERP, Code::Blocks, QGit, Tailor I tested all cd/dvd catalogue tools some time ago and found cdcat to be the best of them. I didn't test gwhere because I wasn't aware of it. gnomecatalog and as I recall all the others I tested, except cdcat, wouldn't show files when I did some random file search. I knew which files I had, so I searched and most of them wouldn't find them even if they indexed them! Only cdcat worked as expected! Is there a chance for cdcat to be included in fedora repos? It is not the most nicest looking program but it does the job - and does it perfectly! -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From lightsolphoenix at gmail.com Sun Jul 22 15:02:33 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 22 Jul 2007 11:02:33 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184962398.3195.20.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> Message-ID: <200707221102.34543.lightsolphoenix@gmail.com> I noticed people discussing problems with the sound in Fedora. I had problems with the sound myself, until I switched everything over to using the PulseAudio daemon. There are fantastic instructions here: http://www.pulseaudio.org/wiki/PerfectSetup and everything is in the repositories. The only thing to note is that the system won't start PulseAudio by default; I fixed that by putting it in a startup script in my ~/.kde/Autostart folder, and I imagine Gnome has a similar procedure. At any rate, if you install pulseaudio-esd-compat, then any program that uses ESound can use PulseAudio directly, and there are setups for ALSA to use PulseAudio as well (so you can pipe ALSA sources to the daemon and have the daemon claim exclusive control over the actual sound port). From valent.turkovic at gmail.com Sun Jul 22 15:05:08 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 22 Jul 2007 17:05:08 +0200 Subject: CD/DVD cataloging software In-Reply-To: <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> References: <1184606483.4145.28.camel@eagle.danny.cz> <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> Message-ID: <64b14b300707220805k207df20h2c7b30c818c535c0@mail.gmail.com> On 7/22/07, Valent Turkovic wrote: > On 7/16/07, Dan Hor?k wrote: > > Hello, > > > > I have spend this weekend with looking for a software that will > > catalogue content of CDs and DVDs (I want to know what file is on which > > CD/DVD). My requirements were simple - work current Fedora (>=6) and > > automagicly use the disc name when storing the content. As > > > > name version platform current use disc > > Fedora name > > gtktalog 1.0.4 C/gtk1 no ? > > gwhere 0.2.3 C/gtk1,gtk2 no* yes > > CdCat 1.01b C/qt no* no > > gnomecatalog 0.2.1 Python/gtk no ? > > cdcollect 0.6.0 Mono no ? > > > > * = can read content of the folder where the disc is mounted > > > > The main problem is that these softs are looking for CD/DVDs into a > > fixed path (/media/cdrom, ...) which doesn't exist in current Fedoras as > > it uses gnome-mount which uses HAL. Also most of them are dead or almost > > dead projects. > > > > As a result I have chosen gwhere for my usage. It required not so much > > effort to make it build and then work. You can find it at > > http://fedora.danny.cz/gwhere-0.2.3-1.src.rpm The CDCollect project > > looks quite promising, but I don't know how to integrate scanning of > > gnome-mounted (using HAL) discs. > > > > When some other solution exists (Beagle?), please let me know. > > > > > > Dan Horak > > > > -- > > Fedora maintainer: TinyERP, Code::Blocks, QGit, Tailor > > I tested all cd/dvd catalogue tools some time ago and found cdcat to > be the best of them. I didn't test gwhere because I wasn't aware of > it. > > gnomecatalog and as I recall all the others I tested, except cdcat, > wouldn't show files when I did some random file search. > > I knew which files I had, so I searched and most of them wouldn't find > them even if they indexed them! Only cdcat worked as expected! > > Is there a chance for cdcat to be included in fedora repos? > It is not the most nicest looking program but it does the job - and > does it perfectly! cdcat has one nice benefit - it also has a windows executable version so you can send your catalog to your friends on "the dark side" :) -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From sundaram at fedoraproject.org Sun Jul 22 15:09:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 20:39:34 +0530 Subject: CD/DVD cataloging software In-Reply-To: <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> References: <1184606483.4145.28.camel@eagle.danny.cz> <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> Message-ID: <46A3732E.2070503@fedoraproject.org> Valent Turkovic wrote: > > Is there a chance for cdcat to be included in fedora repos? > It is not the most nicest looking program but it does the job - and > does it perfectly! Sure, this is a chance. You can maintain it. http://fedoraproject.org/wiki/PackageMaintainers Rahul From sundaram at fedoraproject.org Sun Jul 22 15:10:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 20:40:42 +0530 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <200707221102.34543.lightsolphoenix@gmail.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221102.34543.lightsolphoenix@gmail.com> Message-ID: <46A37372.6090801@fedoraproject.org> Kelly wrote: > I noticed people discussing problems with the sound in Fedora. I had problems > with the sound myself, until I switched everything over to using the > PulseAudio daemon. There are fantastic instructions here: > > http://www.pulseaudio.org/wiki/PerfectSetup > > and everything is in the repositories. The only thing to note is that the > system won't start PulseAudio by default; I fixed that by putting it in a > startup script in my ~/.kde/Autostart folder, and I imagine Gnome has a > similar procedure. Note that Pulse Audio is planned to be the default sound server in the next release of Fedora. Rahul From fedora at leemhuis.info Sun Jul 22 15:12:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Jul 2007 17:12:52 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185115860.2408.2.camel@cutter> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> Message-ID: <46A373F4.8050901@leemhuis.info> On 22.07.2007 16:50, seth vidal wrote: > On Sat, 2007-07-21 at 14:52 -0500, Josh Boyer wrote: >> On Sat, 21 Jul 2007 09:36:34 +0200 >> Ralf Corsepius wrote: >> >>> On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote: >>>> On 7/20/07, Ralf Corsepius wrote: >>>>> So, the new FESCo is going to act as the "Fedora License Police" >>>> Always so negative. >>> Well, why should I change my opinion on something which had been >>> repeatedly discussed to death (E.g. on FPC meetings) and which I >>> consider to be "silly and naive"? >>> >>> Seems to me as if any new FESCo is going to commit the same beginner's >>> mistakes others had been trapped into before. >> I'd like to point out this mandate came from the Board. FESCo did not >> start this on their own, they were told to do it. > > A couple of more items on this decision: > > 1. we're not looking for things to be programming-api-perfect when it > comes to license specification in the License: tag. > 2. We want to make it easier to do a global query to look for certain > things: > ie: license X Requires a package which is license Y - these two are > incompatible and we need to deal with that. > > Now, we're not expecting perfection, but it should be started. /me can see the reasons for kind of GPL2, GPL2+, LGPL2+ stuff in the license tag as well But what I'd like to see added at the same time are some automatic check to make sure properly done license changes get noticed automatically. A basic "sha1sum the LICENSE file from upstream (most ship one) once and put a small script into the %pre section that compares the know sha1sum with the current one from the tarball and aborts if something changed" should find properly done license changes automatically and keeps load off the maintainer. Sure, in an ideal world all maintainers would notice a license change by reading the changelog or when interacting with upstream -- but we don't live in and ideal world afaics and computers are made for such automatic checks, so why not use them for what they were made? Just my 2 cent. Cu thl From valent.turkovic at gmail.com Sun Jul 22 15:23:37 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 22 Jul 2007 17:23:37 +0200 Subject: CD/DVD cataloging software In-Reply-To: <46A3732E.2070503@fedoraproject.org> References: <1184606483.4145.28.camel@eagle.danny.cz> <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> <46A3732E.2070503@fedoraproject.org> Message-ID: <64b14b300707220823h6fa2b494k30557aec9ec8022f@mail.gmail.com> On 7/22/07, Rahul Sundaram wrote: > Valent Turkovic wrote: > > > > > Is there a chance for cdcat to be included in fedora repos? > > It is not the most nicest looking program but it does the job - and > > does it perfectly! > > Sure, this is a chance. You can maintain it. > http://fedoraproject.org/wiki/PackageMaintainers > > Rahul Are you sure you want me as a maintainer? :) I can contribute in many ways but I don't feel upto being a package maintainer. Are there any irc/skype or any other courses on how to get the required knowledge and become a maintainer? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From valent.turkovic at gmail.com Sun Jul 22 15:30:34 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sun, 22 Jul 2007 17:30:34 +0200 Subject: the most serious bug in F7 I found so far... In-Reply-To: <1185113739.2455.13.camel@work> References: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> <20070715144809.GA3070@free.fr> <64b14b300707220702u74f93bddud89b7602d978608d@mail.gmail.com> <1185113739.2455.13.camel@work> Message-ID: <64b14b300707220830w3c111fdej6b48c6510d750b24@mail.gmail.com> On 7/22/07, Richard Hughes wrote: > On Sun, 2007-07-22 at 16:02 +0200, Valent Turkovic wrote: > > It is THE most serious bug I have encontered with Fedora 7 and my > > subjective feeling is that nobody has even looked at it and that is > > being ignored. > > Welcome to open source. Maybe you can get your money back? > > Seriously, if you want _immediate_ response from engineering people to > fix a specific bug then you probably ought to buy a RHEL subscription or > some other supported vendor product. > > For this sort of bug you will need to debug the problem a little more, > try to reproduce on other hardware and try to find the specific way that > this can be reproduced. If you then approach upstream development teams > then the issue is likely to be fixed much quicker (in my experience). > > Posting on a fedora-development mailing list isn't going to get things > fixed any quicker. > > Richard You didn't interpret my intention right. I don't wan't "my money back" and I wouldn't go back to any proprietary os even if they would pay me... I'm just a really concerned Fedora user and this look as a really nasty and serious but and I believe that if need some attention. I never said that it need "immediate" attention, but please notice when I reported a bug - it was 3 weeks ago! When I usualy report some bug I get a response 2-3 days at most. So this looked and still looks like nobody is looking at this but. I wouldn't post to devel mailing-list for attention if this was some minor bug like some others that I posted and give my feedback to (over 30 bugs or more). But this one really needs devel attention. Please, please, please look at it and help me to help you as I can give you more feedback and logs regarding this but, or even access to my machine if it is necessary. I'm willing to give you all of my help in order to help you fix this bug. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From sundaram at fedoraproject.org Sun Jul 22 15:31:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 21:01:55 +0530 Subject: CD/DVD cataloging software In-Reply-To: <64b14b300707220823h6fa2b494k30557aec9ec8022f@mail.gmail.com> References: <1184606483.4145.28.camel@eagle.danny.cz> <64b14b300707220802i45d7c5d1t4946179507471f98@mail.gmail.com> <46A3732E.2070503@fedoraproject.org> <64b14b300707220823h6fa2b494k30557aec9ec8022f@mail.gmail.com> Message-ID: <46A3786B.2040802@fedoraproject.org> Valent Turkovic wrote: > > Are you sure you want me as a maintainer? :) I can contribute in many > ways but I don't feel upto being a package maintainer. The question really isn't whether I want you as a maintainer (sure, why not?) but whether you are interested enough to do that. That is a pretty good way to ensure that the package you want in the repository are there be it cdcat or anything else. > Are there any irc/skype or any other courses on how to get the > required knowledge and become a maintainer? There isn't a IRC course but the above wiki link has a number of good documentation which will help you get started. You can get on Freenode IRC in #fedora-devel and clarify any details. Additionally submitting a package for review will get you very good feedback from more experienced package maintainers. Red Hat has a online program under development that is to be made available publicly once completed according to https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00102.html Rahul From lightsolphoenix at gmail.com Sun Jul 22 16:43:29 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 22 Jul 2007 12:43:29 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <46A37372.6090801@fedoraproject.org> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221102.34543.lightsolphoenix@gmail.com> <46A37372.6090801@fedoraproject.org> Message-ID: <200707221243.30169.lightsolphoenix@gmail.com> On Sunday, July 22, 2007 11:10 am Rahul Sundaram wrote: > > Note that Pulse Audio is planned to be the default sound server in the > next release of Fedora. > > Rahul Awesome. I have a package for a plugin which allows Adobe Flash to use PulseAudio as well; I would have submitted it to the project, but it has a dependency on Flash itself (though the plugin is GPL'ed). -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From sundaram at fedoraproject.org Sun Jul 22 16:44:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 22:14:33 +0530 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <200707221243.30169.lightsolphoenix@gmail.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221102.34543.lightsolphoenix@gmail.com> <46A37372.6090801@fedoraproject.org> <200707221243.30169.lightsolphoenix@gmail.com> Message-ID: <46A38971.4030007@fedoraproject.org> Kelly wrote: > On Sunday, July 22, 2007 11:10 am Rahul Sundaram wrote: >> Note that Pulse Audio is planned to be the default sound server in the >> next release of Fedora. >> >> Rahul > > Awesome. I have a package for a plugin which allows Adobe Flash to use > PulseAudio as well; I would have submitted it to the project, but it has a > dependency on Flash itself (though the plugin is GPL'ed). Wont it work with Gnash? Alternatively talk to Adobe. Rahul From lightsolphoenix at gmail.com Sun Jul 22 16:50:49 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sun, 22 Jul 2007 12:50:49 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <46A38971.4030007@fedoraproject.org> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221243.30169.lightsolphoenix@gmail.com> <46A38971.4030007@fedoraproject.org> Message-ID: <200707221250.49577.lightsolphoenix@gmail.com> On Sunday, July 22, 2007 12:44 pm Rahul Sundaram wrote: > > Wont it work with Gnash? Alternatively talk to Adobe. > > Rahul Not unless Gnash has implemented Flash's new Linux sound plugin API. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From chris.stone at gmail.com Sun Jul 22 22:15:24 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 22 Jul 2007 15:15:24 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <1185100456.4543.2.camel@sb-home> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> Message-ID: On 7/22/07, nodata wrote: > Am Samstag, den 21.07.2007, 09:18 -0700 schrieb Christopher Stone: > > On 7/21/07, Naheem Zaffar wrote: > > > Some applications would only be sane in a specific environment. As an > > > example, Gnome should have a link to Nautilus for file management, KDE > > > to Konqueror (or whatever they have got in KDE 4. Dolphin?). > > > > I do not understand this logic. Why do we assume GNOME users will > > only use Nautilus, and KDE users will only use Konqueror? > > Of course Gnome users might want to use Konqueror, and they are free to > do so. But if they know what Konqueror is, then they know how to add a > launcher to their panel. > > The alternative is what Suse has - a disasterous hard-to-use clutter of > menu items. How can one possibly argue that an installed application should not show up in a users menu? Somehow if I add a menu entry for an application I installed, it will make my menu a unusable clutter of Suse mess? What in the world are you people thinking?? From pertusus at free.fr Sun Jul 22 22:33:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Jul 2007 00:33:59 +0200 Subject: packages for buildinig .deb in fedora ready Message-ID: <20070722223358.GC20359@free.fr> Hello, I have packaged some debian packages to help making debian packages on fedora and compiling them. This includes: * dpkg to manipulate .deb archives, and create source packages. Everything that needs a .deb database will be broken, but that's not an issue in my opinion, we are on fedora after all ;-) * debhelper and dh-make to help the creation of debian packages (and html2text as a debhelper dependency) * debootstrap to create a debian (or ubuntu) chroot * pbuilder to compile a .deb in a chroot (with dependencies tldp-xsl and dblatex, and python-which as a dblatex dependency). I will use them locally, but I don't want to maintain them in fedora, since I have enough packages already. Everything is here: http://www.environnement.ens.fr/perso/dumas/fc-srpms/debian/ pbuilder will need to be launched as root, since the non-root procedure involves user-mode-linux which is not in fedora. these packages have some man pages encoded in non utf8 charsets, and also some install arch independent stuff in %_libdir instead of %_datadir. I would tend to avoid messing with those issues and wait for the debian project to fix them. html2text, python-which, tldp-xsl and dblatex are not debian specific, but are needed as dependencies. (dblatex conflicts with a file in tetex-tex4ht, I am the tetex-tex4ht maintainer and ready to change the name). Other packages may certainly be packaged once the above packages are in, like lintian and devscripts. When/if those packages are accepted I will certainly write something about developping and building .deb on fedora. -- Pat From mattdm at mattdm.org Mon Jul 23 00:49:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 22 Jul 2007 20:49:34 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> Message-ID: <20070723004934.GA28551@jadzia.bu.edu> On Sun, Jul 22, 2007 at 03:15:24PM -0700, Christopher Stone wrote: > How can one possibly argue that an installed application should not > show up in a users menu? Easily. Too many menu items make the menu useless. Not everything should be there. Instead, put some thought into it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From debarshi.ray at gmail.com Mon Jul 23 02:02:51 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 23 Jul 2007 07:32:51 +0530 Subject: Pirut: Edit -> Repositories mock-up -- Part 2. Message-ID: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> http://debarshiray.multiply.com/journal/item/85 I have created a new design for the Manage Repositories dialog. I have tried to incorporate Jeremy's suggestions regarding key management being a repository specific issue and not a top-level one, etc.. For your reference here is the list of possible use cases that were proposed last time: 1) Jim is getting more involved in Fedora and wants to enable the updates-testing repository so that he can be involved in testing updates. Also the disable case here. 2) John has a local mirror that he prefers to use for getting his Fedora updates and would like to point directly at it rather than the mirror list. 3) Sue read about some new software that's available from $vendor and would like to add their repo so that she can install and try it out. 4) $vendor provides a repo file on their website and would like to have it be easy for end-users to add that to their configs 5) Sally is a power-user and likes to micro-manage the details of therepository configuration. 6..X) Probably some more :) Once we start agreeing on the basic top-level design, I would start creating the "Add", "Edit" and "Remove" dialogs. Comments? Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jspaleta at gmail.com Mon Jul 23 02:50:15 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 22 Jul 2007 18:50:15 -0800 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070723004934.GA28551@jadzia.bu.edu> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> Message-ID: <604aa7910707221950q528dd5bfud8782cab8d6a7b20@mail.gmail.com> On 7/22/07, Matthew Miller wrote: > Easily. Too many menu items make the menu useless. Not everything should be > there. Instead, put some thought into it. ... and allow individual users and sysadmins to optionally re-enable items back into the menu without having to edit the actual .desktop files. Tailored defaults are perfectly fine with me, as long as a I can still back in and build my Frankenmenu in a way that doesn't have to be redone every time there is an application package update and the .desktop file is reinstalled. -jef From mattdm at mattdm.org Mon Jul 23 04:25:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Jul 2007 00:25:02 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: <604aa7910707221950q528dd5bfud8782cab8d6a7b20@mail.gmail.com> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <604aa7910707221950q528dd5bfud8782cab8d6a7b20@mail.gmail.com> Message-ID: <20070723042502.GA11388@jadzia.bu.edu> On Sun, Jul 22, 2007 at 06:50:15PM -0800, Jeff Spaleta wrote: > >Easily. Too many menu items make the menu useless. Not everything should be > >there. Instead, put some thought into it. > ... and allow individual users and sysadmins to optionally re-enable > items back into the menu without having to edit the actual .desktop > files. Tailored defaults are perfectly fine with me, as long as a I > can still back in and build my Frankenmenu in a way that doesn't have > to be redone every time there is an application package update and the > .desktop file is reinstalled. Agreed. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From seg at haxxed.com Mon Jul 23 04:26:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 22 Jul 2007 23:26:46 -0500 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <200707221243.30169.lightsolphoenix@gmail.com> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221102.34543.lightsolphoenix@gmail.com> <46A37372.6090801@fedoraproject.org> <200707221243.30169.lightsolphoenix@gmail.com> Message-ID: <1185164806.25858.133.camel@localhost.localdomain> On Sun, 2007-07-22 at 12:43 -0400, Kelly wrote: > Awesome. I have a package for a plugin which allows Adobe Flash to use > PulseAudio as well; I would have submitted it to the project, but it has a > dependency on Flash itself (though the plugin is GPL'ed). Why do we need a plugin? It should be able to use ALSA and Just Work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andy at smile.org.ua Mon Jul 23 04:37:59 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 23 Jul 2007 07:37:59 +0300 Subject: packages for buildinig .deb in fedora ready In-Reply-To: <20070722223358.GC20359@free.fr> References: <20070722223358.GC20359@free.fr> Message-ID: <20070723043759.GB3673@serv.smile.org.ua> Hi Patrice Dumas! On Mon, Jul 23, 2007 at 12:33:59AM +0200, Patrice Dumas wrote next: > I have packaged some debian packages to help making debian packages on > fedora and compiling them. This includes: Nice news. > pbuilder will need to be launched as root, since the non-root procedure > involves user-mode-linux which is not in fedora. Really? What the usermode package is? [andy at localhost ~]$ rpm -qi usermode Name : usermode Relocations: (not relocatable) Version : 1.87 Vendor: Red Hat, Inc. Release : 3 Build Date: ??? 03 ??? 2006 12:08:06 Install Date: ??? 22 ??? 2007 17:48:54 Build Host: hs20-bc2-3.build.redhat.com Group : Applications/System Source RPM: usermode-1.87-3.src.rpm Size : 528510 License: GPL Signature : DSA/SHA1, ??? 04 ??? 2006 18:33:27, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. Summary : Tools for certain user account management tasks. Description : The usermode package contains the userhelper program, which can be used to allow configured programs to be run with superuser privileges by ordinary users. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From lightsolphoenix at gmail.com Mon Jul 23 04:45:32 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Mon, 23 Jul 2007 00:45:32 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: <1185100456.4543.2.camel@sb-home> References: <1185100456.4543.2.camel@sb-home> Message-ID: <200707230045.33057.lightsolphoenix@gmail.com> On Sunday, July 22, 2007 6:34 am nodata wrote: > The alternative is what Suse has - a disasterous hard-to-use clutter of > menu items. Actually, I think SuSE's menu arrangement is brilliant; I never had any trouble finding what I wanted to use. In fact, even now, I generally pattern my Fedora menu after the SuSE structure. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From seg at haxxed.com Mon Jul 23 04:42:59 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 22 Jul 2007 23:42:59 -0500 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <46A37372.6090801@fedoraproject.org> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221102.34543.lightsolphoenix@gmail.com> <46A37372.6090801@fedoraproject.org> Message-ID: <1185165779.25858.149.camel@localhost.localdomain> On Sun, 2007-07-22 at 20:40 +0530, Rahul Sundaram wrote: > Note that Pulse Audio is planned to be the default sound server in the > next release of Fedora. So how good is PulseAudio's resampler? Whatever one is in use now, shits all over my music. Listening on a decent pair of speakers is not even worth it, it just reveals how much high frequencies are completely mangled into a noisy mess. Since a lot of hardware these days seems to only support 48khz, software resampling has to be done to play (ripped) CDs, and wherever the existing one is, it sucks. (dmix? In the kernel?) The crossfade plugin for xmms can do resampling, the "best sinc interpolator" sounds real nice but eats 30% cpu time on a 2ghz Athlon 64 (!). -------------- next part -------------- A non-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 Jul 23 05:33:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 23 Jul 2007 11:03:50 +0530 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1185165779.25858.149.camel@localhost.localdomain> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221102.34543.lightsolphoenix@gmail.com> <46A37372.6090801@fedoraproject.org> <1185165779.25858.149.camel@localhost.localdomain> Message-ID: <46A43DBE.3060709@fedoraproject.org> Callum Lerwick wrote: > On Sun, 2007-07-22 at 20:40 +0530, Rahul Sundaram wrote: >> Note that Pulse Audio is planned to be the default sound server in the >> next release of Fedora. > > So how good is PulseAudio's resampler? Whatever one is in use now, shits > all over my music. Install it and try. The packaging wasn't as good as it should be, the last time I checked though. More details including presentations is available at http://fedoraproject.org/wiki/Releases/FeaturePulseaudio Rahul From jspaleta at gmail.com Mon Jul 23 05:53:16 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 22 Jul 2007 21:53:16 -0800 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <46A373F4.8050901@leemhuis.info> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> Message-ID: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> On 7/22/07, Thorsten Leemhuis wrote: > But what I'd like to see added at the same time are some automatic check > to make sure properly done license changes get noticed automatically. A > basic "sha1sum the LICENSE file from upstream (most ship one) once and > put a small script into the %pre section that compares the know sha1sum > with the current one from the tarball and aborts if something changed" > should find properly done license changes automatically and keeps load > off the maintainer. That's actually a pretty good idea i think. For a lot of packages... packages that can easily define a set of license/copying files...this sort of automatic file checking would help flag problems. Granted its not going to work for all packages, but it might help a lot in the specific case of entire project codebases transitioning to gpl3 from a previous license. But I would definitely like to stress the need for individual maintainers to keep watch as to what the upstream projects are planning as for re-licensing and communicate licensing changes to the other fedora maintainers before they enter cvs/build system. -jef From lightsolphoenix at gmail.com Mon Jul 23 06:00:55 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Mon, 23 Jul 2007 02:00:55 -0400 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1185164806.25858.133.camel@localhost.localdomain> References: <1184962398.3195.20.camel@dimi.lattica.com> <200707221243.30169.lightsolphoenix@gmail.com> <1185164806.25858.133.camel@localhost.localdomain> Message-ID: <200707230200.55603.lightsolphoenix@gmail.com> On Monday, July 23, 2007 12:26 am Callum Lerwick wrote: > On Sun, 2007-07-22 at 12:43 -0400, Kelly wrote: > > Awesome. I have a package for a plugin which allows Adobe Flash to use > > PulseAudio as well; I would have submitted it to the project, but it has > > a dependency on Flash itself (though the plugin is GPL'ed). > > Why do we need a plugin? It should be able to use ALSA and Just Work. Yes, by default Flash uses ALSA directly. However, last time I checked, ALSA has trouble with multiple sound sources, especially if the sources are all trying for exclusive access (*glares at arts*). I use this plugin as part of a system I set up on my computer so that ALL sound is sent through the PulseAudio daemon, which handles mixing and sending the actual sound to ALSA. That way I don't need to worry about program X claiming exclusive control over ALSA and killing the rest of the sound on the system. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From lightsolphoenix at gmail.com Mon Jul 23 06:02:41 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Mon, 23 Jul 2007 02:02:41 -0400 Subject: Update on Sunbird packages Message-ID: <200707230202.41177.lightsolphoenix@gmail.com> I created a review request for my attempt to create a Sunbird RPM. As mentioned, it doesn't seem to be able to compile and I'm not entirely sure why. I'm hoping for some help (preferably from the packagers who deal with the other Mozilla components) in figuring out the problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249234 -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From rc040203 at freenet.de Mon Jul 23 06:20:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 23 Jul 2007 08:20:10 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> Message-ID: <1185171610.10535.52.camel@mccallum.corsepiu.local> On Sun, 2007-07-22 at 21:53 -0800, Jeff Spaleta wrote: > On 7/22/07, Thorsten Leemhuis wrote: > > But what I'd like to see added at the same time are some automatic check > > to make sure properly done license changes get noticed automatically. A > > basic "sha1sum the LICENSE file from upstream (most ship one) once and > > put a small script into the %pre section that compares the know sha1sum > > with the current one from the tarball and aborts if something changed" > > should find properly done license changes automatically and keeps load > > off the maintainer. > > That's actually a pretty good idea i think. For a lot of packages... > packages that can easily define a set of license/copying files... ... __can__ ... the critical cases are those which don't. > this > sort of automatic file checking would help flag problems. In trivial cases such as the GPLv3 change, it could help. In cases of packages changing from FOO-license v1.283 to BAR-license v32.100 it doesn't. In cases of packages pointing to web-sites, it doesn't ... etc. If you try to track these you'll end up with 100s of different license tags - This would require the often mentioned bureaucracy. > Granted its > not going to work for all packages, but it might help a lot in the > specific case of entire project codebases transitioning to gpl3 from a > previous license. If you think so, I disagree. You are driving away contributors from fedora, by imposing more and more bureaucracy. If you really want this YOU (Jef Spaleta in person) will have to do it yourselves. Ralf From andy at warmcat.com Mon Jul 23 06:33:28 2007 From: andy at warmcat.com (Andy Green) Date: Mon, 23 Jul 2007 07:33:28 +0100 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185171610.10535.52.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> Message-ID: <46A44BB8.4070302@warmcat.com> Somebody in the thread at some point said: >> sort of automatic file checking would help flag problems. > In trivial cases such as the GPLv3 change, it could help. > > In cases of packages changing from FOO-license v1.283 to BAR-license > v32.100 it doesn't. Wouldn't it notice the deletion of the FOO-license file at least though and flag it up? At least then someone can examine it further, learn about the change and tell it to track the BAR-license file. > In cases of packages pointing to web-sites, it Yes I guess so, although it could wget the URL periodically and hash that (assuming there are no "today's date" and crud on the page) > doesn't ... etc. If you try to track these you'll end up with 100s of > different license tags - This would require the often mentioned > bureaucracy. > >> Granted its >> not going to work for all packages, but it might help a lot in the >> specific case of entire project codebases transitioning to gpl3 from a >> previous license. > If you think so, I disagree. You are driving away contributors from > fedora, by imposing more and more bureaucracy. If you really want this The automated technique is a small burden if it works for most packages. Since care is taken about the license to get it into Fedora it is consistent to take some care about the license after it is in... and with fun things like "or later" now... -Andy From kevin.kofler at chello.at Mon Jul 23 06:36:46 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 23 Jul 2007 06:36:46 +0000 (UTC) Subject: packages for buildinig .deb in fedora ready References: <20070722223358.GC20359@free.fr> <20070723043759.GB3673@serv.smile.org.ua> Message-ID: Andy Shevchenko smile.org.ua> writes: > > pbuilder will need to be launched as root, since the non-root procedure > > involves user-mode-linux which is not in fedora. > Really? > What the usermode package is? Something completely different, just similarly named. Kevin Kofler From pertusus at free.fr Mon Jul 23 06:44:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Jul 2007 08:44:34 +0200 Subject: packages for buildinig .deb in fedora ready In-Reply-To: <20070723043759.GB3673@serv.smile.org.ua> References: <20070722223358.GC20359@free.fr> <20070723043759.GB3673@serv.smile.org.ua> Message-ID: <20070723064434.GA2994@free.fr> On Mon, Jul 23, 2007 at 07:37:59AM +0300, Andy Shevchenko wrote: > Really? > What the usermode package is? I believe both packages are different. User-mode linux is a special linux kernel, so it allows virtualization, while usermode is pam related. -- Pat From andy at smile.org.ua Mon Jul 23 07:04:42 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Mon, 23 Jul 2007 10:04:42 +0300 Subject: packages for buildinig .deb in fedora ready In-Reply-To: <20070723064434.GA2994@free.fr> References: <20070722223358.GC20359@free.fr> <20070723043759.GB3673@serv.smile.org.ua> <20070723064434.GA2994@free.fr> Message-ID: <20070723070442.GC3673@serv.smile.org.ua> Hi Patrice Dumas! On Mon, Jul 23, 2007 at 08:44:34AM +0200, Patrice Dumas wrote next: > > Really? > > What the usermode package is? > I believe both packages are different. User-mode linux is a special linux > kernel, so it allows virtualization, while usermode is pam related. Understood. Thanks. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From rc040203 at freenet.de Mon Jul 23 07:10:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 23 Jul 2007 09:10:35 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <46A44BB8.4070302@warmcat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> Message-ID: <1185174635.10535.60.camel@mccallum.corsepiu.local> On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote: > Somebody in the thread at some point said: > > >> sort of automatic file checking would help flag problems. > > In trivial cases such as the GPLv3 change, it could help. > > > > In cases of packages changing from FOO-license v1.283 to BAR-license > > v32.100 it doesn't. > > Wouldn't it notice the deletion of the FOO-license file at least though > and flag it up? If there is any, may-be - If there isn't any, no. Also consider: Detached license files are legally questionable/doubtful. What matters is the license inlined or referenced by each files. Non copyright owner added licenses are even more questionable. > At least then someone someone == Jef Spaleta or other people from the Board > > In cases of packages pointing to web-sites, it > > Yes I guess so, although it could wget the URL periodically and hash > that (assuming there are no "today's date" and crud on the page) Feel free to do so ... Feel free to do so if these URLs change or vanish ;) > >> Granted its > >> not going to work for all packages, but it might help a lot in the > >> specific case of entire project codebases transitioning to gpl3 from a > >> previous license. > > If you think so, I disagree. You are driving away contributors from > > fedora, by imposing more and more bureaucracy. If you really want this > > The automated technique is a small burden if it works for most packages. We already _have_ way too much bureaucracy in Fedora. > Since care is taken about the license to get it into Fedora it is > consistent to take some care about the license after it is in... and > with fun things like "or later" now... Feel free to do so - Without me. Shall the "Board" (Whatever board-de-jour we might be talking about) and the dark forces surrounding it inside of RH do so - Without me - Period. Ralf From pertusus at free.fr Mon Jul 23 07:30:21 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Jul 2007 09:30:21 +0200 Subject: packages for buildinig .deb in fedora ready In-Reply-To: <20070722223358.GC20359@free.fr> References: <20070722223358.GC20359@free.fr> Message-ID: <20070723073021.GC2994@free.fr> On Mon, Jul 23, 2007 at 12:33:59AM +0200, Patrice Dumas wrote: > > Other packages may certainly be packaged once the above packages are in, > like lintian and devscripts. And also alien whic depends on dpkg. -- Pat From giallu at gmail.com Mon Jul 23 07:57:05 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 23 Jul 2007 09:57:05 +0200 Subject: What happened to kernel-kdump-devel in 2.6.22 ? Message-ID: My rebuild of sysprof-kmod is failing due to a missing kernel-kdump-devel: http://koji.fedoraproject.org/koji/getfile?taskID=73500&name=root.log What happened to it? From nicolas.mailhot at laposte.net Mon Jul 23 08:48:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Jul 2007 10:48:27 +0200 (CEST) Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> Message-ID: <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> BTW, it's probably a cultural thing, but my brain just shuts down whenever someone posts a usability scenario on the list. Whoever instituted them probably read a USA usability text-book and tried to ape it. For the original author, the writing style is neutral and lets him focus on the use-cases. For me, the user names chosen scream USA (actually 1970' WASP USA), as does the "casual" use of surnames. So I delete messages before I get real angry about Fedora being presented as an effort to please a very small and limited userbase. Can we have use-cases that reflect the diversity on Fedora forums and lists? Or even stop the whole ridiculous synthetic use-case writing and not write about ourselves in the third person like Julius Caesar? In my experience this stuff can be written for two reasons: A. someone conducted an actual usability test campaign, collected a lot of user feedback, and tries to sum them up in a few use-cases to have a short work document. This is the productive synthetic use-case writing scenario. Use-cases reflect reality, not the writer bias, who is just summing up hard data. B. someone didn't have the resources to conduct a usability campaign, but read the kind of document produced in A. He decides it can't be so hard to write use-cases and wipes up a synthetic "professional" use-case list. The problem is without the user feedback data these synthetic use cases are totally removed from reality, the weird writing style actually accentuates the writer bias, while hiding it's all actually just one guy's opinion. What's worse when these use-cases clash with actual user feedback the user feedback is rejected as not being properly formalized when in reality the use-case writers are just self-satisfied with subjective users that reflect their own opinions. This is the not-productive synthetic use-case writing scenario, and I'd rather we avoided it. Or at least be honest and not disguise some people objectives are actual use-cases. Somehow the naming makes me suspect we're in case B. In case A, enough reality always creep-up in the use-case they're not a textbook caricature. -- Nicolas Mailhot From abo at kth.se Mon Jul 23 08:54:53 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 23 Jul 2007 10:54:53 +0200 Subject: When writing to this list... Message-ID: <1185180896.30643.262.camel@home.alexander.bostrom.net> Hi, Sorry if this sounds harsh... Just, please try to follow this, ok? I'm pretty sure most would agree with me on this one. This is a plea to everyone posting to this list. Please try to quote properly when replying to mails. It's rather tiresome, when scanning new messages in the list, to have to scroll down to the bottom of a message to see if it's interesting at all because the whole Evo preview window is showing *only* quoted text which I just read two seconds ago. Chances are I'll just skip the message entirely, only reading the messages which are easy to read. The dos: * Quote only the paragraphs that you're actually commenting. * If a quoted paragraph is long, maybe quote just parts of it. * If you're writing a general reply which isn't written in the context of a specific paragraph of the parent message, then don't quote at all. Or just quote some small part of the parent message. (Or top-post, some would suggest. I'm not going to suggest that, but I'm not going to protest it either.) The do nots: * Don't quote the entire parent message, including sigs and all, just to write some short comment at the end. * To quote a signature is usually a bad idea, unless you're commenting on it specifically. We already have the "Foo Bar wrote..." at the beginning of the quote. * As a general rule, if the first 20-30 lines of the message you're about to send is just quoted text, there's probably something wrong. * Don't be lazy! There are numerous examples to show what I mean, but I'm not going to point to them. :) And yes, sometimes it is useful to quote a bit more than usual, but keep it within reason. Also, remember, in Evolution, if you select a part of a message and then hit Reply to all, only that part of the message will be quoted. It's a good feature. Thank you! /abo PS. Yes, I'm going to upgrade my 1280?1024 LCD someday. But not now, and perhaps I'd like to use the extra pixels for better text resolution instead of to fit more text... DS. From sankarshan.mukhopadhyay at gmail.com Mon Jul 23 09:05:42 2007 From: sankarshan.mukhopadhyay at gmail.com (Sankarshan Mukhopadhyay) Date: Mon, 23 Jul 2007 14:35:42 +0530 Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> Message-ID: <46A46F66.6060409@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicolas Mailhot wrote: > BTW, it's probably a cultural thing, but my brain just shuts down > whenever someone posts a usability scenario on the list. Whoever > instituted them probably read a USA usability text-book and tried to > ape it. For the original author, the writing style is neutral and lets > him focus on the use-cases. For me, the user names chosen scream USA > (actually 1970' WASP USA), as does the "casual" use of surnames. For what it is worth, the original at https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay reads as: # Manu has two machines-- one at work and one at home. The former has a nice Internet connection, while the other one does not. He is a not a geek, and wants to install a media player, which is there on his office box, at home. # Rakesh has five machines, which are not on the same LAN. Although all are connected to the Internet, the bandwidth is not good and it is costly to download the same updates and packages on all the machines individually. # My grandmother wants to try out Fedora. She does not know about computers, and finds it difficult to figure out what to install from the long list of available packages. So, I want to give her a 'yumpack' on a CD containing the packages she wants to have, so that she can just click and ask Pirut to install the contents of the pack, without thinking about anything else. However, what do you think about the context of Rishi's mail ? :Sankarshan - -- You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGpG9mXQZpNTcrCzMRAq8zAKCO+MfwrbTaLnBduaWpjJrfqB6eUwCfQdyA tKeGl9/Sa5DSjTHWIbLTaU0= =qBvB -----END PGP SIGNATURE----- From debarshi.ray at gmail.com Mon Jul 23 09:07:41 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 23 Jul 2007 14:37:41 +0530 Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> Message-ID: <3170f42f0707230207x60509b8ag9b90215082788fd9@mail.gmail.com> > So I delete messages before I get real angry about Fedora being > presented as an effort to please a very small and limited userbase. You could add to the proposed use-cases, which would help to improve the situation. The original proposer of the use-cases did leave room for modification. > Can we have use-cases that reflect the diversity on Fedora forums and > lists? Or even stop the whole ridiculous synthetic use-case writing > and not write about ourselves in the third person like Julius Caesar? > In my experience this stuff can be written for two reasons: > > A. someone conducted an actual usability test campaign, collected a > .... > .... > Somehow the naming makes me suspect we're in case B. In case A, enough > reality always creep-up in the use-case they're not a textbook > caricature. This entire rant did not produce anything positive or constructive. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Mon Jul 23 09:10:01 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 23 Jul 2007 14:40:01 +0530 Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <46A46F66.6060409@gmail.com> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> <46A46F66.6060409@gmail.com> Message-ID: <3170f42f0707230210m29805ba8n54ac75be0cd96cac@mail.gmail.com> > For what it is worth, the original at > https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay reads as: This was written by me, whereas the one I posted here before was proposed by Jeremy Katz in an earlier thread. > # Manu has two machines-- one at work and one at home. The former has a > nice Internet connection, while the other one does not. He is a not a > geek, and wants to install a media player, which is there on his office > box, at home. > # Rakesh has five machines, which are not on the same LAN. Although all > are connected to the Internet, the bandwidth is not good and it is > costly to download the same updates and packages on all the machines > individually. For your information, I do happen to have two friends named Rakesh and Manu who did use Fedora a lot until recently. Right now they are on Debain Etch & Lenny respectively. Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From kzak at redhat.com Mon Jul 23 09:11:39 2007 From: kzak at redhat.com (Karel Zak) Date: Mon, 23 Jul 2007 11:11:39 +0200 Subject: When writing to this list... In-Reply-To: <1185180896.30643.262.camel@home.alexander.bostrom.net> References: <1185180896.30643.262.camel@home.alexander.bostrom.net> Message-ID: <20070723091139.GC3181@petra.dvoda.cz> On Mon, Jul 23, 2007 at 10:54:53AM +0200, Alexander Bostr?m wrote: > Sorry if this sounds harsh... Just, please try to follow this, ok? I'm > pretty sure most would agree with me on this one. http://www.faqs.org/rfcs/rfc1855.html Karel -- Karel Zak From nicolas.mailhot at laposte.net Mon Jul 23 09:20:59 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Jul 2007 11:20:59 +0200 (CEST) Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <46A46F66.6060409@gmail.com> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <58111.192.54.193.51.1185180507.squirrel@rousalka.dyndns.org> <46A46F66.6060409@gmail.com> Message-ID: <60625.192.54.193.51.1185182459.squirrel@rousalka.dyndns.org> Le Lun 23 juillet 2007 11:05, Sankarshan Mukhopadhyay a ?crit : > For what it is worth, the original at > https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay reads as: > > # Manu has two machines-- one at work and one at home. The former has [...] This one is much nicer and has just the right mix of abstraction and reality > However, what do you think about the context of Rishi's mail ? I understand he's not the first one to use this writing style, and I didn't want to point the finger at a particular Fedora member. I just had enough so instead of silently deleting this message like the others and cursing alone I wanted to express my dissatisfaction with this kind of novlang writing. -- Nicolas Mailhot From buildsys at redhat.com Mon Jul 23 09:39:02 2007 From: buildsys at redhat.com (Build System) Date: Mon, 23 Jul 2007 05:39:02 -0400 Subject: rawhide report: 20070723 changes Message-ID: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> Updated Packages: aide-0.13.1-2 ------------- * Sun Jul 22 2007 Michael Schwendt - 0.13.1-2 - Apply Steve Conklin's patch to increase displayed portion of selinux context. * Sun Dec 17 2006 Michael Schwendt - 0.13.1-1 - Update to 0.13.1 release. * Sun Dec 10 2006 Michael Schwendt - 0.13-1 - Update to 0.13 release. - Include default aide.conf from RHEL5 as doc example file. alleggl-0.4.2-0.1.rc1.fc8 ------------------------- * Sun Jul 22 2007 Hans de Goede 0.4.2-0.1.rc1 - New upstream release 0.4.2 RC1 cpanspec-1.73-1.fc8 ------------------- * Sun Jul 22 2007 Steven Pritchard 1.73-1 - Update to 1.73. funtools-1.3.0-0.5.b34.fc8 -------------------------- * Sun Jul 22 2007 Sergio Pascual 1.3.0-0.5.b34 - New upstream version fuse-2.7.0-2.fc8 ---------------- * Sat Jul 21 2007 Tom "spot" Callaway 2.7.0-2 - redefine exec_prefix to / - redefine bindir to /bin - redefine libdir to %{_lib} - don't pass --disable-static to configure - manually rm generated static libs * Wed Jul 18 2007 Peter Lemenkov 2.7.0-1 - Version 2.7.0 - Redefined exec_prefix due to demands from NTFS-3G * Wed Jun 06 2007 Peter Lemenkov 2.6.5-2 - Add BR libselinux-devel (bug #235145) - Config files properly marked as config (bug #211122) fwbackups-1.43.1-1.fc8 ---------------------- * Sun Jul 22 2007 Stewart Adam 1.43.1-1 - Change get_python_lib() to get_python_lib(1) for x86_64 - Add new Requires and Post(un) scripts because of new documentation - Switch all instances of fwbackups to %{name} for consistency - Update to 1.43.1 (see CHANGELOG file for details on version changes) gkrellm-2.3.0-1.fc8 ------------------- * Sun Jul 22 2007 Hans de Goede 2.3.0-1 - New upstream release 2.3.0 * Fri Jul 20 2007 Hans de Goede 2.2.10-3 - Rebuild, including libsensors support on ppc and ppc64 as lm_sensors is available there now. * Wed Nov 08 2006 Hans de Goede 2.2.10-2 - Add special case for via 686 volt sensors (bug 213304) gscan2pdf-0.9.15-1.fc8 ---------------------- * Sun Jul 22 2007 Bernard Johnson - 0.9.15-1 - v 0.9.15 * Wed Jul 11 2007 Bernard Johnson - 0.9.14-1 - v 0.9.14 * Mon Jul 09 2007 Bernard Johnson - 0.9.13-1 - v 0.9.13 jd-1.9.5-2.svn1196.fc8.1 ------------------------ * Mon Jul 23 2007 Mamoru Tasaka - 1.9.5-2.svn1196 - svn 1196 * Sat Jun 30 2007 Mamoru Tasaka - 1.9.5-1 - 1.9.5 * Mon Jun 25 2007 Mamoru Tasaka - 1.9.5-0.6.rc070625 - 1.9.5 rc 070625 kernel-2.6.23-0.44.rc0.git16.fc8 -------------------------------- * Sat Jul 21 2007 Roland McGrath - Fix biarch issue in linux-2.6-elf-core-sysctl.patch * Sat Jul 21 2007 Dave Jones - 2.6.22-git16 * Sat Jul 21 2007 Roland McGrath - Update linux-2.6-elf-core-sysctl.patch mail-notification-4.1-3.fc8 --------------------------- * Sun Jul 22 2007 Thorsten Leemhuis 4.1-3 - Add Desktop-Category X-GNOME-PersonalSettings (#249181) man-pages-ja-20070715-1 ----------------------- * Mon Jul 23 2007 Akira TAGOH - 20070715-1 - updates to 20070715. - man-pages-ja-222495-swapon.2.patch: applied to correct swapon(2). mysql-5.0.45-1.fc8 ------------------ * Sun Jul 22 2007 Tom Lane 5.0.45-1 - Update to MySQL 5.0.45 Resolves: #246535 - Move mysql_config's man page to base package Resolves: #245770 - move my_print_defaults to base RPM, for consistency with Stacks packaging - mysql user is no longer deleted at RPM uninstall Resolves: #241912 * Thu Mar 29 2007 Tom Lane 5.0.37-2 - Use a less hacky method of getting default values in initscript Related: #233771, #194596 - Improve packaging of mysql-libs per suggestions from Remi Collet Resolves: #233731 - Update default /etc/my.cnf ([mysql.server] has been bogus for a long time) * Mon Mar 12 2007 Tom Lane 5.0.37-1 - Update to MySQL 5.0.37 Resolves: #231838 - Put client library into a separate mysql-libs RPM to reduce dependencies Resolves: #205630 perl-DateTime-1:0.39-1.fc8 -------------------------- * Sun Jul 22 2007 Steven Pritchard 1:0.39-1 - Update to DateTIme 0.39. - Update to DateTime::TimeZone 0.6603. * Thu Jul 05 2007 Steven Pritchard 1:0.38-2 - BR Test::Output. * Mon Jul 02 2007 Steven Pritchard 1:0.38-1 - Update to DateTime 0.38. - Update to DateTime::TimeZone 0.6602. - BR Test::Pod::Coverage. perl-PAR-Dist-0.24-1.fc8 ------------------------ * Sun Jul 22 2007 Ville Skytt?? - 0.24-1 - 0.24. ruby-shadow-1.4.1-7.fc8 ----------------------- * Wed Jul 18 2007 David Lutterkort - 1.4.1-7 - Remove dependency on ruby{,io}.h from depend - makes builds on RHEL4 fail, and doesn't provide anything for proper rpm builds sane-backends-1.0.18-10.fc8 --------------------------- * Sun Jul 22 2007 Nils Philippsen - 1.0.18-10 - tweak udev rules generation (#244444) xmlrpc-c-1.06.16-1.fc8 ---------------------- * Sun Jul 22 2007 Enrico Scholz - 1.06.16-1 - updated to 1.06.16 Broken deps for i386 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.i386 requires sysklogd kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.i386 requires firefox = 0:2.0.0.4 Democracy - 0.9.5.1-10.fc8.x86_64 requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.i386 requires sysklogd fcron - 3.0.3-1.fc8.x86_64 requires sysklogd kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- Democracy - 0.9.5.1-10.fc8.ppc requires firefox = 0:2.0.0.4 Democracy - 0.9.5.1-10.fc8.ppc64 requires firefox = 0:2.0.0.4 fcron - 3.0.3-1.fc8.ppc requires sysklogd fcron - 3.0.3-1.fc8.ppc64 requires sysklogd glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 From buc at odusz.so-cdu.ru Mon Jul 23 12:43:01 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 23 Jul 2007 16:43:01 +0400 Subject: separate sysv subpackages Message-ID: <46A4A255.3020807@odu.neva.ru> There are some packages in Fedora which place their init scripts as a separate subpackage. That way packagers avoid the dependency of initscripts (and a lot of related dependencies as well), when they do not use initscripts in some local environments. How it could be useful for Fedora? Whether the other packages should split their init scripts as well? Regards, Dmitry Butskoy From jwboyer at jdub.homelinux.org Mon Jul 23 12:59:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 Jul 2007 07:59:14 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185174635.10535.60.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> Message-ID: <1185195554.3165.1.camel@weaponx.rchland.ibm.com> On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote: > On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote: > > Somebody in the thread at some point said: > > > > >> sort of automatic file checking would help flag problems. > > > In trivial cases such as the GPLv3 change, it could help. > > > > > > In cases of packages changing from FOO-license v1.283 to BAR-license > > > v32.100 it doesn't. > > > > Wouldn't it notice the deletion of the FOO-license file at least though > > and flag it up? > If there is any, may-be - If there isn't any, no. > > Also consider: Detached license files are legally questionable/doubtful. > What matters is the license inlined or referenced by each files. Non > copyright owner added licenses are even more questionable. > > > At least then someone > someone == Jef Spaleta or other people from the Board > > > > > In cases of packages pointing to web-sites, it > > > > Yes I guess so, although it could wget the URL periodically and hash > > that (assuming there are no "today's date" and crud on the page) > Feel free to do so ... Feel free to do so if these URLs change or vanish ;) > > > >> Granted its > > >> not going to work for all packages, but it might help a lot in the > > >> specific case of entire project codebases transitioning to gpl3 from a > > >> previous license. > > > If you think so, I disagree. You are driving away contributors from > > > fedora, by imposing more and more bureaucracy. If you really want this > > > > The automated technique is a small burden if it works for most packages. > We already _have_ way too much bureaucracy in Fedora. > > > Since care is taken about the license to get it into Fedora it is > > consistent to take some care about the license after it is in... and > > with fun things like "or later" now... > Feel free to do so - Without me. Shall the "Board" (Whatever > board-de-jour we might be talking about) and the dark forces surrounding > it inside of RH do so - Without me - Period. dark forces? JFC Ralf. josh From ndbecker2 at gmail.com Mon Jul 23 13:33:11 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 23 Jul 2007 09:33:11 -0400 Subject: help make build References: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> <1184951790.4169.1.camel@eagle.danny.cz> Message-ID: Dan Hor?k wrote: > Neal Becker p??e v P? 20. 07. 2007 v 12:47 -0400: >> OK, I'm completely lost: >> >> Jon Ciesla wrote: >> >> > "TAG_OPTS=-F make tag". >> TAG_OPTS=-F make tag >> cvs tag -F -c uncrustify-0_35-1_fc7 >> ? .build-0.35-1.fc7.log >> ? uncrustify-0.35 >> ? uncrustify-0.35-1.fc7.src.rpm >> ? uncrustify-0.35.tgz >> ? x86_64 >> cvs tag: Tagging . >> Tagged with: uncrustify-0_35-1_fc7 >> >> [nbecker at nbecker4 F-7]$ cvs diff >> ? .build-0.35-1.fc7.log >> ? uncrustify-0.35 >> ? uncrustify-0.35-1.fc7.src.rpm >> ? uncrustify-0.35.tgz >> ? x86_64 >> cvs diff: Diffing . > > Did you "make new-sources FILES=uncrustify-0.35.tgz"? > It looks like that you don't have the upstream sources on the build > server. > > I don't think the page http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo mentions 'make new-sources'. I think there should be a link to this info. From harald at redhat.com Mon Jul 23 13:35:27 2007 From: harald at redhat.com (Harald Hoyer) Date: Mon, 23 Jul 2007 15:35:27 +0200 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <1185010759.2414.16.camel@work> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> Message-ID: <46A4AE9F.3030008@redhat.com> Richard Hughes schrieb: > On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: >> Argh. So why _are_ we doing our own special rules instead >> of using the upstream ones ? This isn't the only time I've >> run into something like this with udev. > > Our udev is about 100x times slower than upstream... > > Richard. > > What makes you think so? Is the udevd binary slower? Is selinux making it slower? Are the default rules in /etc/udev/rules.d/05-udev-early.rules /etc/udev/rules.d/50-udev.rules /etc/udev/rules.d/95-pam-console.rules slow? What is upstream? udev-113/etc/udev/redhat or udev-113/etc/udev/suse ???? Don't troll here!! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From limb at jcomserv.net Mon Jul 23 13:21:02 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 23 Jul 2007 08:21:02 -0500 (CDT) Subject: help make build In-Reply-To: References: <43898.65.192.24.164.1184947570.squirrel@mail.jcomserv.net> <1184951790.4169.1.camel@eagle.danny.cz> Message-ID: <35348.65.192.24.164.1185196862.squirrel@mail.jcomserv.net> > Dan Hor??k wrote: > >> Neal Becker p????e v P?? 20. 07. 2007 v 12:47 -0400: >>> OK, I'm completely lost: >>> >>> Jon Ciesla wrote: >>> >>> > "TAG_OPTS=-F make tag". >>> TAG_OPTS=-F make tag >>> cvs tag -F -c uncrustify-0_35-1_fc7 >>> ? .build-0.35-1.fc7.log >>> ? uncrustify-0.35 >>> ? uncrustify-0.35-1.fc7.src.rpm >>> ? uncrustify-0.35.tgz >>> ? x86_64 >>> cvs tag: Tagging . >>> Tagged with: uncrustify-0_35-1_fc7 >>> >>> [nbecker at nbecker4 F-7]$ cvs diff >>> ? .build-0.35-1.fc7.log >>> ? uncrustify-0.35 >>> ? uncrustify-0.35-1.fc7.src.rpm >>> ? uncrustify-0.35.tgz >>> ? x86_64 >>> cvs diff: Diffing . >> >> Did you "make new-sources FILES=uncrustify-0.35.tgz"? >> It looks like that you don't have the upstream sources on the build >> server. >> >> > I don't think the page > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo > mentions 'make new-sources'. I think there should be a link to this info. > It's there, in http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq, which is linked, but I can envision missing that. I did once. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jkeating at redhat.com Mon Jul 23 13:51:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 09:51:37 -0400 Subject: separate sysv subpackages In-Reply-To: <46A4A255.3020807@odu.neva.ru> References: <46A4A255.3020807@odu.neva.ru> Message-ID: <20070723095137.1de0e65a@localhost.localdomain> On Mon, 23 Jul 2007 16:43:01 +0400 Dmitry Butskoy wrote: > How it could be useful for Fedora? Whether the other packages should > split their init scripts as well? At this time, it's not really useful to Fedora. It's useful to downstream consumers of fedora rpms put into derived distributions, but so far I've only heard of one person who makes use of that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Mon Jul 23 14:01:32 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Jul 2007 16:01:32 +0200 Subject: Understanding gnome-power-manager Message-ID: <20070723160132.42d500c9@banea.int.addix.net> Hi. In order to track down an annoying bug on my X60s I'd like a quick explanation of the various "related events" that g-p-m is able to draw into it's graphs. Especially what "Session {active,idle,powersafe}" exactly mean, whos decision they are, and what happens while transisting from one state to the other. Thanks. From notting at redhat.com Mon Jul 23 14:03:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:03:18 -0400 Subject: rsyslog is in F8 In-Reply-To: <46A2A1B5.2080305@kobold.org> References: <469DE95D.8080006@redhat.com> <469DE966.6040109@fedoraproject.org> <1184754853.18158.0.camel@perun.kabelta.loc> <469DEFD7.5030209@nobugconsulting.ro> <469DF797.2010305@redhat.com> <469DF934.2050706@nobugconsulting.ro> <1184765871.9488.4.camel@localhost.localdomain> <469E1D51.2020208@leemhuis.info> <1184767485.9488.13.camel@localhost.localdomain> <46A2A1B5.2080305@kobold.org> Message-ID: <20070723140318.GE15831@nostromo.devel.redhat.com> Wart (wart at kobold.org) said: >>> But shouldn't it be safe to start if the daemon (or the predecessor in >>> this case) was running already? That's what other scripts do iirc. >> Daemons do a condrestart in their %post, not a start. > > I suppose this should now be 'try-restart' to conform with the LSB > specification? > > http://fedoraproject.org/wiki/FCNewInit/Initscripts There's no requirement that the *system* initscripts conform to the LSB, although that can be useful. However, make sure you're not using the functions from the lsb-functions file; we do not want to pull redhat-lsb into a minimal install. Bill From notting at redhat.com Mon Jul 23 14:10:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:10:51 -0400 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <1185010759.2414.16.camel@work> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> Message-ID: <20070723141051.GF15831@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: > > > > Argh. So why _are_ we doing our own special rules instead > > of using the upstream ones ? This isn't the only time I've > > run into something like this with udev. > > Our udev is about 100x times slower than upstream... I find it hard to believe it's 100x slower. I've done testing of it with most of the not-needed-for-booting rules commented out - execution time only dropped from ~5 to ~3.5 seconds. Bill From jwilson at redhat.com Mon Jul 23 14:16:13 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 23 Jul 2007 10:16:13 -0400 Subject: What happened to kernel-kdump-devel in 2.6.22 ? In-Reply-To: References: Message-ID: <46A4B82D.8090501@redhat.com> Gianluca Sforna wrote: > My rebuild of sysprof-kmod is failing due to a missing kernel-kdump-devel: > > http://koji.fedoraproject.org/koji/getfile?taskID=73500&name=root.log > > What happened to it? The x86_64 relocatable kernel patches have been merged upstream for a while now, meaning a separate kdump kernel serves no purpose, so it isn't built, and neither is the corresponding -devel package. Just don't try to build for the kdump kernel anymore, and you should be all set. As an aside, let me just say that pretty much *all* kmod package, save possibly some network and storage drivers, are actually a complete and total waste of time to build for kdump kernels. The kdump kernel loads into a tiny reserved slice of memory, and is only booted into (via kexec, not via bootloader) when a system properly configured for kdump hits a kernel panic. We stay in this kernel long enough to scribble a vmcore out to a target storage location (thus why network and storage kmod drivers *could* be of use), and then the system reboots back into the normal kernel. So things like sysprof, nvidia, capture card drivers, etc., make little or no sense to build for the kdump kernel, never mind the fact that a separate kdump kernel only needs to exist at all for ppc64 anymore... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Mon Jul 23 14:16:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:16:27 -0400 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <46A4AE9F.3030008@redhat.com> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> <46A4AE9F.3030008@redhat.com> Message-ID: <20070723141627.GG15831@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > What makes you think so? > > Is the udevd binary slower? > > Is selinux making it slower? > > Are the default rules in > /etc/udev/rules.d/05-udev-early.rules > /etc/udev/rules.d/50-udev.rules > /etc/udev/rules.d/95-pam-console.rules > slow? > > What is upstream? udev-113/etc/udev/redhat or udev-113/etc/udev/suse ???? I've never noticed it being 100x slower. However, there are a couple of cases for improvement: - make_extra_nodes in start_udev is relatively slow. The more we can avoid using this, the better - 60-libsane.rules takes measureable time in udevd just to *parse*, even though they're skipped on bootup. As part of deprecating/removing pam_console (http://fedoraproject.org/wiki/Releases/FeatureRemovePAMConsole), these can hopefully go away - the bluetooth rules could use some skip/goto - is check_cdrom.sh really needed? But still, this only shaves startup by about a second or so. Bill From notting at redhat.com Mon Jul 23 14:17:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:17:14 -0400 Subject: chkconfig stat level: lots of services in the 90s (was: Re: rpms/cups/devel cups.init,1.12,1.13 cups.spec,1.346,1.347) In-Reply-To: <46A1E88D.60201@leemhuis.info> References: <200707201444.l6KEiiYL021289@cvs-int.fedora.redhat.com> <46A1E88D.60201@leemhuis.info> Message-ID: <20070723141714.GH15831@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > noticed below commit and started to wonder: why do we have so many > services with start-levels between 90 and 99? On my F7 machine there > seems to be at least 6 services which anlone use the level 98 (see below > as well) -- and lots of them start after readahead_later, which is, if I > understood readahead_later correctly, not what we want. > > Is it time for somebody to just take a look at the mess ^w^w all the > init script we ship, take a look at the interdependencies and reorder > some of them and use the whole space between 0 and 99 more sanely (maybe > we should track it in the wiki -- not sure)? Or is that unneeded with > the "FCNewInit" stuff on the horizon? Theoretically, if they're all using dependencies, this will sort itself out. After all, it's just a number. Bill From notting at redhat.com Mon Jul 23 14:24:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 10:24:43 -0400 Subject: separate sysv subpackages In-Reply-To: <46A4A255.3020807@odu.neva.ru> References: <46A4A255.3020807@odu.neva.ru> Message-ID: <20070723142443.GK15831@nostromo.devel.redhat.com> Dmitry Butskoy (buc at odusz.so-cdu.ru) said: > There are some packages in Fedora which place their init scripts as a > separate subpackage. That way packagers avoid the dependency of initscripts > (and a lot of related dependencies as well), when they do not use > initscripts in some local environments. > > How it could be useful for Fedora? Whether the other packages should split > their init scripts as well? In fact, I can see splits like this causing severe confusion on upgrade if the initscript moves between packages and there are no dependencies to pull it in. Bill From dmc.fedora at filteredperception.org Mon Jul 23 14:29:10 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 23 Jul 2007 09:29:10 -0500 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <20070723141051.GF15831@nostromo.devel.redhat.com> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> <20070723141051.GF15831@nostromo.devel.redhat.com> Message-ID: <46A4BB36.3070403@filteredperception.org> Bill Nottingham wrote: > Richard Hughes (hughsient at gmail.com) said: >> On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: >>> Argh. So why _are_ we doing our own special rules instead >>> of using the upstream ones ? This isn't the only time I've >>> run into something like this with udev. >> Our udev is about 100x times slower than upstream... > > I find it hard to believe it's 100x slower. I've done testing > of it with most of the not-needed-for-booting rules commented out - > execution time only dropped from ~5 to ~3.5 seconds. This may be something unrelated (qemu bug?), but I feel I should mention- When I boot livecds that I've spun with livecd-creator in qemu, the udev step takes a painfully long time to complete, and even just hangs a fair percentage of the time. Has anyone else noticed anything like this? At some point I'll do a little more research and file a proper bug. -dmc From jkeating at redhat.com Mon Jul 23 14:42:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 10:42:00 -0400 Subject: Plan for Today's (20070723) Release Engineering meeting Message-ID: <20070723104200.01cf0456@localhost.localdomain> Below you will find a list of topics that we'd like to go over in the next RelEng meeting that is scheduled for Today, Monday at 1700 UTC in #fedora-meeting on irc.freenode.org: /topic RELENG-Meeting - F8Test1 - JesseKeating /topic RELENG-Meeting - Open Discussion You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Open Discussion" phase. If your name/nick is on above list please update the status on the ReleaseEngineering/Meetings/Agenda page in the wiki ahead of the meeting. That way all the other RelEng members and interested contributors know whats up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his/her slow typing... -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rhally at mindspring.com Mon Jul 23 14:53:08 2007 From: rhally at mindspring.com (Richard Hally) Date: Mon, 23 Jul 2007 10:53:08 -0400 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <46A4BB36.3070403@filteredperception.org> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> <20070723141051.GF15831@nostromo.devel.redhat.com> <46A4BB36.3070403@filteredperception.org> Message-ID: <46A4C0D4.2080101@mindspring.com> Douglas McClendon wrote: > Bill Nottingham wrote: >> Richard Hughes (hughsient at gmail.com) said: >>> On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: >>>> Argh. So why _are_ we doing our own special rules instead >>>> of using the upstream ones ? This isn't the only time I've >>>> run into something like this with udev. >>> Our udev is about 100x times slower than upstream... >> >> I find it hard to believe it's 100x slower. I've done testing >> of it with most of the not-needed-for-booting rules commented out - >> execution time only dropped from ~5 to ~3.5 seconds. > > This may be something unrelated (qemu bug?), but I feel I should mention- > > When I boot livecds that I've spun with livecd-creator in qemu, the udev > step takes a painfully long time to complete, and even just hangs a fair > percentage of the time. > > Has anyone else noticed anything like this? At some point I'll do a > little more research and file a proper bug. > > -dmc > yes, on my rawhide box ( a P4 3.2Ghz with H/T) when booting I get to the "starting udev:" and it sits there for 2:44 (that is 2 minutes and 44 seconds)! then continues booting. HTH Richard From hughsient at gmail.com Mon Jul 23 14:55:31 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 23 Jul 2007 15:55:31 +0100 Subject: Understanding gnome-power-manager In-Reply-To: <20070723160132.42d500c9@banea.int.addix.net> References: <20070723160132.42d500c9@banea.int.addix.net> Message-ID: <1185202531.2907.7.camel@work> On Mon, 2007-07-23 at 16:01 +0200, Ralf Ertzinger wrote: > Hi. > > In order to track down an annoying bug on my X60s I'd like a > quick explanation of the various "related events" that g-p-m > is able to draw into it's graphs. Sure. This needs to be in the help file, those with better persuasion of English than me welcome to submit patches :-) > Especially what "Session {active,idle,powersafe}" exactly mean, > whos decision they are, and what happens while transisting from one > state to the other. active = mouse moved within last idle time powersave = session inactive for a few seconds idle = session inactive for time set in gnome-screensaver so we get: {idle} active -> powersave -> idle {mouse moved} idle -> active Inhibit() also stops the machine going to idle, and a g-s inhibit stops the machine going to powersave. Does that make things clearer? Richard From fedora at camperquake.de Mon Jul 23 15:10:31 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Jul 2007 17:10:31 +0200 Subject: Understanding gnome-power-manager In-Reply-To: <1185202531.2907.7.camel@work> References: <20070723160132.42d500c9@banea.int.addix.net> <1185202531.2907.7.camel@work> Message-ID: <20070723171031.64bfc371@banea.int.addix.net> Hi. On Mon, 23 Jul 2007 15:55:31 +0100, Richard Hughes wrote: > active = mouse moved within last idle time > powersave = session inactive for a few seconds > idle = session inactive for time set in gnome-screensaver OK. > {idle} > active -> powersave -> idle > > {mouse moved} > idle -> active > > Inhibit() also stops the machine going to idle, and a g-s inhibit > stops the machine going to powersave. What is Inhibit()? Is it user controllable? > Does that make things clearer? Yes, it does. I think I'll file a bug against g-p-m for my problem (which is, basically, that the display brightness indicator pops up when the system goes from powersave to active (and sometimes in the other direction, too), although the brightness did not change, and I did not request any change, either). From bpepple at fedoraproject.org Mon Jul 23 15:13:21 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 23 Jul 2007 11:13:21 -0400 Subject: Plan for Today's (20070723) Release Engineering meeting In-Reply-To: <20070723104200.01cf0456@localhost.localdomain> References: <20070723104200.01cf0456@localhost.localdomain> Message-ID: <1185203601.2778.13.camel@kennedy> On Mon, 2007-07-23 at 10:42 -0400, Jesse Keating wrote: > Below you will find a list of topics that we'd like to go over in the next > RelEng meeting that is scheduled for Today, Monday at 1700 UTC in > #fedora-meeting on irc.freenode.org: > > /topic RELENG-Meeting - F8Test1 - JesseKeating > > /topic RELENG-Meeting - Open Discussion > If you guys have time could you start discussing when the rel-eng would like cvs branching to occur? Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 chris.stone at gmail.com Mon Jul 23 15:17:37 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 23 Jul 2007 08:17:37 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070723004934.GA28551@jadzia.bu.edu> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> Message-ID: On 7/22/07, Matthew Miller wrote: > On Sun, Jul 22, 2007 at 03:15:24PM -0700, Christopher Stone wrote: > > How can one possibly argue that an installed application should not > > show up in a users menu? > > Easily. Too many menu items make the menu useless. Not everything should be > there. Instead, put some thought into it. Obviously zero amount of thought is being used right now because there is no reason why an application like kate or banshee (just to name a couple) should not show up in an Xfce desktop menu. From ajackson at redhat.com Mon Jul 23 15:01:29 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 23 Jul 2007 11:01:29 -0400 Subject: the most serious bug in F7 I found so far... In-Reply-To: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> References: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> Message-ID: <1185202889.2794.92.camel@localhost.localdomain> On Sun, 2007-07-15 at 15:43 +0200, Valent Turkovic wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246593 > > This is the most serious bug I found in Fedora 7 so please look at it > and tell me what more info you need of me. I have a response I'd like to give about this bug, but unfortunately, your email tells me nothing about what the bug is. The irony here is that, after clicking through, this probably is my bug to fix, and this email only got seen because of morbid curiosity. Normally I skip things that don't seem like they're related to what I'm working on, and there are plenty of things in F7 with "serious bugs". - ajax From jkeating at redhat.com Mon Jul 23 15:18:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 11:18:12 -0400 Subject: Plan for Today's (20070723) Release Engineering meeting In-Reply-To: <1185203601.2778.13.camel@kennedy> References: <20070723104200.01cf0456@localhost.localdomain> <1185203601.2778.13.camel@kennedy> Message-ID: <20070723111812.58adf72f@localhost.localdomain> On Mon, 23 Jul 2007 11:13:21 -0400 Brian Pepple wrote: > If you guys have time could you start discussing when the rel-eng > would like cvs branching to occur? I wanted to table that until after Test1. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Mon Jul 23 15:25:24 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Jul 2007 17:25:24 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185174635.10535.60.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> Message-ID: <1185204325.9305.6.camel@gibraltar.stuttgart.redhat.com> On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote: > On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote: > > The automated technique is a small burden if it works for most packages. > We already _have_ way too much bureaucracy in Fedora. automation != bureaucracy > > Since care is taken about the license to get it into Fedora it is > > consistent to take some care about the license after it is in... and > > with fun things like "or later" now... > Feel free to do so - Without me. Shall the "Board" (Whatever > board-de-jour we might be talking about) and the dark forces surrounding > it inside of RH do so - Without me - Period. Dark forces? Man, I'd like to have your imagination... I'll repeat myself, but: notifying others of license changes is only courteous. If there is a rule to do it that way, so much for the better -- no nasty surprises for me as the packager or developer person using the package. If that can be assisted in an automated fashion, what is the problem? And Ralf, please refrain from PMs just to make comments that are way out of line. Thanks. 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 notting at redhat.com Mon Jul 23 15:25:32 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Jul 2007 11:25:32 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> Message-ID: <20070723152532.GA2941@nostromo.devel.redhat.com> Christopher Stone (chris.stone at gmail.com) said: > On 7/22/07, Matthew Miller wrote: >> On Sun, Jul 22, 2007 at 03:15:24PM -0700, Christopher Stone wrote: >> > How can one possibly argue that an installed application should not >> > show up in a users menu? >> >> Easily. Too many menu items make the menu useless. Not everything should >> be >> there. Instead, put some thought into it. > > Obviously zero amount of thought is being used right now because there > is no reason why an application like kate or banshee (just to name a > couple) should not show up in an Xfce desktop menu. Well, I'd argue that showing things like both of kreversi/iagno in GNOME/KDE is rather silly. Perhaps we need a DoNotShowIn rather than OnlyShowIn. Bill From jkeating at redhat.com Mon Jul 23 15:25:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 11:25:48 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> Message-ID: <20070723112548.49ffaae0@localhost.localdomain> On Mon, 23 Jul 2007 08:17:37 -0700 "Christopher Stone" wrote: > kate On a shared system where some users prefer Gnome and some prefer KDE, I don't want to have KDE apps such as kate cluttering up the Gnome users's menu. Likewise I wouldn't want the KDE user to be cluttered with gnome. As stated before, perhaps what is needed is the tools such as gnome-menu or whatever xfce uses ignore the ShowOnlyIn argument and display them all anyway. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hughsient at gmail.com Mon Jul 23 15:25:20 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 23 Jul 2007 16:25:20 +0100 Subject: Understanding gnome-power-manager In-Reply-To: <20070723171031.64bfc371@banea.int.addix.net> References: <20070723160132.42d500c9@banea.int.addix.net> <1185202531.2907.7.camel@work> <20070723171031.64bfc371@banea.int.addix.net> Message-ID: <1185204320.2907.11.camel@work> On Mon, 2007-07-23 at 17:10 +0200, Ralf Ertzinger wrote: > What is Inhibit()? Is it user controllable? See the FAQ: http://live.gnome.org/GnomePowerManager/FAQ > > Does that make things clearer? > > Yes, it does. I think I'll file a bug against g-p-m for my problem > (which is, basically, that the display brightness indicator pops > up when the system goes from powersave to active (and sometimes in > the other direction, too), although the brightness did not change, > and I did not request any change, either). You might want to try svn first, there's been some fixes for that recently. Richard, From fedora at camperquake.de Mon Jul 23 15:44:03 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Jul 2007 17:44:03 +0200 Subject: Understanding gnome-power-manager In-Reply-To: <1185204320.2907.11.camel@work> References: <20070723160132.42d500c9@banea.int.addix.net> <1185202531.2907.7.camel@work> <20070723171031.64bfc371@banea.int.addix.net> <1185204320.2907.11.camel@work> Message-ID: <20070723174403.118cdae1@banea.int.addix.net> Hi. On Mon, 23 Jul 2007 16:25:20 +0100, Richard Hughes wrote: > You might want to try svn first, there's been some fixes for that > recently. Thanks, will look into it. From fedora at camperquake.de Mon Jul 23 15:50:51 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Jul 2007 17:50:51 +0200 Subject: rawhide report: 20070723 changes In-Reply-To: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> Message-ID: <20070723175051.784379e7@banea.int.addix.net> Moin. On Mon, 23 Jul 2007 05:39:02 -0400, Build System wrote: > kernel-2.6.23-0.44.rc0.git16.fc8 > -------------------------------- > * Sat Jul 21 2007 Roland McGrath > - Fix biarch issue in linux-2.6-elf-core-sysctl.patch Something's fishy with this one. It is significantly smaller than the kernels before it (factor of 3 for binaries and devel, -PAE version), and yum installing this wants to remove almost all older kernel versions. From jspaleta at gmail.com Mon Jul 23 15:58:20 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 23 Jul 2007 07:58:20 -0800 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185171610.10535.52.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> Message-ID: <604aa7910707230858y570eca2fp7f965e2fd554900a@mail.gmail.com> On 7/22/07, Ralf Corsepius wrote: > If you think so, I disagree. You are driving away contributors from > fedora, by imposing more and more bureaucracy. If you really want this > YOU (Jef Spaleta in person) will have to do it yourselves. I am watching for upstream licensing changes in about as many places as I can think to look. But I am only two people... two very stupid people, with a reading comprehension problem. And please, I sincerely would like to hear off-list from any contributors( other than Ralf) who are being driven away from fedora because of the request to keep the rest of the contributor pool informed of re-licensing issues. I realize that every policy decision has an implementation cost. But given the importance of licensing to the overall availability of the software repository, I don't think the request to keep the maintainer pool informed is over-burdensome. I very much would like to avoid getting into a situation where a serious re-licensing issues necessitates a major disruption in workflow for everyone who currently uses cvs commit access. I'm not much of a gambler, so given the choice I'd rather encourage a proactive approach to the initial season of gpl3 re-licensing, then to wait to be reactive to a licensing problem after it appears inside our software repository. I'd absolutely love it if we could all collectively bury our heads in the sand as upstream codebases choose to re-license under gpl3. I'd love it if we could all be free to be irresponsible. But we can't, the continued availability of the software repository and build system depends on making sure we don't inadvertently introduce licensing violations. The only way we are going to avoid problems, especially with violations concerning library linking, is if we, as a community of peers, communicate re-licensing issues before they enter our repository. -jef"death eater's local #205"spaleta From bpepple at fedoraproject.org Mon Jul 23 16:44:01 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 23 Jul 2007 12:44:01 -0400 Subject: Plan for Today's (20070723) Release Engineering meeting In-Reply-To: <20070723111812.58adf72f@localhost.localdomain> References: <20070723104200.01cf0456@localhost.localdomain> <1185203601.2778.13.camel@kennedy> <20070723111812.58adf72f@localhost.localdomain> Message-ID: <1185209041.2778.32.camel@kennedy> On Mon, 2007-07-23 at 11:18 -0400, Jesse Keating wrote: > On Mon, 23 Jul 2007 11:13:21 -0400 > Brian Pepple wrote: > > > If you guys have time could you start discussing when the rel-eng > > would like cvs branching to occur? > > I wanted to table that until after Test1. No problem. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 jwilson at redhat.com Mon Jul 23 16:48:53 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 23 Jul 2007 12:48:53 -0400 Subject: rawhide report: 20070723 changes In-Reply-To: <20070723175051.784379e7@banea.int.addix.net> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> <20070723175051.784379e7@banea.int.addix.net> Message-ID: <46A4DBF5.5050204@redhat.com> Ralf Ertzinger wrote: > Moin. > > On Mon, 23 Jul 2007 05:39:02 -0400, Build System wrote: > >> kernel-2.6.23-0.44.rc0.git16.fc8 >> -------------------------------- >> * Sat Jul 21 2007 Roland McGrath >> - Fix biarch issue in linux-2.6-elf-core-sysctl.patch > > Something's fishy with this one. > It is significantly smaller than the kernels before it (factor of 3 > for binaries and devel, -PAE version), and yum installing this wants > to remove almost all older kernel versions. Just looking at the builds in koji, everything looks sane... At least, these trees all have files that aren't abnormally different in size: http://koji.fedoraproject.org/packages/kernel/2.6.23/0.28.rc0.git6.fc8/ http://koji.fedoraproject.org/packages/kernel/2.6.23/0.35.rc0.git6.fc8/ http://koji.fedoraproject.org/packages/kernel/2.6.23/0.44.rc0.git16.fc8/ http://koji.fedoraproject.org/packages/kernel/2.6.23/0.45.rc0.git16.fc8/ Perhaps you're seeing an issue w/a bad mirror? -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Mon Jul 23 16:54:21 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 23 Jul 2007 19:54:21 +0300 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: <20070723152532.GA2941@nostromo.devel.redhat.com> References: <20070723152532.GA2941@nostromo.devel.redhat.com> Message-ID: <200707231954.22097.ville.skytta@iki.fi> On Monday 23 July 2007, Bill Nottingham wrote: > Perhaps we need a DoNotShowIn rather than OnlyShowIn. Just in case people are not aware of it, NotShowIn already exists. http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys From dmc.fedora at filteredperception.org Mon Jul 23 17:16:17 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 23 Jul 2007 12:16:17 -0500 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <46A4C0D4.2080101@mindspring.com> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> <20070723141051.GF15831@nostromo.devel.redhat.com> <46A4BB36.3070403@filteredperception.org> <46A4C0D4.2080101@mindspring.com> Message-ID: <46A4E261.301@filteredperception.org> Richard Hally wrote: > Douglas McClendon wrote: >> Bill Nottingham wrote: >>> Richard Hughes (hughsient at gmail.com) said: >>>> On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: >>>>> Argh. So why _are_ we doing our own special rules instead >>>>> of using the upstream ones ? This isn't the only time I've >>>>> run into something like this with udev. >>>> Our udev is about 100x times slower than upstream... >>> >>> I find it hard to believe it's 100x slower. I've done testing >>> of it with most of the not-needed-for-booting rules commented out - >>> execution time only dropped from ~5 to ~3.5 seconds. >> >> This may be something unrelated (qemu bug?), but I feel I should mention- >> >> When I boot livecds that I've spun with livecd-creator in qemu, the >> udev step takes a painfully long time to complete, and even just hangs >> a fair percentage of the time. >> >> Has anyone else noticed anything like this? At some point I'll do a >> little more research and file a proper bug. >> >> -dmc >> > yes, on my rawhide box ( a P4 3.2Ghz with H/T) when booting I get to the > "starting udev:" and it sits there for 2:44 (that is 2 minutes and 44 > seconds)! > then continues booting. > HTH > Richard I'm glad I'm not the only one. The main reason, until this thread, that I pegged it for a qemu bug was that I can hit the hang/2:44 scenario, ctrl-c, and restart with the exact same commandline*, and then it will take a slow, but reasonable (~15-30s) time to complete. * I'm almost positive it has happened at times when I'm either only using cdrom, or using -snapshot. Thus no changed state on the disk file could explain this. Another reason I suspect qemu, is I see plenty of kernel messages relating to problems with the cdrom drive spewing by, which are otherwise ignorable. I'm assuming those have something to do with the new ata driver stuff in f7, and that I should just wait a little while for other people to iron those things out. But then, given the topic that started this thread, makes me wonder if tweaking some udev rules wouldn't perhaps workaround this problem. Anybody have any ideas for experiments - either with some debug/verbose setting or alternate rules? -dmc From mattdm at mattdm.org Mon Jul 23 17:52:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 23 Jul 2007 13:52:02 -0400 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A107C1.8020801@cohtech.com> References: <46A107C1.8020801@cohtech.com> Message-ID: <20070723175202.GA11657@jadzia.bu.edu> On Fri, Jul 20, 2007 at 08:06:41PM +0100, Howard Wilkinson wrote: > First the version of yum available in updates currently is incompatible > with the version of anaconda. The problem is that this version of yum > does not create the headers directory and anaconda assumes it will exist. > anaconda-11.2.0.66-1.i386.rpm > yum-3.2.1-1.fc7 > To get round this we have reverted to yum-3.2.0-1.fc7.noarch.rpm for now > but will probably try out the development releases of anaconda and yum > next week. Pull this patch from Anaconda CVS: Index: yuminstall.py =================================================================== RCS file: /usr/local/CVS/anaconda/yuminstall.py,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- yuminstall.py 26 Jun 2007 18:58:55 -0000 1.290 +++ yuminstall.py 27 Jun 2007 15:59:35 -0000 1.291 @@ -242,6 +242,11 @@ self.setAttribute('pkgdir', root) self.setAttribute('hdrdir', '/tmp/cache/headers') + def dirSetup(self): + YumRepository.dirSetup(self) + if not os.path.isdir(self.hdrdir): + os.makedirs(self.hdrdir, mode=0755) + #XXX: FIXME duplicated from YumRepository due to namespacing def __headersListFromDict(self): """Convert our dict of headers to a list of 2-tuples for urlgrabber.""" -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jul 23 18:03:57 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 24 Jul 2007 03:03:57 +0900 Subject: rpms/rsyslog/devel .cvsignore, 1.3, 1.4 rsyslog.spec, 1.2, 1.3 sources, 1.3, 1.4 rsyslog-1.17.1-rOptionCompat.patch, 1.1, NONE In-Reply-To: <200707231449.l6NEnkQA023145@cvs-int.fedora.redhat.com> References: <200707231449.l6NEnkQA023145@cvs-int.fedora.redhat.com> Message-ID: <46A4ED8D.5030805@ioa.s.u-tokyo.ac.jp> Peter Vrabec (pvrabec) wrote, at 07/23/2007 11:49 PM +9:00: > > > Index: rsyslog.spec > =================================================================== > RCS file: /cvs/extras/rpms/rsyslog/devel/rsyslog.spec,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -r1.2 -r1.3 > --- rsyslog.spec 20 Jul 2007 10:43:39 -0000 1.2 > +++ rsyslog.spec 23 Jul 2007 14:49:14 -0000 1.3 > @@ -1,9 +1,9 @@ > -%define with_db 0 > -%define sbindir /sbin > +%define with_db 0 > +%define sbindir /sbin > > Summary: Enhanced system logging and kernel message trapping daemons > Name: rsyslog > -Version: 1.17.1 > +Version: 1.17.2 > Release: 1%{?dist} > License: GPL > Group: System Environment/Daemons > @@ -11,7 +11,6 @@ > Source0: http://download.adiscon.com/rsyslog/%{name}-%{version}.tar.gz > Source1: rsyslog.init > Source2: rsyslog.sysconfig > -Patch1: rsyslog-1.17.1-rOptionCompat.patch > Conflicts: logrotate < 3.5.2 > %if %{with_db} > BuildRequires: mysql-devel >= 4.0 > @@ -24,6 +23,7 @@ > Requires(preun): /sbin/chkconfig /sbin/chkconfig > Requires(postun): /sbin/service > Provides: syslog > +Provides: sysklogd > Obsoletes: sysklogd > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) I got the following error: [root at localhost mock]# yum -y upgrade rsyslog Setting up Upgrade Process Resolving Dependencies --> Running transaction check ---> Package rsyslog.i386 0:1.17.2-1.fc8 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: rsyslog i386 1.17.2-1.fc8 koji 151 k Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 151 k Downloading Packages: Running rpm_check_debug --> Populating transaction set with selected packages. Please wait. ---> Package rsyslog.i386 0:1.17.2-1.fc8 set to be updated ERROR with rpm_check_debug vs depsolve: Package vixie-cron conflicts with sysklogd < 1.4.1. Complete! Regards, Mamoru From jkeating at redhat.com Mon Jul 23 18:07:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 14:07:50 -0400 Subject: rpms/rsyslog/devel .cvsignore, 1.3, 1.4 rsyslog.spec, 1.2, 1.3 sources, 1.3, 1.4 rsyslog-1.17.1-rOptionCompat.patch, 1.1, NONE In-Reply-To: <46A4ED8D.5030805@ioa.s.u-tokyo.ac.jp> References: <200707231449.l6NEnkQA023145@cvs-int.fedora.redhat.com> <46A4ED8D.5030805@ioa.s.u-tokyo.ac.jp> Message-ID: <20070723140750.3c2f0ff7@localhost.localdomain> On Tue, 24 Jul 2007 03:03:57 +0900 Mamoru Tasaka wrote: > > Provides: syslog > > +Provides: sysklogd > > Obsoletes: sysklogd Please follow the packaging guidelines for Obsoletes/Provides. http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Mon Jul 23 18:24:49 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Jul 2007 20:24:49 +0200 Subject: rawhide report: 20070723 changes In-Reply-To: <46A4DBF5.5050204@redhat.com> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> <20070723175051.784379e7@banea.int.addix.net> <46A4DBF5.5050204@redhat.com> Message-ID: <20070723202449.6c359acb@lain.camperquake.de> Hi. On Mon, 23 Jul 2007 12:48:53 -0400, Jarod Wilson wrote > Perhaps you're seeing an issue w/a bad mirror? No, the size mystery has cleared up. yum --upgrade shows me this: Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kernel-PAE i686 2.6.23-0.44.rc0.git16.fc8 development 17 M kernel-PAE-devel i686 2.6.23-0.44.rc0.git16.fc8 development 4.6 M Removing: kernel-PAE i686 2.6.23-0.30.rc0.git6.fc8 installed 48 M kernel-PAE i686 2.6.22-8.fc8 installed 47 M kernel-PAE i686 2.6.23-0.35.rc0.git6.fc8 installed 48 M kernel-PAE-devel i686 2.6.23-0.35.rc0.git6.fc8 installed 15 M kernel-PAE-devel i686 2.6.23-0.30.rc0.git6.fc8 installed 15 M kernel-PAE-devel i686 2.6.22-8.fc8 installed 15 M The "Size" for the installed (to be removed) packages is the actual on disk size of the package (as displayed by --qf "%{SIZE}\n"). The "Size" for the packages to be installed is the file size. Still does not explain why the other kernels have to go, though. From jkeating at redhat.com Mon Jul 23 18:28:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 14:28:03 -0400 Subject: rawhide report: 20070723 changes In-Reply-To: <20070723202449.6c359acb@lain.camperquake.de> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> <20070723175051.784379e7@banea.int.addix.net> <46A4DBF5.5050204@redhat.com> <20070723202449.6c359acb@lain.camperquake.de> Message-ID: <20070723142803.281590e0@localhost.localdomain> On Mon, 23 Jul 2007 20:24:49 +0200 Ralf Ertzinger wrote: > Still does not explain why the other kernels have to go, though. There is a yum config to keep only N number of packages (like kernel) installed. It used to be the installonlyn plugin, but I think that code was rolled into yum itself and a config entry is used. Yum changelogs and/or Seth would know more 9: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Mon Jul 23 18:29:57 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 23 Jul 2007 14:29:57 -0400 Subject: rawhide report: 20070723 changes In-Reply-To: <20070723202449.6c359acb@lain.camperquake.de> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> <20070723175051.784379e7@banea.int.addix.net> <46A4DBF5.5050204@redhat.com> <20070723202449.6c359acb@lain.camperquake.de> Message-ID: <46A4F3A5.7010001@redhat.com> Ralf Ertzinger wrote: > Hi. > > On Mon, 23 Jul 2007 12:48:53 -0400, Jarod Wilson wrote > >> Perhaps you're seeing an issue w/a bad mirror? > > No, the size mystery has cleared up. > yum --upgrade shows me this: > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > kernel-PAE i686 2.6.23-0.44.rc0.git16.fc8 development 17 M > kernel-PAE-devel i686 2.6.23-0.44.rc0.git16.fc8 development 4.6 M > Removing: > kernel-PAE i686 2.6.23-0.30.rc0.git6.fc8 installed 48 M > kernel-PAE i686 2.6.22-8.fc8 installed 47 M > kernel-PAE i686 2.6.23-0.35.rc0.git6.fc8 installed 48 M > kernel-PAE-devel i686 2.6.23-0.35.rc0.git6.fc8 installed 15 M > kernel-PAE-devel i686 2.6.23-0.30.rc0.git6.fc8 installed 15 M > kernel-PAE-devel i686 2.6.22-8.fc8 installed 15 M > > > The "Size" for the installed (to be removed) packages is the actual on > disk size of the package (as displayed by --qf "%{SIZE}\n"). > The "Size" for the packages to be installed is the file size. Ah, that size mismatch. Yeah, that's normal. :) > Still does not explain why the other kernels have to go, though. What Jesse said and/or the yum changelog and/or Seth says. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From seg at haxxed.com Mon Jul 23 18:26:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 23 Jul 2007 13:26:31 -0500 Subject: separate sysv subpackages In-Reply-To: <20070723095137.1de0e65a@localhost.localdomain> References: <46A4A255.3020807@odu.neva.ru> <20070723095137.1de0e65a@localhost.localdomain> Message-ID: <1185215191.25858.153.camel@localhost.localdomain> On Mon, 2007-07-23 at 09:51 -0400, Jesse Keating wrote: > At this time, it's not really useful to Fedora. It's useful to > downstream consumers of fedora rpms put into derived distributions, but > so far I've only heard of one person who makes use of that. Downstream packagers can just make some kind of dummy package that Provides: initscripts or whatever, if they're really that dead set on removing/replacing an otherwise vital system package like initscripts, rather than pushing this into Fedora. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From luya_tfz at thefinalzone.com Mon Jul 23 19:12:30 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Mon, 23 Jul 2007 12:12:30 -0700 Subject: Moving echo-icon-theme to new host, follow-up Message-ID: <46A4FD9E.70703@thefinalzone.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I would like to get assistance to modify J5 script, echo_pull[1] to only download icons (both png and svg) from Echo development page[2]. I don't have a very good skill on python. The goal is to migrate all Echo icons to a new host[3]. Fedora contributors can have access to this directors for downloading and uploading icons. I have submitted a ticket for hosting package generated by echo_pull to ease the process.[4] Thank you, Luya [1]http://people.redhat.com/johnp/files/echo/echo_pull.tar.bz2 [2]http://fedoraproject.org/wiki/Artwork/EchoDevelopment [3]http://luya.fedorapeople.org/images/echo [4]https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/69 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGpP2ca10Jb0NOz+ERAiSjAJ0eKkwzOu6blskYbG8netdItWL8YACeOcKO 6g/ZLEulifF1lH/NOpRI/14= =99RD -----END PGP SIGNATURE----- From mclasen at redhat.com Mon Jul 23 19:26:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 23 Jul 2007 15:26:06 -0400 Subject: Moving echo-icon-theme to new host, follow-up In-Reply-To: <46A4FD9E.70703@thefinalzone.com> References: <46A4FD9E.70703@thefinalzone.com> Message-ID: <1185218766.13048.12.camel@dhcp83-186.boston.redhat.com> On Mon, 2007-07-23 at 12:12 -0700, Luya Tshimbalanga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I would like to get assistance to modify J5 script, echo_pull[1] to > only download icons (both png and svg) from Echo development page[2]. > I don't have a very good skill on python. The goal is to migrate all > Echo icons to a new host[3]. Fedora contributors can have access to > this directors for downloading and uploading icons. I have submitted a > ticket for hosting package generated by echo_pull to ease the process.[4] > I would really hope that moving Echo to different hosting also includes moving to some kind of RCS, so that we can get rid of all the pull nonsense and just check it out. From kevin.kofler at chello.at Mon Jul 23 19:27:57 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 23 Jul 2007 19:27:57 +0000 (UTC) Subject: Fwd: Re: film at 11: kernel update breaks udev. References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> <20070723141051.GF15831@nostromo.devel.redhat.com> <46A4BB36.3070403@filteredperception.org> <46A4C0D4.2080101@mindspring.com> <46A4E261.301@filteredperception.org> Message-ID: Douglas McClendon filteredperception.org> writes: > Another reason I suspect qemu, is I see plenty of kernel messages relating to > problems with the cdrom drive spewing by, which are otherwise ignorable. I'm > assuming those have something to do with the new ata driver stuff in f7, and > that I should just wait a little while for other people to iron those things > out. Workaround here: https://www.redhat.com/archives/fedora-list/2007-June/msg00551.html A real fix would probably have to be within QEMU's CD-ROM emulation. Kevin Kofler From redhat at olen.net Mon Jul 23 20:26:28 2007 From: redhat at olen.net (Ola Thoresen) Date: Mon, 23 Jul 2007 22:26:28 +0200 Subject: Fwd: Re: film at 11: kernel update breaks udev. In-Reply-To: <46A4E261.301@filteredperception.org> References: <20070721045519.GB19314@redhat.com> <1185010759.2414.16.camel@work> <20070723141051.GF15831@nostromo.devel.redhat.com> <46A4BB36.3070403@filteredperception.org> <46A4C0D4.2080101@mindspring.com> <46A4E261.301@filteredperception.org> Message-ID: <46A50EF4.4030206@olen.net> Douglas McClendon wrote: > Richard Hally wrote: >> Douglas McClendon wrote: >>> Bill Nottingham wrote: >>>> Richard Hughes (hughsient at gmail.com) said: >>>>> On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote: >>>>>> Argh. So why _are_ we doing our own special rules instead >>>>>> of using the upstream ones ? This isn't the only time I've >>>>>> run into something like this with udev. >>>>> Our udev is about 100x times slower than upstream... >>>> >>>> I find it hard to believe it's 100x slower. I've done testing >>>> of it with most of the not-needed-for-booting rules commented out - >>>> execution time only dropped from ~5 to ~3.5 seconds. >>> >>> This may be something unrelated (qemu bug?), but I feel I should >>> mention- >>> >>> When I boot livecds that I've spun with livecd-creator in qemu, the >>> udev step takes a painfully long time to complete, and even just >>> hangs a fair percentage of the time. >>> >>> Has anyone else noticed anything like this? At some point I'll do a >>> little more research and file a proper bug. >>> >>> -dmc >>> >> yes, on my rawhide box ( a P4 3.2Ghz with H/T) when booting I get to >> the "starting udev:" and it sits there for 2:44 (that is 2 minutes and >> 44 seconds)! >> then continues booting. > > I'm glad I'm not the only one. The main reason, until this thread, that > I pegged it for a qemu bug was that I can hit the hang/2:44 scenario, > ctrl-c, and restart with the exact same commandline*, and then it will > take a slow, but reasonable (~15-30s) time to complete. I've had this problem (an extremely long wait for things like udev to start) when the configs are referencing users (or groups) that do not exist in /etc/passwd, and an ldap-server is defined in /etc/ldap.conf and that server is unavailable. Just a thought... -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From luya_tfz at thefinalzone.com Mon Jul 23 20:26:34 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Mon, 23 Jul 2007 13:26:34 -0700 Subject: Moving echo-icon-theme to new host, follow-up In-Reply-To: <1185218766.13048.12.camel@dhcp83-186.boston.redhat.com> References: <46A4FD9E.70703@thefinalzone.com> <1185218766.13048.12.camel@dhcp83-186.boston.redhat.com> Message-ID: <46A50EFA.5030907@thefinalzone.com> Matthias Clasen a ?crit : > I would really hope that moving Echo to different hosting also includes moving > to some kind of RCS, so that we can get rid of all the pull nonsense and > just check it out. > It will. Just it is very hard to tell if all icons from the wiki is included using that echo_pull script. Since it already sorted these icons categories, hosting as they are will be easier and we will no longer have to use pull script again. I am wondering it gtk-icon-coverage-check requires some modifications as well. FAS group named gitecho-icon-theme will be ready shorty. I chose to get git as SCM. Regards, Luya From jonathan.underwood at gmail.com Mon Jul 23 20:28:04 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 23 Jul 2007 21:28:04 +0100 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070723112548.49ffaae0@localhost.localdomain> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> Message-ID: <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> On 23/07/07, Jesse Keating wrote: > On Mon, 23 Jul 2007 08:17:37 -0700 > "Christopher Stone" wrote: > > > kate > > On a shared system where some users prefer Gnome and some prefer KDE, I > don't want to have KDE apps such as kate cluttering up the Gnome > users's menu. Likewise I wouldn't want the KDE user to be cluttered > with gnome. > > As stated before, perhaps what is needed is the tools such as > gnome-menu or whatever xfce uses ignore the ShowOnlyIn argument and > display them all anyway. I seem to recall back in the middle ages, that when in Gnome, there was a main Menu entry called KDE, which brought a submenu up showing the menu of KDE apps you would see in KDE. And vice versa. I think this would be a nice thing to have, and might represent a happy medium for all sides of this argument. From katzj at redhat.com Mon Jul 23 20:30:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 23 Jul 2007 16:30:44 -0400 Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> Message-ID: <1185222644.17926.3.camel@localhost.localdomain> On Mon, 2007-07-23 at 07:32 +0530, Debarshi 'Rishi' Ray wrote: > http://debarshiray.multiply.com/journal/item/85 > > I have created a new design for the Manage Repositories dialog. I have > tried to incorporate Jeremy's suggestions regarding key management > being a repository specific issue and not a top-level one, etc.. [snip] > Once we start agreeing on the basic top-level design, I would start > creating the "Add", "Edit" and "Remove" dialogs. > > Comments? Well, I still think things are being gone about a _little_ backwards, but we're at least getting to where I've kind of suspected we'd end up[1]. I still think the advanced thing is kind of overkill and there are better ways to handle it (see my comments from last time on fixing the real thing that would cause people to want to have temporary changes rather than just assuming that a "make this temporary" checkbox is correct) Jeremy [1] Which somewhat proves Nicholas's point in his response. Not 100% sure how to avoid that without a lot more resources :/ From fedora at camperquake.de Mon Jul 23 20:38:35 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 23 Jul 2007 22:38:35 +0200 Subject: rawhide report: 20070723 changes In-Reply-To: <46A4F3A5.7010001@redhat.com> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> <20070723175051.784379e7@banea.int.addix.net> <46A4DBF5.5050204@redhat.com> <20070723202449.6c359acb@lain.camperquake.de> <46A4F3A5.7010001@redhat.com> Message-ID: <20070723223835.3cf0ccc3@lain.camperquake.de> Hi. On Mon, 23 Jul 2007 14:29:57 -0400, Jarod Wilson wrote > > Still does not explain why the other kernels have to go, though. > > What Jesse said and/or the yum changelog and/or Seth says. Confirmed, installonlyn is part of yum core now and thus got reenabled. Sorry for the noise. From skvidal at linux.duke.edu Mon Jul 23 20:41:45 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 23 Jul 2007 16:41:45 -0400 Subject: rawhide report: 20070723 changes In-Reply-To: <20070723223835.3cf0ccc3@lain.camperquake.de> References: <200707230939.l6N9d2V5017927@porkchop.devel.redhat.com> <20070723175051.784379e7@banea.int.addix.net> <46A4DBF5.5050204@redhat.com> <20070723202449.6c359acb@lain.camperquake.de> <46A4F3A5.7010001@redhat.com> <20070723223835.3cf0ccc3@lain.camperquake.de> Message-ID: <1185223305.2408.41.camel@cutter> On Mon, 2007-07-23 at 22:38 +0200, Ralf Ertzinger wrote: > Hi. > > On Mon, 23 Jul 2007 14:29:57 -0400, Jarod Wilson wrote > > > > Still does not explain why the other kernels have to go, though. > > > > What Jesse said and/or the yum changelog and/or Seth says. > > Confirmed, installonlyn is part of yum core now and thus > got reenabled. > > Sorry for the noise. I mentioned this specifically in the release announcement in f-7. But if you mean in rawhide there isn't that item. -sv From che666 at gmail.com Mon Jul 23 20:49:50 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 23 Jul 2007 22:49:50 +0200 Subject: separate sysv subpackages In-Reply-To: <1185215191.25858.153.camel@localhost.localdomain> References: <46A4A255.3020807@odu.neva.ru> <20070723095137.1de0e65a@localhost.localdomain> <1185215191.25858.153.camel@localhost.localdomain> Message-ID: actually i really have to disagree somewhat with the above statements. infact i do use an unmodified (ok it is modified but unrelated to the initscripts issue) rawhide for ages now i really dont have any use cases for systemV or the systemV init scripts. i also dont like stub packages... it annoys me enough that there are various packages without payload in the distro (just junk in the db in my eyes). regards, Rudolf Kastl From poelstra at redhat.com Mon Jul 23 21:23:49 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 23 Jul 2007 14:23:49 -0700 Subject: feature proposal: NetworkManager umts plugin In-Reply-To: References: Message-ID: <46A51C65.2020503@redhat.com> Rudolf Kastl said the following on 07/20/2007 09:30 AM Pacific Time: > Hello to you! > > Actually in my eyes it would make perfect sense to have a > networkmanager umts plugin because the current ppp support just > doesent provide the required functionality to provide proper umts > functionality integration. > > What it is essentially missing is: > > * the showing of signal strenght and > * the possibility to scan for and > * switch to different providers as well as > * maybe some configuration option to either track the spent time in a > defined timeframe and/or > * the used up bandwidth. > > opinions welcome! > > regards, > Rudolf Kastl > Hi Rudolf, Have you considered creating a proposed feature page? Feel free to create one. http://fedoraproject.org/wiki/Features/Policy#feature-ideas John From lsof at nodata.co.uk Mon Jul 23 21:24:54 2007 From: lsof at nodata.co.uk (nodata) Date: Mon, 23 Jul 2007 23:24:54 +0200 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> Message-ID: <1185225894.3463.3.camel@sb-home> Am Montag, den 23.07.2007, 21:28 +0100 schrieb Jonathan Underwood: > On 23/07/07, Jesse Keating wrote: > > On Mon, 23 Jul 2007 08:17:37 -0700 > > "Christopher Stone" wrote: > > > > > kate > > > > On a shared system where some users prefer Gnome and some prefer KDE, I > > don't want to have KDE apps such as kate cluttering up the Gnome > > users's menu. Likewise I wouldn't want the KDE user to be cluttered > > with gnome. > > > > As stated before, perhaps what is needed is the tools such as > > gnome-menu or whatever xfce uses ignore the ShowOnlyIn argument and > > display them all anyway. > > I seem to recall back in the middle ages, that when in Gnome, there > was a main Menu entry called KDE, which brought a submenu up showing > the menu of KDE apps you would see in KDE. And vice versa. I think > this would be a nice thing to have, and might represent a happy medium > for all sides of this argument. > I don't. It requires the user to know (and care) what a "KDE" or a "Gnome" is. A user shouldn't have to hunt around two different menus (which is what this suggestion is) just to find their application. If they are in Gnome, they get the Gnome stuff, if they are in KDE they get the KDE stuff. If they know better, they know better. From chris.stone at gmail.com Mon Jul 23 21:31:05 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 23 Jul 2007 14:31:05 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> References: <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> Message-ID: On 7/23/07, Jonathan Underwood wrote: > On 23/07/07, Jesse Keating wrote: > > On Mon, 23 Jul 2007 08:17:37 -0700 > > "Christopher Stone" wrote: > > > > > kate > > > > On a shared system where some users prefer Gnome and some prefer KDE, I > > don't want to have KDE apps such as kate cluttering up the Gnome > > users's menu. Likewise I wouldn't want the KDE user to be cluttered > > with gnome. > > > > As stated before, perhaps what is needed is the tools such as > > gnome-menu or whatever xfce uses ignore the ShowOnlyIn argument and > > display them all anyway. > > I seem to recall back in the middle ages, that when in Gnome, there > was a main Menu entry called KDE, which brought a submenu up showing > the menu of KDE apps you would see in KDE. And vice versa. I think > this would be a nice thing to have, and might represent a happy medium > for all sides of this argument. There is a gnome-menus which can be used on the KDE side, but I don't know if there is a kde-menus for GNOME. I think this would be perfectly acceptable provided these packages actually have the ability to override the OnlyShowIn directive. From chris.stone at gmail.com Mon Jul 23 21:55:45 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 23 Jul 2007 14:55:45 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <1185225894.3463.3.camel@sb-home> References: <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> Message-ID: On 7/23/07, nodata wrote: > I don't. It requires the user to know (and care) what a "KDE" or a > "Gnome" is. A user shouldn't have to hunt around two different menus > (which is what this suggestion is) just to find their application. > > If they are in Gnome, they get the Gnome stuff, if they are in KDE they > get the KDE stuff. If they know better, they know better. This is so dumb it makes Microsoft engineers look like friggin' geniuses. You think a user who doesn't know the difference between KDE and GNOME is going to know why banshee doesn't show up in their menus because they run KDE or XFCE? From wolfy at nobugconsulting.ro Mon Jul 23 23:05:49 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 24 Jul 2007 02:05:49 +0300 Subject: separate sysv subpackages In-Reply-To: References: <46A4A255.3020807@odu.neva.ru> <20070723095137.1de0e65a@localhost.localdomain> <1185215191.25858.153.camel@localhost.localdomain> Message-ID: <46A5344D.2040904@nobugconsulting.ro> On 07/23/2007 11:49 PM, Rudolf Kastl wrote: > actually i really have to disagree somewhat with the above statements. > > infact i do use an unmodified (ok it is modified but unrelated to the > initscripts issue) rawhide for ages now i really dont have any use > cases for systemV or the systemV init scripts. > > i also dont like stub packages... it annoys me enough that there are > various packages without payload in the distro (just junk in the db in > my eyes). > I second that. From time to time I feel the urge to use stripped down distributions (-> running from flash or maybe in a LTSP env, not from hdd ) and a separate initscripts not pulling in stuff which is useful on a normal env but useless for this particular usage would be a great help. From jkeating at redhat.com Tue Jul 24 03:06:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 23:06:31 -0400 Subject: separate sysv subpackages In-Reply-To: References: <46A4A255.3020807@odu.neva.ru> <20070723095137.1de0e65a@localhost.localdomain> <1185215191.25858.153.camel@localhost.localdomain> Message-ID: <20070723230631.44cc7ed1@ender> On Mon, 23 Jul 2007 22:49:50 +0200 "Rudolf Kastl" wrote: > infact i do use an unmodified (ok it is modified but unrelated to the > initscripts issue) rawhide for ages now i really dont have any use > cases for systemV or the systemV init scripts. If it's unmodified in relation to the initscript issue, how do you actually boot the system? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From che666 at gmail.com Tue Jul 24 05:10:33 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 24 Jul 2007 07:10:33 +0200 Subject: separate sysv subpackages In-Reply-To: <20070723230631.44cc7ed1@ender> References: <46A4A255.3020807@odu.neva.ru> <20070723095137.1de0e65a@localhost.localdomain> <1185215191.25858.153.camel@localhost.localdomain> <20070723230631.44cc7ed1@ender> Message-ID: 2007/7/24, Jesse Keating : > On Mon, 23 Jul 2007 22:49:50 +0200 > "Rudolf Kastl" wrote: > > > infact i do use an unmodified (ok it is modified but unrelated to the > > initscripts issue) rawhide for ages now i really dont have any use > > cases for systemV or the systemV init scripts. > > If it's unmodified in relation to the initscript issue, how do you > actually boot the system? with initng which is packaged in fedora and comes with its own scripts. boot time till gdm screen is about 16 seconds on my box. regards, Rudolf Kastl > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From denis at poolshark.org Tue Jul 24 06:57:06 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 24 Jul 2007 08:57:06 +0200 Subject: inkscape in rawhide segfaults immediately on start up In-Reply-To: <469DFBFF.9070801@redhat.com> References: <469CD60B.8040009@redhat.com> <469DAA8C.4060005@poolshark.org> <469DFBFF.9070801@redhat.com> Message-ID: <46A5A2C2.2010609@poolshark.org> Richard W.M. Jones wrote: > Denis Leroy wrote: >> Richard W.M. Jones wrote: >>> I haven't looked into this in great detail yet, but I wonder if this >>> is a known problem? There is no bugzilla that I can find and it's a >>> complete show-stopper so I can't imagine how it got past even the >>> most minimal test. >> >> Works here, what version of glib2 and glibmm24 do you have installed ? >> I'll make sure to push a rebuild before we hit f8t1. > > Thanks everyone for replying. I've reproduced this on two different > x86-64 machines, both F7 up to date, so I opened a bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248700 This is caused by an ABI breakage of gc 7.0 in updates-testing, which needs to be pulled out of there. Bug updated accordingly and reassigned to Rex Dieter. From nicolas.mailhot at laposte.net Tue Jul 24 07:36:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 24 Jul 2007 09:36:50 +0200 (CEST) Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <1185222644.17926.3.camel@localhost.localdomain> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <1185222644.17926.3.camel@localhost.localdomain> Message-ID: <31946.192.54.193.51.1185262610.squirrel@rousalka.dyndns.org> Le Lun 23 juillet 2007 22:30, Jeremy Katz a ?crit : > [1] Which somewhat proves Nicholas's point in his response. Not 100% > sure how to avoid that without a lot more resources :/ Yes :( I apologise if I was a bit abrasive yesterday, just saw too many UI disasters justified by synthetic use-cases. IMHO developper/designer identified objectives just should not be formalised as "user foo wants..." so everyone remembers they're just developper hypothesis (esp. since Richi's original use cases are not synthetic cases but actual user feedback, so they're not in the same category at all) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jul 24 07:41:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 24 Jul 2007 09:41:31 +0200 (CEST) Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <31946.192.54.193.51.1185262612.squirrel@rousalka.dyndns.org> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <1185222644.17926.3.camel@localhost.localdomain> <31946.192.54.193.51.1185262612.squirrel@rousalka.dyndns.org> Message-ID: <55094.192.54.193.51.1185262891.squirrel@rousalka.dyndns.org> Le Mar 24 juillet 2007 09:36, Nicolas Mailhot a ?crit : > IMHO developper/designer identified objectives just should not be > formalised as "user foo wants..." so everyone remembers they're just > developper hypothesis Also now we have a "feature" page it may be possible to create associated webforum? topic and ask users/testers to just comment on them here. ? actual webforums of something like gmane as long as users can easily consult topic history and add comments without learning wiki editing. -- Nicolas Mailhot From debarshi.ray at gmail.com Tue Jul 24 08:34:43 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 24 Jul 2007 14:04:43 +0530 Subject: RUM -> OPYUM Message-ID: <3170f42f0707240134u4003dc63i516746daf8c1e31a@mail.gmail.com> Due to a naming conflict with Red Carpet User tool interface to YUM (http://code.google.com/p/rum/), I have decided to rename the Fedora Offline Package Manager (http://fedoraproject.org/wiki/DebarshiRay/rum) to Opyum. Opyum (pronounced 'opium') stands for Offline Package manager using YUM. 'Opium' itself can not be used since it is the name of another package management system: http://media.linspire.com/opium.pdf but no package for it is available in Fedora or Debian. If some one has any issues with new name, please let me know. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Tue Jul 24 08:38:00 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 24 Jul 2007 14:08:00 +0530 Subject: Pirut: Edit -> Repositories mock-up -- Part 2. In-Reply-To: <55094.192.54.193.51.1185262891.squirrel@rousalka.dyndns.org> References: <3170f42f0707221902x5ffe95a4he6c5ef69efaa82b9@mail.gmail.com> <1185222644.17926.3.camel@localhost.localdomain> <31946.192.54.193.51.1185262612.squirrel@rousalka.dyndns.org> <55094.192.54.193.51.1185262891.squirrel@rousalka.dyndns.org> Message-ID: <3170f42f0707240138q67187759yfec9695784db4df8@mail.gmail.com> > Also now we have a "feature" page it may be possible to create > associated webforum? topic and ask users/testers to just comment on > them here. Is this a Fedora "feature" page or meant for a specific package? A URL would help. :-) Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at redhat.com Tue Jul 24 10:55:15 2007 From: buildsys at redhat.com (Build System) Date: Tue, 24 Jul 2007 06:55:15 -0400 Subject: rawhide report: 20070724 changes Message-ID: <200707241055.l6OAtF98027328@porkchop.devel.redhat.com> New package alienblaster Action-loaded 2D arcade shooter game New package drupal An open-source content-management platform New package nss_compat_ossl Source-level compatibility library for OpenSSL to NSS porting New package perl-Authen-PAM Authen::PAM Perl module New package perl-Devel-Profiler Perl profiler compatible with dprofpp New package perl-File-Sync Perl access to fsync() and sync() function calls New package perl-HTTP-DAV WebDAV client library for Perl5 New package perl-Test-File-Contents Test routines for examining the contents of files New package perl-Text-Diff-HTML XHTML format for Text::Diff::Unified New package perl-Text-LevenshteinXS XS implementation of the Levenshtein edit distance New package perl-Text-WordDiff Track changes between documents New package python-pygments A syntax highlighting engine written in Python Updated Packages: CCfits-1.7-1.fc8 ---------------- * Sun Jul 22 2007 Sergio Pascual 1.7-1 - New upstream source 1.7 Democracy-0.9.5.1-11.fc8 ------------------------ * Mon Jul 23 2007 Jesse Keating 0.9.5.1-11 - Rebuild for ff 2.0.0.5 bind-31:9.5.0a5-4.1.fc8 ----------------------- * Sat Jul 21 2007 Adam Tkac 31:9.5.0a5-4.1.fc8 - fixed DLZ drivers building on 64bit systems * Fri Jul 20 2007 Adam Tkac 31:9.5.0a5-4.fc8 - fixed relation between logrotated and chroot-ed named * Wed Jul 18 2007 Adam Tkac 31:9.5.0a5-3.9.fc8 - removed bind-sdb package (default named has compiled SDB backend now) - integrated DLZ (Dynamically loadable zones) drivers - integrated GSS-TSIG support (RFC 3645) - build with -O0 (many new features, potential core dumps will be more useful) busybox-1:1.6.1-1.fc8 --------------------- * Mon Jul 23 2007 Ivana Varekova - 1:1.6.1-1 - update to 1.6.1 control-center-1:2.19.5-3.fc8 ----------------------------- * Mon Jul 23 2007 Matthias Clasen - 2.19.5-3 - Port to new GTK+ tooltips API cracklib-2.8.10-2 ----------------- * Mon Jul 23 2007 Nalin Dahyabhai - 2.8.10-2 - work around non-executable util/cracklib-format giving us empty/garbage dictionaries (#249210) ctapi-common-1.1-2.fc8 ---------------------- * Mon Jul 23 2007 Ville Skytt?? - 1.1-2 - Change group to ctapiusers. - Don't hardcode a static gid. - Don't remove the group at all. - Require shadow-utils for group creation. cups-1:1.3-0.b1.5.fc8 --------------------- * Mon Jul 23 2007 Tim Waugh 1:1.3-0.b1.5 - Use kernel support for USB paper-out detection, when available (bug #249213). cyrus-imapd-2.3.8-3.2.fc8 ------------------------- * Mon Jul 23 2007 Tomas Janousek - 2.3.8-3.2 - removed the lm_sensors-devel dependency, since it's properly required in net-snmp-devel - #248984 - cyrus-imapd.logrotate updated for rsyslog * Mon Apr 23 2007 Tomas Janousek - 2.3.8-3.1 - the -devel subpackage no longer requires the main one docbook-style-xsl-1.73.0-2.fc8 ------------------------------ * Mon Jul 23 2007 Ondrej Vasik 1.73.0-2 - fixed manpages/docbook.xsl failure(Tim Waugh,#249294) * Mon Jul 23 2007 Ondrej Vasik 1.73.0-1 - update to latest upstream version - patch changes because of rejects ed-0.7-1.fc8 ------------ * Mon Jul 23 2007 Karsten Hopp 0.7-1 - update to 0.7 to fix an endless loop (#234689) - add disttag * Mon Jul 02 2007 Karsten Hopp 0.6-1 - update to 0.6 emacs-vm-8.0.2.482-1.fc8 ------------------------ * Sun Jul 22 2007 Jonathan G. Underwood - 8.0.2.482-1 - Update to bugfix release 8.0.2 epiphany-2.19.5-3.fc8 --------------------- * Mon Jul 23 2007 Matthias Clasen - 2.19.5-3 - Port to new GTK+ tooltips API * Fri Jul 20 2007 Kai Engert - 2.19.5-2 - Rebuild against newer gecko * Tue Jul 10 2007 Matthias Clasen 2.19.5-1 - Update to 2.19.5 fcron-3.0.3-2.fc8 ----------------- * Mon Jul 23 2007 Alain Portal 3.0.3-2 - sysklogd is no more in Fedora, replace by rsyslog #249033. So change Requires sysklogd by Requires syslog gcc-4.1.2-16 ------------ * Mon Jul 23 2007 Jakub Jelinek 4.1.2-16 - update from gcc-4_1-branch (-r126302:126830) - PRs rtl-optimization/32450, target/31331, target/32641, target/32660, tree-optimization/32681 - pass --build-id to ld for all linking but ld -r, update {,Build}Requires to binutils that support it (Roland McGrath) - backport ARM fixes from trunk (#246800) - PRs middle-end/24998, target/28516, target/30486 - fix simplify_plus_minus with ppc{,64} power6 tuning (regression from 4.1.1-52.el5.2, #247256) gdb-6.6-21.fc8 -------------- * Mon Jul 23 2007 Jan Kratochvil - 6.6-21 - Fixed compatibility with Rawhide kernel fs.binfmt_elf.core_dump_elf_headers=1. - .spec file updates to mostly pass RPMLINT - Fedora merge review (BZ 225783). - Fixed testcase of the exit of a thread group leader (of BZ 247354). - Cleanup any leftover testsuite processes as it may stuck mock(1) builds. * Sun Jul 08 2007 Jan Kratochvil - 6.6-20 - Do not hang on exit of a thread group leader (BZ 247354). - New test for upstream fix of VDSO decoding while attaching to an i386 process. - Fixed BZ # 232014 -> 232015. * Thu Jul 05 2007 Jan Kratochvil - 6.6-19 - Link with libreadline provided by the operating system. gmime-2.2.10-1.fc8 ------------------ * Mon Jul 23 2007 Matthias Clasen - 2.2.10-1 - Update to 2.2.10 gnome-bluetooth-0.9.1-1.fc8 --------------------------- * Mon Jul 23 2007 - Bastien Nocera - 0.9.1-1 - Upgrade to 0.9.1 to fix a crasher in the server gnome-doc-utils-0.10.3-4.fc8 ---------------------------- * Mon Jul 23 2007 Matthias Clasen - 0.10.3-4 - Split out stylesheets as subpackage to avoid pulling automake in the live CD gnucash-2.2.0-2.fc8 ------------------- * Mon Jul 23 2007 Bill Nottingham - 2.2.0-2 - fix icon (#248492) gtk2-2.11.6-1.fc8 ----------------- * Mon Jul 23 2007 Matthias Clasen - 2.11.6-1 - Update to 2.11.6 - Make it build against recent cups * Thu Jul 19 2007 Matthias Clasen - 2.11.5-4 - Up the glib requirement * Sun Jul 08 2007 Matthias Clasen - 2.11.5-3 - Own /usr/lib/gtk-2.0/modules hplip-2.7.6-10.fc8 ------------------ * Mon Jul 23 2007 Tim Waugh 2.7.6-10 - Move libhpmud to hpijs package (bug #248978). iso-codes-1.2-1.fc8 ------------------- * Tue Jul 24 2007 Parag Nemade - Update to 1.2 iwlwifi-firmware-2.14.4-1 ------------------------- * Sat Jul 14 2007 Matthias Saou 2.14.4-1 - Update to 2.14.4. kernel-2.6.23-0.45.rc0.git16.fc8 -------------------------------- * Mon Jul 23 2007 John W. Linville - Rediff git-wireless-dev.patch * Sat Jul 21 2007 Roland McGrath - Fix biarch issue in linux-2.6-elf-core-sysctl.patch * Sat Jul 21 2007 Dave Jones - 2.6.22-git16 kmymoney2-0.8.7-1.fc8 --------------------- * Mon Jul 23 2007 Rex Dieter 0.8.7-1 - kmymoney2-0.8.7 kst-1.4.0-6.fc8 --------------- * Mon Jul 23 2007 Matthew Truch - 1.4.0-6 - Readd kdebindings-devel: KDE4 slipped; will readjust when appropriate. * Mon Jul 23 2007 Matthew Truch - 1.4.0-5 - kst never needed BR kdebase-devel - Change BR to kdelibs3-devel for upcoming switch to KDE4 as primary. - Remove BR kdebindings-devel; kst will use it's internal bindings which should suffice until kst 2.0 is released (and switch to KDE4). - Fix typo in version of Jesse's changelog entry below from 1.3.0-4 to 1.4.0-4 * Thu Jul 19 2007 Jesse Keating - 1.4.0-4 - Rebuild for new cfitsio libcdio-0.78.2-2.fc8 -------------------- * Mon Jul 23 2007 Adrian Reber - 0.78.2-2 - updated to 0.78.2 (#221359) (this time for real) * Thu Jan 04 2007 Adrian Reber - 0.78.2-1 - updated to 0.78.2 (#221359) libgdamm-2.9.7-1.fc8 -------------------- * Mon Jul 23 2007 Tom "spot" Callaway 2.9.7-1 - back from the dead libselinux-2.0.24-3.fc8 ----------------------- * Mon Jul 23 2007 Dan Walsh - 2.0.24-3 - Apply Steven Smalley patch to fix segfault in string_to_security_class mash-0.1.19-1.fc8 ----------------- * Mon Jul 23 2007 Bill Nottingham 0.1.19-1 - fix spam-o-matic to use python mailer metacity-2.19.34-1.fc8 ---------------------- * Mon Jul 23 2007 Matthias Clasen - 2.19.34-1 - Update to 2.19.34 * Fri Jul 06 2007 Matthias Clasen - 2.19.21-3 - Require control-center-filesystem nautilus-2.19.5-2.fc8 --------------------- * Mon Jul 23 2007 Matthias Clasen - 2.19.5-2 - Port to new GTK+ tooltips API * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 * Fri Jul 06 2007 Matthias Clasen - 2.19.4-2 - Fix directory ownership issues obconf-2.0.2-1.fc8 ------------------ * Mon Jul 23 2007 Miroslav Lichvar - 2.0.2-1 - Update to 2.0.2 openbox-3.4.3-1.fc8 ------------------- * Mon Jul 23 2007 Miroslav Lichvar - 3.4.3-1 - Update to 3.4.3 - Package setlayout tool openjade-1.3.2-29.fc8 --------------------- * Mon Jul 23 2007 Ondrej Vasik 1.3.2-29 - improved dependent libs patch (bug #237500) - same done for libospgrove.so pam_krb5-2.2.15-2 ----------------- * Mon Jul 23 2007 Nalin Dahyabhai - 2.2.15-2 - rebuild * Mon Jul 23 2007 Nalin Dahyabhai - 2.2.15-1 - update to 2.2.15, adjusting the fix for #150056 so that it doesn't run afoul of SELinux policy by attempting to read a ccache which was created for use by the user via the helper - build with --with-default-use-shmem=sshd --with-default-external=sshd, to get the expected behavior without requiring administrator intervention * Thu Jul 19 2007 Nalin Dahyabhai - 2.2.14-2 - rebuild perl-Test-Class-0.24-1.fc8 -------------------------- php-pear-DB-1.7.12-1.fc8 ------------------------ * Mon Jul 23 2007 Remi Collet 1.7.12-1 - update to 1.7.12 - change requires from php to php-common - update test suite to run (but only after install) - add %check, only for documentation purpose phpMyAdmin-2.10.3-1.fc8 ----------------------- * Mon Jul 23 2007 Mike McGrath 2.10.3-1 - Upstream released new version policycoreutils-2.0.22-7.fc8 ---------------------------- * Mon Jul 23 2007 Dan Walsh 2.0.22-7 - Fix fixfiles to report incorrect rpm - Patch provided by Tony Nelson powertop-1.7-4.fc8 ------------------ * Mon Jul 23 2007 Bill Nottingham 1.7-4 - add patch to allow dumping output to stdout python-Coherence-0.3.0-1.fc8 ---------------------------- * Tue Jul 24 2007 Matthias Saou 0.3.0-1 - Update to 0.3.0. rarpd-ss981107-23 ----------------- * Mon Jul 23 2007 Jiri Moskovcak - ss981107-23 - Init script rewrite to comply with LSB. - Resolves: #247042 rpm-4.4.2.1-1.fc8 ----------------- * Mon Jul 23 2007 Panu Matilainen 4.4.2.1-1 - 4.4.2.1 final - reintroduce disttag - include full ChangeLog as doc - use up-to-date config.guess for ARM support (#246803) - ARM EANBI gnu/gnuenabi fix from Lennert Buytenhek (#246803) rsyslog-1.17.2-1.fc8 -------------------- * Mon Jul 23 2007 Peter Vrabec 1.17.2-1 - upstream bug fix release rwall-0.17-26 ------------- * Mon Jul 23 2007 Jiri Moskovcak - 0.17-26 - init script rewrite to comply with the LSB standard - Resolves: #247048 rwho-0.17-27 ------------ * Mon Jul 23 2007 Jiri Moskovcak - 0.17-27 - Fixed init script to comply with the LSB standard - Resolves: #247049 sabayon-2.19.1-1.fc8 -------------------- * Mon Jul 23 2007 Matthias Clasen - 2.19.1-1 - Update to 2.19.1 selinux-policy-3.0.3-5.fc8 -------------------------- * Mon Jul 23 2007 Dan Walsh 3.0.3-5 - Add ntpd_key_t to handle secret data * Fri Jul 20 2007 Dan Walsh 3.0.3-4 - Add anon_inodefs - Allow unpriv user exec pam_exec_t - Fix trigger sonata-1.2.2-1.fc8 ------------------ * Mon Jul 23 2007 Micha?? Bentkowski - 1.2.2-1 - 1.2.2 system-config-date-1.9.2-1.fc8 ------------------------------ * Mon Jul 23 2007 Nils Philippsen 1.9.2 - fix python formatting in Japanese translation (#248667, Jens Petersen) - make "make archive" work with Hg repo system-config-nfs-1.3.27-1.fc8 ------------------------------ * Mon Jul 23 2007 Nils Philippsen 1.3.27 - make "make archive" work with Hg * Wed Jun 27 2007 Nils Philippsen - remove bogus gtk.FileSelection instantiation (spotted by Adel Gadllah) system-config-printer-0.7.70-2.fc8 ---------------------------------- * Mon Jul 23 2007 Tim Waugh 0.7.70-2 - Obsoletes/provides desktop-printing. system-config-samba-1.2.45-1.fc8 -------------------------------- * Mon Jul 23 2007 Nils Philippsen - 1.2.45 - make "make archive" work with Hg system-config-services-0.9.10-1.fc8 ----------------------------------- * Mon Jul 23 2007 Nils Philippsen - 0.9.10 - make "make archive" work with Hg - disable automatic ChangeLog generation system-config-users-1.2.61-1.fc8 -------------------------------- * Mon Jul 23 2007 Nils Philippsen - 1.2.61 - make "make archive" work with Hg * Fri Jul 20 2007 Nils Philippsen - fix exception syntax, catch only IndexErrors caused by group inconsistencies (#243217) - list users and/or groups found to be inconsistent (#243217) * Thu Jul 19 2007 Nils Philippsen - catch IndexErrors caused by group inconsistencies (#243217) tomboy-0.7.2-1.fc8 ------------------ * Mon Jul 23 2007 Matthias Clasen - 0.7.2-1 - Update to 0.7.2 tracker-0.6.0-1.fc8.1 --------------------- * Mon Jul 23 2007 Deji Akingunola - 0.6.0-1 - Update to 0.6.0 - Manually specify path to deskbar-applet handler directory, koji can't find it * Mon Jan 29 2007 Deji Akingunola - 0.5.4-2 - Split out tracker-search-tool sub-packages, for the GUI facility - Add proper requires for the -devel subpackage - Deal with the rpmlint complaints on rpath * Sat Jan 27 2007 Deji Akingunola - 0.5.4-1 - Update to 0.5.4 wfmath-0.3.6-1.fc8 ------------------ * Sun Jul 22 2007 Wart 0.3.6-1 - Update to 0.3.6 xterm-228-1.fc8 --------------- * Mon Jul 23 2007 Miroslav Lichvar 228-1 - update to 228 yelp-2.18.1-6.fc8 ----------------- * Mon Jul 23 2007 Matthias Clasen - 2.18.1-6 - Require gnome-doc-utils-stylesheets instead of gnome-doc-utils Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From valent.turkovic at gmail.com Tue Jul 24 10:56:14 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 24 Jul 2007 12:56:14 +0200 Subject: the most serious bug in F7 I found so far... In-Reply-To: <1185202889.2794.92.camel@localhost.localdomain> References: <64b14b300707150643m22c59c73ifb94c034f485394b@mail.gmail.com> <1185202889.2794.92.camel@localhost.localdomain> Message-ID: <64b14b300707240356p7b4b8aadk3c51e99dfdedd374@mail.gmail.com> On 7/23/07, Adam Jackson wrote: > On Sun, 2007-07-15 at 15:43 +0200, Valent Turkovic wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246593 > > > > This is the most serious bug I found in Fedora 7 so please look at it > > and tell me what more info you need of me. > > I have a response I'd like to give about this bug, but unfortunately, > your email tells me nothing about what the bug is. > > The irony here is that, after clicking through, this probably is my bug > to fix, and this email only got seen because of morbid curiosity. > Normally I skip things that don't seem like they're related to what I'm > working on, and there are plenty of things in F7 with "serious bugs". > > - ajax Well Ajax I'm not a fedora developer and I know that you have serious bugs to deal with but I user fedora since 1st release. Also have enough linux and other experience not to sound false alarm. I really thought that copy/pasting whole bug would not be productive... so I provided a bugzilla link because in three weeks it didn't get any attention and I don't have enough debugging and development knowledge... I'm happy to do the legwork but somebody with more knowledge has to point me in the right direction. HTH Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From d.jacobfeuerborn at conversis.de Tue Jul 24 13:24:54 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 24 Jul 2007 15:24:54 +0200 Subject: =?utf-8?q?WTF=E2=81=88_ShowOnlyIn=3DGNOME?= In-Reply-To: <20070723112548.49ffaae0@localhost.localdomain> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> Message-ID: <46A5FDA6.9040405@conversis.de> Jesse Keating wrote: > On Mon, 23 Jul 2007 08:17:37 -0700 > "Christopher Stone" wrote: > >> kate > > On a shared system where some users prefer Gnome and some prefer KDE, I > don't want to have KDE apps such as kate cluttering up the Gnome > users's menu. Likewise I wouldn't want the KDE user to be cluttered > with gnome. With this approach you make at least two assumptions: 1. Consistency is more important than usability 2. KDE text editor A has the same functionality as GNOME text editor B (making them interchangeable) Not making an important application (for a particular user) available merely on the grounds of consistency shows a disregard for the users needs just so that the menu can look "nice" and is a very bad move in my eyes. Setting up sane defaults is ok but you shouldn't cut off users from applications they might need. > > As stated before, perhaps what is needed is the tools such as > gnome-menu or whatever xfce uses ignore the ShowOnlyIn argument and > display them all anyway. The gnome menu editor needs a way to let the user choose which applications should be available in the menu. I think the best way is not to make that choice based on a particular desktop environment but based on the needs of the user i.e. the user shouldn't have to choose the particular DE he wants to show the app in but instead have a way to say "I need this application for my daily work so show it all the time". If I use Kate to edit my files it should show up in the menu all the time not just when I boot into a particular DE. So to summarize: Setting defaults is fine but there should be an easy way for users to configure an application as "Show always". Regards, Dennis From fedora at camperquake.de Tue Jul 24 14:00:56 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 24 Jul 2007 16:00:56 +0200 Subject: Understanding gnome-power-manager In-Reply-To: <1185204320.2907.11.camel@work> References: <20070723160132.42d500c9@banea.int.addix.net> <1185202531.2907.7.camel@work> <20070723171031.64bfc371@banea.int.addix.net> <1185204320.2907.11.camel@work> Message-ID: <20070724160056.162cd14e@banea.int.addix.net> Hi. On Mon, 23 Jul 2007 16:25:20 +0100, Richard Hughes wrote: > You might want to try svn first, there's been some fixes for that > recently. SVN fixes the more annoying half of it, thanks. From icon at fedoraproject.org Tue Jul 24 14:50:38 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 24 Jul 2007 10:50:38 -0400 Subject: RUM -> OPYUM In-Reply-To: <3170f42f0707240134u4003dc63i516746daf8c1e31a@mail.gmail.com> References: <3170f42f0707240134u4003dc63i516746daf8c1e31a@mail.gmail.com> Message-ID: On 7/24/07, Debarshi 'Rishi' Ray wrote: > Due to a naming conflict with Red Carpet User tool interface to YUM > (http://code.google.com/p/rum/), I have decided to rename the Fedora > Offline Package Manager > (http://fedoraproject.org/wiki/DebarshiRay/rum) to Opyum. > > Opyum (pronounced 'opium') stands for Offline Package manager using YUM. Why don't we jump straight to "crack," then? :) -- Konstantin Ryabitsev Montr?al, Qu?bec From rc040203 at freenet.de Tue Jul 24 16:14:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Jul 2007 18:14:23 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185195554.3165.1.camel@weaponx.rchland.ibm.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> Message-ID: <1185293663.20980.18.camel@mccallum.corsepiu.local> On Mon, 2007-07-23 at 07:59 -0500, Josh Boyer wrote: > On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote: > > On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote: > > > Somebody in the thread at some point said: > > > > > > >> sort of automatic file checking would help flag problems. > > > > In trivial cases such as the GPLv3 change, it could help. > > > > > > > > In cases of packages changing from FOO-license v1.283 to BAR-license > > > > v32.100 it doesn't. > > > > > > Wouldn't it notice the deletion of the FOO-license file at least though > > > and flag it up? > > If there is any, may-be - If there isn't any, no. > > > > Also consider: Detached license files are legally questionable/doubtful. > > What matters is the license inlined or referenced by each files. Non > > copyright owner added licenses are even more questionable. > > > > > At least then someone > > someone == Jef Spaleta or other people from the Board > > > > > > > > In cases of packages pointing to web-sites, it > > > > > > Yes I guess so, although it could wget the URL periodically and hash > > > that (assuming there are no "today's date" and crud on the page) > > Feel free to do so ... Feel free to do so if these URLs change or vanish ;) > > > > > >> Granted its > > > >> not going to work for all packages, but it might help a lot in the > > > >> specific case of entire project codebases transitioning to gpl3 from a > > > >> previous license. > > > > If you think so, I disagree. You are driving away contributors from > > > > fedora, by imposing more and more bureaucracy. If you really want this > > > > > > The automated technique is a small burden if it works for most packages. > > We already _have_ way too much bureaucracy in Fedora. > > > > > Since care is taken about the license to get it into Fedora it is > > > consistent to take some care about the license after it is in... and > > > with fun things like "or later" now... > > Feel free to do so - Without me. Shall the "Board" (Whatever > > board-de-jour we might be talking about) and the dark forces surrounding > > it inside of RH do so - Without me - Period. > > dark forces? The person @RH or the person from whatever "committee-de-jour", who is pushing this nonsense onto users and devs. - Give names, please. Ralf From rc040203 at freenet.de Tue Jul 24 16:17:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Jul 2007 18:17:14 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185204325.9305.6.camel@gibraltar.stuttgart.redhat.com> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185204325.9305.6.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1185293835.20980.22.camel@mccallum.corsepiu.local> On Mon, 2007-07-23 at 17:25 +0200, Nils Philippsen wrote: > On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote: > > On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote: > > > > The automated technique is a small burden if it works for most packages. > > We already _have_ way too much bureaucracy in Fedora. > > automation != bureaucracy Which automation are you referring to? The merger with Core (==RH) hasn't brought automation, it has caused more bureaucracy and further regressions to contributors. Ralf From skvidal at linux.duke.edu Tue Jul 24 16:19:26 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 24 Jul 2007 12:19:26 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185293663.20980.18.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> Message-ID: <1185293966.2408.123.camel@cutter> On Tue, 2007-07-24 at 18:14 +0200, Ralf Corsepius wrote: > > dark forces? > The person @RH or the person from whatever "committee-de-jour", who is > pushing this nonsense onto users and devs. - Give names, please. > I'm one of them. We're asking for this information in the packages b/c we are worried about licensing version conflicts making it a problem for us to ship certain packages linked against other ones. This was after conversation with legal. So, if you want, I'm one of the "Dark Forces". WE NEED THE INFORMATION. The board has been empowered to make this decision. Supposedly, fesco and fpc implement the decisions that the board has made. That's why we asked for it to be addressed there. That's how the system is supposed to work. Exactly where are the dark forces? -sv From jkeating at redhat.com Tue Jul 24 17:02:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 13:02:13 -0400 Subject: Koji outage Message-ID: <20070724130213.01236d2a@localhost.localdomain> Due to some DNS changes this morning, Koji is having troubles contacting the CVS server. We are working as fast as we can to resolve this issue. Thanks. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From buildsys at fedoraproject.org Tue Jul 24 17:05:44 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 24 Jul 2007 13:05:44 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-24 Message-ID: <20070724170544.B11E0152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 13 codeblocks-1.0-0.25.20070718svn4280.fc6 ctapi-cyberjack-3.0.2-1.fc6 fuse-2.7.0-2.fc6 fuse-2.7.0-3.fc6 fwbackups-1.43.1-1.fc6 nail-12.3-1.fc6 php-pear-Net-Ping-2.4.2-1.fc6 phpMyAdmin-2.10.3-1.fc6 qt4-4.3.0-9.fc6 trac-0.10.4-1.fc6 tracker-0.6.0-1.fc6.1 xawtv-3.95-4.fc6 xmlrpc-c-1.06.16-1.fc6 Changes in Fedora Extras 6: codeblocks-1.0-0.25.20070718svn4280.fc6 --------------------------------------- * Thu Jul 19 2007 Dan Horak 1.0-0.25.20070718svn4280 - update to revision 4280 - added missing ldconfig call for the contrib subpackage - fix permissions for source files ctapi-cyberjack-3.0.2-1.fc6 --------------------------- * Sat Jul 21 2007 Frank B?ttner - 3.0.2-1 - update to 3.0.2 * Sat Jun 23 2007 Frank B?ttner - 3.0.0-3.fc6 - disable PC/SC part for EL4 fuse-2.7.0-2.fc6 ---------------- * Sat Jul 21 2007 Tom "spot" Callaway 2.7.0-2 - redefine exec_prefix to / - redefine bindir to /bin - redefine libdir to %{_lib} - don't pass --disable-static to configure - manually rm generated static libs * Wed Jul 18 2007 Peter Lemenkov 2.7.0-1 - Version 2.7.0 - Redefined exec_prefix due to demands from NTFS-3G fuse-2.7.0-3.fc6 ---------------- * Sun Jul 22 2007 Tom "spot" Callaway 2.7.0-3 - put pkgconfig file in correct place - enable compat symlinks for files in /bin fwbackups-1.43.1-1.fc6 ---------------------- * Sun Jul 22 2007 Stewart Adam 1.43.1-1 - Change get_python_lib() to get_python_lib(1) for x86_64 - Add new Requires and Post(un) scripts because of new documentation - Switch all instances of fwbackups to %{name} for consistency - Update to 1.43.1 (see CHANGELOG file for details on version changes) nail-12.3-1.fc6 --------------- * Tue Jul 24 2007 Dmitry Butskoy - 12.3-1 - update to 12.3 php-pear-Net-Ping-2.4.2-1.fc6 ----------------------------- * Mon Jul 16 2007 Remi Collet 2.4.2-1 - update to 2.4.2 - package is now 2.0 (no need to convert) - remove LICENSE (Review Guidelines : If (and only if) the source package includes...) phpMyAdmin-2.10.3-1.fc6 ----------------------- * Mon Jul 23 2007 Mike McGrath 2.10.3-1 - Upstream released new version qt4-4.3.0-9.fc6 --------------- * Sun Jul 15 2007 Rex Dieter 4.3.0-9 - multilib broken: qconfig.h (#248768) - +%_qt4_demosdir,%_qt4_examplesdir - + Qt.pc, provide pkgconfig access to qt4 macros/variables * Thu Jul 05 2007 Rex Dieter 4.3.0-8 - fix %_qt4_prefix/doc symlink * Thu Jun 28 2007 Rex Dieter 4.3.0-7 - prepare for possible rename qt4 -> qt (+Provides: qt4) - make _qt4_* macro usage consistent (with %check's) * Sat Jun 23 2007 Rex Dieter 4.3.0-5 - fix rpm macros, (%_qt_plugindir, %_qt4_translationdir} * Thu Jun 21 2007 Rex Dieter 4.3.0-4 - .desktop Category cleanup * Thu Jun 21 2007 Rex Dieter 4.3.0-3 - cleanup qconfig.h/multilib bits, add s390x/s390 trac-0.10.4-1.fc6 ----------------- * Thu May 03 2007 Jeffrey C. Ollie - 0.10.4-1 - Update to 0.10.4 tracker-0.6.0-1.fc6.1 --------------------- * Tue Jul 24 2007 Deji Akingunola - 0.6.0-1 - Disable using external sqlite, build failed with it on FC6 * Mon Jul 23 2007 Deji Akingunola - 0.6.0-1 - Update to 0.6.0 - Manually specify path to deskbar-applet handler directory, koji can't find it xawtv-3.95-4.fc6 ---------------- * Tue Jul 24 2007 Dmitry Butskoy - 3.95-4 - don't assume v4l-conf as system config util (#249130) * Tue Jun 26 2007 Dmitry Butskoy - drop X-Fedora category from desktop file xmlrpc-c-1.06.16-1.fc6 ---------------------- * Sun Jul 22 2007 Enrico Scholz - 1.06.16-1 - updated to 1.06.16 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lsof at nodata.co.uk Tue Jul 24 17:07:30 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 24 Jul 2007 19:07:30 +0200 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> Message-ID: <1185296850.5046.5.camel@sb-home> Am Montag, den 23.07.2007, 14:55 -0700 schrieb Christopher Stone: > On 7/23/07, nodata wrote: > > I don't. It requires the user to know (and care) what a "KDE" or a > > "Gnome" is. A user shouldn't have to hunt around two different menus > > (which is what this suggestion is) just to find their application. > > > > If they are in Gnome, they get the Gnome stuff, if they are in KDE they > > get the KDE stuff. If they know better, they know better. > > This is so dumb it makes Microsoft engineers look like friggin' geniuses. It's a damn lot letter than the "Let's have a KDE and a Gnome and a XFCE menu" suggestion. Show the KDE equivalent in the KDE desktop - Amarok or whatever. From jkeating at redhat.com Tue Jul 24 17:22:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 13:22:50 -0400 Subject: Koji outage In-Reply-To: <20070724130213.01236d2a@localhost.localdomain> References: <20070724130213.01236d2a@localhost.localdomain> Message-ID: <20070724132250.42912627@localhost.localdomain> On Tue, 24 Jul 2007 13:02:13 -0400 Jesse Keating wrote: > Due to some DNS changes this morning, Koji is having troubles > contacting the CVS server. We are working as fast as we can to > resolve this issue. Thanks. An update of your common/ directory should fix this issue and allow your build to continue. An update to Makefile.common was made to use a canonical reference for our CVS server. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From orion at cora.nwra.com Tue Jul 24 18:04:47 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 24 Jul 2007 12:04:47 -0600 Subject: updating common dirs In-Reply-To: <20070724132250.42912627@localhost.localdomain> References: <20070724130213.01236d2a@localhost.localdomain> <20070724132250.42912627@localhost.localdomain> Message-ID: <46A63F3F.1000603@cora.nwra.com> Jesse Keating wrote: > An update of your common/ directory should fix this issue and allow > your build to continue. An update to Makefile.common was made to use a > canonical reference for our CVS server. Is there an easy way to update all of my common dirs in one step? [orion at cynosure ~/fedora]$ cvs update */common cvs update: in directory .: cvs [update aborted]: *PANIC* administration files missing -- 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 ajackson at redhat.com Tue Jul 24 18:39:03 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 24 Jul 2007 14:39:03 -0400 Subject: updating common dirs In-Reply-To: <46A63F3F.1000603@cora.nwra.com> References: <20070724130213.01236d2a@localhost.localdomain> <20070724132250.42912627@localhost.localdomain> <46A63F3F.1000603@cora.nwra.com> Message-ID: <1185302343.2794.121.camel@localhost.localdomain> On Tue, 2007-07-24 at 12:04 -0600, Orion Poplawski wrote: > Jesse Keating wrote: > > An update of your common/ directory should fix this issue and allow > > your build to continue. An update to Makefile.common was made to use a > > canonical reference for our CVS server. > > Is there an easy way to update all of my common dirs in one step? > > [orion at cynosure ~/fedora]$ cvs update */common > cvs update: in directory .: > cvs [update aborted]: *PANIC* administration files missing for i in */common ; do pushd $i ; cvs up ; popd ; done - ajax From rc040203 at freenet.de Tue Jul 24 19:20:45 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Jul 2007 21:20:45 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185293966.2408.123.camel@cutter> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> Message-ID: <1185304845.20980.87.camel@mccallum.corsepiu.local> On Tue, 2007-07-24 at 12:19 -0400, seth vidal wrote: > On Tue, 2007-07-24 at 18:14 +0200, Ralf Corsepius wrote: > > > dark forces? > > The person @RH or the person from whatever "committee-de-jour", who is > > pushing this nonsense onto users and devs. - Give names, please. > > > > I'm one of them. We're asking for this information in the packages b/c > we are worried about licensing version conflicts making it a problem for > us to ship certain packages linked against other ones. This was after > conversation with legal. Then spare your breath. I've been told all FSF owned packages will change to [L]GPLv3 by RMS order until 2007-07-31. GCC/binutils/gdb already are changing. I don't know about others. Once glibc will change, you can mark all packages for "review by legal". > So, if you want, I'm one of the "Dark Forces". > > WE NEED THE INFORMATION. The board has been empowered to make this > decision. Supposedly, fesco and fpc implement the decisions that the > board has made. That's why we asked for it to be addressed there. > > That's how the system is supposed to work. Exactly where are the dark > forces? The dark forces are those people behind the various (almost daily mushrooming - At least I've lost oversight) committees trying to push volunteering contributors around. Wake up RedHat, FAB, FPB, FPC, FESCo, FMB ...! We are volunteers! You can try to push us - but not for very much longer. My camel's back already is broken, I've significantly reduced my involvement. Ralf From jkeating at redhat.com Tue Jul 24 19:34:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 15:34:20 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185304845.20980.87.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> Message-ID: <20070724153420.26b167a7@ender> On Tue, 24 Jul 2007 21:20:45 +0200 Ralf Corsepius wrote: > Then spare your breath. I've been told all FSF owned packages will > change to [L]GPLv3 by RMS order until 2007-07-31. > > GCC/binutils/gdb already are changing. I don't know about others. > Once glibc will change, you can mark all packages for "review by > legal". Until the FSF figures out what the hell they're going to do with gplv2 being incompatible with gplv3, we can't allow it in the distribution. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Jul 24 19:40:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Jul 2007 21:40:52 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724153420.26b167a7@ender> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> Message-ID: <1185306052.20980.99.camel@mccallum.corsepiu.local> On Tue, 2007-07-24 at 15:34 -0400, Jesse Keating wrote: > On Tue, 24 Jul 2007 21:20:45 +0200 > Ralf Corsepius wrote: > > > Then spare your breath. I've been told all FSF owned packages will > > change to [L]GPLv3 by RMS order until 2007-07-31. > > > > GCC/binutils/gdb already are changing. I don't know about others. > > Once glibc will change, you can mark all packages for "review by > > legal". > > Until the FSF figures out what the hell they're going to do with gplv2 > being incompatible with gplv3, we can't allow it in the distribution. Check the gcc list. There is pretty monsterous discussion on related topics taking place (100+ postings so far). Ralf From jkeating at redhat.com Tue Jul 24 19:48:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 15:48:42 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185306052.20980.99.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306052.20980.99.camel@mccallum.corsepiu.local> Message-ID: <20070724154842.4338daeb@localhost.localdomain> On Tue, 24 Jul 2007 21:40:52 +0200 Ralf Corsepius wrote: > Check the gcc list. There is pretty monsterous discussion on related > topics taking place (100+ postings so far). I know. The outcome of such discussions is what is important, and preventing anything from 'jumping the gun' is really important to Fedora. This is why we want to be on top of any and all license changes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at infradead.org Tue Jul 24 19:49:59 2007 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 24 Jul 2007 12:49:59 -0700 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724153420.26b167a7@ender> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> Message-ID: <1185306599.2686.1.camel@laptopd505.fenrus.org> On Tue, 2007-07-24 at 15:34 -0400, Jesse Keating wrote: > On Tue, 24 Jul 2007 21:20:45 +0200 > Ralf Corsepius wrote: > > > Then spare your breath. I've been told all FSF owned packages will > > change to [L]GPLv3 by RMS order until 2007-07-31. > > > > GCC/binutils/gdb already are changing. I don't know about others. > > Once glibc will change, you can mark all packages for "review by > > legal". > > Until the FSF figures out what the hell they're going to do with gplv2 > being incompatible with gplv3, we can't allow it in the distribution. that's sort of an unfair statement of the situation. gplv3 is not compatible with v2, but for what would it need to be? YOu can have v2 and v3 programs in the same distro just like you can have v2 and other licensed programs in the same distro. It only becomes a problem when you're linking (and for most cases that is fine) or are otherwise a derived work. From jkeating at redhat.com Tue Jul 24 19:57:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 15:57:45 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185306599.2686.1.camel@laptopd505.fenrus.org> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> Message-ID: <20070724155745.5fee23d5@localhost.localdomain> On Tue, 24 Jul 2007 12:49:59 -0700 Arjan van de Ven wrote: > gplv3 is not compatible with v2, but for what would it need to be? YOu > can have v2 and v3 programs in the same distro just like you can have > v2 and other licensed programs in the same distro. > > It only becomes a problem when you're linking (and for most cases that > is fine) or are otherwise a derived work. Yes, and that's why we need to know, so we can examine the linking path and ensure that we're not breaking any (l)gplv2 only licenses. We can't just rely upon upstream, as they have no idea what we're linking to their software. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub at redhat.com Tue Jul 24 20:02:46 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 24 Jul 2007 16:02:46 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185306599.2686.1.camel@laptopd505.fenrus.org> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> Message-ID: <20070724200246.GY2063@devserv.devel.redhat.com> On Tue, Jul 24, 2007 at 12:49:59PM -0700, Arjan van de Ven wrote: > > > GCC/binutils/gdb already are changing. I don't know about others. > > > Once glibc will change, you can mark all packages for "review by > > > legal". > > > > Until the FSF figures out what the hell they're going to do with gplv2 > > being incompatible with gplv3, we can't allow it in the distribution. > > > that's sort of an unfair statement of the situation. > gplv3 is not compatible with v2, but for what would it need to be? YOu > can have v2 and v3 programs in the same distro just like you can have v2 > and other licensed programs in the same distro. > > It only becomes a problem when you're linking (and for most cases that > is fine) or are otherwise a derived work. The only problem is lgplv3, I don't see any problems with including gplv3 programs in Fedora and including gplv3 gcc or binutils in Fedora will be soon a necessity. Jakub From tmraz at redhat.com Tue Jul 24 20:10:18 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 24 Jul 2007 22:10:18 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724200246.GY2063@devserv.devel.redhat.com> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> Message-ID: <1185307818.20962.12.camel@perun.kabelta.loc> On Tue, 2007-07-24 at 16:02 -0400, Jakub Jelinek wrote: > On Tue, Jul 24, 2007 at 12:49:59PM -0700, Arjan van de Ven wrote: > > > > GCC/binutils/gdb already are changing. I don't know about others. > > > > Once glibc will change, you can mark all packages for "review by > > > > legal". > > > > > > Until the FSF figures out what the hell they're going to do with gplv2 > > > being incompatible with gplv3, we can't allow it in the distribution. > > > > > > that's sort of an unfair statement of the situation. > > gplv3 is not compatible with v2, but for what would it need to be? YOu > > can have v2 and v3 programs in the same distro just like you can have v2 > > and other licensed programs in the same distro. > > > > It only becomes a problem when you're linking (and for most cases that > > is fine) or are otherwise a derived work. > > The only problem is lgplv3, I don't see any problems with including > gplv3 programs in Fedora and including gplv3 gcc or binutils in Fedora > will be soon a necessity. And I don't even see the problem with lgplv3 - we just have to ensure that we don't link any gplv2 only program to such library. Such as we have to ensure that we don't link any gpl program to openssl library and so on. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mitr at volny.cz Tue Jul 24 20:15:04 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 24 Jul 2007 22:15:04 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185307818.20962.12.camel@perun.kabelta.loc> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> Message-ID: <46A65DC8.6020508@volny.cz> Tomas Mraz napsal(a): > And I don't even see the problem with lgplv3 - we just have to ensure > that we don't link any gplv2 only program to such library. Such as we > have to ensure that we don't link any gpl program to openssl library and > so on. Fedora currently packages software under GPLv2. What happens to the software if we update glibc go a lgplv3 version? Mirek From fedora at camperquake.de Tue Jul 24 20:18:53 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 24 Jul 2007 22:18:53 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185307818.20962.12.camel@perun.kabelta.loc> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> Message-ID: <20070724221853.77fc69e8@lain.camperquake.de> Hi. On Tue, 24 Jul 2007 22:10:18 +0200, Tomas Mraz wrote > And I don't even see the problem with lgplv3 - we just have to ensure > that we don't link any gplv2 only program to such library. Such as we > have to ensure that we don't link any gpl program to openssl library > and so on. Errr.. like these? stunnel: GPL ssmtp: GPL wget: GPL slrn: GPL htdig: GPL cadaver: GPL pam_ccreds: GPL lftp: GPL openvpn: GPL ctorrent: GPL elinks: GPL wpa_supplicant: GPL perl-Crypt-SSLeay: GPL or Artistic libdhcp6client: GPL xen: GPL dhcpv6_client: GPL git-core: GPL fetchmail: GPL rdesktop: GPL claws-mail: GPL claws-mail-plugins-pgp: GPL gkrellm: GPL From rhallyx at mindspring.com Tue Jul 24 20:26:28 2007 From: rhallyx at mindspring.com (Richard Hally) Date: Tue, 24 Jul 2007 16:26:28 -0400 Subject: vixie-cron conflict Message-ID: <46A66074.80507@mindspring.com> what is the fix for this: [root at new3 ~]# yum install vixie-cron Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package vixie-cron.i386 4:4.1-84.fc8 set to be updated --> Processing Conflict: vixie-cron conflicts sysklogd < 1.4.1 --> Finished Dependency Resolution Error: vixie-cron conflicts with sysklogd < 1.4.1 [root at new3 ~]# rpm -q rsyslog rsyslog-1.17.2-1.fc8 Thanks for any help Richard From tmraz at redhat.com Tue Jul 24 20:28:22 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 24 Jul 2007 22:28:22 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724221853.77fc69e8@lain.camperquake.de> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <20070724221853.77fc69e8@lain.camperquake.de> Message-ID: <1185308902.20962.16.camel@perun.kabelta.loc> On Tue, 2007-07-24 at 22:18 +0200, Ralf Ertzinger wrote: > Hi. > > On Tue, 24 Jul 2007 22:10:18 +0200, Tomas Mraz wrote > > > And I don't even see the problem with lgplv3 - we just have to ensure > > that we don't link any gplv2 only program to such library. Such as we > > have to ensure that we don't link any gpl program to openssl library > > and so on. > > Errr.. like these? > > stunnel: GPL > ssmtp: GPL > wget: GPL > slrn: GPL > htdig: GPL > cadaver: GPL > pam_ccreds: GPL > lftp: GPL > openvpn: GPL > ctorrent: GPL > elinks: GPL > wpa_supplicant: GPL > perl-Crypt-SSLeay: GPL or Artistic > libdhcp6client: GPL > xen: GPL > dhcpv6_client: GPL > git-core: GPL > fetchmail: GPL > rdesktop: GPL > claws-mail: GPL > claws-mail-plugins-pgp: GPL > gkrellm: GPL Either they have exception for linking with openssl or we are already breaking the licenses and we should stop doing that. Why nobody noticed that earlier? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From skvidal at linux.duke.edu Tue Jul 24 20:29:52 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 24 Jul 2007 16:29:52 -0400 Subject: vixie-cron conflict In-Reply-To: <46A66074.80507@mindspring.com> References: <46A66074.80507@mindspring.com> Message-ID: <1185308993.2408.176.camel@cutter> On Tue, 2007-07-24 at 16:26 -0400, Richard Hally wrote: > what is the fix for this: > > [root at new3 ~]# yum install vixie-cron > Setting up Install Process > Parsing package install arguments > Resolving Dependencies > --> Running transaction check > ---> Package vixie-cron.i386 4:4.1-84.fc8 set to be updated > --> Processing Conflict: vixie-cron conflicts sysklogd < 1.4.1 > --> Finished Dependency Resolution > Error: vixie-cron conflicts with sysklogd < 1.4.1 > [root at new3 ~]# rpm -q rsyslog > rsyslog-1.17.2-1.fc8 > rsyslog pushed into rawhide with a faulty 'provides' tag. It's been fixed in cvs and will be up in rawhide probably tomorrow or the next day. hope this helps. -sv From jkeating at redhat.com Tue Jul 24 20:30:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 16:30:36 -0400 Subject: vixie-cron conflict In-Reply-To: <46A66074.80507@mindspring.com> References: <46A66074.80507@mindspring.com> Message-ID: <20070724163036.041d4ed2@localhost.localdomain> On Tue, 24 Jul 2007 16:26:28 -0400 Richard Hally wrote: > what is the fix for this: > > [root at new3 ~]# yum install vixie-cron > Setting up Install Process > Parsing package install arguments > Resolving Dependencies > --> Running transaction check > ---> Package vixie-cron.i386 4:4.1-84.fc8 set to be updated > --> Processing Conflict: vixie-cron conflicts sysklogd < 1.4.1 > --> Finished Dependency Resolution > Error: vixie-cron conflicts with sysklogd < 1.4.1 > [root at new3 ~]# rpm -q rsyslog > rsyslog-1.17.2-1.fc8 This will be fixed in tomorrow's rawhide. rsyslog adjusted what it provided. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Jul 24 20:31:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 16:31:33 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185308902.20962.16.camel@perun.kabelta.loc> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <20070724221853.77fc69e8@lain.camperquake.de> <1185308902.20962.16.camel@perun.kabelta.loc> Message-ID: <20070724163133.503afa14@localhost.localdomain> On Tue, 24 Jul 2007 22:28:22 +0200 Tomas Mraz wrote: > Either they have exception for linking with openssl or we are already > breaking the licenses and we should stop doing that. Why nobody > noticed that earlier? Maybe because we were assuming that the maintainers knew what they were doing? (not that I know if there is any problem here...) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rhally at mindspring.com Tue Jul 24 20:36:35 2007 From: rhally at mindspring.com (Richard Hally) Date: Tue, 24 Jul 2007 16:36:35 -0400 Subject: vixie-cron conflict In-Reply-To: <20070724163036.041d4ed2@localhost.localdomain> References: <46A66074.80507@mindspring.com> <20070724163036.041d4ed2@localhost.localdomain> Message-ID: <46A662D3.4020300@mindspring.com> Jesse Keating wrote: > On Tue, 24 Jul 2007 16:26:28 -0400 > Richard Hally wrote: > >> what is the fix for this: >> >> [root at new3 ~]# yum install vixie-cron >> Setting up Install Process >> Parsing package install arguments >> Resolving Dependencies >> --> Running transaction check >> ---> Package vixie-cron.i386 4:4.1-84.fc8 set to be updated >> --> Processing Conflict: vixie-cron conflicts sysklogd < 1.4.1 >> --> Finished Dependency Resolution >> Error: vixie-cron conflicts with sysklogd < 1.4.1 >> [root at new3 ~]# rpm -q rsyslog >> rsyslog-1.17.2-1.fc8 > > This will be fixed in tomorrow's rawhide. rsyslog adjusted what it > provided. > Thanks Jesse and Seth. I had thought it was fixed in rawhide... Just got ahead of myself. sorry for the noise. Richard From fabio.comolli at gmail.com Tue Jul 24 20:47:43 2007 From: fabio.comolli at gmail.com (Fabio Comolli) Date: Tue, 24 Jul 2007 22:47:43 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724163133.503afa14@localhost.localdomain> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <20070724221853.77fc69e8@lain.camperquake.de> <1185308902.20962.16.camel@perun.kabelta.loc> <20070724163133.503afa14@localhost.localdomain> Message-ID: Hi. Maybe this link can help? http://www.gnome.org/~markmc/openssl-and-the-gpl.html Regards, Fabio On 7/24/07, Jesse Keating wrote: > On Tue, 24 Jul 2007 22:28:22 +0200 > Tomas Mraz wrote: > > > Either they have exception for linking with openssl or we are already > > breaking the licenses and we should stop doing that. Why nobody > > noticed that earlier? > > Maybe because we were assuming that the maintainers knew what they were > doing? (not that I know if there is any problem here...) > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From cmadams at hiwaay.net Tue Jul 24 20:51:15 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 24 Jul 2007 15:51:15 -0500 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724221853.77fc69e8@lain.camperquake.de> References: <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <20070724221853.77fc69e8@lain.camperquake.de> Message-ID: <20070724205115.GA1337691@hiwaay.net> Once upon a time, Ralf Ertzinger said: > claws-mail: GPL > fetchmail: GPL > openvpn: GPL > rdesktop: GPL > stunnel: GPL > wget: GPL These include an OpenSSL exception. > elinks: GPL This has a sort-of OpenSSL exception. > claws-mail-plugins-pgp: GPL This is a collection of different things; some list an OpenSSL exception (and may be the only ones that use OpenSSL). > cadaver: GPL > ctorrent: GPL > git-core: GPL > gkrellm: GPL > lftp: GPL > pam_ccreds: GPL > slrn: GPL > ssmtp: GPL No mention of an exception. > htdig: GPL LGPL not GPL (not sure what that means for OpenSSL linking though). > wpa_supplicant: GPL Dual-licensed GPLv2 and BSD. > perl-Crypt-SSLeay: GPL or Artistic I believe Artistic is okay with OpenSSL. > dhcpv6_client: GPL > libdhcp6client: GPL Boy, this looks like a mess. No overall license that I can find (looking at dhcpv6-0.10-42.fc7), most files under a BSD-style (3 clause) license from IBM, and one file that is patched out under LGPL. The libdhcp6client subdirectory files are mixed as well; some have no license and some have GPL (no version). > xen: GPL Some files are dual-licensed BSD; I'm not sure which link to OpenSSL. This is a good example of why license changes need to be clearly announced and researched. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jspaleta at gmail.com Tue Jul 24 20:51:53 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 Jul 2007 12:51:53 -0800 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185307818.20962.12.camel@perun.kabelta.loc> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> Message-ID: <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> On 7/24/07, Tomas Mraz wrote: > And I don't even see the problem with lgplv3 - we just have to ensure > that we don't link any gplv2 only program to such library. Such as we > have to ensure that we don't link any gpl program to openssl library and > so on. "We" have to ensure.... let me stress the "We" in that first sentence. The individual library maintainers are the absolute best people to be running point for the library packages they are maintaining. They are best positioned to make sure information gets to the other maintainers who depend on that package, before a re-licensed version of the library gets into one of the build trees. It would be best if "we" could prevent situations where "we" have inadvertent linking violations. But each individual maintainer needs to try the find the time to review their packages to see what the hell is going on upstream for the libraries they are linking against. Pretty please, with sugar on top. I'd really like to avoid a situation where we have to start arbitrarily rolling back commits to clean up linking violations which could have been avoided through reasonable communication. As more individual projects who were previous under LGPL2/GPL2 start relicensing we may need to adjust how we do things until the licensing situation settles out and upstream projects are back to a consistent understood licensing state. -jef"i need a new watch, i smashed mine against something yesterday and now the glass face as an internal crack. There's no way that thing is going to survive the winter"spaleta From pjones at redhat.com Tue Jul 24 20:52:12 2007 From: pjones at redhat.com (Peter Jones) Date: Tue, 24 Jul 2007 16:52:12 -0400 Subject: rawhide report: 20070721 changes In-Reply-To: <20070721204244.615a8355@vader.jdub.homelinux.org> References: <200707211124.l6LBOcLn031605@porkchop.devel.redhat.com> <6e24a8e80707211816g1d2b386bu1314f3df9e387fd8@mail.gmail.com> <20070721204244.615a8355@vader.jdub.homelinux.org> Message-ID: <46A6667C.3070609@redhat.com> Josh Boyer wrote: > On Sun, 22 Jul 2007 03:16:39 +0200 > Mark wrote: > >> just wondering.. Alot of packages have fc8 in there name.. Why is >> that? shouldn't it be f8? > > No. This has been asked a lot. It stands for "fedora collection" now. And also, we kindof painter ourselves into a corner -- "f8" sorts before "fc7" in rpm's version compare. That is to say, if all other parts of the version tuple are the same, the "f8" is older than "fc7". -- Peter From arjan at infradead.org Tue Jul 24 20:55:52 2007 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 24 Jul 2007 13:55:52 -0700 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> Message-ID: <1185310553.2686.3.camel@laptopd505.fenrus.org> On Tue, 2007-07-24 at 12:51 -0800, Jeff Spaleta wrote: > I'd really like to avoid a situation where we have to start > arbitrarily rolling back commits to clean up linking violations which > could have been avoided through reasonable communication. As more > individual projects who were previous under LGPL2/GPL2 start > relicensing we may need to adjust how we do things until the licensing > situation settles out and upstream projects are back to a consistent > understood licensing state. this is where tools help! if the License: tag is machine parsable, at least some of the "mistakes" can be detected. It won't be perfect, but it's at least some level of safeguard. From dcantrell at redhat.com Tue Jul 24 20:59:40 2007 From: dcantrell at redhat.com (David Cantrell) Date: Tue, 24 Jul 2007 16:59:40 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724205115.GA1337691@hiwaay.net> References: <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <20070724221853.77fc69e8@lain.camperquake.de> <20070724205115.GA1337691@hiwaay.net> Message-ID: <20070724165940.4ee4dba3.dcantrell@redhat.com> On Tue, 24 Jul 2007 15:51:15 -0500 Chris Adams wrote: > Once upon a time, Ralf Ertzinger said: > > dhcpv6_client: GPL > > libdhcp6client: GPL > > Boy, this looks like a mess. No overall license that I can find > (looking at dhcpv6-0.10-42.fc7), most files under a BSD-style (3 clause) > license from IBM, and one file that is patched out under LGPL. The > libdhcp6client subdirectory files are mixed as well; some have no > license and some have GPL (no version). The things added should all be under GPLv2 with Red Hat as the copyright holder. Double checking as this is one of my packages. -- David Cantrell Red Hat / Westford, MA -------------- 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 Jul 24 21:05:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 24 Jul 2007 17:05:52 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185307818.20962.12.camel@perun.kabelta.loc> References: <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> Message-ID: <20070724210552.GA8481@nostromo.devel.redhat.com> Tomas Mraz (tmraz at redhat.com) said: > And I don't even see the problem with lgplv3 - we just have to ensure > that we don't link any gplv2 only program to such library. Such as we > have to ensure that we don't link any gpl program to openssl library and > so on. Right, but that means the LPGLv3 change just suddenly made software we already ship undistributable. That's bad, obviously. Bill From jkeating at redhat.com Tue Jul 24 21:09:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 17:09:33 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185310553.2686.3.camel@laptopd505.fenrus.org> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> <1185310553.2686.3.camel@laptopd505.fenrus.org> Message-ID: <20070724170933.6b8f3b93@localhost.localdomain> On Tue, 24 Jul 2007 13:55:52 -0700 Arjan van de Ven wrote: > this is where tools help! > if the License: tag is machine parsable, at least some of the > "mistakes" can be detected. It won't be perfect, but it's at least > some level of safeguard. The Fedora Packaging Committee is working on exactly that. Defining a valid set of content that can be in License so that it can be machine parsable, or at least easy to weed out the easy cases and get a list of things that need closer inspection. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From walters at redhat.com Tue Jul 24 21:18:27 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 24 Jul 2007 17:18:27 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185310553.2686.3.camel@laptopd505.fenrus.org> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> <1185310553.2686.3.camel@laptopd505.fenrus.org> Message-ID: <1185311907.3416.6.camel@neutron.verbum.private> On Tue, 2007-07-24 at 13:55 -0700, Arjan van de Ven wrote: > On Tue, 2007-07-24 at 12:51 -0800, Jeff Spaleta wrote: > > > I'd really like to avoid a situation where we have to start > > arbitrarily rolling back commits to clean up linking violations which > > could have been avoided through reasonable communication. As more > > individual projects who were previous under LGPL2/GPL2 start > > relicensing we may need to adjust how we do things until the licensing > > situation settles out and upstream projects are back to a consistent > > understood licensing state. > > this is where tools help! > if the License: tag is machine parsable, at least some of the "mistakes" > can be detected. It won't be perfect, but it's at least some level of > safeguard. We should be *reducing* the amount of manually-created goo[1] involved in putting software into Fedora, not increasing it. An automatic tool which scans the actual sources included upstream wouldn't be difficult to write. In fact it seems very likely to already exist, though I couldn't find something in a quick search. Automating the checking would also allow us to catch changes automatically. From skvidal at linux.duke.edu Tue Jul 24 21:21:29 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 24 Jul 2007 17:21:29 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185311907.3416.6.camel@neutron.verbum.private> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> <1185310553.2686.3.camel@laptopd505.fenrus.org> <1185311907.3416.6.camel@neutron.verbum.private> Message-ID: <1185312089.2408.181.camel@cutter> On Tue, 2007-07-24 at 17:18 -0400, Colin Walters wrote: > On Tue, 2007-07-24 at 13:55 -0700, Arjan van de Ven wrote: > > On Tue, 2007-07-24 at 12:51 -0800, Jeff Spaleta wrote: > > > > > I'd really like to avoid a situation where we have to start > > > arbitrarily rolling back commits to clean up linking violations which > > > could have been avoided through reasonable communication. As more > > > individual projects who were previous under LGPL2/GPL2 start > > > relicensing we may need to adjust how we do things until the licensing > > > situation settles out and upstream projects are back to a consistent > > > understood licensing state. > > > > this is where tools help! > > if the License: tag is machine parsable, at least some of the "mistakes" > > can be detected. It won't be perfect, but it's at least some level of > > safeguard. > > We should be *reducing* the amount of manually-created goo[1] involved > in putting software into Fedora, not increasing it. > > An automatic tool which scans the actual sources included upstream > wouldn't be difficult to write. In fact it seems very likely to already > exist, though I couldn't find something in a quick search. when spot looked into all of our licenses before he found this was not all that much that case. Especially when it has to look for things like 'or later' and multiple licenses per package. -sv From pjones at redhat.com Tue Jul 24 21:29:21 2007 From: pjones at redhat.com (Peter Jones) Date: Tue, 24 Jul 2007 17:29:21 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185311907.3416.6.camel@neutron.verbum.private> References: <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724200246.GY2063@devserv.devel.redhat.com> <1185307818.20962.12.camel@perun.kabelta.loc> <604aa7910707241351i26f19917y1ca2742ea401493@mail.gmail.com> <1185310553.2686.3.camel@laptopd505.fenrus.org> <1185311907.3416.6.camel@neutron.verbum.private> Message-ID: <46A66F31.4020200@redhat.com> Colin Walters wrote: > An automatic tool which scans the actual sources included upstream > wouldn't be difficult to write. In fact it seems very likely to already > exist, though I couldn't find something in a quick search. That winds up having a lot of weird caveats -- not the least of which being things like cdrecord, which is full of additional restrictions (thus invalidating *something*, though it's not quite clear what.) Basically, an automatic tool is ok for finding potential problems with the License: line, but not very good for choosing it to start with. -- Peter From chris.stone at gmail.com Tue Jul 24 23:57:58 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 24 Jul 2007 16:57:58 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <1185296850.5046.5.camel@sb-home> References: <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> Message-ID: On 7/24/07, nodata wrote: > Am Montag, den 23.07.2007, 14:55 -0700 schrieb Christopher Stone: > > On 7/23/07, nodata wrote: > > > I don't. It requires the user to know (and care) what a "KDE" or a > > > "Gnome" is. A user shouldn't have to hunt around two different menus > > > (which is what this suggestion is) just to find their application. > > > > > > If they are in Gnome, they get the Gnome stuff, if they are in KDE they > > > get the KDE stuff. If they know better, they know better. > > > > This is so dumb it makes Microsoft engineers look like friggin' geniuses. > > It's a damn lot letter than the "Let's have a KDE and a Gnome and a XFCE > menu" suggestion. > > Show the KDE equivalent in the KDE desktop - Amarok or whatever. I should not have disrespected your opinion before, but if a user installs Amarok, then that user should have a menu item for it regardless of what desktop environment she is using. If a user running Xfce wants to use Amarok, then let her. Do not try to force her into using non-KDE and non-GNOME apps simply because she runs Xfce. From jkeating at redhat.com Wed Jul 25 00:17:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 20:17:10 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> Message-ID: <20070724201710.70f3a9fa@ender> On Tue, 24 Jul 2007 16:57:58 -0700 "Christopher Stone" wrote: > I should not have disrespected your opinion before, but if a user > installs Amarok, then that user should have a menu item for it > regardless of what desktop environment she is using. > > If a user running Xfce wants to use Amarok, then let her. Do not try > to force her into using non-KDE and non-GNOME apps simply because she > runs Xfce. Stop assuming A) a single user system. B) a user controlled system C) an intelligent thought about what gets installed (everything crowd?) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yabraham2 at gmail.com Wed Jul 25 00:18:12 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Tue, 24 Jul 2007 20:18:12 -0400 Subject: todays update wipes all kernels and rpm is broken Message-ID: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> in my rawhide machine, I use pirut to apply the appdates. it failed at almost the end. after reboot, I am left with only one kernel vesrion. I had it set up in /etc/yum/pluginconf.d/installonlyn.conf to keep 3 kernels. now that file is actually removed and saved as /etc/yum/pluginconf.d/installonlyn.conf.rpmsave running rpm gives :error loading shared libraries: libgcc_s.so.1 /usr/bin/pirut : error in loading libgtk-x11-2.0.so.0 any idea. /yonas From skvidal at linux.duke.edu Wed Jul 25 00:45:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 24 Jul 2007 20:45:00 -0400 Subject: todays update wipes all kernels and rpm is broken In-Reply-To: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> References: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> Message-ID: <1185324301.2408.188.camel@cutter> On Tue, 2007-07-24 at 20:18 -0400, yonas Abraham wrote: > in my rawhide machine, I use pirut to apply the appdates. it failed at > almost the end. after reboot, I am left with only one kernel vesrion. > I had it set up in /etc/yum/pluginconf.d/installonlyn.conf to keep 3 > kernels. now that file is actually removed and saved as > /etc/yum/pluginconf.d/installonlyn.conf.rpmsave > > running rpm gives :error loading shared libraries: libgcc_s.so.1 > > /usr/bin/pirut : error in loading libgtk-x11-2.0.so.0 1. the installonlyn plugin is no longer in the yum package in rawhide. That feature has been moved into yum itself so the plugin isn't needed. Yum should be preserving 2 kernels by default in the configuration in fedora. You can set the number you want it to keep by setting installonly_limit in yum.conf 2. not sure about the deps but something as deep as libgcc_s.so.1 seems bad. When you say pirut 'failed' what did it print out? -sv From jkeating at redhat.com Wed Jul 25 00:55:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 20:55:26 -0400 Subject: todays update wipes all kernels and rpm is broken In-Reply-To: <1185324301.2408.188.camel@cutter> References: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> <1185324301.2408.188.camel@cutter> Message-ID: <20070724205526.32520d62@ender> On Tue, 24 Jul 2007 20:45:00 -0400 seth vidal wrote: > 2. not sure about the deps but something as deep as libgcc_s.so.1 > seems bad. > When you say pirut 'failed' what did it print out? I wonder if this is more fallout from the %pretrans stuff. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yabraham2 at gmail.com Wed Jul 25 01:04:53 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Tue, 24 Jul 2007 21:04:53 -0400 Subject: todays update wipes all kernels and rpm is broken In-Reply-To: <1185324301.2408.188.camel@cutter> References: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> <1185324301.2408.188.camel@cutter> Message-ID: <47324ed80707241804u2872d07dx9b150725ddc31edc@mail.gmail.com> On 7/24/07, seth vidal wrote: > On Tue, 2007-07-24 at 20:18 -0400, yonas Abraham wrote: > > in my rawhide machine, I use pirut to apply the appdates. it failed at > > almost the end. after reboot, I am left with only one kernel vesrion. > > I had it set up in /etc/yum/pluginconf.d/installonlyn.conf to keep 3 > > kernels. now that file is actually removed and saved as > > /etc/yum/pluginconf.d/installonlyn.conf.rpmsave > > > > running rpm gives :error loading shared libraries: libgcc_s.so.1 > > > > /usr/bin/pirut : error in loading libgtk-x11-2.0.so.0 > > 1. the installonlyn plugin is no longer in the yum package in rawhide. > That feature has been moved into yum itself so the plugin isn't needed. > Yum should be preserving 2 kernels by default in the configuration in > fedora. You can set the number you want it to keep by setting > installonly_limit in yum.conf > it is good to know. > 2. not sure about the deps but something as deep as libgcc_s.so.1 seems > bad. > When you say pirut 'failed' what did it print out? > i don't remember what was it but it was a very long trace_back. The machine is still here, planning to re install it with fresh. But if you want me to try before that, i am willing to try /yonas From chris.stone at gmail.com Wed Jul 25 01:34:09 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 24 Jul 2007 18:34:09 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070724201710.70f3a9fa@ender> References: <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> Message-ID: On 7/24/07, Jesse Keating wrote: > On Tue, 24 Jul 2007 16:57:58 -0700 > "Christopher Stone" wrote: > > > I should not have disrespected your opinion before, but if a user > > installs Amarok, then that user should have a menu item for it > > regardless of what desktop environment she is using. > > > > If a user running Xfce wants to use Amarok, then let her. Do not try > > to force her into using non-KDE and non-GNOME apps simply because she > > runs Xfce. > > > Stop assuming > > A) a single user system. > B) a user controlled system > C) an intelligent thought about what gets installed (everything crowd?) Can you please clarify? How is it any different if a system has one user or one hundred? If a sysadmin requires everyone to use Kate as their editor (for some hypothetical reason), then the menu item should show up no matter what DE any one of the users chooses to run. I'm not sure what a "user controlled system" means. Also, I don't understand your argument for item C. If someone wants to install every single application then I would guess that this same user would also want to have these applications show up in their menu. Why would someone who installs every single application only want a subset of those applications in their menus? Is it really correct to assume that someone who installs all applications is not intelligent and we need to think for them? This is Microsoft philosophy. Do not try to force a user into using her machine the way *you* think she should. From jkeating at redhat.com Wed Jul 25 01:43:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 21:43:34 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> Message-ID: <20070724214334.5b6eec19@ender> On Tue, 24 Jul 2007 18:34:09 -0700 "Christopher Stone" wrote: > Can you please clarify? How is it any different if a system has one > user or one hundred? I can have a handfull of gnomeusers that only want gnome apps like gedit. I can have a handfull of kde users that only want kde apps like kate. I can have other "power" users that make use of things like gnome-menu or the kde equiv to see /all/ items. I don't want to needlessly clutter the gnome user's menus with 10 different editor choices, or even 2. Likewise others. > If a sysadmin requires everyone to use Kate as > their editor (for some hypothetical reason), then the menu item should > show up no matter what DE any one of the users chooses to run. If the sysadmin is requiring it, the sysadmin will be able to force it in the menus, using something like sabayon to setup a desktop and enforce the policy. > > I'm not sure what a "user controlled system" means. Where the user is the admin and is in control over what applications are installed. > > Also, I don't understand your argument for item C. If someone wants > to install every single application then I would guess that this same > user would also want to have these applications show up in their menu. > Why would someone who installs every single application only want a > subset of those applications in their menus? > > Is it really correct to assume that someone who installs all > applications is not intelligent and we need to think for them? This > is Microsoft philosophy. Do not try to force a user into using her > machine the way *you* think she should. Most often those that install "everything" are the ones that put no thought into what they actually want. They give up and just install everything, and then complain when the menus are too cluttered. It's not like we haven't played this game before. While what we have now may have a few bugs, and a few ShowOnlyIn may need to get converted to DontShowIn or some such, it's a far sight better than the chaos we've had before. And yes, some tools like gnome-menu should probably learn to override/ignore these things and show what it would look like on a gnome login. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From darth_linux at ameritech.net Wed Jul 25 02:00:34 2007 From: darth_linux at ameritech.net (eah) Date: Tue, 24 Jul 2007 22:00:34 -0400 Subject: Qt4 RPMs broken? In-Reply-To: References: <200707201735.40344.darth_linux@ameritech.net> <200707202343.34817.darth_linux@ameritech.net> Message-ID: <200707242200.34830.darth_linux@ameritech.net> On Saturday 21 July 2007 01:03:06 Rex Dieter wrote: > eah wrote: > > On Friday 20 July 2007 22:42:38 Kevin Kofler wrote: > >> > (*) doc is a link to /usr/share/doc/qt, but should point > >> > to /usr/share/doc/qt4. > >> > >> That one sounds like a bug. Are you sure about that? It points > >> to ../../share/doc/qt4 here (qt4-4.3.0-8.fc7). > > \ > > > yep, i'm sure. but i did notice that updated version is qt4-4.3.0-2.fc6. > > maybe it's something that was fixed in the minor release(s) between -2 > > and -8.... ? > > Yep: > * Thu Jul 05 2007 Rex Dieter 4.3.0-8 > - fix %%_qt4_prefix/doc symlink > > There have been a few other fixes since then too... maybe an update is in > order. > > -- Rex thank you, sir. eah From jkeating at redhat.com Wed Jul 25 02:33:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 22:33:14 -0400 Subject: Frozen for Fedora 8 Test1 Message-ID: <20070724223314.13ea9d19@ender> We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' that is a container for the packages that are destined to be in Test1 (and rawhide until test1 is fully composed and released to mirrors). As per http://fedoraproject.org/wiki/ReleaseEngineering/Overview , builds from devel/ will continue to be tagged with 'dist-f8' and will be picked up by rawhide composes once the freeze is over. If you feel you must have your build in Test1 and it isn't already tagged with 'f8-test1', please follow http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy If you wish to help us get to Test1, please follow http://fedoraproject.org/wiki/QA/8/Test1TreeTesting -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From chris.stone at gmail.com Wed Jul 25 03:20:23 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 24 Jul 2007 20:20:23 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070724214334.5b6eec19@ender> References: <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> Message-ID: On 7/24/07, Jesse Keating wrote: > On Tue, 24 Jul 2007 18:34:09 -0700 > "Christopher Stone" wrote: > > > Can you please clarify? How is it any different if a system has one > > user or one hundred? > > I can have a handfull of gnomeusers that only want gnome apps like > gedit. I can have a handfull of kde users that only want kde apps like > kate. I can have other "power" users that make use of things like > gnome-menu or the kde equiv to see /all/ items. I don't want to > needlessly clutter the gnome user's menus with 10 different editor > choices, or even 2. Likewise others. Yes, and I can have a handfull of kde users that only want gnome apps like gedit. I can have a handfull of gnome users that only want kde apps like kate. What's the difference? > > I'm not sure what a "user controlled system" means. > > Where the user is the admin and is in control over what applications > are installed. So I still don't understand your argument against adding menu items for installed applications in this case. > Most often those that install "everything" are the ones that put no > thought into what they actually want. They give up and just install > everything, and then complain when the menus are too cluttered. Yea, okay. Let's make life difficult for everyone else so that the idiots who install every application will no longer complain about every application showing up in their menus. This makes a lot of sense. NOT! > It's not like we haven't played this game before. While what we have > now may have a few bugs, and a few ShowOnlyIn may need to get converted > to DontShowIn or some such, it's a far sight better than the chaos > we've had before. And yes, some tools like gnome-menu should probably > learn to override/ignore these things and show what it would look like > on a gnome login. I see nothing wrong with gnome-menu and/or kde-menu as long as its able to override ShowOnlyIn. From jkeating at redhat.com Wed Jul 25 03:27:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 23:27:57 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> Message-ID: <20070724232757.74adddf6@ender> On Tue, 24 Jul 2007 20:20:23 -0700 "Christopher Stone" wrote: > I see nothing wrong with gnome-menu and/or kde-menu as long as its > able to override ShowOnlyIn. Good, lets work toward that end end this silly argument. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From poelstra at redhat.com Wed Jul 25 07:20:43 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 25 Jul 2007 00:20:43 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-JUL-23 Message-ID: <46A6F9CB.80304@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jul-23 Please make corrections and clarifications to the wiki page. == F8 Test1 Freeze coming up == * builds from devel/ continue to get auto-tagged with 'dist-f8'. To get them into the test release they are manually tagged with 'f8-test1'. 'dist-rawhide' is pointed at 'f8-test1' during the freeze. Post-freeze 'dist-rawhide' is redirected to 'dist-f8' and life continues. * Freeze starts tomorrow (2007-07-24) * The typical workings that releng does during a freeze is thus: 1. tag build(s) for freeze tag (f8-test1) 1. sign build(s) 1. mash freeze tag 1. pungi / livecd-tools runs 1. test 1. wash, rinse, repeat * status of things with KDE4 * on hold, looks like kde4 release schedule will be delayed, at least month, so we'll likely miss f8 * How many of the F8 features are actually read to test in test1? * poelcat will: 1. create list of features that are close to 100% completion 1. ping feature owners to see if there are special testing needs for F8Test1 * wwoods created a f8test1 tracker bug--alias is "F8Test1" * bugs for F8 Test1 will have a separate entry in bugzilla * f13 will get it created == Next status meeting == * Thursday (2007-07-26) after FESCo From ich at frank-schmitt.net Wed Jul 25 07:31:47 2007 From: ich at frank-schmitt.net (Frank Schmitt) Date: Wed, 25 Jul 2007 09:31:47 +0200 Subject: Frozen for Fedora 8 Test1 References: <20070724223314.13ea9d19@ender> Message-ID: Jesse Keating writes: > We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' > that is a container for the packages that are destined to be in Test1 > (and rawhide until test1 is fully composed and released to mirrors). I guess that means yet another release with broken zsh when the fix would be just updating the package to upstream, as upstream developers recommend. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183557 http://www.zsh.org/mla/workers/2007/msg00471.html I mean OpenSuse and Ubuntu think zsh 4.3.x it's good enough for their release, not to mention that even Debian includes 4.3 in their *stable* release. Only the fedora maintainer sticks to 4.2 leaving everyone who is using a UTF-8 locale with a broken shell. This is just ridiculous. -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From buildsys at redhat.com Wed Jul 25 07:33:01 2007 From: buildsys at redhat.com (Build System) Date: Wed, 25 Jul 2007 03:33:01 -0400 Subject: rawhide report: 20070725 changes Message-ID: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> New package bacula Cross platform network backup for Linux, Unix, Mac and Windows New package hardinfo System Profiler and Benchmark New package libgeotiff GeoTIFF format library New package libtimidity MIDI to WAVE converter library New package m17n-contrib Contributed multilingualization datafiles for m17n-lib New package mcabber Console Jabber instant messaging client New package perl-Catalyst-Action-RenderView Sensible default end action for view renders New package pixman Pixel manipulation library New package schedtool Tool to query or alter process scheduling policy New package yum-updatesd Update notification daemon Updated Packages: R-mvtnorm-0.8-2.fc8 ------------------- * Tue Jul 24 2007 Orion Poplawski - 0.8-2 - Update to 0.8-1, fixes test adminutil-1.1.3-1.fc8 --------------------- * Tue Jul 24 2007 Rich Megginson - 1.1.3-1 - updated to version 1.1.3 - fixes bugzillas 246124 and 247192 allegro-4.2.2-2.fc8 ------------------- * Tue Jul 24 2007 Hans de Goede 4.2.2-2 - sync .libdir patch to 4.2.2 and use it again for multilib devel goodness (make allegro-devel i386 and x86_64 parallel installable again) * Mon Jul 23 2007 Jindrich Novy 4.2.2-1 - update to 4.2.2 - drop .libdir patch - sync .multilib patch * Fri Jul 06 2007 Hans de Goede 4.2.1-3 - Silence output of chcon command in %post, because otherwise users get this: "chcon: can't apply partial context to unlabeled file" when installing with selinux disabled (bz 246820) alsa-oss-1.0.14-1.fc8 --------------------- * Tue Jul 24 2007 Patrick "Jima" Laughton 1.0.14-1 - Updated to match F8 alsa-libs - Changed reference to patch filename anaconda-11.3.0.9-1 ------------------- * Tue Jul 24 2007 Jeremy Katz - 11.3.0.9-1 - Rebuild keymaps (clumens, #240087) - Fix kickstart docs about dhcpclass (clumens, #248910) - Fix for usb-storage dance (pjones, #247830) - Fix protected partitions problem (clumens) - Improve stage2 generation bind-32:9.5.0-6.a6.fc8 ---------------------- * Tue Jul 24 2007 Adam Tkac 32:9.5.0-6.a6.fc8 - updated to 9.5.0a6 which contains fixes for CVE-2007-2925 and CVE-2007-2926 - fixed building on 64bits * Mon Jul 23 2007 Adam Tkac 31:9.5.0a5-5.fc8 - integrated "autotools" patch for testing purposes (upstream will accept it in future, for easier building) * Mon Jul 23 2007 Adam Tkac 31:9.5.0a5-4.1.fc8 - fixed DLZ drivers building on 64bit systems binutils-2.17.50.0.17-5 ----------------------- * Wed Jul 25 2007 Jakub Jelinek 2.17.50.0.17-5 - add .note.gnu.build-id into default linker script (#249435) * Wed Jul 25 2007 Jakub Jelinek 2.17.50.0.17-4 - don't kill the %{_gnu} part of target name on arm (Lennert Buytenhek, #243516) - create just one PT_NOTE segment header for all consecutive SHT_NOTE sections * Wed Jul 18 2007 Roland McGrath 2.17.50.0.17-3 - fix for ld --build-id cone-0.71-1.fc8 --------------- * Tue Jul 24 2007 Steven Pritchard 0.71-1 - Update to 0.71. * Mon Apr 09 2007 Steven Pritchard 0.69-1 - Update to 0.69. * Mon Aug 28 2006 Steven Pritchard 0.68-2 - Rebuild. eog-2.19.4-2.fc8 ---------------- * Tue Jul 24 2007 Matthias Clasen - 2.19.4-2 - Fix a undefined macro use (#248689) fuse-2.7.0-3.fc8 ---------------- * Sun Jul 22 2007 Tom "spot" Callaway 2.7.0-3 - put pkgconfig file in correct place - enable compat symlinks for files in /bin * Sat Jul 21 2007 Tom "spot" Callaway 2.7.0-2 - redefine exec_prefix to / - redefine bindir to /bin - redefine libdir to %{_lib} - don't pass --disable-static to configure - manually rm generated static libs * Wed Jul 18 2007 Peter Lemenkov 2.7.0-1 - Version 2.7.0 - Redefined exec_prefix due to demands from NTFS-3G gc-7.0-2.fc8 ------------ * Tue Jul 24 2007 Rex Dieter 7.0-2 - gcinit patch, ABI compatibility (#248700) gcc-4.1.2-17 ------------ * Tue Jul 24 2007 Jakub Jelinek 4.1.2-17 - fix {,Build}Requires from last change (#249384) gnome-panel-2.19.5-3.fc8 ------------------------ * Tue Jul 24 2007 Matthias Clasen - 2.19.5-3 - Fix launcher tooltips to react to changes. (#212164) gnome-speech-0.4.15-2.fc8 ------------------------- * Tue Jul 24 2007 Matthias Clasen - 0.4.15-2 - Build the espeak driver and put it in a subpackage gpm-1.20.1-87.fc8 ----------------- * Tue Jul 24 2007 Tomas Janousek - 1.20.1-87 - replace OPEN_MAX with sysconf(_SC_OPEN_MAX), fixing build with 2.6.23 kernel * Tue Jul 24 2007 Tomas Janousek - 1.20.1-86 - don't install t-mouse.el, emacs-common contains a newer version, fixes #249362 kde-settings-3.5-30.fc8 ----------------------- * Mon Jul 02 2007 Than Ngo - 3.5-30 - fix bz#245100 kdesdk-3.5.7-7.fc8 ------------------ * Tue Jul 24 2007 Rex Dieter - 3.5.7-7 - don't use %pretrans (#249374) kernel-xen-2.6-2.6.21-2925.14.fc8 --------------------------------- * Tue Jul 24 2007 Eduardo Habkost - Rebase to 2.6.21.6 ktorrent-2.2.1-1.fc8 -------------------- * Tue Jul 24 2007 Roland Wolters 2.2.1-1 - update to bugfix upstream 2.2.1 libXcomposite-0.4.0-1.fc8 ------------------------- * Tue Jul 24 2007 Adam Jackson 0.4.0-1 - libXcomposite 0.4.0 * Sat Apr 21 2007 Matthias Clasen - 0.3.1-2 - Don't install INSTALL libhangul-0.0.6-1.fc8 --------------------- * Tue Jul 24 2007 Hu Zheng - 0.0.6-1 - New upstream release. libpcap-14:0.9.7-1.fc8 ---------------------- libvirt-0.3.1-1.fc8 ------------------- * Tue Jul 24 2007 Daniel Veillard - 0.3.1-1.fc8 - Release of 0.3.1 - localtime clock support - PS/2 and USB input devices - lots of assorted bugfixes and cleanups - documentation and localization improvements libwnck-2.19.5-2.fc8 -------------------- * Tue Jul 24 2007 Matthias Clasen - 2.19.5-2 - Fix a crash on shutdown in the wnck-applet libxml++-2.18.1-1.fc8 --------------------- * Tue Jul 24 2007 Denis Leroy - 2.18.1-1 - Update to version 2.18.1 meld-1.1.5-2.fc8 ---------------- * Sun Jun 10 2007 Brian Pepple - 1.1.5-2 - Drop requires on yelp. mesa-6.5.2-15.fc8 ----------------- * Tue Jul 24 2007 Adam Jackson 6.5.2-15 - Add dri_interface.h to mesa-libGL-devel, and conflict with xorg-x11-proto-devel versions that attempted to provide it. * Tue Jul 10 2007 Adam Jackson 6.5.2-14 - Add mesa-demos subpackage. (#247252) mod_dnssd-0.5-3.fc8 ------------------- ntfs-3g-2:1.710-1.fc8 --------------------- * Sun Jul 22 2007 Tom "spot" Callaway 2:1.710-1 - bump to 1.710 - add compat symlinks * Wed Jun 27 2007 Tom "spot" Callaway 2:1.616-1 - bump to 1.616 ntp-4.2.4p2-2.fc8 ----------------- * Tue Jul 24 2007 Miroslav Lichvar 4.2.4p2-2 - ignore tentative addresses (#246297) - improve init script (#247003) - fix sleep patch - ease Autokey setup (#139673) - change default keysdir to /etc/ntp/crypto - set crypto password in /etc/ntp/crypto/pw - don't use randfile if /dev/urandom is used by OpenSSL - change default statsdir to /var/log/ntpstats/, use statistics type as default filename - package more doc files pam-0.99.8.1-1.fc8 ------------------ * Mon Jul 23 2007 Tomas Mraz 0.99.8.1-1 - upgrade to latest upstream version - add some firewire devices to default console perms (#240770) * Thu Apr 26 2007 Tomas Mraz 0.99.7.1-6 - pam_namespace: better document behavior on failure (#237249) - pam_unix: split out passwd change to a new helper binary (#236316) - pam_namespace: add support for temporary logons (#241226) * Fri Apr 13 2007 Tomas Mraz 0.99.7.1-5 - pam_selinux: improve context change auditing (#234781) - pam_namespace: fix parsing config file with unknown users (#234513) perl-4:5.8.8-22.fc8 ------------------- * Tue Jul 24 2007 Robin Norwood - 4:5.8.8-22 - Resolves: rhbz#247386 - Use getcwd() instead of cwd() in File::Spec::Unix to avoid forking. - Appy patch to skip hostname tests, since hostname lookup isn't available in Fedora buildroots by design. * Mon Jul 02 2007 Tom "spot" Callaway - 4:5.8.8-21 - perl-core metapackage * Fri Jun 22 2007 Robin Norwood - 4:5.8.8-20 - Resolves: rhbz#196836 - Apply upstream patch #28775, which fixes an issue where reblessing overloaded objects incurs significant performance penalty perl-Taint-Runtime-0.03-1.fc8.1 ------------------------------- * Tue Jul 24 2007 Tom "spot" Callaway 0.03-1.1 - BR: perl(Test::More) php-eaccelerator-1:0.9.5.1-3.fc8 -------------------------------- * Tue Jul 24 2007 Matthias Saou 1:0.9.5.1-3 - Include patch to skip the exact PHP version check, we'll rely on our package's php_zend_api version requirement to "get it right". policycoreutils-2.0.22-8.fc8 ---------------------------- * Tue Jul 24 2007 Dan Walsh 2.0.22-8 - Add requires libselinux-python pungi-0.3.9-1.fc8 ----------------- * Tue Jul 24 2007 Jesse Keating - 0.3.9-1 - Add a few more desktopy things to manifest - Rename f7 files to f8; set up config files for f8test1 - Don't quote things passed to mkisofs, not a shell - Always log stdout before checking for stderr output - Include memtest86+ in the "Fedora" manifest rsyslog-1.17.2-3.fc8 -------------------- * Tue Jul 24 2007 Peter Vrabec 1.17.2-3 - take care of sysklogd configuration files in %post * Tue Jul 24 2007 Peter Vrabec 1.17.2-2 - use EVR in provides/obsoletes sysklogd rusers-0.17-48 -------------- * Mon Jul 23 2007 Jiri Moskovcak 0.17-48 - Fixed init scripts to comply with LSB standard - Resolves: #247047 sane-backends-1.0.18-12.fc8 --------------------------- * Tue Jul 24 2007 Nils Philippsen - 1.0.18-12 - fix typo in spec file * Tue Jul 24 2007 Nils Philippsen - 1.0.18-11 - work around udev regexes not matching as they should (#244444) selinux-policy-3.0.3-6.fc8 -------------------------- * Mon Jul 23 2007 Dan Walsh 3.0.3-6 - Fix prelink to handle execmod setup-2.6.9-1.fc8 ----------------- * Tue Jul 24 2007 Phil Knirsch 2.6.9-1 - Assigned uid 87 for PolicyKit package (#244950) - Fixed precmd fix if TERM isn't set (#242732) * Wed Jun 06 2007 Phil Knirsch 2.6.7-1 - Fixed precmd setting to behave like bash for (t)csh (#242732) * Thu May 24 2007 Phil Knirsch 2.6.6-1 - Added another set of proposed changes to /etc/csh.cshrc (#199817) - Added missing documentation in /etc/hosts.[allow|deny] (#157053) system-config-users-1.2.62-1.fc8 -------------------------------- * Tue Jul 24 2007 Nils Philippsen - 1.2.62 - pull in updated translations tcpdump-14:3.9.7-1.fc8 ---------------------- * Tue Jul 24 2007 Miroslav Lichvar - 14:3.9.7-1 - update to 3.9.7 - with -C option, drop root privileges before opening first savefile (#244860) - update tcpslice to 1.2a3 - include time patch from Debian to fix tcpslice on 64-bit architectures tkcvs-8.0.4-2.fc8 ----------------- uuid-1.6.0-1.fc8 ---------------- * Tue Jul 24 2007 Steven Pritchard 1.6.0-1 - Update to 1.6.0. - BR Test::More. w3m-0.5.2-2.fc8 --------------- * Tue Jul 24 2007 Parag Nemade - 0.5.2-2 - Build against new gc-7.0 release. * Tue Jun 26 2007 Parag Nemade - 0.5.2-1 - Update to 0.5.2 and remove merged patches. - Build against system gc library. - Add BR: nkf for multipart.cgi. - Don't call unneeded autotool * Tue Mar 27 2007 Parag Nemade - 0.5.1-19 - and more cleanup. wlassistant-0.5.7-3.fc8 ----------------------- * Mon Jul 23 2007 Tom "spot" Callaway 0.5.7-3 - close file descriptors with FD_CLOEXEC, try to resolve bz 243509 xawtv-3.95-4.fc8 ---------------- * Tue Jul 24 2007 Dmitry Butskoy - 3.95-4 - don't assume v4l-conf as system config util (#249130) * Tue Jun 26 2007 Dmitry Butskoy - drop X-Fedora category from desktop file xorg-x11-proto-devel-7.2-12.fc8 ------------------------------- * Tue Jul 24 2007 Adam Jackson 7.2-12 - Remove dri_interface.h. It's not protocol, it belongs in Mesa. * Wed Jul 11 2007 Adam Jackson 7.2-11 - compositeproto 0.4 xorg-x11-server-utils-7.2-4.fc8 ------------------------------- * Tue Jul 24 2007 Adam Jackson 7.2-4 - iceauth 1.0.2 * Wed Jul 11 2007 Adam Jackson 7.2-3 - xrandr 1.2.2 xorg-x11-xkb-utils-7.2-1.fc8 ---------------------------- * Tue Jul 24 2007 Adam Jackson 7.2-1 - setxkbmap 1.0.4 - Arbitrary version number bump, to match X.org release numbering. Why not. ytalk-3.3.0-7.fc8 ----------------- * Tue Jul 24 2007 Mike McGrath 3.3.0-7 - release bump and rebuild yum-3.2.2-2.fc8 --------------- * Tue Jul 24 2007 Jeremy Katz - 3.2.2-2 - remove yum-updatesd subpackage; moving to the separate version * Fri Jul 20 2007 Seth Vidal - 3.2.2-1 - 3.2.2 - disable unused installonlyn plugin - set installonly_limit to '2' * Tue Jul 10 2007 James Bowes - 3.2.1-2 - defattr, buldarch, and macro suggestions from the merge review From buildsys at fedoraproject.org Wed Jul 25 07:36:37 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Wed, 25 Jul 2007 07:36:37 -0000 Subject: Summary - Broken dependencies in Fedora 7 + Test Updates - 2007-07-25 Message-ID: <20070725073637.27625.93375@extras64.linux.duke.edu> ====================================================================== The results in this summary consider Test Updates! ====================================================================== Summary of broken packages (by owner): Axel.Thimm AT ATrpms.net vtk-examples - 5.0.3-18.2.fc7.i386 (4 days) vtk-examples - 5.0.3-18.2.fc7.ppc (4 days) vtk-examples - 5.0.3-18.2.fc7.x86_64 (4 days) vtk-testing - 5.0.3-18.2.fc7.i386 (4 days) vtk-testing - 5.0.3-18.2.fc7.ppc (4 days) vtk-testing - 5.0.3-18.2.fc7.x86_64 (4 days) allisson AT gmail.com ruby-gtkmozembed - 0.16.0-6.fc7.i386 (6 days) ruby-gtkmozembed - 0.16.0-6.fc7.ppc (6 days) ruby-gtkmozembed - 0.16.0-6.fc7.x86_64 (6 days) andreas.bierfert AT lowlatency.de syncekonnector - 0.3.2-2.fc7.i386 (36 days) syncekonnector - 0.3.2-2.fc7.i386 (36 days) syncekonnector - 0.3.2-2.fc7.ppc (36 days) syncekonnector - 0.3.2-2.fc7.x86_64 (36 days) bjohnson AT symetrix.com dbmail - 2.2.4-4.fc7.i386 (20 days) gauret AT free.fr glest-data - 2.0.0-2.fc7.noarch (53 days) giallu AT gmail.com kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3116.fc7.x86_64 oliver AT linux-kernel.at syck-php - 0.55-16.fc7.i386 (10 days) syck-php - 0.55-16.fc7.ppc (10 days) syck-php - 0.55-16.fc7.x86_64 (10 days) tcallawa AT redhat.com compat-wxGTK-devel - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-devel - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-devel - 2.4.2-21.fc6.ppc (9 days) compat-wxGTK-devel - 2.4.2-21.fc6.x86_64 (9 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-gl - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-gl - 2.4.2-21.fc6.ppc (9 days) compat-wxGTK-gl - 2.4.2-21.fc6.x86_64 (9 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-stc - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-stc - 2.4.2-21.fc6.ppc (9 days) compat-wxGTK-stc - 2.4.2-21.fc6.x86_64 (9 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-xrc - 2.4.2-21.fc6.i386 (9 days) compat-wxGTK-xrc - 2.4.2-21.fc6.ppc (9 days) compat-wxGTK-xrc - 2.4.2-21.fc6.x86_64 (9 days) twoerner AT redhat.com postfix-pflogsumm - 2:2.4.3-2.fc7.i386 (40 days) postfix-pflogsumm - 2:2.4.3-2.fc7.ppc (40 days) postfix-pflogsumm - 2:2.4.3-2.fc7.x86_64 (40 days) ====================================================================== Broken packages in fedora-7-i386: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 ====================================================================== Broken packages in fedora-7-ppc: compat-wxGTK-devel-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.ppc requires libwx_gtk-2.4.so.0 compat-wxGTK-gl-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.ppc requires compat-wxGTK = 0:2.4.2-21.fc6 glest-data-2.0.0-2.fc7.noarch requires glest = 0:2.0.0 ====================================================================== Broken packages in fedora-7-x86_64: compat-wxGTK-devel-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.i386 requires libwx_gtk-2.4.so.0 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-devel-2.4.2-21.fc6.x86_64 requires libwx_gtk-2.4.so.0()(64bit) compat-wxGTK-gl-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-gl-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-stc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.i386 requires compat-wxGTK = 0:2.4.2-21.fc6 compat-wxGTK-xrc-2.4.2-21.fc6.x86_64 requires compat-wxGTK = 0:2.4.2-21.fc6 dbmail-2.2.4-4.fc7.i386 requires dbmail-database-driver = 0:2.2.4-4.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.21_1.3116.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3116.fc7kdump ====================================================================== Broken packages in fedora-updates-7-i386: postfix-pflogsumm-2:2.4.3-2.fc7.i386 requires postfix = 0:2.4.3-2.fc7 ruby-gtkmozembed-0.16.0-6.fc7.i386 requires firefox = 0:2.0.0.4 syck-php-0.55-16.fc7.i386 requires php = 0:5.2.2 syncekonnector-0.3.2-2.fc7.i386 requires libmultisynk.so.0 syncekonnector-0.3.2-2.fc7.i386 requires libksync.so.1 syncekonnector-0.3.2-2.fc7.i386 requires libkonnector.so.0 ====================================================================== Broken packages in fedora-updates-7-ppc: postfix-pflogsumm-2:2.4.3-2.fc7.ppc requires postfix = 0:2.4.3-2.fc7 ruby-gtkmozembed-0.16.0-6.fc7.ppc requires firefox = 0:2.0.0.4 syck-php-0.55-16.fc7.ppc requires php = 0:5.2.2 syncekonnector-0.3.2-2.fc7.ppc requires libmultisynk.so.0 syncekonnector-0.3.2-2.fc7.ppc requires libkonnector.so.0 syncekonnector-0.3.2-2.fc7.ppc requires libksync.so.1 ====================================================================== Broken packages in fedora-updates-7-x86_64: postfix-pflogsumm-2:2.4.3-2.fc7.x86_64 requires postfix = 0:2.4.3-2.fc7 ruby-gtkmozembed-0.16.0-6.fc7.x86_64 requires firefox = 0:2.0.0.4 syck-php-0.55-16.fc7.x86_64 requires php = 0:5.2.2 syncekonnector-0.3.2-2.fc7.i386 requires libmultisynk.so.0 syncekonnector-0.3.2-2.fc7.i386 requires libksync.so.1 syncekonnector-0.3.2-2.fc7.i386 requires libkonnector.so.0 syncekonnector-0.3.2-2.fc7.x86_64 requires libmultisynk.so.0()(64bit) syncekonnector-0.3.2-2.fc7.x86_64 requires libksync.so.1()(64bit) syncekonnector-0.3.2-2.fc7.x86_64 requires libkonnector.so.0()(64bit) ====================================================================== Broken packages in fedora-updates-testing-7-i386: vtk-examples-5.0.3-18.2.fc7.i386 requires vtkdata = 0:5.0.3 vtk-testing-5.0.3-18.2.fc7.i386 requires vtkdata = 0:5.0.3 ====================================================================== Broken packages in fedora-updates-testing-7-ppc: vtk-examples-5.0.3-18.2.fc7.ppc requires vtkdata = 0:5.0.3 vtk-testing-5.0.3-18.2.fc7.ppc requires vtkdata = 0:5.0.3 ====================================================================== Broken packages in fedora-updates-testing-7-x86_64: vtk-examples-5.0.3-18.2.fc7.x86_64 requires vtkdata = 0:5.0.3 vtk-testing-5.0.3-18.2.fc7.x86_64 requires vtkdata = 0:5.0.3 From mschwendt.tmp0701.nospam at arcor.de Wed Jul 25 10:00:32 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 25 Jul 2007 12:00:32 +0200 Subject: rawhide report: 20070725 changes In-Reply-To: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> Message-ID: <20070725120032.95f840a3.mschwendt.tmp0701.nospam@arcor.de> The "repodata" directory is missing: http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/ From ssorce at redhat.com Wed Jul 25 10:42:53 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 25 Jul 2007 06:42:53 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070724155745.5fee23d5@localhost.localdomain> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> Message-ID: <1185360173.6631.56.camel@hopeson> On Tue, 2007-07-24 at 15:57 -0400, Jesse Keating wrote: > On Tue, 24 Jul 2007 12:49:59 -0700 > Arjan van de Ven wrote: > > > gplv3 is not compatible with v2, but for what would it need to be? YOu > > can have v2 and v3 programs in the same distro just like you can have > > v2 and other licensed programs in the same distro. > > > > It only becomes a problem when you're linking (and for most cases that > > is fine) or are otherwise a derived work. > > Yes, and that's why we need to know, so we can examine the linking path > and ensure that we're not breaking any (l)gplv2 only licenses. We > can't just rely upon upstream, as they have no idea what we're linking > to their software. Not so easy, some packages may contain differently licensed binaries/libraries. As an example samba is GPLv2 (GPLv3 with the next release) but some key libraries are LGPLv2 (v3 next). These libraries have been released under the LGPL explicitly because some other projects wanted to use them and needed (because of foreign constraints) a more liberal license. So a tool that marks samba as GPLv3 may raise a high number of false positives. I guess many other projects will fall under the same conditions. Also sometimes plugins falls in a grey area while technically a graph may seem to link incompatible licensed code that is not clearly derivative. Lots of corner cases. Finally managing exceptions (like the OpenSSL one many projects have) may not be easy at all. Simo. From jkeating at redhat.com Wed Jul 25 11:05:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 07:05:57 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185360173.6631.56.camel@hopeson> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> Message-ID: <20070725070557.546b96c6@ender> On Wed, 25 Jul 2007 06:42:53 -0400 Simo Sorce wrote: > So a tool that marks samba as GPLv3 may raise a high number of false > positives. I guess many other projects will fall under the same > conditions. > > Also sometimes plugins falls in a grey area while technically a graph > may seem to link incompatible licensed code that is not clearly > derivative. Lots of corner cases. > > Finally managing exceptions (like the OpenSSL one many projects have) > may not be easy at all. I think you're missing the point of the task. The task isn't to mark perfectly in every spec file exactly what a package contains. Instead it can mark the easy cases, and denote something in the hard cases so that when an issue arises, we can easily weed out the easy cases and focus on the hard ones manually. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 25 11:09:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 07:09:08 -0400 Subject: rawhide report: 20070725 changes In-Reply-To: <20070725120032.95f840a3.mschwendt.tmp0701.nospam@arcor.de> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> <20070725120032.95f840a3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070725070908.126cda01@ender> On Wed, 25 Jul 2007 12:00:32 +0200 Michael Schwendt wrote: > The "repodata" directory is missing: > http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/ The compose failed in some unknown way :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jul 25 11:26:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Jul 2007 13:26:52 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070725070557.546b96c6@ender> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> Message-ID: <46A7337C.70602@leemhuis.info> On 25.07.2007 13:05, Jesse Keating wrote: > On Wed, 25 Jul 2007 06:42:53 -0400 > Simo Sorce wrote: > >> So a tool that marks samba as GPLv3 may raise a high number of false >> positives. I guess many other projects will fall under the same >> conditions. >> [...] > I think you're missing the point of the task. The task isn't to mark > perfectly in every spec file exactly what a package contains. Instead > it can mark the easy cases, and denote something in the hard cases so > that when an issue arises, we can easily weed out the easy cases and > focus on the hard ones manually. In addition -- in some cases like the quoted one for samba it *might* be the easiest and cleanest solution for everyone to just put the libs with a different license into a different (sub)package. Cu thl From ssorce at redhat.com Wed Jul 25 12:43:04 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 25 Jul 2007 08:43:04 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <46A7337C.70602@leemhuis.info> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> Message-ID: <1185367384.6631.67.camel@hopeson> On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote: > > On 25.07.2007 13:05, Jesse Keating wrote: > > On Wed, 25 Jul 2007 06:42:53 -0400 > > Simo Sorce wrote: > > > >> So a tool that marks samba as GPLv3 may raise a high number of false > >> positives. I guess many other projects will fall under the same > >> conditions. > >> [...] > > I think you're missing the point of the task. The task isn't to mark > > perfectly in every spec file exactly what a package contains. Instead > > it can mark the easy cases, and denote something in the hard cases so > > that when an issue arises, we can easily weed out the easy cases and > > focus on the hard ones manually. > > In addition -- in some cases like the quoted one for samba it *might* be > the easiest and cleanest solution for everyone to just put the libs with > a different license into a different (sub)package. While it may be the case, the decision should absolutely not be dictated by the license. Simo. From Christian.Iseli at licr.org Wed Jul 25 12:44:09 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 25 Jul 2007 14:44:09 +0200 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <20070717190404.GA9859@redhat.com> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> <20070717190404.GA9859@redhat.com> Message-ID: <20070725144409.48c5ace0@ludwig-alpha.unil.ch> On Tue, 17 Jul 2007 20:04:04 +0100, Joe Orton wrote: > This one is a "dropped since F7 release" package - it was renamed to > (and is obsoleted by) perl-Newt. In that case, please follow the retired package procedure outlined here: http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife Thanks, Christian From snecklifter at gmail.com Wed Jul 25 12:54:52 2007 From: snecklifter at gmail.com (Chris Brown) Date: Wed, 25 Jul 2007 13:54:52 +0100 Subject: Frozen for Fedora 8 Test1 In-Reply-To: References: <20070724223314.13ea9d19@ender> Message-ID: <364d303b0707250554q35b229a7te616a2372d51abc5@mail.gmail.com> On 25/07/07, Frank Schmitt wrote: > Jesse Keating writes: > > > We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' > > that is a container for the packages that are destined to be in Test1 > > (and rawhide until test1 is fully composed and released to mirrors). > > I guess that means yet another release with broken zsh when the fix > would be just updating the package to upstream, as upstream developers > recommend. No, because as Matthias pointed out in the the bug release below it is not included in the default install. There's a chance that given the comments made by the development team the maintainer will re-consider upgrading to this release. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183557 > http://www.zsh.org/mla/workers/2007/msg00471.html > > I mean OpenSuse and Ubuntu think zsh 4.3.x it's good enough for their > release, not to mention that even Debian includes 4.3 in their *stable* > release. Only the fedora maintainer sticks to 4.2 leaving everyone who > is using a UTF-8 locale with a broken shell. > > This is just ridiculous. No, its a technical decision not to ship an unstable release. That said, Fedora *is* supposed to be cutting edge stuff and if the only argument against version bumping is upstream's versioning system (since dismissed on their mailing list) I agree that its high time to up the game a little. :) Regards Chris -- http://www.chruz.com From nicolas.mailhot at laposte.net Wed Jul 25 12:55:39 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 25 Jul 2007 14:55:39 +0200 (CEST) Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185367384.6631.67.camel@hopeson> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> Message-ID: <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> Le Mer 25 juillet 2007 14:43, Simo Sorce a ?crit : > On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote: >> In addition -- in some cases like the quoted one for samba it >> *might* be >> the easiest and cleanest solution for everyone to just put the libs >> with >> a different license into a different (sub)package. > > While it may be the case, the decision should absolutely not be > dictated > by the license. I respectfuly disagree - for every project that uses a mix of licenses the licensing split is motivated either by different code origin or by a careful reflexion on what part can be re-used in what context. In both cases bundling everything in a single package or subackage is not doing anyone any favour. -- Nicolas Mailhot From ssorce at redhat.com Wed Jul 25 13:09:44 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 25 Jul 2007 09:09:44 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> Message-ID: <1185368984.6631.72.camel@hopeson> On Wed, 2007-07-25 at 14:55 +0200, Nicolas Mailhot wrote: > Le Mer 25 juillet 2007 14:43, Simo Sorce a ?crit : > > On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote: > > >> In addition -- in some cases like the quoted one for samba it > >> *might* be > >> the easiest and cleanest solution for everyone to just put the libs > >> with > >> a different license into a different (sub)package. > > > > While it may be the case, the decision should absolutely not be > > dictated > > by the license. > > I respectfuly disagree - for every project that uses a mix of licenses > the licensing split is motivated either by different code origin or by > a careful reflexion on what part can be re-used in what context. In > both cases bundling everything in a single package or subackage is not > doing anyone any favour. I believe packaging splits should be done based on the functionality they provide. As long as licenses are compatible I don't see why you should package stuff based on the component license. Simo. From jkeating at redhat.com Wed Jul 25 13:24:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 09:24:43 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185368984.6631.72.camel@hopeson> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> <1185368984.6631.72.camel@hopeson> Message-ID: <20070725092443.0ee2c034@localhost.localdomain> On Wed, 25 Jul 2007 09:09:44 -0400 Simo Sorce wrote: > I believe packaging splits should be done based on the functionality > they provide. As long as licenses are compatible I don't see why you > should package stuff based on the component license. Compatible with eachother is different than compatible in the same ways with other licensed software you may wish to combine with it. (yes this is hyperbole) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From karsten at redhat.com Wed Jul 25 13:38:21 2007 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 25 Jul 2007 15:38:21 +0200 Subject: Errors during an everything install (x86_64) Message-ID: <46A7524D.5070408@redhat.com> These package got skipped because requirements were not met: Autoerasing package openalpp-0:20060714-3.fc7.x86_64 due to unresolved symbols. Autoerasing package osgal-0:20060903-3.fc7.x86_64 due to unresolved symbols. Autoerasing package osgal-devel-0:20060903-3.fc7.x86_64 due to unresolved symbols. Autoerasing package openalpp-devel-0:20060714-3.fc7.x86_64 due to unresolved symbols. Autoerasing package fcron-0:3.0.3-1.fc8.x86_64 due to unresolved symbols. Autoerasing package scipy-0:0.5.2-2.2.fc7.x86_64 due to unresolved symbols. Autoerasing package osgcal-0:0.1.44-4.fc7.x86_64 due to unresolved symbols. Autoerasing package osgcal-devel-0:0.1.44-4.fc7.x86_64 due to unresolved symbols. Autoerasing package kmod-em8300-0:0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 due to unresolved symbols. Autoerasing package em8300-0:0.16.3-0.1.rc2.fc8.x86_64 due to unresolved symbols. Autoerasing package em8300-utils-0:0.16.3-0.1.rc2.fc8.x86_64 due to unresolved symbols. Autoerasing package xsupplicant-0:1.2.8-1.fc7.1.x86_64 due to unresolved symbols. Autoerasing package xsupplicant-devel-0:1.2.8-1.fc7.1.x86_64 due to unresolved symbols. Autoerasing package tellico-0:1.2.11-1.fc8.x86_64 due to unresolved symbols. Autoerasing package ruby-gtkmozembed-0:0.16.0-6.fc8.x86_64 due to unresolved symbols. Autoerasing package vtk-examples-0:5.0.3-18.2.fc8.x86_64 due to unresolved symbols. Autoerasing package Democracy-0:0.9.5.1-10.fc8.x86_64 due to unresolved symbols. Autoerasing package vtk-testing-0:5.0.3-18.2.fc8.x86_64 due to unresolved symbols. Autoerasing package kmod-sysprof-0:1.0.8-1.2.6.21_1.3228.fc7.x86_64 due to unresolved symbols. Autoerasing package sysprof-0:1.0.8-1.fc7.x86_64 due to unresolved symbols. Autoerasing package kmod-sysprof-kdump-0:1.0.8-1.2.6.21_1.3228.fc7.x86_64 due to unresolved symbols. Autoerasing package torque-gui-0:2.1.8-1.fc7.x86_64 due to unresolved symbols. Autoerasing package pbstop-0:4.14-3.fc6.x86_64 due to unresolved symbols. Autoerasing package evolution-brutus-devel-0:1.1.26.2-2.fc7.x86_64 due to unresolved symbols. Autoerasing package dbus-sharp-devel-0:0.63-6.fc6.x86_64 due to unresolved symbols. These packages had conflicts: Autoerasing package digikamimageplugins-0:0.9.1-1.fc7.x86_64 due to conflicting obsoletes. Autoerasing package php-dbase-0:5.2.1-1.fc7.x86_64 due to conflicting obsoletes. Autoerasing package jaxen-bootstrap-0:1.1-1jpp.1.fc7.noarch due to conflicting obsoletes. Autoerasing package pulseaudio-esound-compat-0:0.9.6-2.fc8.x86_64 due to conflicts Autoerasing package dbus-sharp-0:0.63-6.fc6.x86_64 due to conflicts And then there are quite a few packages which have errors in their scripts or missing Requires(post)|(pre): Install: gallery2-0:2.2-0.6.svn20070506.fc8.noarch ERROR: Output running post install script for package gallery2-0:2.2-0.6.svn20070506.fc8.noarch If this is an upgrade from a previously installed version of Gallery2, please be sure to point a web browser at http:///gallery2/upgrade/ and follow the instructions there to complete the upgrade process. Install: gauche-0:0.8.10-1.fc7.x86_64 ERROR: Output running post install script for package gauche-0:0.8.10-1.fc7.x86_64 Install: util-vserver-0:0.30.213-1.fc8.x86_64 ERROR: Output running post install script for package util-vserver-0:0.30.213-1.fc8.x86_64 /vservers: Function not implemented /vservers/.pkg: Function not implemented Install: deskbar-applet-0:2.19.5-1.fc8.x86_64 ERROR: Output running post install script for package deskbar-applet-0:2.19.5-1.fc8.x86_64 gconfd-2: no process killed Install: nemiver-0:0.4.0-1.fc8.x86_64 ERROR: Output running post install script for package nemiver-0:0.4.0-1.fc8.x86_64 Resolved address "xml:merged:/etc/gconf/gconf.xml.defaults" to a writable configuration source at position 0 Attached schema `/schemas/apps/nemiver/dbgperspective/source-search-dirs' to key `/apps/nemiver/dbgperspective/source-search-dirs' Installed schema `/schemas/apps/nemiver/dbgperspective/source-search-dirs' for locale `C' --- cut off many more such messages --- Install: mod_nss-0:1.0.7-1.fc8.x86_64 ERROR: Output running post install script for package mod_nss-0:1.0.7-1.fc8.x86_64 mod_nss certificate database generated. Install: bigboard-0:0.5.3-1.fc8.x86_64 ERROR: Output running post install script for package bigboard-0:0.5.3-1.fc8.x86_64 gconfd-2: no process killed Install: Canna-0:3.7p3-18.fc7.x86_64 ERROR: Output running post install script for package Canna-0:3.7p3-18.fc7.x86_64 chown: `canna:canna': invalid user Install: freenx-0:0.6.0-12.fc7.x86_64 ERROR: Output running post install script for package freenx-0:0.6.0-12.fc7.x86_64 cat: /etc/ssh/ssh_host_rsa_key.pub: No such file or directory Install: squidGuard-0:1.2.0-15.fc7.x86_64 ERROR: Output running post install script for package squidGuard-0:1.2.0-15.fc7.x86_64 /etc/squid/squidGuard.conf created as /etc/squid/squidGuard.conf.rpmnew Loading new SELinux policy /etc/selinux/targeted/src/policy / Install: mantis-config-httpd-0:1.0.8-1.fc8.noarch ERROR: Output running post install script for package mantis-config-httpd-0:1.0.8-1.fc8.noarch (98)Address already in use: make_sock: could not bind to address [::]:80 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs httpd not running, trying to start Install: selinux-policy-mls-0:3.0.3-3.fc8.noarch ERROR: Output running post install script for package selinux-policy-mls-0:3.0.3-3.fc8.noarch Traceback (most recent call last): File "/usr/sbin/genhomedircon", line 29, in import selinux ImportError: No module named selinux libsemanage.semanage_install_sandbox: genhomedircon returned error code 1. Install: ngspice-doc-0:17-11.fc7.x86_64 ERROR: Output running post install script for package ngspice-doc-0:17-11.fc7.x86_64 install-info: warning: no info dir entry in `/usr/share/info/ngspice.info.gz' Install: gnochm-0:0.9.10-1.fc8.noarch ERROR: Output running post install script for package gnochm-0:0.9.10-1.fc8.noarch gconfd-2: no process killed Install: NetworkManager-openvpn-0:0.3.2-7.fc6.x86_64 ERROR: Output running post install script for package NetworkManager-openvpn-0:0.3.2-7.fc6.x86_64 Cache file created successfully. Install: gimmie-0:0.2.7-1.fc8.x86_64 ERROR: Output running post install script for package gimmie-0:0.2.7-1.fc8.x86_64 gconfd-2: no process killed Install: xpilot-ng-selinux-0:4.7.2-12.fc7.x86_64 ERROR: Output running post install script for package xpilot-ng-selinux-0:4.7.2-12.fc7.x86_64 cut: write error: Broken pipe Install: cyphesis-selinux-0:0.5.13-1.fc8.x86_64 ERROR: Output running post install script for package cyphesis-selinux-0:0.5.13-1.fc8.x86_64 cut: write error: Broken pipe Install: util-vserver-build-0:0.30.213-1.fc8.x86_64 ERROR: Output running post install script for package util-vserver-build-0:0.30.213-1.fc8.x86_64 /vservers/.hash: Function not implemented Install: krusader-0:1.80.0-0.1.beta2.fc7.x86_64 ERROR: Output running post install script for package krusader-0:1.80.0-0.1.beta2.fc7.x86_64 No theme index file in '/usr/share/icons/locolor'. If you really want to create an icon cache here, use --ignore-theme-index. Install: crossfire-selinux-0:1.10.0-2.fc8.x86_64 ERROR: Output running post install script for package crossfire-selinux-0:1.10.0-2.fc8.x86_64 cut: write error: Broken pipe Install: NetworkManager-vpnc-1:0.6.4-3.fc7.x86_64 ERROR: Output running post install script for package NetworkManager-vpnc-1:0.6.4-3.fc7.x86_64 Cache file created successfully. Install: iksemel-devel-0:1.2-13.fc7.x86_64 ERROR: Output running post install script for package iksemel-devel-0:1.2-13.fc7.x86_64 install-info: warning: no info dir entry in `/usr/share/info/iksemel.info' Install: gchempaint-0:0.6.9-1.fc7.x86_64 ERROR: Output running post install script for package gchempaint-0:0.6.9-1.fc7.x86_64 gconfd-2: no process killed Install: oki4linux-0:2.1gst-1.fc6.x86_64 ERROR: Output running post install script for package oki4linux-0:2.1gst-1.fc6.x86_64 Run "/etc/rc.d/init.d/oki4daemon start" to start oki4daemon daemon. Install: awstats-0:6.6-1.fc7.noarch ERROR: Output running post install script for package awstats-0:6.6-1.fc7.noarch chcon: can't apply partial context to unlabeled file /usr/share/awstats/wwwroot/cgi-bin chcon: can't apply partial context to unlabeled file /var/lib/awstats Install: gnome-specimen-0:0.3-1.fc8.noarch ERROR: Output running post install script for package gnome-specimen-0:0.3-1.fc8.noarch gconfd-2: no process killed Install: qa-assistant-0:0.4.90.5-2.fc6.noarch ERROR: Output running post install script for package qa-assistant-0:0.4.90.5-2.fc6.noarch gconfd-2: no process killed Install: byzanz-0:0.1.1-4.fc6.x86_64 ERROR: Output running post install script for package byzanz-0:0.1.1-4.fc6.x86_64 gconfd-2: no process killed Install: gnomeradio-0:1.6-3.fc6.x86_64 ERROR: Output running post install script for package gnomeradio-0:1.6-3.fc6.x86_64 gconfd-2: no process killed Install: comix-0:3.6.4-1.fc8.noarch ERROR: Output running post install script for package comix-0:3.6.4-1.fc8.noarch gconfd-2: no process killed Install: xca-0:0.6.3-2.fc8.x86_64 ERROR: Output running post install script for package xca-0:0.6.3-2.fc8.x86_64 Unknown media type in type 'chemical/x-alchemy' Unknown media type in type 'chemical/x-cache' --- cut off many more such messages --- Install: cups-pdf-0:2.4.6-1.fc7.x86_64 ERROR: Output running post install script for package cups-pdf-0:2.4.6-1.fc7.x86_64 semodule: SELinux policy is not managed or store cannot be accessed. Install: cfengine-0:2.2.1-3.fc8.x86_64 ERROR: Output running post install script for package cfengine-0:2.2.1-3.fc8.x86_64 Making a key pair for cfengine, please wait, this could take a minute... Writing private key to /var/cfengine/ppkeys/localhost.priv Writing public key to /var/cfengine/ppkeys/localhost.pub Install: gutenprint-cups-0:5.0.1-3.fc8.x86_64 ERROR: Output running post install script for package gutenprint-cups-0:5.0.1-3.fc8.x86_64 No Gutenprint PPD files to update. -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From cra at WPI.EDU Wed Jul 25 13:57:59 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 25 Jul 2007 09:57:59 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> References: <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> Message-ID: <20070725135759.GI6932@angus.ind.WPI.EDU> On Wed, Jul 25, 2007 at 02:55:39PM +0200, Nicolas Mailhot wrote: > > While it may be the case, the decision should absolutely not be > > dictated > > by the license. > > I respectfuly disagree - for every project that uses a mix of licenses > the licensing split is motivated either by different code origin or by > a careful reflexion on what part can be re-used in what context. In > both cases bundling everything in a single package or subackage is not > doing anyone any favour. Additionally, if the -devel packages were split on license boundaries, then perhaps the buildsystem could flag attempts to link to incompatibly-licensed libararies. From katzj at redhat.com Wed Jul 25 14:23:41 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 Jul 2007 10:23:41 -0400 Subject: rawhide report: 20070725 changes In-Reply-To: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> Message-ID: <1185373421.11828.12.camel@localhost.localdomain> On Wed, 2007-07-25 at 03:33 -0400, Build System wrote: > New package yum-updatesd > Update notification daemon FYI -- this is a new and reworked yum-updatesd that should hopefully help with some of the complaints that I have been had. The *big* change is that it's bit split into two pieces: * The actual daemon. This is small, listens to dbus, and doesn't ever touch the rpmdb, etc. Which should keep its memory footprint low. * Helper process that's forked off to do actual update checks (+downloads +installs if so configured). Helper isn't threaded, which should avoid some of the problems that have been cropping up. People prodding and testing at this would be much appreciated; I'm hoping to be able to push this to F7-updates at some point as well. Bugs to bugzilla as usual Jeremy From karsten at redhat.com Wed Jul 25 14:30:20 2007 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 25 Jul 2007 16:30:20 +0200 Subject: [Fwd: unowned directories in an everything install (x86_64)] Message-ID: <46A75E7C.3040606@redhat.com> While I'm at it, here is a quite long list of unowned directories in an everything install: # find / -xdev -type d -print0 | xargs -0 rpm -qf | grep "not owned" http://karsten.fedorapeople.org/unowned_dirs -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From j.w.r.degoede at hhs.nl Wed Jul 25 14:31:02 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 25 Jul 2007 16:31:02 +0200 Subject: rawhide report: 20070725 changes In-Reply-To: <1185373421.11828.12.camel@localhost.localdomain> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> <1185373421.11828.12.camel@localhost.localdomain> Message-ID: <46A75EA6.7010804@hhs.nl> Jeremy Katz wrote: > On Wed, 2007-07-25 at 03:33 -0400, Build System wrote: >> New package yum-updatesd >> Update notification daemon > > FYI -- this is a new and reworked yum-updatesd that should hopefully > help with some of the complaints that I have been had. The *big* change > is that it's bit split into two pieces: > * The actual daemon. This is small, listens to dbus, and doesn't ever > touch the rpmdb, etc. Which should keep its memory footprint low. > * Helper process that's forked off to do actual update checks > (+downloads +installs if so configured). Helper isn't threaded, which > should avoid some of the problems that have been cropping up. > > People prodding and testing at this would be much appreciated; I'm > hoping to be able to push this to F7-updates at some point as well. > Bugs to bugzilla as usual > Does this also fix the issue where issuing any yum command wil fail while it is checking for updates? That is the no 1 reason for not to use yum-updatesd. If it doesn't fix this, maybe the following is an idea: -modify yum to detect if its yum-updatesd which is locking the current yum "database" -if it is yum-updatesd send it a signal to stop doing whats its doing, on which it will finish its current operation, and then release the db. -print: "waiting for yum-updatesdb to release the database" -poll the database lock 2 times a second or so -continue Regards, Hans From jkeating at redhat.com Wed Jul 25 15:20:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 11:20:12 -0400 Subject: rawhide report: 20070725 changes In-Reply-To: <46A75EA6.7010804@hhs.nl> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> <1185373421.11828.12.camel@localhost.localdomain> <46A75EA6.7010804@hhs.nl> Message-ID: <20070725112012.32fc6349@localhost.localdomain> On Wed, 25 Jul 2007 16:31:02 +0200 Hans de Goede wrote: > If it doesn't fix this, maybe the following is an idea: > -modify yum to detect if its yum-updatesd which is locking the > current yum "database" > -if it is yum-updatesd send it a signal to stop doing whats its > doing, on which it will finish its current operation, and then > release the db. -print: "waiting for yum-updatesdb to release the > database" -poll the database lock 2 times a second or so > -continue Just to point out that this could be quite the long wait if you've got yum-updatesd configured to auto install. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Wed Jul 25 15:30:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 Jul 2007 11:30:04 -0400 Subject: rawhide report: 20070725 changes In-Reply-To: <46A75EA6.7010804@hhs.nl> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> <1185373421.11828.12.camel@localhost.localdomain> <46A75EA6.7010804@hhs.nl> Message-ID: <1185377404.11828.25.camel@localhost.localdomain> On Wed, 2007-07-25 at 16:31 +0200, Hans de Goede wrote: > Jeremy Katz wrote: > > On Wed, 2007-07-25 at 03:33 -0400, Build System wrote: > >> New package yum-updatesd > >> Update notification daemon > > > > FYI -- this is a new and reworked yum-updatesd that should hopefully > > help with some of the complaints that I have been had. The *big* change > > is that it's bit split into two pieces: > > * The actual daemon. This is small, listens to dbus, and doesn't ever > > touch the rpmdb, etc. Which should keep its memory footprint low. > > * Helper process that's forked off to do actual update checks > > (+downloads +installs if so configured). Helper isn't threaded, which > > should avoid some of the problems that have been cropping up. > > > > People prodding and testing at this would be much appreciated; I'm > > hoping to be able to push this to F7-updates at some point as well. > > Bugs to bugzilla as usual > > > > Does this also fix the issue where issuing any yum command wil fail while it is > checking for updates? That is the no 1 reason for not to use yum-updatesd. While the actual update check is going on, yes, things won't work. But that's just like if you run a yum command while another one is running. The plus side is the thing holding the lock is a separate process that dies and shouldn't just get hung up in thread-land > If it doesn't fix this, maybe the following is an idea: > -modify yum to detect if its yum-updatesd which is locking the current yum > "database" We could print out what the process holding the lock is easily enough I guess if people think it would be a substantial help. > -if it is yum-updatesd send it a signal to stop doing whats its doing, on which > it will finish its current operation, and then release the db. Can't really do this -- you can't just interrupt the metadata download or package installation, etc. But the time period for which it should have the lock held should be able to be much more constrained now and if it gets stuck, should be far more debuggable > -print: "waiting for yum-updatesdb to release the database" > -poll the database lock 2 times a second or so > -continue This could also be done, but I'm not convinced that it's better than just dropping you back to a prompt. The difference is # yum update ... Lock is held by yum-updatesd-helper. Spinning until released. Hit ctrl-c to exit. ... ... ... Got it, carrying on vs # yum update Lock is held by yum-updatesd-helper. # (wait here, do other tasks, etc) # yum update Jeremy From jima at beer.tclug.org Wed Jul 25 15:46:28 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 25 Jul 2007 10:46:28 -0500 (CDT) Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070725135759.GI6932@angus.ind.WPI.EDU> References: <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> <20070725135759.GI6932@angus.ind.WPI.EDU> Message-ID: On Wed, 25 Jul 2007, Chuck Anderson wrote: > On Wed, Jul 25, 2007 at 02:55:39PM +0200, Nicolas Mailhot wrote: >> I respectfuly disagree - for every project that uses a mix of licenses >> the licensing split is motivated either by different code origin or by >> a careful reflexion on what part can be re-used in what context. In >> both cases bundling everything in a single package or subackage is not >> doing anyone any favour. > > Additionally, if the -devel packages were split on license boundaries, > then perhaps the buildsystem could flag attempts to link to > incompatibly-licensed libararies. Oooh. While that would still require the License tags to be correct, that seems like a really clever idea to me. Jima From jkeating at redhat.com Wed Jul 25 17:00:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 13:00:54 -0400 Subject: Package rebuilds for binutils/gcc bug Message-ID: <20070725130054.10bb7f37@localhost.localdomain> Re https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249435 , there are a number of packages that need to be rebuilt (and subsequently tagged for the test release). The list of packages is the intersection of packages that were built with the combination of binutils >= 2.17.50.0.17-2 && binutils <= 2.17.50.0.17-4 && gcc >= 4.1.2-16 and not noarch. The list is at http://jkeating.fedorapeople.org/needrebuild While not every package will show errors, we're going to rebuild them just in case. Fedora rel-eng will be working to rebuild these packages today. If you were already rebuilding one of these, please drop a line to rel-eng at fedoraproject.org so that we don't step on each other. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From andy at smile.org.ua Wed Jul 25 17:15:25 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Wed, 25 Jul 2007 20:15:25 +0300 Subject: Package rebuilds for binutils/gcc bug In-Reply-To: <20070725130054.10bb7f37@localhost.localdomain> References: <20070725130054.10bb7f37@localhost.localdomain> Message-ID: <20070725171525.GF3673@serv.smile.org.ua> Hi Jesse Keating! On Wed, Jul 25, 2007 at 01:00:54PM -0400, Jesse Keating wrote next: > The list is at http://jkeating.fedorapeople.org/needrebuild While not every package will show errors, we're going to rebuild them just in case. Is it possible to regenerate alphabeticaly sorted list? Thanks. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From jkeating at redhat.com Wed Jul 25 17:23:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 13:23:32 -0400 Subject: Package rebuilds for binutils/gcc bug In-Reply-To: <20070725171525.GF3673@serv.smile.org.ua> References: <20070725130054.10bb7f37@localhost.localdomain> <20070725171525.GF3673@serv.smile.org.ua> Message-ID: <20070725132332.3c692c7c@localhost.localdomain> On Wed, 25 Jul 2007 20:15:25 +0300 Andy Shevchenko wrote: > > The list is at http://jkeating.fedorapeople.org/needrebuild While > > not every package will show errors, we're going to rebuild them > > just in case. > Is it possible to regenerate alphabeticaly sorted list? This was already done (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Jul 25 17:25:24 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 25 Jul 2007 13:25:24 -0400 Subject: Plan for tomorrows (20070726) FESCO meeting Message-ID: <1185384324.2807.4.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- elect FESCo Chair - all /topic FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat /topic FESCO-Meeting -- Rebuilding Packages -- Needs to decide whether to always rebuild, or only when toolchain warrants it - all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 williams at redhat.com Wed Jul 25 17:46:55 2007 From: williams at redhat.com (Clark Williams) Date: Wed, 25 Jul 2007 12:46:55 -0500 Subject: todays update wipes all kernels and rpm is broken In-Reply-To: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> References: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> Message-ID: <46A78C8F.8090707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yonas Abraham wrote: > in my rawhide machine, I use pirut to apply the appdates. it failed at > almost the end. after reboot, I am left with only one kernel vesrion. > I had it set up in /etc/yum/pluginconf.d/installonlyn.conf to keep 3 > kernels. now that file is actually removed and saved as > /etc/yum/pluginconf.d/installonlyn.conf.rpmsave > > running rpm gives :error loading shared libraries: libgcc_s.so.1 > > /usr/bin/pirut : error in loading libgtk-x11-2.0.so.0 > > After yesterday's update, I had to manually fixup the following so that thunderbird/firefox would run (running XFCE): /lib/libgcc_s.so.1 -> libgcc_s-4.1.2-20070723.so.1 /usr/lib/libgdk_pixbuf-2.0.so.0 -> libgdk_pixbuf-2.0.so.0.1106.0 /usr/lib/libgdk-x11-2.0.so.0 -> /usr/lib/libgdk-x11-2.0.so.0.1106.0 /usr/lib/libgtk-x11-2.0.so.0 -> /usr/lib/libgtk-x11-2.0.so.0.1106.0 /usr/lib/libmetacity-private.so -> libmetacity-private.so.0.0.0 /usr/lib/libgdk_pixbuf-2.0.so -> libgdk_pixbuf-2.0.so.0.1106.0 /usr/lib/libgdk_pixbuf_xlib-2.0.so -> libgdk_pixbuf_xlib-2.0.so.0.1106.0 Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGp4yPHyuj/+TTEp0RAktIAKCnDZ75PMRH+iFbhp5TCpeOT6dnpwCdFUap oVM+r0Iwr+2mWenqx2ouVbI= =PWi/ -----END PGP SIGNATURE----- From orion at cora.nwra.com Wed Jul 25 18:07:11 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 25 Jul 2007 12:07:11 -0600 Subject: Are the builders okay? Message-ID: <46A7914F.3000004@cora.nwra.com> openssl is still building (running tests) after ~6 hours. All of the gnome-panel build tasks have completed, but the main task is still open, tracker x86_64 job seems stuck installing the buildroot long after others have completed. etc... -- 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 tmraz at redhat.com Wed Jul 25 18:11:14 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 25 Jul 2007 20:11:14 +0200 Subject: Are the builders okay? In-Reply-To: <46A7914F.3000004@cora.nwra.com> References: <46A7914F.3000004@cora.nwra.com> Message-ID: <1185387074.6357.4.camel@perun.kabelta.loc> On Wed, 2007-07-25 at 12:07 -0600, Orion Poplawski wrote: > openssl is still building (running tests) after ~6 hours. All of the > gnome-panel build tasks have completed, but the main task is still open, > tracker x86_64 job seems stuck installing the buildroot long after > others have completed. etc... The tests in openssl build are very slowly going ahead. So not stuck, but there is definitely something strange on the builders - the tests definitely shouldn't take so much time to finish. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From jeff at ocjtech.us Wed Jul 25 18:13:31 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 25 Jul 2007 13:13:31 -0500 Subject: Are the builders okay? In-Reply-To: <1185387074.6357.4.camel@perun.kabelta.loc> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> Message-ID: <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> On Wed, 2007-07-25 at 20:11 +0200, Tomas Mraz wrote: > On Wed, 2007-07-25 at 12:07 -0600, Orion Poplawski wrote: > > openssl is still building (running tests) after ~6 hours. All of the > > gnome-panel build tasks have completed, but the main task is still open, > > tracker x86_64 job seems stuck installing the buildroot long after > > others have completed. etc... > The tests in openssl build are very slowly going ahead. So not stuck, > but there is definitely something strange on the builders - the tests > definitely shouldn't take so much time to finish. Do the tests access the network or do DNS lookups? Besides being a no-no, I doubt that the chroot is set up with a proper resolv.conf etc. 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 atkac at redhat.com Wed Jul 25 18:11:16 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 25 Jul 2007 20:11:16 +0200 Subject: Are the builders okay? In-Reply-To: <46A7914F.3000004@cora.nwra.com> References: <46A7914F.3000004@cora.nwra.com> Message-ID: <46A79244.9040702@redhat.com> Orion Poplawski napsal(a): > openssl is still building (running tests) after ~6 hours. All of the > gnome-panel build tasks have completed, but the main task is still > open, tracker x86_64 job seems stuck installing the buildroot long > after others have completed. etc... > Builders are under heavy load due bug in gcc/binutils rebuilding Adam From dr.diesel at gmail.com Wed Jul 25 18:21:18 2007 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 25 Jul 2007 13:21:18 -0500 Subject: Are the builders okay? In-Reply-To: <46A79244.9040702@redhat.com> References: <46A7914F.3000004@cora.nwra.com> <46A79244.9040702@redhat.com> Message-ID: <2a28d2ab0707251121t4f0c5a6w8f951227fb428773@mail.gmail.com> On 7/25/07, Adam Tkac wrote: > Orion Poplawski napsal(a): > > openssl is still building (running tests) after ~6 hours. All of the > > gnome-panel build tasks have completed, but the main task is still > > open, tracker x86_64 job seems stuck installing the buildroot long > > after others have completed. etc... > > > Builders are under heavy load due bug in gcc/binutils rebuilding > How much horsepower are they anyhow? -- On Tap: Imperial English Pale Ale and a Belgian Tripel Fermentating: Guinness Extra Extra Imperial Stout Fermentating: Robust Porter Fermentating: Full-Bodied Weizenbier Fermentating: Brutal Blackend Bitter From tmraz at redhat.com Wed Jul 25 18:30:21 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 25 Jul 2007 20:30:21 +0200 Subject: Are the builders okay? In-Reply-To: <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> Message-ID: <1185388221.6357.10.camel@perun.kabelta.loc> On Wed, 2007-07-25 at 13:13 -0500, Jeffrey C. Ollie wrote: > On Wed, 2007-07-25 at 20:11 +0200, Tomas Mraz wrote: > > On Wed, 2007-07-25 at 12:07 -0600, Orion Poplawski wrote: > > > openssl is still building (running tests) after ~6 hours. All of the > > > gnome-panel build tasks have completed, but the main task is still open, > > > tracker x86_64 job seems stuck installing the buildroot long after > > > others have completed. etc... > > The tests in openssl build are very slowly going ahead. So not stuck, > > but there is definitely something strange on the builders - the tests > > definitely shouldn't take so much time to finish. > > Do the tests access the network or do DNS lookups? Besides being a > no-no, I doubt that the chroot is set up with a proper resolv.conf etc. They do network communication and perhaps they even are trying to do some dns lookups if /etc/hosts is not set up properly to resolve the machine's hostname. But they should communicate only on the machine itself. Being a no-no means that we shouldn't be running them? They are very useful for for example finding bugs in compiler. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From andy at warmcat.com Wed Jul 25 18:30:32 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 25 Jul 2007 19:30:32 +0100 Subject: Are the builders okay? In-Reply-To: <1185387074.6357.4.camel@perun.kabelta.loc> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> Message-ID: <46A796C8.1000608@warmcat.com> Somebody in the thread at some point said: > On Wed, 2007-07-25 at 12:07 -0600, Orion Poplawski wrote: >> openssl is still building (running tests) after ~6 hours. All of the >> gnome-panel build tasks have completed, but the main task is still open, >> tracker x86_64 job seems stuck installing the buildroot long after >> others have completed. etc... > The tests in openssl build are very slowly going ahead. So not stuck, > but there is definitely something strange on the builders - the tests > definitely shouldn't take so much time to finish. crypto stuff can easily stall depending on entropy on /dev/random, maybe it is that. -Andy From jkeating at redhat.com Wed Jul 25 18:38:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 14:38:11 -0400 Subject: Are the builders okay? In-Reply-To: <1185388221.6357.10.camel@perun.kabelta.loc> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> <1185388221.6357.10.camel@perun.kabelta.loc> Message-ID: <20070725143811.3e02eccf@localhost.localdomain> On Wed, 25 Jul 2007 20:30:21 +0200 Tomas Mraz wrote: > They do network communication and perhaps they even are trying to do > some dns lookups if /etc/hosts is not set up properly to resolve the > machine's hostname. But they should communicate only on the machine > itself. Being a no-no means that we shouldn't be running them? They > are very useful for for example finding bugs in compiler. /etc/hosts has an entry for localhost, but it seems your test is trying to hit what is in /etc/resolv.conf which is a bogus IP. Perhaps your test is getting a hostname of the builder and trying to look that up? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Jul 25 18:37:32 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 25 Jul 2007 21:37:32 +0300 Subject: perl-Encode-HanExtra, perl-Encode-JIS2K anyone? Message-ID: <200707252137.33103.ville.skytta@iki.fi> Hello, Anyone interested in packaging and submitting for review these two CPAN distributions or one of them? http://search.cpan.org/dist/Encode-HanExtra/ http://search.cpan.org/dist/Encode-JIS2K/ A new version of W3C markup validator was released today, and it depends on these, thus blocking the update. So if someone submits them, ping me and I'll help with the review. If nobody shows up, I'll consider submiting them and will then need help with the review ;). But I'd really prefer someone else to submit them though as I can't even read the characters these beasts operate on... alternatively it could be possible to remove hard dependencies on these by patching, but I'd rather not go there either. From atkac at redhat.com Wed Jul 25 18:42:52 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 25 Jul 2007 20:42:52 +0200 Subject: Are the builders okay? In-Reply-To: <20070725143811.3e02eccf@localhost.localdomain> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> <1185388221.6357.10.camel@perun.kabelta.loc> <20070725143811.3e02eccf@localhost.localdomain> Message-ID: <46A799AC.8080907@redhat.com> Jesse Keating napsal(a): > On Wed, 25 Jul 2007 20:30:21 +0200 > Tomas Mraz wrote: > > >> They do network communication and perhaps they even are trying to do >> some dns lookups if /etc/hosts is not set up properly to resolve the >> machine's hostname. But they should communicate only on the machine >> itself. Being a no-no means that we shouldn't be running them? They >> are very useful for for example finding bugs in compiler. >> > > /etc/hosts has an entry for localhost, but it seems your test is trying > to hit what is in /etc/resolv.conf which is a bogus IP. Perhaps your > test is getting a hostname of the builder and trying to look that up? > If we are talking about DNS problems (and when I add yesterday "cvs renumbering" problem or what it was) I think it would be good have DNS server in build system and builders will ask to them instead using /etc/hosts file. Adam From yabraham2 at gmail.com Wed Jul 25 18:48:31 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Wed, 25 Jul 2007 14:48:31 -0400 Subject: todays update wipes all kernels and rpm is broken In-Reply-To: <46A78C8F.8090707@redhat.com> References: <47324ed80707241718h4ef8669dx29198256a168f507@mail.gmail.com> <46A78C8F.8090707@redhat.com> Message-ID: <47324ed80707251148w2d565fefu6cfe7fda0bff6d@mail.gmail.com> On 7/25/07, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > yonas Abraham wrote: > > in my rawhide machine, I use pirut to apply the appdates. it failed at > > almost the end. after reboot, I am left with only one kernel vesrion. > > I had it set up in /etc/yum/pluginconf.d/installonlyn.conf to keep 3 > > kernels. now that file is actually removed and saved as > > /etc/yum/pluginconf.d/installonlyn.conf.rpmsave > > > > running rpm gives :error loading shared libraries: libgcc_s.so.1 > > > > /usr/bin/pirut : error in loading libgtk-x11-2.0.so.0 > > > > > > After yesterday's update, I had to manually fixup the following so that > thunderbird/firefox would run (running XFCE): > > /lib/libgcc_s.so.1 -> > /usr/lib/libgdk_pixbuf-2.0.so.0 -> libgdk_pixbuf-2.0.so.0.1106.0 > /usr/lib/libgdk-x11-2.0.so.0 -> /usr/lib/libgdk-x11-2.0.so.0.1106.0 > /usr/lib/libgtk-x11-2.0.so.0 -> /usr/lib/libgtk-x11-2.0.so.0.1106.0 > /usr/lib/libmetacity-private.so -> libmetacity-private.so.0.0.0 > /usr/lib/libgdk_pixbuf-2.0.so -> libgdk_pixbuf-2.0.so.0.1106.0 > /usr/lib/libgdk_pixbuf_xlib-2.0.so -> libgdk_pixbuf_xlib-2.0.so.0.1106.0 Fo me, I didn't have libgcc_s-4.1.2-20070723.so.1. So I had to copy /lib/libgcc_s.so.1 and libgcc_s-4.1.2-20070723.so.1 from a diffrent F7 machine and put them on /lib/. Now rpm seem to work, but there seems to be other issues with the rpm as yum failed to install system-config-users due to some python dependencies. /yonas From jkeating at redhat.com Wed Jul 25 18:56:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 14:56:39 -0400 Subject: Are the builders okay? In-Reply-To: <46A799AC.8080907@redhat.com> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> <1185388221.6357.10.camel@perun.kabelta.loc> <20070725143811.3e02eccf@localhost.localdomain> <46A799AC.8080907@redhat.com> Message-ID: <20070725145639.46930cc6@localhost.localdomain> On Wed, 25 Jul 2007 20:42:52 +0200 Adam Tkac wrote: > If we are talking about DNS problems (and when I add yesterday "cvs > renumbering" problem or what it was) I think it would be good have > DNS server in build system and builders will ask to them instead > using /etc/hosts file. For the builders we have that taken care of. For the chroots we don't want them being able to resolve names or access the network. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmraz at redhat.com Wed Jul 25 19:37:18 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 25 Jul 2007 21:37:18 +0200 Subject: Are the builders okay? In-Reply-To: <20070725143811.3e02eccf@localhost.localdomain> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> <1185387211.4060.5.camel@lt21223.campus.dmacc.edu> <1185388221.6357.10.camel@perun.kabelta.loc> <20070725143811.3e02eccf@localhost.localdomain> Message-ID: <1185392238.6357.14.camel@perun.kabelta.loc> On Wed, 2007-07-25 at 14:38 -0400, Jesse Keating wrote: > On Wed, 25 Jul 2007 20:30:21 +0200 > Tomas Mraz wrote: > > > They do network communication and perhaps they even are trying to do > > some dns lookups if /etc/hosts is not set up properly to resolve the > > machine's hostname. But they should communicate only on the machine > > itself. Being a no-no means that we shouldn't be running them? They > > are very useful for for example finding bugs in compiler. > > /etc/hosts has an entry for localhost, but it seems your test is trying > to hit what is in /etc/resolv.conf which is a bogus IP. Perhaps your > test is getting a hostname of the builder and trying to look that up? Yes, it doesn't connect over localhost but over the machine hostname. Either in the buildroots the hostname should be set to localhost or the /etc/hosts in the buildroot should have an entry for the machine's hostname as 127.0.0.1. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From tmraz at redhat.com Wed Jul 25 19:38:07 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 25 Jul 2007 21:38:07 +0200 Subject: Are the builders okay? In-Reply-To: <46A796C8.1000608@warmcat.com> References: <46A7914F.3000004@cora.nwra.com> <1185387074.6357.4.camel@perun.kabelta.loc> <46A796C8.1000608@warmcat.com> Message-ID: <1185392287.6357.16.camel@perun.kabelta.loc> On Wed, 2007-07-25 at 19:30 +0100, Andy Green wrote: > Somebody in the thread at some point said: > > > On Wed, 2007-07-25 at 12:07 -0600, Orion Poplawski wrote: > >> openssl is still building (running tests) after ~6 hours. All of the > >> gnome-panel build tasks have completed, but the main task is still open, > >> tracker x86_64 job seems stuck installing the buildroot long after > >> others have completed. etc... > > The tests in openssl build are very slowly going ahead. So not stuck, > > but there is definitely something strange on the builders - the tests > > definitely shouldn't take so much time to finish. > > crypto stuff can easily stall depending on entropy on /dev/random, maybe > it is that. Openssl prefers /dev/urandom over /dev/random if available. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From buildsys at redhat.com Wed Jul 25 19:58:20 2007 From: buildsys at redhat.com (Build System) Date: Wed, 25 Jul 2007 15:58:20 -0400 Subject: rawhide report: 20070725 changes Message-ID: <200707251958.l6PJwK31003987@porkchop.devel.redhat.com> New package bacula Cross platform network backup for Linux, Unix, Mac and Windows New package hardinfo System Profiler and Benchmark New package libgeotiff GeoTIFF format library New package libtimidity MIDI to WAVE converter library New package m17n-contrib Contributed multilingualization datafiles for m17n-lib New package mcabber Console Jabber instant messaging client New package perl-Catalyst-Action-RenderView Sensible default end action for view renders New package pixman Pixel manipulation library New package schedtool Tool to query or alter process scheduling policy New package yum-updatesd Update notification daemon Updated Packages: R-mvtnorm-0.8-2.fc8 ------------------- * Tue Jul 24 2007 Orion Poplawski - 0.8-2 - Update to 0.8-1, fixes test adminutil-1.1.3-1.fc8 --------------------- * Tue Jul 24 2007 Rich Megginson - 1.1.3-1 - updated to version 1.1.3 - fixes bugzillas 246124 and 247192 allegro-4.2.2-2.fc8 ------------------- * Tue Jul 24 2007 Hans de Goede 4.2.2-2 - sync .libdir patch to 4.2.2 and use it again for multilib devel goodness (make allegro-devel i386 and x86_64 parallel installable again) * Mon Jul 23 2007 Jindrich Novy 4.2.2-1 - update to 4.2.2 - drop .libdir patch - sync .multilib patch * Fri Jul 06 2007 Hans de Goede 4.2.1-3 - Silence output of chcon command in %post, because otherwise users get this: "chcon: can't apply partial context to unlabeled file" when installing with selinux disabled (bz 246820) alsa-oss-1.0.14-1.fc8 --------------------- * Tue Jul 24 2007 Patrick "Jima" Laughton 1.0.14-1 - Updated to match F8 alsa-libs - Changed reference to patch filename anaconda-11.3.0.9-1 ------------------- * Tue Jul 24 2007 Jeremy Katz - 11.3.0.9-1 - Rebuild keymaps (clumens, #240087) - Fix kickstart docs about dhcpclass (clumens, #248910) - Fix for usb-storage dance (pjones, #247830) - Fix protected partitions problem (clumens) - Improve stage2 generation bind-32:9.5.0-6.a6.fc8 ---------------------- * Tue Jul 24 2007 Adam Tkac 32:9.5.0-6.a6.fc8 - updated to 9.5.0a6 which contains fixes for CVE-2007-2925 and CVE-2007-2926 - fixed building on 64bits * Mon Jul 23 2007 Adam Tkac 31:9.5.0a5-5.fc8 - integrated "autotools" patch for testing purposes (upstream will accept it in future, for easier building) * Mon Jul 23 2007 Adam Tkac 31:9.5.0a5-4.1.fc8 - fixed DLZ drivers building on 64bit systems binutils-2.17.50.0.17-5 ----------------------- * Wed Jul 25 2007 Jakub Jelinek 2.17.50.0.17-5 - add .note.gnu.build-id into default linker script (#249435) * Wed Jul 25 2007 Jakub Jelinek 2.17.50.0.17-4 - don't kill the %{_gnu} part of target name on arm (Lennert Buytenhek, #243516) - create just one PT_NOTE segment header for all consecutive SHT_NOTE sections * Wed Jul 18 2007 Roland McGrath 2.17.50.0.17-3 - fix for ld --build-id cone-0.71-1.fc8 --------------- * Tue Jul 24 2007 Steven Pritchard 0.71-1 - Update to 0.71. * Mon Apr 09 2007 Steven Pritchard 0.69-1 - Update to 0.69. * Mon Aug 28 2006 Steven Pritchard 0.68-2 - Rebuild. eog-2.19.4-2.fc8 ---------------- * Tue Jul 24 2007 Matthias Clasen - 2.19.4-2 - Fix a undefined macro use (#248689) fuse-2.7.0-3.fc8 ---------------- * Sun Jul 22 2007 Tom "spot" Callaway 2.7.0-3 - put pkgconfig file in correct place - enable compat symlinks for files in /bin * Sat Jul 21 2007 Tom "spot" Callaway 2.7.0-2 - redefine exec_prefix to / - redefine bindir to /bin - redefine libdir to %{_lib} - don't pass --disable-static to configure - manually rm generated static libs * Wed Jul 18 2007 Peter Lemenkov 2.7.0-1 - Version 2.7.0 - Redefined exec_prefix due to demands from NTFS-3G gc-7.0-2.fc8 ------------ * Tue Jul 24 2007 Rex Dieter 7.0-2 - gcinit patch, ABI compatibility (#248700) gcc-4.1.2-17 ------------ * Tue Jul 24 2007 Jakub Jelinek 4.1.2-17 - fix {,Build}Requires from last change (#249384) gnome-panel-2.19.5-3.fc8 ------------------------ * Tue Jul 24 2007 Matthias Clasen - 2.19.5-3 - Fix launcher tooltips to react to changes. (#212164) gnome-speech-0.4.15-2.fc8 ------------------------- * Tue Jul 24 2007 Matthias Clasen - 0.4.15-2 - Build the espeak driver and put it in a subpackage gpm-1.20.1-87.fc8 ----------------- * Tue Jul 24 2007 Tomas Janousek - 1.20.1-87 - replace OPEN_MAX with sysconf(_SC_OPEN_MAX), fixing build with 2.6.23 kernel * Tue Jul 24 2007 Tomas Janousek - 1.20.1-86 - don't install t-mouse.el, emacs-common contains a newer version, fixes #249362 kde-settings-3.5-30.fc8 ----------------------- * Mon Jul 02 2007 Than Ngo - 3.5-30 - fix bz#245100 kdesdk-3.5.7-7.fc8 ------------------ * Tue Jul 24 2007 Rex Dieter - 3.5.7-7 - don't use %pretrans (#249374) kernel-xen-2.6-2.6.21-2925.14.fc8 --------------------------------- * Tue Jul 24 2007 Eduardo Habkost - Rebase to 2.6.21.6 ktorrent-2.2.1-1.fc8 -------------------- * Tue Jul 24 2007 Roland Wolters 2.2.1-1 - update to bugfix upstream 2.2.1 libXcomposite-0.4.0-1.fc8 ------------------------- * Tue Jul 24 2007 Adam Jackson 0.4.0-1 - libXcomposite 0.4.0 * Sat Apr 21 2007 Matthias Clasen - 0.3.1-2 - Don't install INSTALL libhangul-0.0.6-1.fc8 --------------------- * Tue Jul 24 2007 Hu Zheng - 0.0.6-1 - New upstream release. libpcap-14:0.9.7-1.fc8 ---------------------- libvirt-0.3.1-1.fc8 ------------------- * Tue Jul 24 2007 Daniel Veillard - 0.3.1-1.fc8 - Release of 0.3.1 - localtime clock support - PS/2 and USB input devices - lots of assorted bugfixes and cleanups - documentation and localization improvements libwnck-2.19.5-2.fc8 -------------------- * Tue Jul 24 2007 Matthias Clasen - 2.19.5-2 - Fix a crash on shutdown in the wnck-applet libxml++-2.18.1-1.fc8 --------------------- * Tue Jul 24 2007 Denis Leroy - 2.18.1-1 - Update to version 2.18.1 meld-1.1.5-2.fc8 ---------------- * Sun Jun 10 2007 Brian Pepple - 1.1.5-2 - Drop requires on yelp. mesa-6.5.2-15.fc8 ----------------- * Tue Jul 24 2007 Adam Jackson 6.5.2-15 - Add dri_interface.h to mesa-libGL-devel, and conflict with xorg-x11-proto-devel versions that attempted to provide it. * Tue Jul 10 2007 Adam Jackson 6.5.2-14 - Add mesa-demos subpackage. (#247252) mod_dnssd-0.5-3.fc8 ------------------- ntfs-3g-2:1.710-1.fc8 --------------------- * Sun Jul 22 2007 Tom "spot" Callaway 2:1.710-1 - bump to 1.710 - add compat symlinks * Wed Jun 27 2007 Tom "spot" Callaway 2:1.616-1 - bump to 1.616 ntp-4.2.4p2-2.fc8 ----------------- * Tue Jul 24 2007 Miroslav Lichvar 4.2.4p2-2 - ignore tentative addresses (#246297) - improve init script (#247003) - fix sleep patch - ease Autokey setup (#139673) - change default keysdir to /etc/ntp/crypto - set crypto password in /etc/ntp/crypto/pw - don't use randfile if /dev/urandom is used by OpenSSL - change default statsdir to /var/log/ntpstats/, use statistics type as default filename - package more doc files pam-0.99.8.1-1.fc8 ------------------ * Mon Jul 23 2007 Tomas Mraz 0.99.8.1-1 - upgrade to latest upstream version - add some firewire devices to default console perms (#240770) * Thu Apr 26 2007 Tomas Mraz 0.99.7.1-6 - pam_namespace: better document behavior on failure (#237249) - pam_unix: split out passwd change to a new helper binary (#236316) - pam_namespace: add support for temporary logons (#241226) * Fri Apr 13 2007 Tomas Mraz 0.99.7.1-5 - pam_selinux: improve context change auditing (#234781) - pam_namespace: fix parsing config file with unknown users (#234513) perl-4:5.8.8-22.fc8 ------------------- * Tue Jul 24 2007 Robin Norwood - 4:5.8.8-22 - Resolves: rhbz#247386 - Use getcwd() instead of cwd() in File::Spec::Unix to avoid forking. - Appy patch to skip hostname tests, since hostname lookup isn't available in Fedora buildroots by design. * Mon Jul 02 2007 Tom "spot" Callaway - 4:5.8.8-21 - perl-core metapackage * Fri Jun 22 2007 Robin Norwood - 4:5.8.8-20 - Resolves: rhbz#196836 - Apply upstream patch #28775, which fixes an issue where reblessing overloaded objects incurs significant performance penalty perl-Taint-Runtime-0.03-1.fc8.1 ------------------------------- * Tue Jul 24 2007 Tom "spot" Callaway 0.03-1.1 - BR: perl(Test::More) php-eaccelerator-1:0.9.5.1-3.fc8 -------------------------------- * Tue Jul 24 2007 Matthias Saou 1:0.9.5.1-3 - Include patch to skip the exact PHP version check, we'll rely on our package's php_zend_api version requirement to "get it right". policycoreutils-2.0.22-8.fc8 ---------------------------- * Tue Jul 24 2007 Dan Walsh 2.0.22-8 - Add requires libselinux-python pungi-0.3.9-1.fc8 ----------------- * Tue Jul 24 2007 Jesse Keating - 0.3.9-1 - Add a few more desktopy things to manifest - Rename f7 files to f8; set up config files for f8test1 - Don't quote things passed to mkisofs, not a shell - Always log stdout before checking for stderr output - Include memtest86+ in the "Fedora" manifest rsyslog-1.17.2-3.fc8 -------------------- * Tue Jul 24 2007 Peter Vrabec 1.17.2-3 - take care of sysklogd configuration files in %post * Tue Jul 24 2007 Peter Vrabec 1.17.2-2 - use EVR in provides/obsoletes sysklogd rusers-0.17-48 -------------- * Mon Jul 23 2007 Jiri Moskovcak 0.17-48 - Fixed init scripts to comply with LSB standard - Resolves: #247047 sane-backends-1.0.18-12.fc8 --------------------------- * Tue Jul 24 2007 Nils Philippsen - 1.0.18-12 - fix typo in spec file * Tue Jul 24 2007 Nils Philippsen - 1.0.18-11 - work around udev regexes not matching as they should (#244444) selinux-policy-3.0.3-6.fc8 -------------------------- * Mon Jul 23 2007 Dan Walsh 3.0.3-6 - Fix prelink to handle execmod setup-2.6.9-1.fc8 ----------------- * Tue Jul 24 2007 Phil Knirsch 2.6.9-1 - Assigned uid 87 for PolicyKit package (#244950) - Fixed precmd fix if TERM isn't set (#242732) * Wed Jun 06 2007 Phil Knirsch 2.6.7-1 - Fixed precmd setting to behave like bash for (t)csh (#242732) * Thu May 24 2007 Phil Knirsch 2.6.6-1 - Added another set of proposed changes to /etc/csh.cshrc (#199817) - Added missing documentation in /etc/hosts.[allow|deny] (#157053) system-config-users-1.2.62-1.fc8 -------------------------------- * Tue Jul 24 2007 Nils Philippsen - 1.2.62 - pull in updated translations tcpdump-14:3.9.7-1.fc8 ---------------------- * Tue Jul 24 2007 Miroslav Lichvar - 14:3.9.7-1 - update to 3.9.7 - with -C option, drop root privileges before opening first savefile (#244860) - update tcpslice to 1.2a3 - include time patch from Debian to fix tcpslice on 64-bit architectures tkcvs-8.0.4-2.fc8 ----------------- uuid-1.6.0-1.fc8 ---------------- * Tue Jul 24 2007 Steven Pritchard 1.6.0-1 - Update to 1.6.0. - BR Test::More. w3m-0.5.2-2.fc8 --------------- * Tue Jul 24 2007 Parag Nemade - 0.5.2-2 - Build against new gc-7.0 release. * Tue Jun 26 2007 Parag Nemade - 0.5.2-1 - Update to 0.5.2 and remove merged patches. - Build against system gc library. - Add BR: nkf for multipart.cgi. - Don't call unneeded autotool * Tue Mar 27 2007 Parag Nemade - 0.5.1-19 - and more cleanup. wlassistant-0.5.7-3.fc8 ----------------------- * Mon Jul 23 2007 Tom "spot" Callaway 0.5.7-3 - close file descriptors with FD_CLOEXEC, try to resolve bz 243509 xawtv-3.95-4.fc8 ---------------- * Tue Jul 24 2007 Dmitry Butskoy - 3.95-4 - don't assume v4l-conf as system config util (#249130) * Tue Jun 26 2007 Dmitry Butskoy - drop X-Fedora category from desktop file xorg-x11-proto-devel-7.2-12.fc8 ------------------------------- * Tue Jul 24 2007 Adam Jackson 7.2-12 - Remove dri_interface.h. It's not protocol, it belongs in Mesa. * Wed Jul 11 2007 Adam Jackson 7.2-11 - compositeproto 0.4 xorg-x11-server-utils-7.2-4.fc8 ------------------------------- * Tue Jul 24 2007 Adam Jackson 7.2-4 - iceauth 1.0.2 * Wed Jul 11 2007 Adam Jackson 7.2-3 - xrandr 1.2.2 xorg-x11-xkb-utils-7.2-1.fc8 ---------------------------- * Tue Jul 24 2007 Adam Jackson 7.2-1 - setxkbmap 1.0.4 - Arbitrary version number bump, to match X.org release numbering. Why not. ytalk-3.3.0-7.fc8 ----------------- * Tue Jul 24 2007 Mike McGrath 3.3.0-7 - release bump and rebuild yum-3.2.2-2.fc8 --------------- * Tue Jul 24 2007 Jeremy Katz - 3.2.2-2 - remove yum-updatesd subpackage; moving to the separate version * Fri Jul 20 2007 Seth Vidal - 3.2.2-1 - 3.2.2 - disable unused installonlyn plugin - set installonly_limit to '2' * Tue Jul 10 2007 James Bowes - 3.2.1-2 - defattr, buldarch, and macro suggestions from the merge review Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From jaroslav at aster.pl Wed Jul 25 21:08:58 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Wed, 25 Jul 2007 23:08:58 +0200 Subject: emacs-22.x - comments highlighting is "wrong" In-Reply-To: References: <200707072339.37806.jaroslav@aster.pl> Message-ID: <200707252309.07153.jaroslav@aster.pl> Wednesday 11 of July 2007 21:32:20 Leo napisa?(a): > > In 21.x if you put a comment mark at the beginning of the line or > > comment a region with "/*" and "*/", _all_ the text that is commented > > changes its color to "comment_font_color" (please forgive this > > arbitrary and non-technical term). In 22.x _only_ the comment > > characters color is "comment_font_color" and the whole commented text > > is "plain_text_font_color" > > You should test by starting emacs with "emacs -Q". Because you old > config file might be causing those problems. 1. This happens only in console mode (emacs -nw), 2. "emacs -nw -Q" is even worse - no single char of commented line is being highlighted ;) BTW. Dan Nicolaescu clarified that this change has happened upstream. He shown me useful tip. After setting TERM variable to 'xterm-256color' normal highlighting is back. Unfortunately it does not work in Linux standard console. regards, Jaroslaw PS. Is there a particular reason why TERM=xterm by default? -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mschwendt.tmp0701.nospam at arcor.de Wed Jul 25 22:16:24 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 26 Jul 2007 00:16:24 +0200 Subject: libBrutusKeyringd-1.0.so.1 Message-ID: <20070726001624.05573511.mschwendt.tmp0701.nospam@arcor.de> This in Rawhide looks suspicious: brutus-keyring-devel provides libBrutusKeyringd-1.0.so.1 evolution-brutus provides libBrutusKeyringd-1.0.so.1 required by: brutus-keyring - 0.9.0-5.fc8.i386 required by: evolution-brutus - 1.1.26.2-2.fc7.i386 required by: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 required by: brutus-keyring - 0.9.0-5.fc8.i386 required by: brutus-keyring-devel - 0.9.0-5.fc8.i386 required by: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 From mschwendt.tmp0701.nospam at arcor.de Wed Jul 25 22:21:40 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 26 Jul 2007 00:21:40 +0200 Subject: libBrutusKeyringd-1.0.so.1 In-Reply-To: <20070726001624.05573511.mschwendt.tmp0701.nospam@arcor.de> References: <20070726001624.05573511.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070726002140.164c2616.mschwendt.tmp0701.nospam@arcor.de> On Thu, 26 Jul 2007 00:16:24 +0200, Michael Schwendt wrote: > This in Rawhide looks suspicious: > > brutus-keyring-devel provides libBrutusKeyringd-1.0.so.1 > evolution-brutus provides libBrutusKeyringd-1.0.so.1 > required by: brutus-keyring - 0.9.0-5.fc8.i386 > required by: evolution-brutus - 1.1.26.2-2.fc7.i386 > required by: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 > required by: brutus-keyring - 0.9.0-5.fc8.i386 > required by: brutus-keyring-devel - 0.9.0-5.fc8.i386 > required by: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 brutus-keyring-devel - 0.9.0-5.fc8.i386 File conflict with: evolution-brutus - 1.1.26.2-2.fc7.i386 /usr/lib/libBrutusKeyringd-1.0.so.1.0.0 File conflict with: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 /usr/lib/pkgconfig/libBrutusKeyringd-1.0.pc evolution-brutus - 1.1.26.2-2.fc7.i386 File conflict with: brutus-keyring-devel - 0.9.0-5.fc8.i386 /usr/lib/libBrutusKeyringd-1.0.so.1.0.0 evolution-brutus-devel - 1.1.26.2-2.fc7.i386 File conflict with: brutus-keyring-devel - 0.9.0-5.fc8.i386 /usr/lib/pkgconfig/libBrutusKeyringd-1.0.pc Which package to file this about? From luya_tfz at thefinalzone.com Wed Jul 25 22:46:51 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 25 Jul 2007 18:46:51 -0400 Subject: Temporairly echo-icos source host location Message-ID: <1185403611.46a7d2dba5e47@ssl.mecca.ca> Sorry for a late message, I am very busy with Graphics Design classes. The echo-icon-theme source is temporairly located at luya.fedorapeople.org/images/echo . The future host will us git to import/export package which should dramatically reduce the need to use echo-pull script online. More details soon. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From chris.stone at gmail.com Wed Jul 25 22:51:12 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 25 Jul 2007 15:51:12 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070724232757.74adddf6@ender> References: <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> <20070724232757.74adddf6@ender> Message-ID: On 7/24/07, Jesse Keating wrote: > On Tue, 24 Jul 2007 20:20:23 -0700 > "Christopher Stone" wrote: > > > I see nothing wrong with gnome-menu and/or kde-menu as long as its > > able to override ShowOnlyIn. > > Good, lets work toward that end end this silly argument. Right. I'm not sure why you think it's silly. And I'm even more puzzled why you participate in arguments you think are silly. But anyway, shall I go ahead and file a bug against gnome-menus for this? From vonbrand at inf.utfsm.cl Wed Jul 25 15:20:05 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 25 Jul 2007 11:20:05 -0400 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <20070725135759.GI6932@angus.ind.WPI.EDU> References: <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> <20070725135759.GI6932@angus.ind.WPI.EDU> Message-ID: <21275.1185376805@laptop13.inf.utfsm.cl> Chuck Anderson wrote: [...] > Additionally, if the -devel packages were split on license boundaries, > then perhaps the buildsystem could flag attempts to link to > incompatibly-licensed libararies. This is worse than I feared the fabled GPLv3 fallout could be... -- 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 markg85 at gmail.com Wed Jul 25 22:54:25 2007 From: markg85 at gmail.com (Mark) Date: Thu, 26 Jul 2007 00:54:25 +0200 Subject: Package rebuilds for binutils/gcc bug In-Reply-To: <20070725132332.3c692c7c@localhost.localdomain> References: <20070725130054.10bb7f37@localhost.localdomain> <20070725171525.GF3673@serv.smile.org.ua> <20070725132332.3c692c7c@localhost.localdomain> Message-ID: <6e24a8e80707251554y7249f5c8kbaa20f9141d1c57a@mail.gmail.com> is: "kernel-xen-2.6" still needed in Fedora 8? Kernel 2.6.23 (rc1) has xen build in (jguest as well). 2007/7/25, Jesse Keating : > On Wed, 25 Jul 2007 20:15:25 +0300 > Andy Shevchenko wrote: > > > > The list is at http://jkeating.fedorapeople.org/needrebuild While > > > not every package will show errors, we're going to rebuild them > > > just in case. > > Is it possible to regenerate alphabeticaly sorted list? > > This was already done (: > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From drago01 at gmail.com Wed Jul 25 23:41:29 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 26 Jul 2007 01:41:29 +0200 Subject: Package rebuilds for binutils/gcc bug In-Reply-To: <6e24a8e80707251554y7249f5c8kbaa20f9141d1c57a@mail.gmail.com> References: <20070725130054.10bb7f37@localhost.localdomain> <20070725171525.GF3673@serv.smile.org.ua> <20070725132332.3c692c7c@localhost.localdomain> <6e24a8e80707251554y7249f5c8kbaa20f9141d1c57a@mail.gmail.com> Message-ID: On 7/26/07, Mark wrote: > > is: "kernel-xen-2.6" still needed in Fedora 8? > Kernel 2.6.23 (rc1) has xen build in (jguest as well). only a part of xen has been merged yet... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Jul 26 00:06:00 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 25 Jul 2007 16:06:00 -0800 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <21275.1185376805@laptop13.inf.utfsm.cl> References: <1185293966.2408.123.camel@cutter> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> <20070725135759.GI6932@angus.ind.WPI.EDU> <21275.1185376805@laptop13.inf.utfsm.cl> Message-ID: <604aa7910707251706q4c318ee2x1db931ad5c6f9230@mail.gmail.com> On 7/25/07, Horst H. von Brand wrote: > This is worse than I feared the fabled GPLv3 fallout could be... Worse in what way exactly? Isn't licensing transparency important? Splitting packages based on licensing might look like a crap load of work that noone is thrilled about doing... but the reality is, noone is going to be thrilled about doing the work to that makes license compliance a managable endeavor. There is nothing sexy from a technical perspective about license compliance, but the need for it a reality...especially now that we've run into a situation where lots of concurrent codebase relicensing will be happening higgly-piggly. If we are serious about having tools in our buildsystem that make this less painful moving forward, then what Chuck has suggested seems like a reasonably valid point of discussion. If we are serious about building programmatic automation tools, then we will have to adapt how we do things to make the automation reliable. The only question is how much error are we prepared to deal with, and how much effort are we prepared to expend. -jef"Are there people out there who enjoy exploring the minutia of open source licensing? If you are reading this, feel free to talk to me off-list about potentially contributing time for Fedora licensing auditing"spaleta From tjb at unh.edu Thu Jul 26 00:14:12 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 25 Jul 2007 20:14:12 -0400 Subject: Dim Screen after Resume - which component to file bug against? Message-ID: <1185408852.4305.6.camel@continuity> The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start using suspend and hibernate again on my Inspiron XPS M1210. Hibernate works perfectly, suspend has one quirk. On resume the screen is quite dim and the level can't be changed. Is this a kernel bug or a g-power-m one? On a possibly related note, when I first installed F7, the Power Manager Brightness Applet used to work but now doesn't. I just get the "no" symbol over the top of it. An update soon after the initial install broke it. I run updates-testing on my laptop and I regularly download and run koji f7 kernels. So same question, kernel or g-p-m? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From bloch at verdurin.com Thu Jul 26 00:21:17 2007 From: bloch at verdurin.com (Adam Huffman) Date: Thu, 26 Jul 2007 01:21:17 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185408852.4305.6.camel@continuity> References: <1185408852.4305.6.camel@continuity> Message-ID: <20070726002117.GA32514@bloch.config> On Wed, 25 Jul 2007, Thomas J. Baker wrote: > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > works perfectly, suspend has one quirk. On resume the screen is quite > dim and the level can't be changed. Is this a kernel bug or a g-power-m > one? > I have exactly the same problem on a Vaio SZ3 - I reported it as a kernel bug. Adam From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jul 26 00:30:14 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 26 Jul 2007 09:30:14 +0900 Subject: libBrutusKeyringd-1.0.so.1 In-Reply-To: <20070726002140.164c2616.mschwendt.tmp0701.nospam@arcor.de> References: <20070726001624.05573511.mschwendt.tmp0701.nospam@arcor.de> <20070726002140.164c2616.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46A7EB16.2050808@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote, at 07/26/2007 07:21 AM +9:00: > On Thu, 26 Jul 2007 00:16:24 +0200, Michael Schwendt wrote: > >> This in Rawhide looks suspicious: >> >> brutus-keyring-devel provides libBrutusKeyringd-1.0.so.1 >> evolution-brutus provides libBrutusKeyringd-1.0.so.1 >> required by: brutus-keyring - 0.9.0-5.fc8.i386 >> required by: evolution-brutus - 1.1.26.2-2.fc7.i386 >> required by: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 >> required by: brutus-keyring - 0.9.0-5.fc8.i386 >> required by: brutus-keyring-devel - 0.9.0-5.fc8.i386 >> required by: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 > > brutus-keyring-devel - 0.9.0-5.fc8.i386 > File conflict with: evolution-brutus - 1.1.26.2-2.fc7.i386 > /usr/lib/libBrutusKeyringd-1.0.so.1.0.0 > File conflict with: evolution-brutus-devel - 1.1.26.2-2.fc7.i386 > /usr/lib/pkgconfig/libBrutusKeyringd-1.0.pc > > evolution-brutus - 1.1.26.2-2.fc7.i386 > File conflict with: brutus-keyring-devel - 0.9.0-5.fc8.i386 > /usr/lib/libBrutusKeyringd-1.0.so.1.0.0 > > evolution-brutus-devel - 1.1.26.2-2.fc7.i386 > File conflict with: brutus-keyring-devel - 0.9.0-5.fc8.i386 > /usr/lib/pkgconfig/libBrutusKeyringd-1.0.pc > > Which package to file this about? > File against evolution-brutus. evolution-brutus must be upgraded to >=1.1.28. [tasaka1 at localhost i386]$ rpm -qp --conflicts brutus-keyring-0.9.0-5.fc8.i386.rpm evolution-brutus < 1.1.28 Mamoru From jkeating at redhat.com Thu Jul 26 00:40:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Jul 2007 20:40:04 -0400 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: References: <1185225894.3463.3.camel@sb-home> <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> <20070724232757.74adddf6@ender> Message-ID: <20070725204004.4fe96a14@ender> On Wed, 25 Jul 2007 15:51:12 -0700 "Christopher Stone" wrote: > shall I go ahead and file a bug against gnome-menus for this? Sure. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjb at unh.edu Thu Jul 26 01:43:45 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 25 Jul 2007 21:43:45 -0400 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <20070726002117.GA32514@bloch.config> References: <1185408852.4305.6.camel@continuity> <20070726002117.GA32514@bloch.config> Message-ID: <1185414225.4305.9.camel@continuity> On Thu, 2007-07-26 at 01:21 +0100, Adam Huffman wrote: > On Wed, 25 Jul 2007, Thomas J. Baker wrote: > > > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > > works perfectly, suspend has one quirk. On resume the screen is quite > > dim and the level can't be changed. Is this a kernel bug or a g-power-m > > one? > > > > I have exactly the same problem on a Vaio SZ3 - I reported it as a > kernel bug. > > Adam > Thanks. Do you have the bug number? I searched bugzilla but couldn't find it. 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 markg85 at gmail.com Thu Jul 26 02:05:21 2007 From: markg85 at gmail.com (Mark) Date: Thu, 26 Jul 2007 04:05:21 +0200 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070725204004.4fe96a14@ender> References: <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> <20070724232757.74adddf6@ender> <20070725204004.4fe96a14@ender> Message-ID: <6e24a8e80707251905k19119c85x1fd215860eae01ff@mail.gmail.com> I didn't want to join in this argument but i feel like i have to point out my opinion. I personally don't like the gnome or kde menu structure at all!! both are extremely user unfriendly and doesn't seem to experience any changes (gnome 2.20? kde 4?? both still seem to have the unfriendly menu). But what i dislike most of all is that somehow you guys figured out that have the rights to restrict us access from certain menu items (kde programs not showing up in gnome and visa versa) i find this kinda shocking in Fedora's behavior... and i don't want menu items to be hidden from view in another WM. you guys _need_ to change this. and (like pointed out before by others) if i install a gnome app on KDE than if it adds a menu entry (some apps don't add a entry) i want it to be seen in the menu regardless of gnome, xfce or kde or any WM. just show the icon!! and _don't_ add things like "KDE Icons" or "Gnome Icons" (i _will_ start complaining about them if they get in) just sort the icons how they are supposed to be sorted and show them. hiding my (windows) partitions icons.. (sadly) oke but hiding my application ICONS.. no that's not good!! 2007/7/26, Jesse Keating : > On Wed, 25 Jul 2007 15:51:12 -0700 > "Christopher Stone" wrote: > > > shall I go ahead and file a bug against gnome-menus for this? > > Sure. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From markg85 at gmail.com Thu Jul 26 02:08:23 2007 From: markg85 at gmail.com (Mark) Date: Thu, 26 Jul 2007 04:08:23 +0200 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070725204004.4fe96a14@ender> References: <1185296850.5046.5.camel@sb-home> <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> <20070724232757.74adddf6@ender> <20070725204004.4fe96a14@ender> Message-ID: <6e24a8e80707251908s70aaac0apc7a83a0cfa2a9a17@mail.gmail.com> and can you tell me of a quick way of getting rid of those lines? without having to edit each file and without updates that restore it again. Thanx. 2007/7/26, Jesse Keating : > On Wed, 25 Jul 2007 15:51:12 -0700 > "Christopher Stone" wrote: > > > shall I go ahead and file a bug against gnome-menus for this? > > Sure. > > -- > Jesse Keating > Release Engineer: Fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From katzj at redhat.com Thu Jul 26 02:31:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 Jul 2007 22:31:35 -0400 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185408852.4305.6.camel@continuity> References: <1185408852.4305.6.camel@continuity> Message-ID: <1185417095.4088.9.camel@localhost.localdomain> On Wed, 2007-07-25 at 20:14 -0400, Thomas J. Baker wrote: > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > works perfectly, suspend has one quirk. On resume the screen is quite > dim and the level can't be changed. Is this a kernel bug or a g-power-m > one? Try using any brightness keys that you have to change down and then up. If that works, then it probably needs the reset-brightness-quirk (which we really need to build a new pm-utils, etc so that it can be taken advantage of) Jeremy From chris.stone at gmail.com Thu Jul 26 03:15:02 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 25 Jul 2007 20:15:02 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <6e24a8e80707251908s70aaac0apc7a83a0cfa2a9a17@mail.gmail.com> References: <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> <20070724232757.74adddf6@ender> <20070725204004.4fe96a14@ender> <6e24a8e80707251908s70aaac0apc7a83a0cfa2a9a17@mail.gmail.com> Message-ID: On 7/25/07, Mark wrote: > and can you tell me of a quick way of getting rid of those lines? > without having to edit each file and without updates that restore it again. > > Thanx. This is an example command to remove the lines: # desktop-file-install --remove-only-show-in GNOME /usr/share/applications/gnome-banshee.desktop running this with find twice using GNOME and KDE should fix it, but I think updates will probably overwrite your changes. From nicolas.mailhot at laposte.net Thu Jul 26 08:02:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 26 Jul 2007 10:02:43 +0200 (CEST) Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <21275.1185376805@laptop13.inf.utfsm.cl> References: <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> <1185367384.6631.67.camel@hopeson> <47760.192.54.193.51.1185368139.squirrel@rousalka.dyndns.org> <20070725135759.GI6932@angus.ind.WPI.EDU> <21275.1185376805@laptop13.inf.utfsm.cl> Message-ID: <17918.192.54.193.51.1185436963.squirrel@rousalka.dyndns.org> Le Mer 25 juillet 2007 17:20, Horst H. von Brand a ?crit : > Chuck Anderson wrote: > > [...] > >> Additionally, if the -devel packages were split on license >> boundaries, >> then perhaps the buildsystem could flag attempts to link to >> incompatibly-licensed libararies. > > This is worse than I feared the fabled GPLv3 fallout could be... Don't be ridiculous, we're addressing this now because some people have decided to make GPLv3 an issue, but licence tagging and checking is a longstanding problem which was going to bite us sooner or later once Fedora expanded from a small well-known core to a huge package collection. Some software pools have standardised on a single well-understood licence. Many haven't and this was true before the GPLv3 endeavour was announced. -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Thu Jul 26 07:57:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 09:57:27 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185384324.2807.4.camel@kennedy> References: <1185384324.2807.4.camel@kennedy> Message-ID: <46A853E7.3030303@hhs.nl> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCO-Meeting -- MISC -- elect FESCo Chair - all > > /topic FESCO-Meeting -- MISC -- Feature Proposal Approval - > http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat > > /topic FESCO-Meeting -- Rebuilding Packages -- Needs to decide whether > to always rebuild, or only when toolchain warrants it - all > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > I've got a somewhat strange question for FESco to look at, I would like to have an exception to the rule that all packages must be reviewed for the following set of packages: * arm-gp2x-linux-binutils Cross Compiling GNU binutils targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 * arm-gp2x-linux-kernel-headers Kernel headers for Cross Compiling to arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 * arm-gp2x-linux-gcc Cross Compiling GNU GCC targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206 * arm-gp2x-linux-glibc Cross Compiled GNU C Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207 * arm-gp2x-linux-SDL Cross Compiled SDL Library targeted at arm-gp2x-linux https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147 * arm-gp2x-linux-zlib Cross Compiled zlib Library targeted at avr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254 I've been trying to find a reviewer for them for ages, but there seems to be no-one with both the expertise and the time to review them. You all know that I'm a very serious packager, and that I have near 0 bugs open against my 135+ packages, so I hope that you will trust me to deliver good quality even without a review. --- Another issue I would like FESco to look at is the current somewhat grey state of kmod's I'm considering packaging kmod's for uvc (usb video class driver), lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in rawhide). But before I invest time in these I would first like to have the state of kmod's cleared up. I will try to work with there resp. upstreams to get them in the upstream kernel, and atleast for uvc and islsm upstream merger is planned already. Regards, Hans From mschwendt.tmp0701.nospam at arcor.de Thu Jul 26 08:53:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 26 Jul 2007 10:53:21 +0200 Subject: .noarch <-> .i386/.x86_64/.ppc change Message-ID: <20070726105321.d9a2d3e0.mschwendt.tmp0701.nospam@arcor.de> There's another package in FE6 doing a jump from .noarch to .i386/.x86_64/.ppc -- I can't find the notes on when this can cause problems. Searching the Wiki has been fruitless, too. Where is this documented? From kevin.kofler at chello.at Thu Jul 26 09:12:37 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 26 Jul 2007 09:12:37 +0000 (UTC) Subject: Plan for tomorrows (20070726) FESCO meeting References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: Wow, still no reviewer for arm-gp2x-linux-*? I'll bite the bullet and review these if you promise you'll do the same for my tigcc cross-toolchain once I submit it (should be in a few weeks, I need to spin a tarball without the optional non-Free A68k assembler). (TIGCC is just one package, so you'll get away with less work than me in the deal. ;-) ) Oh, and in exchange you can also review kdegames3 and atlantikdesigner (part of the KDE 4 plan, those are the packages for the KDE 3 games not yet ported to KDE 4) for me if the KDE folks don't get at it first. :-) Kevin Kofler From peter at thecodergeek.com Thu Jul 26 09:24:06 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 26 Jul 2007 02:24:06 -0700 Subject: .noarch <-> .i386/.x86_64/.ppc change In-Reply-To: <20070726105321.d9a2d3e0.mschwendt.tmp0701.nospam@arcor.de> References: <20070726105321.d9a2d3e0.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1185441846.14828.15.camel@tuxhugs> On Thu, 2007-07-26 at 10:53 +0200, Michael Schwendt wrote: > There's another package in FE6 doing a jump from .noarch to > .i386/.x86_64/.ppc -- I can't find the notes on when this can cause > problems. Searching the Wiki has been fruitless, too. Where is this > documented? AFAIK it doesn't cause trouble. Deluge went from noarch (0.4.x) to arch-specific (0.5.x) in February, due to a change in how rb_libtorrent was used internally; and I've heard of no bugs or troubles from it. Just make sure that your EVR of the arch-specific package is higher than that of the noarch one and you should be okay. Hope that helps. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roland at redhat.com Thu Jul 26 09:34:45 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 26 Jul 2007 02:34:45 -0700 (PDT) Subject: .noarch <-> .i386/.x86_64/.ppc change In-Reply-To: Peter Gordon's message of Thursday, 26 July 2007 02:24:06 -0700 <1185441846.14828.15.camel@tuxhugs> Message-ID: <20070726093445.575C24D058D@magilla.localdomain> I believe it's the inverse transition that was a real problem in the past. From Christian.Iseli at licr.org Thu Jul 26 09:36:03 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 26 Jul 2007 11:36:03 +0200 Subject: unfiled merge reviews In-Reply-To: <46A03E73.2090906@redhat.com> References: <469C540C.2020005@redhat.com> <46A03E73.2090906@redhat.com> Message-ID: <20070726113603.01f2f1c6@ludwig-alpha.unil.ch> On Fri, 20 Jul 2007 14:47:47 +1000, Jens Petersen wrote: > (Some old reviews exist for m17n-db (#169919), m17n-lib (#169922), and > libchewing (#166472), but this is also true of scim-m17n and > scim-chewing though they have new merge reviews too.) If they had a review that's fine. No need for a re-review at this point. C From Christian.Iseli at licr.org Thu Jul 26 09:40:27 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 26 Jul 2007 11:40:27 +0200 Subject: Fedora Package Status of Jul 12, 2007 In-Reply-To: <20070717175344.GA26489@hurricane.linuxnetz.de> References: <20070713002414.660f1ccb@ludwig-alpha.unil.ch> <20070717175344.GA26489@hurricane.linuxnetz.de> Message-ID: <20070726114027.6daaec17@ludwig-alpha.unil.ch> On Tue, 17 Jul 2007 19:53:44 +0200, Robert Scheck wrote: > please note, that this package got obsoleted in Fedora 7 by uw-imap - > right, Joe? Then please follow http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife Thanks, C From atkac at redhat.com Thu Jul 26 10:10:19 2007 From: atkac at redhat.com (Adam Tkac) Date: Thu, 26 Jul 2007 12:10:19 +0200 Subject: Package rebuilds for binutils/gcc bug In-Reply-To: <6e24a8e80707251554y7249f5c8kbaa20f9141d1c57a@mail.gmail.com> References: <20070725130054.10bb7f37@localhost.localdomain> <20070725171525.GF3673@serv.smile.org.ua> <20070725132332.3c692c7c@localhost.localdomain> <6e24a8e80707251554y7249f5c8kbaa20f9141d1c57a@mail.gmail.com> Message-ID: <46A8730B.4090401@redhat.com> Mark napsal(a): > is: "kernel-xen-2.6" still needed in Fedora 8? > Kernel 2.6.23 (rc1) has xen build in (jguest as well). Interesting. Does anybody know if standard non-xen kernel will work with xen + libvirt + virt-manager (on machine with hardware virtualization)? I wasn't successful :( Adam From hellwolf.misty at gmail.com Thu Jul 26 10:59:42 2007 From: hellwolf.misty at gmail.com (ZC Miao) Date: Thu, 26 Jul 2007 18:59:42 +0800 Subject: GDM BUG : Do a User switching without correct password Message-ID: <1185447582.32162.1.camel@cocteau.freehell.org> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249653 -- http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F Necessity has no law. -- St. Augustine From buildsys at redhat.com Thu Jul 26 11:13:04 2007 From: buildsys at redhat.com (Build System) Date: Thu, 26 Jul 2007 07:13:04 -0400 Subject: rawhide report: 20070726 changes Message-ID: <200707261113.l6QBD4de004514@porkchop.devel.redhat.com> Updated Packages: adminutil-1.1.3-1.fc8.1 ----------------------- * Wed Jul 25 2007 Warren Togami - 1.1.3-1.1 - binutils/gcc bug rebuild (#249435) alienblaster-1.1.0-2.fc8 ------------------------ alsa-oss-1.0.14-2.fc8 --------------------- * Wed Jul 25 2007 Warren Togami 1.0.14-2 - binutils/gcc bug rebuild (#249435) bacula-2.0.3-9.fc8 ------------------ * Wed Jul 25 2007 Andreas Thienemann 2.0.3-9 - Corrected the %post alternatives calls. Fixing #249560. bind-32:9.5.0-7.a6.fc8 ---------------------- * Wed Jul 25 2007 Warren Togami 32:9.5.0-7.a6 - binutils/gcc bug rebuild (#249435) * Tue Jul 24 2007 Adam Tkac 32:9.5.0-6.a6 - updated to 9.5.0a6 which contains fixes for CVE-2007-2925 and CVE-2007-2926 - fixed building on 64bits * Mon Jul 23 2007 Adam Tkac 31:9.5.0a5-5 - integrated "autotools" patch for testing purposes (upstream will accept it in future, for easier building) binutils-2.17.50.0.17-6 ----------------------- * Wed Jul 25 2007 Jakub Jelinek 2.17.50.0.17-6 - rebuilt to make sure even libbfd.so and libopcodes.so aren't broken by #249435 * Tue Jul 24 2007 Jakub Jelinek 2.17.50.0.17-5 - add .note.gnu.build-id into default linker script (#249435) * Tue Jul 24 2007 Jakub Jelinek 2.17.50.0.17-4 - don't kill the %{_gnu} part of target name on arm (Lennert Buytenhek, #243516) - create just one PT_NOTE segment header for all consecutive SHT_NOTE sections cone-0.71-2.fc8 --------------- * Wed Jul 25 2007 Jesse Keating - 0.71-2 - Rebuild for RH #249435 * Tue Jul 24 2007 Steven Pritchard 0.71-1 - Update to 0.71. * Mon Apr 09 2007 Steven Pritchard 0.69-1 - Update to 0.69. control-center-1:2.19.5-4.fc8 ----------------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-4 - Rebuild for RH #249435 emacs-vm-8.0.2.482-2.fc8 ------------------------ * Wed Jul 25 2007 Jesse Keating - 8.0.2.482-2 - Rebuild for RH #249435 epiphany-2.19.5-4.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-4 - Rebuild for RH #249435 * Mon Jul 23 2007 Matthias Clasen - 2.19.5-3 - Port to new GTK+ tooltips API * Fri Jul 20 2007 Kai Engert - 2.19.5-2 - Rebuild against newer gecko gdb-6.6-22.fc8 -------------- * Wed Jul 25 2007 Jesse Keating - 6.6-22 - Rebuild for RH #249435 gmime-2.2.10-2.fc8 ------------------ * Wed Jul 25 2007 Jesse Keating - 2.2.10-2 - Rebuild for RH #249435 gnome-panel-2.19.5-4.fc8 ------------------------ * Wed Jul 25 2007 Jesse Keating - 2.19.5-4 - Rebuild for RH #249435 gpm-1.20.1-88.fc8 ----------------- * Wed Jul 25 2007 Jesse Keating - 1.20.1-88 - Rebuild for RH #249435 gtk2-2.11.6-3.fc8 ----------------- * Wed Jul 25 2007 Matthias Clasen - 2.11.6-3 - Fix the behaviour of tooltips on system tray icons * Tue Jul 24 2007 Matthias Clasen - 2.11.6-2 - Silence the icon cache validator (#248789) * Mon Jul 23 2007 Matthias Clasen - 2.11.6-1 - Update to 2.11.6 - Make it build against recent cups hardinfo-0.4.2.2-3.fc8 ---------------------- kmymoney2-0.8.7-2.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 0.8.7-2 - Rebuild for RH #249435 ktorrent-2.2.1-2.fc8 -------------------- * Wed Jul 25 2007 Jesse Keating - 2.2.1-2 - Rebuild for RH #249435 libXcomposite-0.4.0-2.fc8 ------------------------- * Wed Jul 25 2007 Jesse Keating - 0.4.0-2 - Rebuild for RH #249435 libgeotiff-1.2.4-0.4.rc1.fc8 ---------------------------- * Wed Jul 25 2007 Jesse Keating - 1.2.4-0.4.rc1 - Rebuild for RH #249435 libhangul-0.0.6-2.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 0.0.6-2 - Rebuild for RH #249435 libpcap-14:0.9.7-2.fc8 ---------------------- * Wed Jul 25 2007 Jesse Keating - 14:0.9.7-2 - Rebuild for RH #249435 libtimidity-0.1.0-2.fc8 ----------------------- libvirt-0.3.1-2.fc8 ------------------- * Wed Jul 25 2007 Jesse Keating - 0.3.1-2 - Rebuild for RH #249435 libwnck-2.19.5-3.fc8 -------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-3 - Rebuild for RH #249435 libxml++-2.18.1-2.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 2.18.1-2 - Rebuild for RH #249435 livecd-tools-010-1.fc8 ---------------------- * Wed Jul 25 2007 Jeremy Katz - 010-1 - Separate out configs used for Fedora 7 - Add patch from Douglas McClendon to make images smaller - Add patch from Matt Domsch to work with older syslinux without vesamenu - Add support for using mirrorlists; use them - Let livecd-iso-to-disk work with uncompressed images (#248081) - Raise error if SELinux requested without being enabled (#248080) - Set service defaults on level 2 also (#246350) - Catch some failure cases - Allow specifying tmpdir - Add patch from nameserver specification from Elias Hunt mcabber-0.9.3-3.fc8 ------------------- * Wed Jul 25 2007 Jesse Keating - 0.9.3-3 - Rebuild for RH #249435 mesa-6.5.2-16.fc8 ----------------- * Wed Jul 25 2007 Jesse Keating - 6.5.2-16 - Rebuild for RH #249435 metacity-2.19.34-2.fc8 ---------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.34-2 - Rebuild for RH #249435 nautilus-2.19.5-3.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-3 - Rebuild for RH #249435 * Mon Jul 23 2007 Matthias Clasen - 2.19.5-2 - Port to new GTK+ tooltips API * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 nss_compat_ossl-0.9.1-4.fc8 --------------------------- * Wed Jul 25 2007 Jesse Keating - 0.9.1-4 - Rebuild for RH #249435 ntp-4.2.4p2-3.fc8 ----------------- * Wed Jul 25 2007 Jesse Keating - 4.2.4p2-3 - Rebuild for RH #249435 pam-0.99.8.1-2.fc8 ------------------ * Wed Jul 25 2007 Jeremy Katz - 0.99.8.1-2 - rebuild for toolchain bug * Mon Jul 23 2007 Tomas Mraz 0.99.8.1-1 - upgrade to latest upstream version - add some firewire devices to default console perms (#240770) * Thu Apr 26 2007 Tomas Mraz 0.99.7.1-6 - pam_namespace: better document behavior on failure (#237249) - pam_unix: split out passwd change to a new helper binary (#236316) - pam_namespace: add support for temporary logons (#241226) perl-Authen-PAM-0.16-2.fc8 -------------------------- * Wed Jul 25 2007 Jeremy Katz - 0.16-2 - rebuild for toolchain bug perl-File-Sync-0.09-2.fc8 ------------------------- perl-Text-LevenshteinXS-0.03-2.fc8 ---------------------------------- php-eaccelerator-1:0.9.5.1-4.fc8 -------------------------------- * Wed Jul 25 2007 Jeremy Katz - 1:0.9.5.1-4 - rebuild for toolchain bug pixman-0.9.0-3.20070724.fc8 --------------------------- * Wed Jul 25 2007 Jeremy Katz - 0.9.0-3.20070724 - rebuild for toolchain bug policycoreutils-2.0.22-9.fc8 ---------------------------- * Wed Jul 25 2007 Jeremy Katz - 2.0.22-9 - rebuild for toolchain bug rsyslog-1.17.2-4.fc8 -------------------- * Wed Jul 25 2007 Jeremy Katz - 1.17.2-4 - rebuild for toolchain bug rusers-0.17-49 -------------- * Wed Jul 25 2007 Jeremy Katz - 0.17-49 - rebuild for toolchain bug sabayon-2.19.1-2.fc8 -------------------- * Wed Jul 25 2007 Jeremy Katz - 2.19.1-2 - rebuild for toolchain bug sane-backends-1.0.18-13.fc8 --------------------------- * Wed Jul 25 2007 Jeremy Katz - 1.0.18-13 - rebuild for toolchain bug schedtool-1.2.10-5.fc8 ---------------------- * Wed Jul 25 2007 Jeremy Katz - 1.2.10-5 - rebuild for toolchain bug spamassassin-3.2.2-1.fc8 ------------------------ * Wed Jul 25 2007 Warren Togami 3.2.2-1 - 3.2.2 minor bugfix release tcpdump-14:3.9.7-2.fc8 ---------------------- * Wed Jul 25 2007 Jeremy Katz - 14:3.9.7-2 - rebuild for toolchain bug tomboy-0.7.2-2.fc8 ------------------ * Wed Jul 25 2007 Jeremy Katz - 0.7.2-2 - rebuild for toolchain bug tracker-0.6.0-2.fc8.1 --------------------- * Wed Jul 25 2007 Jeremy Katz - 0.6.0-2.1 - rebuild for toolchain bug w3m-0.5.2-3.fc8 --------------- * Wed Jul 25 2007 Jeremy Katz - 0.5.2-3 - rebuild for toolchain bug * Tue Jul 24 2007 Parag Nemade - 0.5.2-2 - Build against new gc-7.0 release. * Tue Jun 26 2007 Parag Nemade - 0.5.2-1 - Update to 0.5.2 and remove merged patches. - Build against system gc library. - Add BR: nkf for multipart.cgi. - Don't call unneeded autotool wfmath-0.3.6-2.fc8 ------------------ * Wed Jul 25 2007 Jeremy Katz - 0.3.6-2 - rebuild for toolchain bug xawtv-3.95-5.fc8 ---------------- * Wed Jul 25 2007 Jeremy Katz - 3.95-5 - rebuild for toolchain bug xorg-x11-server-utils-7.2-5.fc8 ------------------------------- * Wed Jul 25 2007 Jeremy Katz - 7.2-5 - rebuild for toolchain bug xorg-x11-xkb-utils-7.2-2.fc8 ---------------------------- * Wed Jul 25 2007 Jeremy Katz - 7.2-2 - rebuild for toolchain bug yelp-2.18.1-7.fc8 ----------------- * Wed Jul 25 2007 Jeremy Katz - 2.18.1-7 - rebuild for toolchain bug ytalk-3.3.0-8.fc8 ----------------- * Wed Jul 25 2007 Jeremy Katz - 3.3.0-8 - rebuild for toolchain bug yum-3.2.2-3.fc8 --------------- * Wed Jul 25 2007 Seth Vidal 3.2.2-3 - include panu's rpm-signal-catch patch from yum head. - include exception fix, too. Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From jkeating at redhat.com Thu Jul 26 11:19:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 07:19:11 -0400 Subject: rawhide report: 20070726 changes In-Reply-To: <200707261113.l6QBD4de004514@porkchop.devel.redhat.com> References: <200707261113.l6QBD4de004514@porkchop.devel.redhat.com> Message-ID: <20070726071911.2c4b8a8a@ender> On Thu, 26 Jul 2007 07:13:04 -0400 Build System wrote: > Subject: rawhide report: 20070726 changes This rawhide push is broken. It's got way too much as multilib, may be missing repodata. I'm doing another rawhide compose which will hopefully fix it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bloch at verdurin.com Thu Jul 26 11:23:08 2007 From: bloch at verdurin.com (Adam Huffman) Date: Thu, 26 Jul 2007 12:23:08 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185414225.4305.9.camel@continuity> References: <1185408852.4305.6.camel@continuity> <20070726002117.GA32514@bloch.config> <1185414225.4305.9.camel@continuity> Message-ID: <20070726112307.GA32213@bloch.config> On Wed, 25 Jul 2007, Thomas J. Baker wrote: > On Thu, 2007-07-26 at 01:21 +0100, Adam Huffman wrote: > > On Wed, 25 Jul 2007, Thomas J. Baker wrote: > > > > > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > > > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > > > works perfectly, suspend has one quirk. On resume the screen is quite > > > dim and the level can't be changed. Is this a kernel bug or a g-power-m > > > one? > > > > > > > I have exactly the same problem on a Vaio SZ3 - I reported it as a > > kernel bug. > > > > Adam > > > > Thanks. Do you have the bug number? I searched bugzilla but couldn't > find it. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249482 From bloch at verdurin.com Thu Jul 26 11:24:17 2007 From: bloch at verdurin.com (Adam Huffman) Date: Thu, 26 Jul 2007 12:24:17 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185417095.4088.9.camel@localhost.localdomain> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> Message-ID: <20070726112417.GB32213@bloch.config> On Wed, 25 Jul 2007, Jeremy Katz wrote: > On Wed, 2007-07-25 at 20:14 -0400, Thomas J. Baker wrote: > > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > > works perfectly, suspend has one quirk. On resume the screen is quite > > dim and the level can't be changed. Is this a kernel bug or a g-power-m > > one? > > Try using any brightness keys that you have to change down and then up. > If that works, then it probably needs the reset-brightness-quirk (which > we really need to build a new pm-utils, etc so that it can be taken > advantage of) > None of the special Fn-key combinations work for me, even when the sony_laptop module is manually loaded. Adam From hughsient at gmail.com Thu Jul 26 11:24:39 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 26 Jul 2007 12:24:39 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <20070726112417.GB32213@bloch.config> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> <20070726112417.GB32213@bloch.config> Message-ID: <1185449079.3041.0.camel@work> On Thu, 2007-07-26 at 12:24 +0100, Adam Huffman wrote: > > None of the special Fn-key combinations work for me, even when the > sony_laptop module is manually loaded. If you suspend, resume, rmmod sony-laptop, modprobe sony-laptop - does that work? If so we'll have to add a resume hook somewhere in the driver. Richard. From pnasrat at redhat.com Thu Jul 26 11:29:51 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 26 Jul 2007 12:29:51 +0100 Subject: rawhide report: 20070726 changes In-Reply-To: <20070726071911.2c4b8a8a@ender> References: <200707261113.l6QBD4de004514@porkchop.devel.redhat.com> <20070726071911.2c4b8a8a@ender> Message-ID: <1185449392.28483.13.camel@enki.eridu> On Thu, 2007-07-26 at 07:19 -0400, Jesse Keating wrote: > On Thu, 26 Jul 2007 07:13:04 -0400 > Build System wrote: > > > Subject: rawhide report: 20070726 changes > > This rawhide push is broken. It's got way too much as multilib, may be > missing repodata. I'm doing another rawhide compose which will > hopefully fix it. Anyway to automate testing for this kind of breakage before push? Paul From jkeating at redhat.com Thu Jul 26 11:57:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 07:57:46 -0400 Subject: rawhide report: 20070726 changes In-Reply-To: <1185449392.28483.13.camel@enki.eridu> References: <200707261113.l6QBD4de004514@porkchop.devel.redhat.com> <20070726071911.2c4b8a8a@ender> <1185449392.28483.13.camel@enki.eridu> Message-ID: <20070726075746.61735e62@ender> On Thu, 26 Jul 2007 12:29:51 +0100 Paul Nasrat wrote: > Anyway to automate testing for this kind of breakage before push? That's going to be on the rel-eng schedule after test1 is all wrapped up, better catching of error codes and aborting. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From panemade at gmail.com Thu Jul 26 12:27:57 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Thu, 26 Jul 2007 17:57:57 +0530 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A853E7.3030303@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: Hi, On 7/26/07, Hans de Goede wrote: > Brian Pepple wrote: > > Hi, > > > > Please find below the list of topics that are likely to come up in the > > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > > in #fedora-meeting on irc.freenode.org: > > > > /topic FESCO-Meeting -- MISC -- elect FESCo Chair - all > > > > /topic FESCO-Meeting -- MISC -- Feature Proposal Approval - > > http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat > > > > /topic FESCO-Meeting -- Rebuilding Packages -- Needs to decide whether > > to always rebuild, or only when toolchain warrants it - all > > > > /topic FESCo meeting -- Free discussion around Fedora > > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > > > If your name/nick is on above list please update the status on the > > Extras schedule pages in the wiki ahead of the meeting. That way all the > > other FESCo members and interested contributors know what up ahead of > > the meeting. And we will avoid long delays in the meeting -- those often > > arise if someone describes the recent happenings on a topic directly in > > the meeting while all the others have to wait for his slow typing... > > > > > I've got a somewhat strange question for FESco to look at, I would like to have > an exception to the rule that all packages must be reviewed for the following > set of packages: > > * arm-gp2x-linux-binutils > Cross Compiling GNU binutils targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234749 > > * arm-gp2x-linux-kernel-headers > Kernel headers for Cross Compiling to arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242203 > > * arm-gp2x-linux-gcc > Cross Compiling GNU GCC targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242206 > > * arm-gp2x-linux-glibc > Cross Compiled GNU C Library targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242207 > > * arm-gp2x-linux-SDL > Cross Compiled SDL Library targeted at arm-gp2x-linux > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243147 > > * arm-gp2x-linux-zlib > Cross Compiled zlib Library targeted at avr > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243254 > > > I've been trying to find a reviewer for them for ages, but there seems to be > no-one with both the expertise and the time to review them. You all know that > I'm a very serious packager, and that I have near 0 bugs open against my 135+ > packages, so I hope that you will trust me to deliver good quality even without > a review. > > --- > > Another issue I would like FESco to look at is the current somewhat grey state > of kmod's I'm considering packaging kmod's for uvc (usb video class driver), > lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in > rawhide). But before I invest time in these I would first like to have the > state of kmod's cleared up. I will try to work with there resp. upstreams to > get them in the upstream kernel, and atleast for uvc and islsm upstream merger > is planned already. Just FYI, kmod's got always low priority from FESCO. The usual answer for kmods reviews are "why not kmod is added in upstream kernel yet?" I struggled a lot to get first spca5xx kmod in Fedora but failed as no one dare to review it. Then after it got considered as unsuccessful attempt, I tried on submitting gspca kmod. After much struggle I got KMOD_APPROVED on gspca-kmod package review. But then no one dare to review it even after I showed my willingness to maintain it for each kernel release in rawhide and with such unfortunate happened things, I decided to CLOSE my own package reviews for gspca kmod. I feel really bad for that. I am sure many peoples like to have some of the under development kmods in Fedora. I often used to get request from peoples about what happened to webcam kmods like gspca I tried to add in Fedora. Today also I got query for available webcam drivers in Fedora and RHEL, but unfortunately people now need to compromise on webcams for available webcam kmods in kernel. There are few webcam kmods which are, though under development but working well and their upstream is prompt to release updates for newer kernels. These kmods supports most of new webcams. But still we are not having those kmods approved in Fedora atleast. Regards, Parag. From billcrawford1970 at gmail.com Thu Jul 26 12:32:33 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 26 Jul 2007 13:32:33 +0100 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070723112548.49ffaae0@localhost.localdomain> References: <20070720153840.GQ22182@psilocybe.teonanacatl.org> <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> Message-ID: <544eb990707260532l3cab4bebxfc0fa7d4991dd68e@mail.gmail.com> On 23/07/07, Jesse Keating wrote: As stated before, perhaps what is needed is the tools such as > gnome-menu or whatever xfce uses ignore the ShowOnlyIn argument and > display them all anyway. > > I seem to remember many years ago, having a "KDE menu" top level show up in the GNOME menu. Could we not arrange for something like this (and likewise a "GNOME" toplevel entry in the KDE menu) so that those who know what they want can go look in there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laroche at redhat.com Thu Jul 26 12:31:53 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 26 Jul 2007 14:31:53 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: <20070726123153.GA7446@dudweiler.stuttgart.redhat.com> > Just FYI, kmod's got always low priority from FESCO. The usual > answer for kmods reviews are "why not kmod is added in upstream kernel > yet?" > I struggled a lot to get first spca5xx kmod in Fedora but failed as > no one dare to review it. Then after it got considered as unsuccessful > attempt, I tried on submitting gspca kmod. After much struggle I got > KMOD_APPROVED on gspca-kmod package review. But then no one dare to > review it even after I showed my willingness to maintain it for each > kernel release in rawhide and with such unfortunate happened things, I > decided to CLOSE my own package reviews for gspca kmod. > I feel really bad for that. I am sure many peoples like to have some > of the under development kmods in Fedora. I often used to get request > from peoples about what happened to webcam kmods like gspca I tried to > add in Fedora. > Today also I got query for available webcam drivers in Fedora and > RHEL, but unfortunately people now need to compromise on webcams for > available webcam kmods in kernel. There are few webcam kmods which > are, though under development but working well and their upstream is > prompt to release updates for newer kernels. These kmods supports most > of new webcams. > But still we are not having those kmods approved in Fedora atleast. Is this in need to be reviewed by the board or more waiting for a package review? I'd love to see gspca upstream, but also a kmod rpm would be superb. Also while kmods have many problems, I think we'll continue to see use cases for them, so getting through the pain of maintaining them does build up useful infrastructure. Last time I checked, building kmod rpms needed too many additional requirements, so I decided to stay at "make; make install" for each new kernel for my own machine. regards, Florian La Roche From j.w.r.degoede at hhs.nl Thu Jul 26 12:36:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 14:36:27 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: <46A8954B.6060907@hhs.nl> Kevin Kofler wrote: > Wow, still no reviewer for arm-gp2x-linux-*? I'll bite the bullet and review > these if you promise you'll do the same for my tigcc cross-toolchain once I > submit it (should be in a few weeks, I need to spin a tarball without the > optional non-Free A68k assembler). (TIGCC is just one package, so you'll get > away with less work than me in the deal. ;-) ) > > Oh, and in exchange you can also review kdegames3 and atlantikdesigner (part of > the KDE 4 plan, those are the packages for the KDE 3 games not yet ported to > KDE 4) for me if the KDE folks don't get at it first. :-) > Deal! Can you mail me the BZ links for those 2 kde packages please? Regards, Hans From billcrawford1970 at gmail.com Thu Jul 26 12:41:03 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 26 Jul 2007 13:41:03 +0100 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: References: <3adc77210707210704m37c4930cq9a46be57723eac8a@mail.gmail.com> <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> Message-ID: <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> On 23/07/07, Christopher Stone wrote: > > I seem to recall back in the middle ages, that when in Gnome, there > > was a main Menu entry called KDE, which brought a submenu up showing > > the menu of KDE apps you would see in KDE. And vice versa. I think > > this would be a nice thing to have, and might represent a happy medium > > for all sides of this argument. > > There is a gnome-menus which can be used on the KDE side, but I don't > know if there is a kde-menus for GNOME. I think this would be > perfectly acceptable provided these packages actually have the ability > to override the OnlyShowIn directive. > Ah. My apologies for the (now obsolete) message earlier :) I too remember the middle ages ;) I found the package "kmenu-gnome" lurking in the package manager, ... seems to work, although it only shows two items (grip and "Configuration Editor" :)) Thanks for the pointer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From panemade at gmail.com Thu Jul 26 12:43:08 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Thu, 26 Jul 2007 18:13:08 +0530 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <20070726123153.GA7446@dudweiler.stuttgart.redhat.com> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <20070726123153.GA7446@dudweiler.stuttgart.redhat.com> Message-ID: Hi, On 7/26/07, Florian La Roche wrote: > > Just FYI, kmod's got always low priority from FESCO. The usual > > answer for kmods reviews are "why not kmod is added in upstream kernel > > yet?" > > I struggled a lot to get first spca5xx kmod in Fedora but failed as > > no one dare to review it. Then after it got considered as unsuccessful > > attempt, I tried on submitting gspca kmod. After much struggle I got > > KMOD_APPROVED on gspca-kmod package review. But then no one dare to > > review it even after I showed my willingness to maintain it for each > > kernel release in rawhide and with such unfortunate happened things, I > > decided to CLOSE my own package reviews for gspca kmod. > > I feel really bad for that. I am sure many peoples like to have some > > of the under development kmods in Fedora. I often used to get request > > from peoples about what happened to webcam kmods like gspca I tried to > > add in Fedora. > > Today also I got query for available webcam drivers in Fedora and > > RHEL, but unfortunately people now need to compromise on webcams for > > available webcam kmods in kernel. There are few webcam kmods which > > are, though under development but working well and their upstream is > > prompt to release updates for newer kernels. These kmods supports most > > of new webcams. > > But still we are not having those kmods approved in Fedora atleast. > > > Is this in need to be reviewed by the board or more waiting for > a package review? I'd love to see gspca upstream, but also > a kmod rpm would be superb. Feel free to resubmit gspca kmod packages. I am no longer interested to submit in Fedora. I tried to submit gspca kmod which I really meant to submit gspcav2 kmod. later on upstream forked tarball to gspcav1. So if you want my old packaged gspcav2 rpms, download if from http://people.redhat.com/pnemade/Deffered/gspca/ These contains gspcav2 kmod. > > Also while kmods have many problems, I think we'll continue to see > use cases for them, so getting through the pain of maintaining them > does build up useful infrastructure. > > Last time I checked, building kmod rpms needed too many additional > requirements, so I decided to stay at "make; make install" for each > new kernel for my own machine. > regards, Parag. From tjb at unh.edu Thu Jul 26 12:50:10 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 26 Jul 2007 08:50:10 -0400 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185417095.4088.9.camel@localhost.localdomain> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> Message-ID: <1185454210.6208.4.camel@raptor.sr.unh.edu> On Wed, 2007-07-25 at 22:31 -0400, Jeremy Katz wrote: > On Wed, 2007-07-25 at 20:14 -0400, Thomas J. Baker wrote: > > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > > works perfectly, suspend has one quirk. On resume the screen is quite > > dim and the level can't be changed. Is this a kernel bug or a g-power-m > > one? > > Try using any brightness keys that you have to change down and then up. > If that works, then it probably needs the reset-brightness-quirk (which > we really need to build a new pm-utils, etc so that it can be taken > advantage of) > > Jeremy > The hardware keys don't work after the resume. They work fine before the suspend. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From j.w.r.degoede at hhs.nl Thu Jul 26 12:52:46 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 14:52:46 +0200 Subject: Abuse of Fedora trademark Message-ID: <46A8991E.3050306@hhs.nl> Hi All, I was reading todays lwn and found this article: http://lwn.net/Articles/242830/ About this piece of software: http://www.kde-apps.org/content/show.php?content=62829 Which is a utility to ease the install of certain software on Fedora. As you all know I've suggested the inclusion of such a utility into Fedora, and thus I have nothing against the idea in general, nor to call something like this easyfedora, as its called. But this software is released under a proprietary license (according to the webpage). To me the use of the Fedora Trademark in combination with a proprietary license is not acceptable and a clear violation of the Fedora trademark policies. Can those who have the power please kindly request this person to cease and desist. Thanks & Regards, Hans From oliver at linux-kernel.at Thu Jul 26 13:03:29 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 26 Jul 2007 15:03:29 +0200 Subject: Abuse of Fedora trademark In-Reply-To: <46A8991E.3050306@hhs.nl> References: <46A8991E.3050306@hhs.nl> Message-ID: <46A89BA1.2020600@linux-kernel.at> On 07/26/2007 02:52 PM, Hans de Goede wrote: > I was reading todays lwn and found this article: > http://lwn.net/Articles/242830/ > > About this piece of software: > http://www.kde-apps.org/content/show.php?content=62829 > > Which is a utility to ease the install of certain software on Fedora. As > you all know I've suggested the inclusion of such a utility into Fedora, > and thus I have nothing against the idea in general, nor to call > something like this easyfedora, as its called. But this software is > released under a proprietary license (according to the webpage). To me > the use of the Fedora Trademark in combination with a proprietary > license is not acceptable and a clear violation of the Fedora trademark > policies. Can those who have the power please kindly request this person > to cease and desist. Copy that! -of From Christian.Iseli at licr.org Thu Jul 26 13:12:16 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 26 Jul 2007 15:12:16 +0200 Subject: Fedora Package Status of Jul 26, 2007 Message-ID: <20070726151216.24876949@ludwig-alpha.unil.ch> Hi folks, Open bugs slightly down, but number of new review tickets climbed a bit again... Cheers, Christian ---- Fedora Package Status of Jul 26, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4783 packages - 7895 binary rpms in devel - 109 orphans - 58 packages not available in devel or release Axel dot Thimm at ATrpms dot net vtkdata andreas dot bierfert at lowlatency dot de libopensync-plugin-synce andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue bdpepple at ameritech dot net galago-filesystem bdpepple at ameritech dot net gaim-galago cgoorah at yahoo dot com dot au netgen cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu gaim-gaym dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask devrim at commandprompt dot com postgresql-pgpool-ha foolish at guezz dot net perl-SQLite-Simple gauret at free dot fr pdftohtml gilboad at gmail dot com kdebluetooth green at redhat dot com ws-common-utils j dot w dot r dot degoede at hhs dot nl cdogs-data j dot w dot r dot degoede at hhs dot nl cdogs-sdl jafo at tummy dot com python-mechanoid jafo at tummy dot com python-memcached jmp at safe dot ca clement johnp at redhat dot com GConf2-dbus jorton at redhat dot com libc-client mastahnke at gmail dot com epel-release mchristi at redhat dot com scsi-target-utils mike at flyn dot org linkchecker mpg at redhat dot com olpc-hardware-manager mpg at redhat dot com sugar mpg at redhat dot com sugar-presence-service mpg at redhat dot com xulrunner mpg at redhat dot com sugar-artwork mpg at redhat dot com sugar-datastore mpg at redhat dot com hulahop mpg at redhat dot com xapian-core mpg at redhat dot com pyxapian mpg at redhat dot com xapian-bindings orion at cora dot nwra dot com R-multcomp orion at cora dot nwra dot com R-systemfit paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman qspencer at ieee dot org suitesparse rdieter at math dot unl dot edu pykdeextensions richard at hughsie dot com ohm rjones at redhat dot com ocaml-ssl rjones at redhat dot com ocaml-ulex rvokal at redhat dot com gaim-guifications splinux at fedoraproject dot org drapes steve at silug dot org perl-Params-CallbackRequest steve at silug dot org perl-Term-ReadPassword sundaram at redhat dot com olpc-utils than at redhat dot com kdepimlibs than at redhat dot com kdelibs3 vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp xgl-maint at redhat dot com xorg-x11-drv-vermilion yufanyufan at gmail dot com audacious-plugins-docklet - 5 packages not available in devel but present in release andreas dot bierfert at lowlatency dot de syncekonnector caolanm at redhat dot com hunspell-he jorton at redhat dot com newt-perl twaugh at redhat dot com desktop-printing wolfy at nobugconsulting dot ro qfaxreader - 7 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=222191,231861,240616 eclipse bkonrath at redhat.com cyrus-imapd tjanouse at redhat.com pixman ajackson at redhat.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221717,224458,245649,247930 agg caolanm at redhat.com libsilc wtogami at redhat.com gnome-password-generator debarshi.ray at gmail.com linkchecker mike at flyn.org - 5 packages present in the development repo which have no owners entry audacious-docklet s390utils stardict-dic ufsparse ws-commons-util - 21 orphaned packages, yet available in devel docbook-dtds docbook-simple docbook-slides docbook-style-dsssl docbook-style-xsl docbook-utils driftnet empathy gnome-bluetooth gob2 libbtctl libedit linuxdoc-tools luks-tools ndesk-dbus openjade opensp pam_usb udftools xmltex xmlto FE-ACCEPT packages stats: - 2913 accepted, closed package reviews - 44 accepted, closed package reviews not in repo - 7 accepted, closed package reviews not in owners - 102 accepted, open package reviews older than 4 weeks; - 97 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 219 open tickets - 79 tickets with no activity in eight weeks - 53 tickets with no activity in four weeks - 14 closed tickets FE-NEW packages stats: - 919 open tickets - 710 tickets with no activity in eight weeks - 57 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 36 open tickets - 2 tickets with no activity in eight weeks - 6 tickets with no activity in four weeks FE-LEGAL 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: - 8517 open tickets - 5323 tickets with no activity in eight weeks - 1268 tickets with no activity in four weeks CVS stats: - 4779 packages with a devel directory - 1 packages with no owners entry tdma - 208 packages were dropped from Fedora Maintainers stats: - 406 maintainers - 2 inactive maintainers with open bugs - 3 inactive maintainers Dropped Fedora packages: - 13 packages were dropped since Fedora 7 Comps.xml files stats: - 2412 packages in comps-f8 file - 1054 packages missing from comps-f8 file - 25 packages in comps-f8 but not in repo - 2389 packages in comps-f7 file - 1028 packages missing from comps-f7 file - 33 packages in comps-f7 but not in repo From drago01 at gmail.com Thu Jul 26 13:12:46 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 26 Jul 2007 15:12:46 +0200 Subject: Abuse of Fedora trademark In-Reply-To: <46A8991E.3050306@hhs.nl> References: <46A8991E.3050306@hhs.nl> Message-ID: <46A89DCE.5020601@gmail.com> Hans de Goede wrote: > To me the use of the Fedora Trademark in combination with a > proprietary license is not acceptable and a clear violation of the > Fedora trademark policies. > +1 From j.w.r.degoede at hhs.nl Thu Jul 26 13:20:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 15:20:44 +0200 Subject: Fedora Package Status of Jul 26, 2007 In-Reply-To: <20070726151216.24876949@ludwig-alpha.unil.ch> References: <20070726151216.24876949@ludwig-alpha.unil.ch> Message-ID: <46A89FAC.8060708@hhs.nl> Christian Iseli wrote: > Hi folks, > > Open bugs slightly down Thats excellent news! As already said on my blog, I would very much like to take this number down even further. So if you want me to help out with a package of yours, which has open bugs which should be fixable by someone with good coding / debugging skill, while not requiring a total guru, add me to the acl and let me know you need help and I'll start squashing those bugs. Packages I've given the bug squasing treatment sofar: lm_sensors, 1 left open, 7 closed. gnome-games, 1 left open, 6 closed. So who wants to see similar results for his or her package? Regards, Hans From j.w.r.degoede at hhs.nl Thu Jul 26 13:54:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 15:54:06 +0200 Subject: rawhide report: 20070725 changes In-Reply-To: <1185377404.11828.25.camel@localhost.localdomain> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> <1185373421.11828.12.camel@localhost.localdomain> <46A75EA6.7010804@hhs.nl> <1185377404.11828.25.camel@localhost.localdomain> Message-ID: <46A8A77E.1090209@hhs.nl> Jeremy Katz wrote: > On Wed, 2007-07-25 at 16:31 +0200, Hans de Goede wrote: >> Jeremy Katz wrote: >>> On Wed, 2007-07-25 at 03:33 -0400, Build System wrote: >>>> New package yum-updatesd >>>> Update notification daemon >>> FYI -- this is a new and reworked yum-updatesd that should hopefully >>> help with some of the complaints that I have been had. The *big* change >>> is that it's bit split into two pieces: >>> * The actual daemon. This is small, listens to dbus, and doesn't ever >>> touch the rpmdb, etc. Which should keep its memory footprint low. >>> * Helper process that's forked off to do actual update checks >>> (+downloads +installs if so configured). Helper isn't threaded, which >>> should avoid some of the problems that have been cropping up. >>> >>> People prodding and testing at this would be much appreciated; I'm >>> hoping to be able to push this to F7-updates at some point as well. >>> Bugs to bugzilla as usual >>> >> Does this also fix the issue where issuing any yum command wil fail while it is >> checking for updates? That is the no 1 reason for not to use yum-updatesd. > > While the actual update check is going on, yes, things won't work. But > that's just like if you run a yum command while another one is running. > The plus side is the thing holding the lock is a separate process that > dies and shouldn't just get hung up in thread-land > >> If it doesn't fix this, maybe the following is an idea: >> -modify yum to detect if its yum-updatesd which is locking the current yum >> "database" > > We could print out what the process holding the lock is easily enough I > guess if people think it would be a substantial help. > It would be a start, but see below. >> -if it is yum-updatesd send it a signal to stop doing whats its doing, on which >> it will finish its current operation, and then release the db. > > Can't really do this -- you can't just interrupt the metadata download > or package installation, etc. But the time period for which it should > have the lock held should be able to be much more constrained now and if > it gets stuck, should be far more debuggable > With installation I agree, but yum-updatesd installing packages is not the default. And the meta datadownload needs to be done one way or the other, so the time lost while waiting for updatesd todo this is later won again. >> -print: "waiting for yum-updatesdb to release the database" >> -poll the database lock 2 times a second or so >> -continue > > This could also be done, but I'm not convinced that it's better than > just dropping you back to a prompt. The difference is > # yum update > ... > Lock is held by yum-updatesd-helper. Spinning until released. Hit > ctrl-c to exit. > ... > ... > ... > Got it, carrying on > > vs > > # yum update > Lock is held by yum-updatesd-helper. > # (wait here, do other tasks, etc) > # yum update > There are 3 important differences: 1. Despite recent cleanups yum still isn't exactly instant, so usually I type "yum -y foo bar" and then switch away, only to find yum-updatesd was holding the lock when I look to see if yum is finished 2. There is no way to tell when yum-updatesd is finished so one still needs todo the polling manual, very anyoing. Or as I do just kill it and disable it in ntsysv (which AFAIK is not what we want). 3. I give various Linux labs, where students often need to install package foobar, because I try to make my labs excercises as real life as possible (debugging bugs in bugzilla for example) and thus not all needed packages are installed in advance. To you and me the difference is as you describe above, to them however its the difference between yum working as expect and remarks along the lines like: "Hans it isn't working" or "WTF does this error mean?", so to regular end users the difference is huge. Regards, Hans From kwizart at gmail.com Thu Jul 26 14:00:20 2007 From: kwizart at gmail.com (KH KH) Date: Thu, 26 Jul 2007 16:00:20 +0200 Subject: Abuse of Fedora trademark In-Reply-To: <46A89DCE.5020601@gmail.com> References: <46A8991E.3050306@hhs.nl> <46A89DCE.5020601@gmail.com> Message-ID: 2007/7/26, dragoran : > Hans de Goede wrote: > > To me the use of the Fedora Trademark in combination with a > > proprietary license is not acceptable and a clear violation of the > > Fedora trademark policies. > > > +1 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Hi This person was adviced in this thead (french) http://forums.fedora-fr.org/viewtopic.php?pid=180056 Quick sum-up, he was asked to release the code, anyway i don't think. This is the right way of doing (it is better to script - and some scripts exist with the same purpose). For those interested in it, and in my view, the mandatory thing will be to advices end-users and beginners and in each case, why this is not merged into Fedora... Not only to tick some boxes to have thing installed without to understand anythings and how to work with alternatives... Nicolas (kwizart) Ps: See works that have already done on the subject : http://www.brandonhutchinson.com/Fedora_Helper.html http://easylinux.info/wiki/Fedora_frog From jkeating at redhat.com Thu Jul 26 14:06:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 10:06:44 -0400 Subject: Abuse of Fedora trademark In-Reply-To: References: <46A8991E.3050306@hhs.nl> <46A89DCE.5020601@gmail.com> Message-ID: <20070726100644.45cdc4de@ender> On Thu, 26 Jul 2007 16:00:20 +0200 "KH KH" wrote: > This person was adviced in this thead (french) > http://forums.fedora-fr.org/viewtopic.php?pid=180056 > > Quick sum-up, he was asked to release the code, anyway i don't think. > This is the right way of doing (it is better to script - and some > scripts exist with the same purpose). Regardless if he opens the code, he doesn't have the right to use the Fedora logo/Trademark. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Thu Jul 26 14:18:23 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 26 Jul 2007 15:18:23 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185454210.6208.4.camel@raptor.sr.unh.edu> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> <1185454210.6208.4.camel@raptor.sr.unh.edu> Message-ID: <645d17210707260718n73171620oc21965f50e141f18@mail.gmail.com> On 26/07/07, Thomas J. Baker wrote: > On Wed, 2007-07-25 at 22:31 -0400, Jeremy Katz wrote: > > On Wed, 2007-07-25 at 20:14 -0400, Thomas J. Baker wrote: > > > The 2.6.22 kernel and associated iwlwifi upgrade has allowed me to start > > > using suspend and hibernate again on my Inspiron XPS M1210. Hibernate > > > works perfectly, suspend has one quirk. On resume the screen is quite > > > dim and the level can't be changed. Is this a kernel bug or a g-power-m > > > one? > > > > Try using any brightness keys that you have to change down and then up. > > If that works, then it probably needs the reset-brightness-quirk (which > > we really need to build a new pm-utils, etc so that it can be taken > > advantage of) > > > > Jeremy > > > > The hardware keys don't work after the resume. They work fine before the > suspend. > > Thanks, FWIW... "me too" on same hardware. Doing a ctrl-alt-F1 ctrl-alt-f7 remedies the situation, does it for you? However, doing that just now I noticed that the ttys had stopped working. hm. From hughsient at gmail.com Thu Jul 26 14:17:29 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 26 Jul 2007 15:17:29 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <645d17210707260718n73171620oc21965f50e141f18@mail.gmail.com> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> <1185454210.6208.4.camel@raptor.sr.unh.edu> <645d17210707260718n73171620oc21965f50e141f18@mail.gmail.com> Message-ID: <1185459449.2315.9.camel@work> On Thu, 2007-07-26 at 15:18 +0100, Jonathan Underwood wrote: > FWIW... "me too" on same hardware. Doing a ctrl-alt-F1 ctrl-alt-f7 > remedies the situation, does it for you? However, doing that just now > I noticed that the ttys had stopped working. hm. Can you try with the sony-laptop module here: http://people.freedesktop.org/~hughsient/temp/sony-laptop-git20070725.tar.gz Thanks, Richard. From bpepple at fedoraproject.org Thu Jul 26 14:48:39 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 26 Jul 2007 10:48:39 -0400 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A853E7.3030303@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: <1185461319.2801.7.camel@kennedy> On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: > I've been trying to find a reviewer for them for ages, but there seems to be > no-one with both the expertise and the time to review them. You all know that > I'm a very serious packager, and that I have near 0 bugs open against my 135+ > packages, so I hope that you will trust me to deliver good quality even without > a review. Since it looks like Kevin has volunteered to help out, I'll keep this of the schedule for now. > Another issue I would like FESco to look at is the current somewhat grey state > of kmod's I'm considering packaging kmod's for uvc (usb video class driver), > lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in > rawhide). But before I invest time in these I would first like to have the > state of kmod's cleared up. I will try to work with there resp. upstreams to > get them in the upstream kernel, and atleast for uvc and islsm upstream merger > is planned already. I'll go ahead and add this to today's schedule for you. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 dwmw2 at infradead.org Thu Jul 26 14:57:20 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 15:57:20 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A853E7.3030303@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> Message-ID: <1185461840.14697.464.camel@pmac.infradead.org> On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: > Another issue I would like FESco to look at is the current somewhat grey state > of kmod's I'm considering packaging kmod's for uvc (usb video class driver), > lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in > rawhide). But before I invest time in these I would first like to have the > state of kmod's cleared up. I will try to work with there resp. upstreams to > get them in the upstream kernel, and atleast for uvc and islsm upstream merger > is planned already. I would still like to see kmod packages entirely deprecated in Fedora. If you want to maintain that kernel code and ship it with the 'Fedora' brand on it, why don't we just give you commit access to the kernel package? We can trust you to limit yourself to just those areas, and we can trivially disable your patch(es) if it gets in the way of progress. We've done precisely that kind of thing before (including for bcm43xx before that got merged). There's just no need for separate packages. -- dwmw2 From jonathan.underwood at gmail.com Thu Jul 26 15:10:49 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 26 Jul 2007 16:10:49 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185459449.2315.9.camel@work> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> <1185454210.6208.4.camel@raptor.sr.unh.edu> <645d17210707260718n73171620oc21965f50e141f18@mail.gmail.com> <1185459449.2315.9.camel@work> Message-ID: <645d17210707260810x15441779r6115a4f7b0e7b32c@mail.gmail.com> On 26/07/07, Richard Hughes wrote: > On Thu, 2007-07-26 at 15:18 +0100, Jonathan Underwood wrote: > > FWIW... "me too" on same hardware. Doing a ctrl-alt-F1 ctrl-alt-f7 > > remedies the situation, does it for you? However, doing that just now > > I noticed that the ttys had stopped working. hm. > > Can you try with the sony-laptop module here: > http://people.freedesktop.org/~hughsient/temp/sony-laptop-git20070725.tar.gz Sorry - by same hardware, I meant the same as the OP - a Dell XPSM1210. From fedora at leemhuis.info Thu Jul 26 15:17:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 17:17:25 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185461840.14697.464.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> Message-ID: <46A8BB05.4080206@leemhuis.info> On 26.07.2007 16:57, David Woodhouse wrote: > On Thu, 2007-07-26 at 09:57 +0200, Hans de Goede wrote: >> Another issue I would like FESco to look at is the current somewhat grey state >> of kmod's I'm considering packaging kmod's for uvc (usb video class driver), >> lirc and islsm (prism54 softmac driver, which is in F-7, but no longer in >> rawhide). But before I invest time in these I would first like to have the >> state of kmod's cleared up. I will try to work with there resp. upstreams to >> get them in the upstream kernel, and atleast for uvc and islsm upstream merger >> is planned already. > > I would still like to see kmod packages entirely deprecated in Fedora. I would like to see kmod packages entirely deprecated in the Everything spin of Fedora 8and thus updates-proper as well), but at the same time would like us to open a official testing area in the scope of the fedora project with a special repo for kmods and its deps to easen testing of that code, help getting it ready for upstream merge and semi-easy access for users. > If you want to maintain that kernel code and ship it with the 'Fedora' > brand on it, why don't we just give you commit access to the kernel > package? We can trust you to limit yourself to just those areas, and we > can trivially disable your patch(es) if it gets in the way of progress. > > We've done precisely that kind of thing before (including for bcm43xx > before that got merged). There's just no need for separate packages. I tend to say that approach is fine for you, Hans and some other developers that are familiar with kernel-coding as those people have shown to be able to get code upstream and know how to work with upstream. But the code in question IMHO should show potential for a nearby upstream merge before it's being added. But users and packagers want some modules that do not head upstream in the near future -- let's take the lirc kernel-modules as example, where the lirc-upstream afaik is not actively working on getting the code into linus kernel. Nobody else is doing that either. I'd prefer to not have stuff like that in fedora's kernel rpm, as that could soon and in a major maintenance nightmare, which we all want to avoid afaics. CU knurd From kagesenshi.87 at gmail.com Thu Jul 26 15:24:01 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Thu, 26 Jul 2007 23:24:01 +0800 Subject: yum , https repo , and proxy : Yum fails .. Message-ID: is yum's https proxy support broken? or am I doing this wrong? in /etc/yum.conf , I've added this line proxy=http://160.0.234.1:8080 and when trying to yum from my https repo, I got "X-Squid-Error: ERR_UNSUP_REQ 0" from the proxy.. [kagesenshi at Hikari ~]$ sudo yum install python-twisted Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml: [Errno 14] HTTP Error 400: Server: squid/2.5.STABLE11 Mime-Version: 1.0 Date: Tue, 24 Jul 2007 15:17:50 GMT Content-Type: text/html Content-Length: 1137 Expires: Tue, 24 Jul 2007 15:17:50 GMT X-Squid-Error: ERR_UNSUP_REQ 0 X-Cache: MISS from Network-Box Proxy-Connection: close My yum & urlgrabber version: yum-3.2.1-1.fc7 python-urlgrabber-2.9.9-5.fc7 anybody can confirm whether this is a bug or not?? -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From yabraham2 at gmail.com Thu Jul 26 15:26:11 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Thu, 26 Jul 2007 11:26:11 -0400 Subject: F8t1: not able to use the whole screen Message-ID: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> I am using a 19" wide screen flat panel monitor, and after successfully installed Rawhide (F8T1) yesterday, I found that like about 10% of the screen on the left side is just black and unusable. I taught the screen just shifted to the right, but no. The resolution is set correctly (1400x900). /yonas From dwmw2 at infradead.org Thu Jul 26 15:26:25 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 16:26:25 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8BB05.4080206@leemhuis.info> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> Message-ID: <1185463585.14697.475.camel@pmac.infradead.org> On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > I tend to say that approach is fine for you, Hans and some other > developers that are familiar with kernel-coding as those people have > shown to be able to get code upstream and know how to work with > upstream. Yes, although I'd phrase it as "that approach is fine for anyone who we'd actually want maintaining kernel code with the 'Fedora' name on it". > But the code in question IMHO should show potential for a > nearby upstream merge before it's being added. Absolutely. > But users and packagers want some modules that do not head upstream in > the near future -- let's take the lirc kernel-modules as example, > where the lirc-upstream afaik is not actively working on getting the > code into linus kernel. Nobody else is doing that either. I'd prefer > to not have stuff like that in fedora's kernel rpm, as that could soon > and in a major maintenance nightmare, which we all want to avoid > afaics. It doesn't become any _less_ of a nightmare just because you ship it separately. If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all. -- dwmw2 From jkeating at redhat.com Thu Jul 26 15:35:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 11:35:42 -0400 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185463585.14697.475.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> Message-ID: <20070726113542.34b925ca@ender> On Thu, 26 Jul 2007 16:26:25 +0100 David Woodhouse wrote: > It doesn't become any _less_ of a nightmare just because you ship it > separately. If we don't want it Fedora's kernel RPM, then we don't > want it in Fedora at all. +10. Most the problems with external mods surround the headaches that rpm / yum has to go through to support them, and having them on the system when bugs occur. Regardless of where they live, we'll still have these pains so long as they're external to the kernel rpm. If they're in the kernel, then the only problem we have is carrying them forward and perhaps having them unloaded to dupe a problem, and marshaling bugs to the right people (but we do that anyway). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Jul 26 15:36:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 17:36:36 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185463585.14697.475.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> Message-ID: <46A8BF84.3060509@leemhuis.info> On 26.07.2007 17:26, David Woodhouse wrote: > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > [...] >> But users and packagers want some modules that do not head upstream in >> the near future -- let's take the lirc kernel-modules as example, >> where the lirc-upstream afaik is not actively working on getting the >> code into linus kernel. Nobody else is doing that either. I'd prefer >> to not have stuff like that in fedora's kernel rpm, as that could soon >> and in a major maintenance nightmare, which we all want to avoid >> afaics. > > It doesn't become any _less_ of a nightmare just because you ship it > separately. I'd even say the nightmare is a bit bigger. > If we don't want it Fedora's kernel RPM, then we don't want > it in Fedora at all. Users want it and we have people wanting to package and maintain those drivers. So let's give them a playing area with a big fat warning sign. That's IMHO way better to leave them out in the cold. Cu knurd From dwmw2 at infradead.org Thu Jul 26 15:40:48 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 16:40:48 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8BF84.3060509@leemhuis.info> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8BF84.3060509@leemhuis.info> Message-ID: <1185464448.14697.479.camel@pmac.infradead.org> On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: > On 26.07.2007 17:26, David Woodhouse wrote: > > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: > > [...] > >> But users and packagers want some modules that do not head upstream in > >> the near future -- let's take the lirc kernel-modules as example, > >> where the lirc-upstream afaik is not actively working on getting the > >> code into linus kernel. Nobody else is doing that either. I'd prefer > >> to not have stuff like that in fedora's kernel rpm, as that could soon > >> and in a major maintenance nightmare, which we all want to avoid > >> afaics. > > > > It doesn't become any _less_ of a nightmare just because you ship it > > separately. > > I'd even say the nightmare is a bit bigger. It's a lot bigger. > > If we don't want it Fedora's kernel RPM, then we don't want > > it in Fedora at all. > > Users want it and we have people wanting to package and maintain those > drivers. So let's give them a playing area with a big fat warning sign. > That's IMHO way better to leave them out in the cold. Users want ponies too. People can go and implement kmod stuff in their own repositories -- we _really_ don't want to be putting the 'Fedora' name on it. If it's good enough for Fedora, it's good enough for the kernel RPM. If not, let them do it elsewhere. -- dwmw2 From j.w.r.degoede at hhs.nl Thu Jul 26 15:48:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 17:48:57 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185463585.14697.475.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> Message-ID: <46A8C269.6060904@hhs.nl> David Woodhouse wrote: > On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: >> I tend to say that approach is fine for you, Hans and some other >> developers that are familiar with kernel-coding as those people have >> shown to be able to get code upstream and know how to work with >> upstream. > > Yes, although I'd phrase it as "that approach is fine for anyone who > we'd actually want maintaining kernel code with the 'Fedora' name on > it". > >> But the code in question IMHO should show potential for a >> nearby upstream merge before it's being added. > > Absolutely. > >> But users and packagers want some modules that do not head upstream in >> the near future -- let's take the lirc kernel-modules as example, >> where the lirc-upstream afaik is not actively working on getting the >> code into linus kernel. Nobody else is doing that either. I'd prefer >> to not have stuff like that in fedora's kernel rpm, as that could soon >> and in a major maintenance nightmare, which we all want to avoid >> afaics. > > It doesn't become any _less_ of a nightmare just because you ship it > separately. If we don't want it Fedora's kernel RPM, then we don't want > it in Fedora at all. > I must say I like this approach, it avoids the whole problem of having to rebuild kmods all the time and of wether to delay kernel security updates until all kmods are fixetd etc. I do think however that this might cause some pain for Dave Jones, whose job already is hard. Maybe we should ask him what he thinks about this? Regards, Hans From jkeating at redhat.com Thu Jul 26 15:59:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 11:59:12 -0400 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8C269.6060904@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> Message-ID: <20070726115912.3d690073@ender> On Thu, 26 Jul 2007 17:48:57 +0200 Hans de Goede wrote: > I must say I like this approach, it avoids the whole problem of > having to rebuild kmods all the time and of wether to delay kernel > security updates until all kmods are fixetd etc. I do think however > that this might cause some pain for Dave Jones, whose job already is > hard. Maybe we should ask him what he thinks about this? Well, if the module doesn't build fine with an update, most likely what's going to happen is the module gets disabled, which could result in even more frequent kernel updates just for getting a single module to build again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Thu Jul 26 15:42:41 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 26 Jul 2007 11:42:41 -0400 Subject: F8t1: not able to use the whole screen In-Reply-To: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> References: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> Message-ID: <1185464561.2794.155.camel@localhost.localdomain> On Thu, 2007-07-26 at 11:26 -0400, yonas Abraham wrote: > I am using a 19" wide screen flat panel monitor, and after > successfully installed Rawhide (F8T1) yesterday, I found that like > about 10% of the screen on the left side is just black and unusable. I > taught the screen just shifted to the right, but no. The resolution is > set correctly (1400x900). What hardware? - ajax From fedora at leemhuis.info Thu Jul 26 16:02:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 18:02:45 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185464448.14697.479.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8BF84.3060509@leemhuis.info> <1185464448.14697.479.camel@pmac.infradead.org> Message-ID: <46A8C5A5.6050303@leemhuis.info> On 26.07.2007 17:40, David Woodhouse wrote: > On Thu, 2007-07-26 at 17:36 +0200, Thorsten Leemhuis wrote: >> On 26.07.2007 17:26, David Woodhouse wrote: >>> On Thu, 2007-07-26 at 17:17 +0200, Thorsten Leemhuis wrote: >>> [...] > People can go and implement kmod stuff in their own repositories -- we > _really_ don't want to be putting the 'Fedora' name on it. > > If it's good enough for Fedora, it's good enough for the kernel RPM. > If not, let them do it elsewhere. I see your point, nevertheless I think we should have kmods (and other experimental stuff) in a special testing repo For me the whole thing is connected to current "target audience" discussion on FAB. Fedora is trying to do lots stuff right, even if it's bad for Fedora (firefox.x86_64 by default, no kmods that don't head upstream, ...). That actually something I why I like Fedora and that's why I agree with you in the "don't put the 'Fedora' name on it". Nevertheless a lot of users and maintainers often fail to understand our high standards. I'd like to give those users a solution and educate them while at it. And I want to get the maintainers involved in that testing ground as they might grow up and soon do other stuff in the project, which will help us growing. CU thl From debarshi.ray at gmail.com Thu Jul 26 16:13:18 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 26 Jul 2007 21:43:18 +0530 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: References: Message-ID: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> > is yum's https proxy support broken? or am I doing this wrong? > > in /etc/yum.conf , I've added this line > > proxy=http://160.0.234.1:8080 You need to put a slash at the end. Try: proxy=http://160.0.234.1:8080/ Otherwise you might like to consult: http://debarshiray.multiply.com/journal/item/30 Good luck, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From dwmw2 at infradead.org Thu Jul 26 16:43:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 17:43:33 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <20070726115912.3d690073@ender> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> <20070726115912.3d690073@ender> Message-ID: <1185468213.14697.488.camel@pmac.infradead.org> On Thu, 2007-07-26 at 11:59 -0400, Jesse Keating wrote: > On Thu, 26 Jul 2007 17:48:57 +0200 > Hans de Goede wrote: > > > I must say I like this approach, it avoids the whole problem of > > having to rebuild kmods all the time and of wether to delay kernel > > security updates until all kmods are fixetd etc. I do think however > > that this might cause some pain for Dave Jones, whose job already is > > hard. Maybe we should ask him what he thinks about this? > > Well, if the module doesn't build fine with an update, most likely > what's going to happen is the module gets disabled, which could result > in even more frequent kernel updates just for getting a single module > to build again. I assume you're thinking of updates, not rawhide. In rawhide, Dave or Chuck send you a mail saying "your $FOO patch broke; I turned it off". You fix it, and it appears again in rawhide in a day or two. In updates, such things are actually much less likely to break, except when we rebase to a newer kernel -- and if you've kept your driver working in rawhide then it should work fine when we rebase the release to the newer kernel anyway. Even if not, we tend to be quite conservative about releasing new kernels anyway -- they end up in updates-testing for some time, and that gives you time to get it working. The urgent security fixes are usually relatively small and unlikely to break drivers. It's not something that scales hugely, but we don't _want_ it to. We should be sticking close to upstream, and not shipping drivers which aren't getting merged. -- dwmw2 From j.w.r.degoede at hhs.nl Thu Jul 26 17:00:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 26 Jul 2007 19:00:52 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185468213.14697.488.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> <20070726115912.3d690073@ender> <1185468213.14697.488.camel@pmac.infradead.org> Message-ID: <46A8D344.4090003@hhs.nl> David Woodhouse wrote: > On Thu, 2007-07-26 at 11:59 -0400, Jesse Keating wrote: >> On Thu, 26 Jul 2007 17:48:57 +0200 >> Hans de Goede wrote: >> >>> I must say I like this approach, it avoids the whole problem of >>> having to rebuild kmods all the time and of wether to delay kernel >>> security updates until all kmods are fixetd etc. I do think however >>> that this might cause some pain for Dave Jones, whose job already is >>> hard. Maybe we should ask him what he thinks about this? >> Well, if the module doesn't build fine with an update, most likely >> what's going to happen is the module gets disabled, which could result >> in even more frequent kernel updates just for getting a single module >> to build again. > > I assume you're thinking of updates, not rawhide. In rawhide, Dave or > Chuck send you a mail saying "your $FOO patch broke; I turned it off". > You fix it, and it appears again in rawhide in a day or two. > > In updates, such things are actually much less likely to break, except > when we rebase to a newer kernel -- and if you've kept your driver > working in rawhide then it should work fine when we rebase the release > to the newer kernel anyway. Even if not, we tend to be quite > conservative about releasing new kernels anyway -- they end up in > updates-testing for some time, and that gives you time to get it > working. The urgent security fixes are usually relatively small and > unlikely to break drivers. > That sounds an excellent way of handling this, can I say +1 Regards, Hans From kagesenshi.87 at gmail.com Thu Jul 26 17:13:39 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 27 Jul 2007 01:13:39 +0800 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> References: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> Message-ID: On 7/27/07, Debarshi 'Rishi' Ray wrote: > > is yum's https proxy support broken? or am I doing this wrong? > > > > in /etc/yum.conf , I've added this line > > > > proxy=http://160.0.234.1:8080 > > You need to put a slash at the end. > > Try: > proxy=http://160.0.234.1:8080/ > > Otherwise you might like to consult: > http://debarshiray.multiply.com/journal/item/30 > > Good luck, > Debarshi its still not working a little test with a python script using urlgrabber yields the same error .. a bug in urlgrabber? yum uses urlgrabber to grab downloads right? import urlgrabber import os os.environ['https_proxy'] = 'http://160.0.234.1:8080/' urlgrabber.urlgrab('https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml') [kagesenshi at Hikari tmp]$ python testurlgrab.py Traceback (most recent call last): File "testurlgrab.py", line 8, in urlgrabber.urlgrab('https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml') File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 597, in urlgrab return default_grabber.urlgrab(url, filename, **kwargs) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 913, in retryfunc fo = URLGrabberFileObject(url, filename, opts) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1001, in __init__ self._do_open() File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1068, in _do_open fo, hdr = self._make_request(req, opener) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1178, in _make_request raise new_e urlgrabber.grabber.URLGrabError: [Errno 14] HTTP Error 400: Server: squid/2.5.STABLE11 Mime-Version: 1.0 Date: Thu, 26 Jul 2007 17:11:35 GMT Content-Type: text/html Content-Length: 1137 Expires: Thu, 26 Jul 2007 17:11:35 GMT X-Squid-Error: ERR_UNSUP_REQ 0 X-Cache: MISS from Network-Box Proxy-Connection: close > -- > GPG key ID: 63D4A5A7 > Key server: pgp.mit.edu > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From tmus at tmus.dk Thu Jul 26 17:23:22 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 26 Jul 2007 15:23:22 -0200 Subject: F8t1: not able to use the whole screen In-Reply-To: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> References: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> Message-ID: yonas Abraham wrote: > I am using a 19" wide screen flat panel monitor, and after > successfully installed Rawhide (F8T1) yesterday, I found that like > about 10% of the screen on the left side is just black and unusable. I > taught the screen just shifted to the right, but no. The resolution is > set correctly (1400x900). > > /yonas > I've seen similar, only on slightly earlier versions of stuff... Make sure You are using the very latest driver (i810 in my case). If you're using an analog (VGA) connection to the monitor, make sure the cable is of a good quality. This is actually the one that solved things for me. The original cable was not broken as such, just a very cheap cable. Hope it helps. /Thomas From jkeating at redhat.com Thu Jul 26 17:30:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 13:30:06 -0400 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <1185468213.14697.488.camel@pmac.infradead.org> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> <20070726115912.3d690073@ender> <1185468213.14697.488.camel@pmac.infradead.org> Message-ID: <20070726133006.1447e05f@ender> On Thu, 26 Jul 2007 17:43:33 +0100 David Woodhouse wrote: > In updates, such things are actually much less likely to break, except > when we rebase to a newer kernel -- and if you've kept your driver > working in rawhide then it should work fine when we rebase the release > to the newer kernel anyway. Even if not, we tend to be quite > conservative about releasing new kernels anyway -- they end up in > updates-testing for some time, and that gives you time to get it > working. The urgent security fixes are usually relatively small and > unlikely to break drivers. > > It's not something that scales hugely, but we don't _want_ it to. We > should be sticking close to upstream, and not shipping drivers which > aren't getting merged. Yeah that sounds reasonable. Any chance we could get a peep from Davej and Cebbert on this? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yabraham2 at gmail.com Thu Jul 26 17:56:11 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Thu, 26 Jul 2007 13:56:11 -0400 Subject: F8t1: not able to use the whole screen In-Reply-To: <1185464561.2794.155.camel@localhost.localdomain> References: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> <1185464561.2794.155.camel@localhost.localdomain> Message-ID: <47324ed80707261056q6b5c59f5x504c6b3cc3622893@mail.gmail.com> On 7/26/07, Adam Jackson wrote: > On Thu, 2007-07-26 at 11:26 -0400, yonas Abraham wrote: > > I am using a 19" wide screen flat panel monitor, and after > > successfully installed Rawhide (F8T1) yesterday, I found that like > > about 10% of the screen on the left side is just black and unusable. I > > taught the screen just shifted to the right, but no. The resolution is > > set correctly (1400x900). > > What hardware? > > - ajax the machine is Dell dimension with Intel 915 cheapest. integrated graphics card. From dwmw2 at infradead.org Thu Jul 26 17:56:45 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Jul 2007 18:56:45 +0100 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <20070726133006.1447e05f@ender> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> <20070726115912.3d690073@ender> <1185468213.14697.488.camel@pmac.infradead.org> <20070726133006.1447e05f@ender> Message-ID: <1185472605.14697.494.camel@pmac.infradead.org> On Thu, 2007-07-26 at 13:30 -0400, Jesse Keating wrote: > On Thu, 26 Jul 2007 17:43:33 +0100 > David Woodhouse wrote: > > > In updates, such things are actually much less likely to break, except > > when we rebase to a newer kernel -- and if you've kept your driver > > working in rawhide then it should work fine when we rebase the release > > to the newer kernel anyway. Even if not, we tend to be quite > > conservative about releasing new kernels anyway -- they end up in > > updates-testing for some time, and that gives you time to get it > > working. The urgent security fixes are usually relatively small and > > unlikely to break drivers. > > > > It's not something that scales hugely, but we don't _want_ it to. We > > should be sticking close to upstream, and not shipping drivers which > > aren't getting merged. > > Yeah that sounds reasonable. Any chance we could get a peep from Davej > and Cebbert on this? I think they should approve any individual driver or system which gets added. If they want to express disapproval of the whole concept, they can feel free to use a procmail filter to say "nah, sod off" to _every_ such request. :) -- dwmw2 From yabraham2 at gmail.com Thu Jul 26 17:58:34 2007 From: yabraham2 at gmail.com (yonas Abraham) Date: Thu, 26 Jul 2007 13:58:34 -0400 Subject: F8t1: not able to use the whole screen In-Reply-To: References: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> Message-ID: <47324ed80707261058j5ec2fa03tdfd1ede43aa662e2@mail.gmail.com> On 7/26/07, Thomas M Steenholdt wrote: > yonas Abraham wrote: > > I am using a 19" wide screen flat panel monitor, and after > > successfully installed Rawhide (F8T1) yesterday, I found that like > > about 10% of the screen on the left side is just black and unusable. I > > taught the screen just shifted to the right, but no. The resolution is > > set correctly (1400x900). > > > > /yonas > > > > I've seen similar, only on slightly earlier versions of stuff... > > Make sure You are using the very latest driver (i810 in my case). > > If you're using an analog (VGA) connection to the monitor, make sure the > cable is of a good quality. This is actually the one that solved things > for me. The original cable was not broken as such, just a very cheap cable. > > Hope it helps. The machine workes fine if I boot to F7. and it had worked FC4 till F8T1. /yonas From seandarcy2 at gmail.com Thu Jul 26 17:24:13 2007 From: seandarcy2 at gmail.com (sean) Date: Thu, 26 Jul 2007 13:24:13 -0400 Subject: /lib/libxxx.so.x is truncated?? Message-ID: Running yum today I keep seeing errors like this: ............ Updating : metacity ##################### [ 51/265] /sbin/ldconfig: file /lib/libpamc.so.0 is truncated /sbin/ldconfig: file /lib/libpam_misc.so.0 is truncated /sbin/ldconfig: file /lib/libpamc.so.0.81.0 is truncated /sbin/ldconfig: file /lib/libpam.so.0.81.8 is truncated /sbin/ldconfig: file /lib/libpam_misc.so.0.81.2 is truncated /sbin/ldconfig: file /usr/lib/libGL.so.1 is truncated /sbin/ldconfig: file /usr/lib/libGLU.so.1 is truncated /sbin/ldconfig: file /usr/lib/libwnck-1.so.22.2.0 is truncated /sbin/ldconfig: file /usr/lib/libGLU.so.1.3.060502 is truncated /sbin/ldconfig: file /usr/lib/libgdk_pixbuf-2.0.so.0.1106.0 is truncated /sbin/ldconfig: file /usr/lib/libgdk-x11-2.0.so.0.1106.0 is truncated /sbin/ldconfig: file /usr/lib/libgtk-x11-2.0.so.0.1106.0 is truncated /sbin/ldconfig: file /usr/lib/libgdk_pixbuf_xlib-2.0.so.0.1106.0 is truncated /sbin/ldconfig: file /usr/lib/libGL.so.1.2 is truncated /sbin/ldconfig: file /usr/lib/libXcomposite.so.1 is truncated /sbin/ldconfig: file /usr/lib/libXcomposite.so.1.0.0 is truncated /sbin/ldconfig: file /usr/lib/libwnck-1.so.22 is truncated ........... What's the problem, and what, if anything, should I do? sean From dakingun at gmail.com Thu Jul 26 18:13:36 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Thu, 26 Jul 2007 14:13:36 -0400 Subject: /lib/libxxx.so.x is truncated?? In-Reply-To: References: Message-ID: On 7/26/07, sean wrote: > Running yum today I keep seeing errors like this: > > ............ > > /sbin/ldconfig: file /usr/lib/libwnck-1.so.22 is truncated > ........... > > What's the problem, and what, if anything, should I do? > See https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01389.html. Deji From sundaram at fedoraproject.org Thu Jul 26 06:45:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 26 Jul 2007 12:15:21 +0530 Subject: Fedora & Sound: an excercise in frustration In-Reply-To: <1184962398.3195.20.camel@dimi.lattica.com> References: <1184962398.3195.20.camel@dimi.lattica.com> Message-ID: <46A84301.2040201@fedoraproject.org> Dimi Paun wrote: > Guys, > > The sound situation is appalling: since FC6, my sounds stops/starts > working with pretty much _every_ kernel update! Don't worry, the > steady state is that it's not working. It will start working for a > short lived kernel version, but people are diligently working to > fix it back to its non-working state. > > Hardware (bog standard): > [root at dimi ~]# lspci | grep -i audio > 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) > > Software: > Standard FC6, now F7 > I would appreciate if you can try this and let me know if this fixes your problem: ----- yum -y update glibc\* yum -y install automake gcc mercurial iwl\* hg clone http://hg.alsa-project.org/alsa-driver alsa-driver cd alsa-driver ./cvscompile make install Rahul From mschwendt.tmp0701.nospam at arcor.de Thu Jul 26 19:13:26 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 26 Jul 2007 21:13:26 +0200 Subject: rpms/pbzip2/FC-6 .cvsignore, 1.6, 1.7 pbzip2.spec, 1.8, 1.9 sources, 1.6, 1.7 In-Reply-To: <200707261720.l6QHKm1K011366@cvs-int.fedora.redhat.com> References: <200707261720.l6QHKm1K011366@cvs-int.fedora.redhat.com> Message-ID: <20070726211326.413a8217.mschwendt.tmp0701.nospam@arcor.de> On Thu, 26 Jul 2007 13:20:48 -0400, Jeff Gilchrist (jeffg) wrote: > Author: jeffg > > Update of /cvs/extras/rpms/pbzip2/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv11298/FC-6 > +%post > +cd %{_bindir} > +ln -s -f %{name} pbunzip2 > + > + > +%postun > +cd %{_bindir} > +rm -rf pbunzip2 > + > + Wouldn't pass any review. Please create this link in %install and package it in %files _normally_. From debarshi.ray at gmail.com Thu Jul 26 19:16:53 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 27 Jul 2007 00:46:53 +0530 Subject: High frequency noise in Fedora 7 Message-ID: <3170f42f0707261216o348cebdcrd32f94c9a3954fe9@mail.gmail.com> I am on a Fedora 7 system, running the latest kernel-2.6.22.1-27.fc7 from updates, with a small mix of Rawhide packages thrown in. Whenever I play a song or a movie I get a constant high frequency monotonous note alongwith the expected soundtrack. [root at ginger ~]# lspci ... ... 04:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller ... [root at ginger ~]# lsmod Module Size Used by dm_mirror 25153 0 dm_multipath 21961 0 dm_mod 56961 2 dm_mirror,dm_multipath video 21065 0 sbs 22729 0 button 12113 0 dock 13921 0 ac 9285 0 lp 16105 0 snd_hda_intel 243416 2 snd_seq_dummy 7877 0 snd_seq_oss 33473 0 snd_seq_midi_event 11073 1 snd_seq_oss snd_seq 50609 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 11981 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 43457 0 snd_mixer_oss 19521 2 snd_pcm_oss snd_pcm 74949 2 snd_hda_intel,snd_pcm_oss snd_timer 24901 2 snd_seq,snd_pcm firewire_ohci 20673 0 snd 53317 10 snd_hda_intel,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer firewire_core 43137 1 firewire_ohci soundcore 11681 2 snd snd_page_alloc 13769 2 snd_hda_intel,snd_pcm crc_itu_t 6337 1 firewire_core parport_pc 30821 1 rtc_cmos 12001 0 parport 38281 3 ppdev,lp,parport_pc usblp 17473 0 k8temp 9537 0 hwmon 7365 1 k8temp via_rhine 28361 0 i2c_viapro 12373 0 serio_raw 10821 0 mii 9409 1 via_rhine i2c_core 27841 1 i2c_viapro sr_mod 20837 0 sg 37469 0 ahci 25541 0 pata_via 15813 7 sd_mod 31297 11 scsi_mod 140621 5 usb_storage,sr_mod,sg,libata,sd_mod jbd 59881 1 ext3 mbcache 12485 1 ext3 ... ... [root at ginger ~]# Worth filing a bug, or am I making a mistake? Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at fedoraproject.org Thu Jul 26 19:26:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 Jul 2007 15:26:35 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-26 Message-ID: <20070726192635.43AD0152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 24 adminutil-1.1.3-1.fc6 NEW alienblaster-1.1.0-1.fc6 : Action-loaded 2D arcade shooter game NEW bacula-2.0.3-9.fc6 : Cross platform network backup for Linux, Unix, Mac and Windows deluge-0.5.3-1.fc6 NEW drupal-5.1-5.fc6 : An open-source content-management platform fwbackups-1.43.1-2.fc6 gdal-1.4.2-2.fc6 grass-6.2.2-1.fc6 ktorrent-2.2.1-1.fc6 NEW libgeotiff-1.2.4-0.3.rc1.fc6 : GeoTIFF format library NEW libtimidity-0.1.0-1.fc6 : MIDI to WAVE converter library lighttpd-1.4.16-1.fc6 NEW memcached-1.2.3-4.fc6 : High Performance, Distributed Memory Object Cache mod_dnssd-0.5-3.fc6 ntfs-3g-1.710-1.fc6 NEW perl-Callback-1.07-1.fc6 : Object interface for function callbacks NEW perl-Catalyst-Action-RenderView-0.04-3.fc6 : Sensible default end action for view renders perl-Want-0.15-1.fc6 pikloops-0.2.3-1.fc6 python-paramiko-1.7.1-2.fc6 NEW qfaxreader-0.3.1-7.fc6 : A multipage monochrome/color TIFF/FAX viewer R-mvtnorm-0.8-2.fc6 rb_libtorrent-0.12-1.fc6 speedcrunch-0.8-4.fc6 Changes in Fedora Extras 6: adminutil-1.1.3-1.fc6 --------------------- * Tue Jul 24 2007 Rich Megginson - 1.1.3-1 - updated to version 1.1.3 - fixes bugzillas 246124 and 247192 alienblaster-1.1.0-1.fc6 ------------------------ * Sun Jul 22 2007 Hans de Goede 1.1.0-1 - Initial Fedora Extras package bacula-2.0.3-9.fc6 ------------------ * Wed Jul 25 2007 Andreas Thienemann 2.0.3-9 - Corrected the %post alternatives calls. Fixing #249560. * Thu Jul 19 2007 Andreas Thienemann 2.0.3-8 - Moved some files around in the %files section and refactored spec parts a bit - Fixed up the catalog-backup scripts by including them in the alternatives system - Applied tls patch fixing some tls disconnection issues. * Wed Jul 18 2007 Andreas Thienemann 2.0.3-7 - Minor specchanges, mostly typos in the comments - Incorporated minor changes from dgilmore's review. * Fri Jul 13 2007 Andreas Thienemann 2.0.3-6 - Fixing %preun scripts. Thx to Dan for spotting this * Fri Jul 13 2007 Andreas Thienemann 2.0.3-5 - Fixed provides and requires * Wed Jul 11 2007 Andreas Thienemann 2.0.3-4 - Fixed many rpmlint issues deluge-0.5.3-1.fc6 ------------------ * Wed Jul 25 2007 Peter Gordon - 0.5.3-1 - Update to new upstream release candidate (0.5.3) - Drop %ifarch invocations for 64-bit builds. The internal setup script now properly determines this and adds the AMD64 compiler definition if necessary. * Tue Jul 24 2007 Peter Gordon - 0.5.2-1 - Update to new upstream release (0.5.2) - Update Summary and %description to reflect new ?Torrent-compatible Peer Exchange ("PEX") functionality. - Make Deluge the upgrade path of the now-orphaned python-libtorrent package. * Wed Mar 07 2007 Peter Gordon - 0.4.99.1-1 - Update to new upstream release (0.5 RC1). - Drop unneeded 64bit-python_long patch; as it seems to cause more trouble than it's worth. Instead, pass -DAMD64 as a compiler flag on 64-bit arches. - 64bit-python_long patch (This should fix the bug where, even though torrents are active, they are not shown in the GtkTreeView listing.) - Use rewritten setup.py instead of patching it so much, since it's easier to maintain across version upgrades and whatnot: + fixed-setup.py - Remove the setup.py patch (no longer needed, since I'm packaging my own): - setup.py-build-against-system-libtorrent.patch * Sun Feb 25 2007 Peter Gordon - 0.4.90.2-2 - Add patch to fix 64-bit python_long type. + 64bit-python_long.patch * Sat Feb 24 2007 Peter Gordon - 0.4.90.2-1 - Update to new upstream release (0.5 Beta 2) - Add patch to force building against system copy of rb_libtorrent: + setup.py-build-against-system-libtorrent.patch - Remove python-libtorrent and a few other dependencies that are no longer used. drupal-5.1-5.fc6 ---------------- * Fri Jul 20 2007 Jon Ciesla - 5.1-5 - Corrected buildroot. - Moved /etc/drupal/all/README.txt to correct place. * Wed Jul 04 2007 Jon Ciesla - 5.1-4 - Made settings.php not readonly by default, with note in drupal-README.fedora - Locked down initial security configuration, documented steps required. - Description cleanup. - Added wget requires. fwbackups-1.43.1-2.fc6 ---------------------- * Wed Jul 25 2007 Stewart Adam 1.43.1-2 - Add Manual fields patch (bz #249592) gdal-1.4.2-2.fc6 ---------------- * Tue Jul 24 2007 Balint Cristian 1.4.2-2 - disable one more HFA test, HFA is unaviable due to license * Tue Jul 24 2007 Balint Cristian 1.4.2-1 - new upstream one - catch some more docs - fix ogr python module runtime - include testcases and run tests - enable geotiff external library we have new libgeotiff now - EPSG geodetic database is licensed OK since v6.13 so re-enable - enable it against grass by default, implement optional switches * Tue Jun 05 2007 Balint Cristian 1.4.1-4 - re-build. * Sat May 12 2007 Balint Cristian 1.4.1-3 - re-build against grass. * Fri May 11 2007 Balint Cristian 1.4.1-2 - fix python lookup paths for ppc64. grass-6.2.2-1.fc6 ----------------- * Wed Jul 25 2007 Balint Cristian 6.2.2-1 - new upstream stable version * Thu Jun 07 2007 Balint Cristian 6.2.2-0.2.RC1 - fix version string in desktop file - add RO lang to desktop file - dropped one patch, seems fixed upstream. * Fri Jun 01 2007 Balint Cristian 6.2.2-0.1.RC1 - 6.2.2 rc1 bugfix release - fix docbase lookup path for g.manual * Sat May 12 2007 Balint Cristian 6.2.1-16 - fix koji build for ppc ppc64, dont use _host macro anymore. * Sat May 12 2007 Balint Cristian 6.2.1-15 - rebuild against new gdal * Mon Apr 02 2007 Balint Cristian 6.2.1-14 - remove bogus requirement in grass-libs - rename gem loader to gem62 ktorrent-2.2.1-1.fc6 -------------------- * Tue Jul 24 2007 Roland Wolters 2.2.1-1 - update to bugfix upstream 2.2.1 libgeotiff-1.2.4-0.3.rc1.fc6 ---------------------------- * Tue Jul 24 2007 Balint Cristian 1.2.4-0.3.rc1 - codes are under MIT - pkg-config cflags return fix - epsg_csv ownership * Mon Jul 23 2007 Balint Cristian 1.2.4-0.2.rc1 - fix debuginfo usability - move header files to the subdirectory - specify the full URL of the source - leave *.inc headers included - libgeotiff-devel should require libtiff-devel - works to keep timestamps on the header files installed - docs proper triage * Mon Jul 23 2007 Balint Cristian 1.2.4-0.1.rc1 - initial pack for fedora - add pkgconfig file - add soname versioning patch libtimidity-0.1.0-1.fc6 ----------------------- * Fri Jun 29 2007 Hans de Goede 0.1.0-1 - Initial Fedora package lighttpd-1.4.16-1.fc6 --------------------- * Thu Jul 26 2007 Matthias Saou 1.4.16-1 - Update to 1.4.16 security fix release. * Mon Apr 16 2007 Matthias Saou 1.4.15-1 - Update to 1.4.15. - Remove now included previous patch. - Switch to using the bz2 source. - Add optional --with-webdav-locks support. * Fri Feb 16 2007 Matthias Saou 1.4.13-6 - Include patch to fix 99% cpu bug when client connection is dropped. * Fri Feb 02 2007 Matthias Saou 1.4.13-5 - Update defaultconf patch to change php binary to /usr/bin/php-cgi (#219723). - Noticed %{?_smp_mflags} was missing, so add it as it works fine. * Mon Jan 29 2007 Matthias Saou 1.4.13-4 - Remove readline-devel build req, added by lua but since fixed (#213895). memcached-1.2.3-4.fc6 --------------------- * Fri Jul 13 2007 Paul Lindner - 1.2.3-4 - Remove test that fails in fedora build system on ppc64 * Sat Jul 07 2007 root - 1.2.3-2 - Upgrade to 1.2.3 upstream - Adjust make install to preserve man page timestamp - Conform with LSB init scripts standards, add force-reload * Wed Jul 04 2007 Paul Lindner - 1.2.2-5 - Use /var/run/memcached/ directory to hold PID file mod_dnssd-0.5-3.fc6 ------------------- * Tue Jul 24 2007 Ignacio Vazquez-Abrams 0.5-3 - Add upstream patch to fix UID issue ntfs-3g-1.710-1.fc6 ------------------- * Sun Jul 22 2007 Tom "spot" Callaway 2:1.710-1 - bump to 1.710 - add compat symlinks * Wed Jun 27 2007 Tom "spot" Callaway 2:1.616-1 - bump to 1.616 perl-Callback-1.07-1.fc6 ------------------------ * Thu Mar 15 2007 mkpai 1.07-1 - Specfile autogenerated by cpanspec 1.69.1. perl-Catalyst-Action-RenderView-0.04-3.fc6 ------------------------------------------ * Tue Jul 24 2007 Chris Weyl 0.04-3 - bump perl-Want-0.15-1.fc6 -------------------- * Thu Jul 26 2007 Ralf Cors?pius - 0.15-1 - Upstream update. pikloops-0.2.3-1.fc6 -------------------- * Thu Jul 26 2007 Alain Portal 0.2.3-1 - New upstream version python-paramiko-1.7.1-2.fc6 --------------------------- * Thu Jul 19 2007 Jeffrey C. Ollie - 1.7.1-2 - Bump rev * Thu Jul 19 2007 Jeffrey C. Ollie - 1.7.1-1 - Update to 1.7.1 qfaxreader-0.3.1-7.fc6 ---------------------- * Tue Jul 24 2007 manuel wolfshant - 0.3.1-7 - Parallel build, take two (yet another patch) * Mon Jul 23 2007 manuel wolfshant - 0.3.1-6 - Adding automake as BR * Mon Jul 23 2007 manuel wolfshant - 0.3.1-5 - More cleanup - Reenable SMP * Mon Jul 23 2007 manuel wolfshant - 0.3.1-4 - Spec file cleanup - Disabled parallel build, it does not seem to work. R-mvtnorm-0.8-2.fc6 ------------------- * Tue Jul 24 2007 Orion Poplawski - 0.8-2 - Update to 0.8-1, fixes test * Mon Jul 23 2007 Orion Poplawski - 0.8-1 - Update to 0.8-0 rb_libtorrent-0.12-1.fc6 ------------------------ * Thu Jun 07 2007 Peter Gordon - 0.12-1 - Update to new upstream release (0.12 Final) - Split examples into a subpackage. Applications that use rb_libtorrent don't need the example binaries installed; and splitting the package in this manner is a bit more friendly to multilib environments. * Sun Mar 11 2007 Peter Gordon - 0.12-0.rc1 - Update to new upstream release (0.12 RC). - Forcibly use the system libtool to ensure that we remove any RPATH hacks. speedcrunch-0.8-4.fc6 --------------------- * Thu Jul 26 2007 Roland Wolters 0.8-1 - update to upstream 0.8 - various new features and bugfixes For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From kevin.kofler at chello.at Thu Jul 26 19:34:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 26 Jul 2007 19:34:03 +0000 (UTC) Subject: Plan for tomorrows (20070726) FESCO meeting References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <46A8954B.6060907@hhs.nl> Message-ID: Hans de Goede hhs.nl> writes: > Deal! > > Can you mail me the BZ links for those 2 kde packages please? kdegames3: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248647 atlantikdesigner: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248648 Kevin Kofler From opensource at till.name Thu Jul 26 19:46:19 2007 From: opensource at till.name (Till Maas) Date: Thu, 26 Jul 2007 21:46:19 +0200 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: References: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> Message-ID: <200707262146.23188.opensource@till.name> On Thursday 26 July 2007 19:13:39 Hikaru Amano wrote: > import urlgrabber > import os > os.environ['https_proxy'] = 'http://160.0.234.1:8080/' > urlgrabber.urlgrab('https://161.0.2.218/pub/mirror/repos/fedora_i686/repoda >ta/repomd.xml') With another proxy and another https URL above works for me. Does this work for you: curl -x http://160.0.234.1:8080/ https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml Or this: curl -p http://160.0.234.1:8080/ https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml Regards, Till From andy at smile.org.ua Thu Jul 26 20:32:33 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Thu, 26 Jul 2007 23:32:33 +0300 Subject: High frequency noise in Fedora 7 In-Reply-To: <3170f42f0707261216o348cebdcrd32f94c9a3954fe9@mail.gmail.com> References: <3170f42f0707261216o348cebdcrd32f94c9a3954fe9@mail.gmail.com> Message-ID: <20070726203233.GG3673@serv.smile.org.ua> Hi Debarshi 'Rishi' Ray! On Fri, Jul 27, 2007 at 12:46:53AM +0530, Debarshi 'Rishi' Ray wrote next: > I am on a Fedora 7 system, running the latest kernel-2.6.22.1-27.fc7 > from updates, with a small mix of Rawhide packages thrown in. Whenever > I play a song or a movie I get a constant high frequency monotonous > note alongwith the expected soundtrack. Did you try to setup ALSA 1.0.14 ? In first, I recommend to update ALSA and try with new one. Then (if bug is still reproduced) you may fill bug report to ALSA team. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From kevin.kofler at chello.at Thu Jul 26 20:32:35 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 26 Jul 2007 20:32:35 +0000 (UTC) Subject: Abuse of Fedora trademark References: <46A8991E.3050306@hhs.nl> Message-ID: Hans de Goede hhs.nl> writes: > easyfedora, as its called. But this software is released under a proprietary > license (according to the webpage). To me the use of the Fedora Trademark in > combination with a proprietary license is not acceptable and a clear > violation of the Fedora trademark policies. Not only that, he's also in violation of the Qt license (unless he has a commercial license, which I strongly doubt). Kevin Kofler From bloch at verdurin.com Thu Jul 26 20:56:29 2007 From: bloch at verdurin.com (Adam Huffman) Date: Thu, 26 Jul 2007 21:56:29 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185459449.2315.9.camel@work> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> <1185454210.6208.4.camel@raptor.sr.unh.edu> <645d17210707260718n73171620oc21965f50e141f18@mail.gmail.com> <1185459449.2315.9.camel@work> Message-ID: <20070726205629.GC32213@bloch.config> On Thu, 26 Jul 2007, Richard Hughes wrote: > On Thu, 2007-07-26 at 15:18 +0100, Jonathan Underwood wrote: > > FWIW... "me too" on same hardware. Doing a ctrl-alt-F1 ctrl-alt-f7 > > remedies the situation, does it for you? However, doing that just now > > I noticed that the ttys had stopped working. hm. > > Can you try with the sony-laptop module here: > http://people.freedesktop.org/~hughsient/temp/sony-laptop-git20070725.tar.gz > Perhaps that was intended for me? Just tried it, and I still can't assign the keys to do anything. Here are the messages when I load the module: kernel: sony-laptop: Sony Programmable IO Control Driver v0.5. kernel: sony-laptop: detected Type3 model kernel: input: Sony Vaio Keys as /class/input/input6 kernel: input: Sony Vaio Jogdial as /class/input/input7 kernel: sony-laptop: device allocated minor is 62 kernel: sony-laptop: Sony Notebook Control Driver v0.5. From buildsys at redhat.com Thu Jul 26 21:31:59 2007 From: buildsys at redhat.com (Build System) Date: Thu, 26 Jul 2007 17:31:59 -0400 Subject: rawhide report: 20070726 changes Message-ID: <200707262131.l6QLVxAd020833@porkchop.devel.redhat.com> Updated Packages: adminutil-1.1.3-1.fc8.1 ----------------------- * Wed Jul 25 2007 Warren Togami - 1.1.3-1.1 - binutils/gcc bug rebuild (#249435) alienblaster-1.1.0-2.fc8 ------------------------ alsa-oss-1.0.14-2.fc8 --------------------- * Wed Jul 25 2007 Warren Togami 1.0.14-2 - binutils/gcc bug rebuild (#249435) bacula-2.0.3-9.fc8 ------------------ * Wed Jul 25 2007 Andreas Thienemann 2.0.3-9 - Corrected the %post alternatives calls. Fixing #249560. bind-32:9.5.0-7.a6.fc8 ---------------------- * Wed Jul 25 2007 Warren Togami 32:9.5.0-7.a6 - binutils/gcc bug rebuild (#249435) * Tue Jul 24 2007 Adam Tkac 32:9.5.0-6.a6 - updated to 9.5.0a6 which contains fixes for CVE-2007-2925 and CVE-2007-2926 - fixed building on 64bits * Mon Jul 23 2007 Adam Tkac 31:9.5.0a5-5 - integrated "autotools" patch for testing purposes (upstream will accept it in future, for easier building) binutils-2.17.50.0.17-6 ----------------------- * Wed Jul 25 2007 Jakub Jelinek 2.17.50.0.17-6 - rebuilt to make sure even libbfd.so and libopcodes.so aren't broken by #249435 * Tue Jul 24 2007 Jakub Jelinek 2.17.50.0.17-5 - add .note.gnu.build-id into default linker script (#249435) * Tue Jul 24 2007 Jakub Jelinek 2.17.50.0.17-4 - don't kill the %{_gnu} part of target name on arm (Lennert Buytenhek, #243516) - create just one PT_NOTE segment header for all consecutive SHT_NOTE sections cone-0.71-2.fc8 --------------- * Wed Jul 25 2007 Jesse Keating - 0.71-2 - Rebuild for RH #249435 * Tue Jul 24 2007 Steven Pritchard 0.71-1 - Update to 0.71. * Mon Apr 09 2007 Steven Pritchard 0.69-1 - Update to 0.69. control-center-1:2.19.5-4.fc8 ----------------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-4 - Rebuild for RH #249435 emacs-vm-8.0.2.482-2.fc8 ------------------------ * Wed Jul 25 2007 Jesse Keating - 8.0.2.482-2 - Rebuild for RH #249435 epiphany-2.19.5-4.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-4 - Rebuild for RH #249435 * Mon Jul 23 2007 Matthias Clasen - 2.19.5-3 - Port to new GTK+ tooltips API * Fri Jul 20 2007 Kai Engert - 2.19.5-2 - Rebuild against newer gecko gdb-6.6-22.fc8 -------------- * Wed Jul 25 2007 Jesse Keating - 6.6-22 - Rebuild for RH #249435 gmime-2.2.10-2.fc8 ------------------ * Wed Jul 25 2007 Jesse Keating - 2.2.10-2 - Rebuild for RH #249435 gnome-panel-2.19.5-4.fc8 ------------------------ * Wed Jul 25 2007 Jesse Keating - 2.19.5-4 - Rebuild for RH #249435 gpm-1.20.1-88.fc8 ----------------- * Wed Jul 25 2007 Jesse Keating - 1.20.1-88 - Rebuild for RH #249435 gtk2-2.11.6-3.fc8 ----------------- * Wed Jul 25 2007 Matthias Clasen - 2.11.6-3 - Fix the behaviour of tooltips on system tray icons * Tue Jul 24 2007 Matthias Clasen - 2.11.6-2 - Silence the icon cache validator (#248789) * Mon Jul 23 2007 Matthias Clasen - 2.11.6-1 - Update to 2.11.6 - Make it build against recent cups hardinfo-0.4.2.2-3.fc8 ---------------------- kmymoney2-0.8.7-2.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 0.8.7-2 - Rebuild for RH #249435 ktorrent-2.2.1-2.fc8 -------------------- * Wed Jul 25 2007 Jesse Keating - 2.2.1-2 - Rebuild for RH #249435 libXcomposite-0.4.0-2.fc8 ------------------------- * Wed Jul 25 2007 Jesse Keating - 0.4.0-2 - Rebuild for RH #249435 libgeotiff-1.2.4-0.4.rc1.fc8 ---------------------------- * Wed Jul 25 2007 Jesse Keating - 1.2.4-0.4.rc1 - Rebuild for RH #249435 libhangul-0.0.6-2.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 0.0.6-2 - Rebuild for RH #249435 libpcap-14:0.9.7-2.fc8 ---------------------- * Wed Jul 25 2007 Jesse Keating - 14:0.9.7-2 - Rebuild for RH #249435 libtimidity-0.1.0-2.fc8 ----------------------- libvirt-0.3.1-2.fc8 ------------------- * Wed Jul 25 2007 Jesse Keating - 0.3.1-2 - Rebuild for RH #249435 libwnck-2.19.5-3.fc8 -------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-3 - Rebuild for RH #249435 libxml++-2.18.1-2.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 2.18.1-2 - Rebuild for RH #249435 livecd-tools-010-1.fc8 ---------------------- * Wed Jul 25 2007 Jeremy Katz - 010-1 - Separate out configs used for Fedora 7 - Add patch from Douglas McClendon to make images smaller - Add patch from Matt Domsch to work with older syslinux without vesamenu - Add support for using mirrorlists; use them - Let livecd-iso-to-disk work with uncompressed images (#248081) - Raise error if SELinux requested without being enabled (#248080) - Set service defaults on level 2 also (#246350) - Catch some failure cases - Allow specifying tmpdir - Add patch from nameserver specification from Elias Hunt mcabber-0.9.3-3.fc8 ------------------- * Wed Jul 25 2007 Jesse Keating - 0.9.3-3 - Rebuild for RH #249435 mesa-6.5.2-16.fc8 ----------------- * Wed Jul 25 2007 Jesse Keating - 6.5.2-16 - Rebuild for RH #249435 metacity-2.19.34-2.fc8 ---------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.34-2 - Rebuild for RH #249435 nautilus-2.19.5-3.fc8 --------------------- * Wed Jul 25 2007 Jesse Keating - 2.19.5-3 - Rebuild for RH #249435 * Mon Jul 23 2007 Matthias Clasen - 2.19.5-2 - Port to new GTK+ tooltips API * Tue Jul 10 2007 Matthias Clasen - 2.19.5-1 - Update to 2.19.5 nss_compat_ossl-0.9.1-4.fc8 --------------------------- * Wed Jul 25 2007 Jesse Keating - 0.9.1-4 - Rebuild for RH #249435 ntp-4.2.4p2-3.fc8 ----------------- * Wed Jul 25 2007 Jesse Keating - 4.2.4p2-3 - Rebuild for RH #249435 pam-0.99.8.1-2.fc8 ------------------ * Wed Jul 25 2007 Jeremy Katz - 0.99.8.1-2 - rebuild for toolchain bug * Mon Jul 23 2007 Tomas Mraz 0.99.8.1-1 - upgrade to latest upstream version - add some firewire devices to default console perms (#240770) * Thu Apr 26 2007 Tomas Mraz 0.99.7.1-6 - pam_namespace: better document behavior on failure (#237249) - pam_unix: split out passwd change to a new helper binary (#236316) - pam_namespace: add support for temporary logons (#241226) perl-Authen-PAM-0.16-2.fc8 -------------------------- * Wed Jul 25 2007 Jeremy Katz - 0.16-2 - rebuild for toolchain bug perl-File-Sync-0.09-2.fc8 ------------------------- perl-Text-LevenshteinXS-0.03-2.fc8 ---------------------------------- php-eaccelerator-1:0.9.5.1-4.fc8 -------------------------------- * Wed Jul 25 2007 Jeremy Katz - 1:0.9.5.1-4 - rebuild for toolchain bug pixman-0.9.0-3.20070724.fc8 --------------------------- * Wed Jul 25 2007 Jeremy Katz - 0.9.0-3.20070724 - rebuild for toolchain bug policycoreutils-2.0.22-9.fc8 ---------------------------- * Wed Jul 25 2007 Jeremy Katz - 2.0.22-9 - rebuild for toolchain bug rsyslog-1.17.2-4.fc8 -------------------- * Wed Jul 25 2007 Jeremy Katz - 1.17.2-4 - rebuild for toolchain bug rusers-0.17-49 -------------- * Wed Jul 25 2007 Jeremy Katz - 0.17-49 - rebuild for toolchain bug sabayon-2.19.1-2.fc8 -------------------- * Wed Jul 25 2007 Jeremy Katz - 2.19.1-2 - rebuild for toolchain bug sane-backends-1.0.18-13.fc8 --------------------------- * Wed Jul 25 2007 Jeremy Katz - 1.0.18-13 - rebuild for toolchain bug schedtool-1.2.10-5.fc8 ---------------------- * Wed Jul 25 2007 Jeremy Katz - 1.2.10-5 - rebuild for toolchain bug spamassassin-3.2.2-1.fc8 ------------------------ * Wed Jul 25 2007 Warren Togami 3.2.2-1 - 3.2.2 minor bugfix release tcpdump-14:3.9.7-2.fc8 ---------------------- * Wed Jul 25 2007 Jeremy Katz - 14:3.9.7-2 - rebuild for toolchain bug tomboy-0.7.2-2.fc8 ------------------ * Wed Jul 25 2007 Jeremy Katz - 0.7.2-2 - rebuild for toolchain bug tracker-0.6.0-2.fc8.1 --------------------- * Wed Jul 25 2007 Jeremy Katz - 0.6.0-2.1 - rebuild for toolchain bug w3m-0.5.2-3.fc8 --------------- * Wed Jul 25 2007 Jeremy Katz - 0.5.2-3 - rebuild for toolchain bug * Tue Jul 24 2007 Parag Nemade - 0.5.2-2 - Build against new gc-7.0 release. * Tue Jun 26 2007 Parag Nemade - 0.5.2-1 - Update to 0.5.2 and remove merged patches. - Build against system gc library. - Add BR: nkf for multipart.cgi. - Don't call unneeded autotool wfmath-0.3.6-2.fc8 ------------------ * Wed Jul 25 2007 Jeremy Katz - 0.3.6-2 - rebuild for toolchain bug xawtv-3.95-5.fc8 ---------------- * Wed Jul 25 2007 Jeremy Katz - 3.95-5 - rebuild for toolchain bug xorg-x11-server-utils-7.2-5.fc8 ------------------------------- * Wed Jul 25 2007 Jeremy Katz - 7.2-5 - rebuild for toolchain bug xorg-x11-xkb-utils-7.2-2.fc8 ---------------------------- * Wed Jul 25 2007 Jeremy Katz - 7.2-2 - rebuild for toolchain bug yelp-2.18.1-7.fc8 ----------------- * Wed Jul 25 2007 Jeremy Katz - 2.18.1-7 - rebuild for toolchain bug ytalk-3.3.0-8.fc8 ----------------- * Wed Jul 25 2007 Jeremy Katz - 3.3.0-8 - rebuild for toolchain bug yum-3.2.2-3.fc8 --------------- * Wed Jul 25 2007 Seth Vidal 3.2.2-3 - include panu's rpm-signal-catch patch from yum head. - include exception fix, too. Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From yocum at fnal.gov Thu Jul 26 21:32:30 2007 From: yocum at fnal.gov (Dan Yocum) Date: Thu, 26 Jul 2007 16:32:30 -0500 Subject: please enable XFS in anaconda Message-ID: <46A912EE.9040402@fnal.gov> Hi, It's been many years since I, and others, have pushed Marcelo and Linus to include XFS in the kernel. And we *have* been able to install using XFS as the default filesystem by passing the command line option 'linux xfs' (see: http://www.fedorafaq.org/#reiserjfs) when starting the install, but can you please enable XFS as a default FS option during the formating section so we don't have to remember to pass this option when booting? Here at Fermilab we've got nearly a petabyte (or more!) of spinning disk with XFS filesystems. It's stable, widely tested, widely deployed, and it's being actively developed and maintained (which is more than can be said of some other filesystems that remain in the default list). It's in the kernel, it shouldn't be "hidden" in the depths of anaconda anymore. Thanks, Dan -- Dan Yocum Fermilab 630.840.6509 yocum at fnal.gov, http://fermigrid.fnal.gov Fermilab. Just zeros and ones. From bloch at verdurin.com Thu Jul 26 21:53:15 2007 From: bloch at verdurin.com (Adam Huffman) Date: Thu, 26 Jul 2007 22:53:15 +0100 Subject: Dim Screen after Resume - which component to file bug against? In-Reply-To: <1185449079.3041.0.camel@work> References: <1185408852.4305.6.camel@continuity> <1185417095.4088.9.camel@localhost.localdomain> <20070726112417.GB32213@bloch.config> <1185449079.3041.0.camel@work> Message-ID: <20070726215315.GD32213@bloch.config> On Thu, 26 Jul 2007, Richard Hughes wrote: > On Thu, 2007-07-26 at 12:24 +0100, Adam Huffman wrote: > > > > None of the special Fn-key combinations work for me, even when the > > sony_laptop module is manually loaded. > > If you suspend, resume, rmmod sony-laptop, modprobe sony-laptop - does > that work? If so we'll have to add a resume hook somewhere in the > driver. > No, that doesn't make any difference. From giallu at gmail.com Thu Jul 26 22:16:36 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 27 Jul 2007 00:16:36 +0200 Subject: Failing kmod build on rawhide Message-ID: Thanks to Jarod Wilson, I sorted out the sysprof-kmod build for F-7. Now something different happens on rawhide: http://koji.fedoraproject.org/koji/getfile?taskID=78762&name=root.log No Package Found for kernel-devel-i686 = 2.6.23-0.45.rc0.git16.fc8 No Package Found for kernel-PAE-devel-i686 = 2.6.23-0.45.rc0.git16.fc8 But I checked and the other kmod we have right now in Fedora built correctly against those variants: http://koji.fedoraproject.org/koji/buildinfo?buildID=11979 any hint? From peter at thecodergeek.com Thu Jul 26 22:47:46 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 26 Jul 2007 15:47:46 -0700 Subject: rpms/net6/F-7 .cvsignore, 1.11, 1.12 net6.spec, 1.17, 1.18 sources, 1.11, 1.12 In-Reply-To: <200707262229.l6QMT16u016042@cvs-int.fedora.redhat.com> References: <200707262229.l6QMT16u016042@cvs-int.fedora.redhat.com> Message-ID: <1185490066.26467.0.camel@tuxhugs> On Thu, 2007-07-26 at 18:29 -0400, Luke Macken wrote: > [...] > diff -u -r1.17 -r1.18 > --- net6.spec 26 Apr 2007 04:18:29 -0000 1.17 > +++ net6.spec 26 Jul 2007 22:28:28 -0000 1.18 > @@ -1,5 +1,5 @@ > Name: net6 > -Version: 1.3.4 > +Version: 1.3.5 > Release: 1%{?dist} > Summary: A TCP protocol abstraction for library C++ That Summary seems oddly worded. Perhaps it'd be better as "A TCP Protocol abstraction library for C++"? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-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 Jul 26 23:07:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 19:07:54 -0400 Subject: please enable XFS in anaconda In-Reply-To: <46A912EE.9040402@fnal.gov> References: <46A912EE.9040402@fnal.gov> Message-ID: <20070726190754.68d0316c@ender> On Thu, 26 Jul 2007 16:32:30 -0500 Dan Yocum wrote: > It's stable, widely tested, widely deployed, and > it's being actively developed and maintained (which is more than can > be said of some other filesystems that remain in the default list). > It's in the kernel, it shouldn't be "hidden" in the depths of > anaconda anymore. How's the SELinux support these days? And why can't I boot from xfs yet? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davidc at ccmi.salk.edu Thu Jul 26 23:25:45 2007 From: davidc at ccmi.salk.edu (David Chambers) Date: Thu, 26 Jul 2007 16:25:45 -0700 Subject: please enable XFS in anaconda In-Reply-To: <20070726190754.68d0316c@ender> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> Message-ID: <46A92D79.7040600@ccmi.salk.edu> On 7/26/2007 4:07 PM, Jesse Keating wrote: > On Thu, 26 Jul 2007 16:32:30 -0500 > Dan Yocum wrote: > > >> It's stable, widely tested, widely deployed, and >> it's being actively developed and maintained (which is more than can >> be said of some other filesystems that remain in the default list). >> It's in the kernel, it shouldn't be "hidden" in the depths of >> anaconda anymore. >> > > How's the SELinux support these days? And why can't I boot from xfs > yet? > > Back in the old Red Hat Linux and FC2-4 days when I had more time, I seem to remember that Grub fully supported XFS. I could make all the filesystems XFS and I could boot just fine from them. Nowadays, I have less time, or I'm lazy, and just accept the Anaconda ext3 defaults for the system partitions. I still store all the important user data under XFS, though. I haven't lost a byte to XFS yet. Can't comment on SELinux, don't use it :-) :-) I agree with Dan. From davidc at ccmi.salk.edu Thu Jul 26 23:29:49 2007 From: davidc at ccmi.salk.edu (David Chambers) Date: Thu, 26 Jul 2007 16:29:49 -0700 Subject: High frequency noise in Fedora 7 In-Reply-To: <3170f42f0707261216o348cebdcrd32f94c9a3954fe9@mail.gmail.com> References: <3170f42f0707261216o348cebdcrd32f94c9a3954fe9@mail.gmail.com> Message-ID: <46A92E6D.7060204@ccmi.salk.edu> On 7/26/2007 12:16 PM, Debarshi 'Rishi' Ray wrote: > I am on a Fedora 7 system, running the latest kernel-2.6.22.1-27.fc7 > from updates, with a small mix of Rawhide packages thrown in. Whenever > I play a song or a movie I get a constant high frequency monotonous > note alongwith the expected soundtrack. Ah, that would be due to the new **AA DRM scheme, craftily designed to prevent you using your disks or MP3s more than once. :-) /couldn't resist... From sundaram at fedoraproject.org Thu Jul 26 12:52:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 26 Jul 2007 18:22:14 +0530 Subject: please enable XFS in anaconda In-Reply-To: <46A92D79.7040600@ccmi.salk.edu> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A92D79.7040600@ccmi.salk.edu> Message-ID: <46A898FE.3000609@fedoraproject.org> David Chambers wrote: > > Can't comment on SELinux, don't use it :-) :-) It doesn't matter whether you use it or not. SELinux support is important to this project and filesystem is a critical piece. If anyone is volunteering to support whatever features Fedora needs, test it and keep it updated, that's when XFS can be considered for being available for default. I am not particular fond of the current solution either. I would prefer it to be completed supported or dropped. Rahul From tmus at tmus.dk Fri Jul 27 01:04:32 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 26 Jul 2007 23:04:32 -0200 Subject: F8t1: not able to use the whole screen In-Reply-To: <47324ed80707261058j5ec2fa03tdfd1ede43aa662e2@mail.gmail.com> References: <47324ed80707260826k6551d14ctebc99786866f6db1@mail.gmail.com> <47324ed80707261058j5ec2fa03tdfd1ede43aa662e2@mail.gmail.com> Message-ID: yonas Abraham wrote: > On 7/26/07, Thomas M Steenholdt wrote: >> yonas Abraham wrote: >> > I am using a 19" wide screen flat panel monitor, and after >> > successfully installed Rawhide (F8T1) yesterday, I found that like >> > about 10% of the screen on the left side is just black and unusable. I >> > taught the screen just shifted to the right, but no. The resolution is >> > set correctly (1400x900). >> > >> > /yonas >> > >> >> I've seen similar, only on slightly earlier versions of stuff... >> >> Make sure You are using the very latest driver (i810 in my case). >> >> If you're using an analog (VGA) connection to the monitor, make sure the >> cable is of a good quality. This is actually the one that solved things >> for me. The original cable was not broken as such, just a very cheap >> cable. >> >> Hope it helps. > > The machine workes fine if I boot to F7. and it had worked FC4 till F8T1. > > /yonas > Try using a gtf generated modeline, then. /Thomas From vonbrand at inf.utfsm.cl Thu Jul 26 22:06:08 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 26 Jul 2007 18:06:08 -0400 Subject: /lib/libxxx.so.x is truncated?? In-Reply-To: References: Message-ID: <7283.1185487568@laptop13.inf.utfsm.cl> sean wrote: > Running yum today I keep seeing errors like this: > > ............ > Updating : metacity ##################### [ 51/265] > /sbin/ldconfig: file /lib/libpamc.so.0 is truncated Same here, only on x86_64. -- 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 esandeen at redhat.com Fri Jul 27 02:05:15 2007 From: esandeen at redhat.com (Eric Sandeen) Date: Thu, 26 Jul 2007 21:05:15 -0500 Subject: please enable XFS in anaconda In-Reply-To: <20070726190754.68d0316c@ender> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> Message-ID: <46A952DB.5020304@redhat.com> Jesse Keating wrote: > On Thu, 26 Jul 2007 16:32:30 -0500 > Dan Yocum wrote: > >> It's stable, widely tested, widely deployed, and >> it's being actively developed and maintained (which is more than can >> be said of some other filesystems that remain in the default list). >> It's in the kernel, it shouldn't be "hidden" in the depths of >> anaconda anymore. > > How's the SELinux support these days? Should be fine. Do you know of any outstanding bugs? (the selinux debacle for FC6 was my fault... I took the sgi guys' word that a new mkfs option was well tested & optimal for selinux; turns out that wasn't quite right. Bug was resolved pretty quickly after working with the sgi xfs team, though). > And why can't I boot from xfs > yet? have you tried lately? It's always been fine on Suse... Based on the ext3 vs. grub corruption problem I sorted out with pjones for RHEL, it was because the way anaconda invoked grub, grub was doing STUPID things like writing to the underlying block device *while the filesystem was mounted* This occasionally wreaked havoc with ext3 and may have been the root cause for xfs too. "sync sync sync sync write to the bdev" is not a good plan for grub for ANY fs. The only other limitation on xfs & grub is that since the xfs superblock lives in the first sector, you can't install grub to an xfs *partition*. MBR works fine though. The remaining issue may be xfs+4kstacks+complicated/deep IO stacks on x86. Honestly I've never much liked 4kstacks... layered filesystems coming down the pipe (ecryptfs, unionfs) may well have trouble too. I'd prefer to see the stack size boot-time selectable, maybe - or perhaps disallow xfs (or issue a stern warning) on x86 boxes? (x86_64 & ia64, with sane stack size, work fine in this regard). -Eric From janina at rednote.net Fri Jul 27 02:15:40 2007 From: janina at rednote.net (Janina Sajka) Date: Thu, 26 Jul 2007 22:15:40 -0400 Subject: tftp-server -- connection refused issue Message-ID: <20070727021539.GA6148@rednote.net> I'm probably asking on the wrong list ... I'm getting connection refused in /var/log/messages over tftp when attempting to download firmware to my snom voip phones. Yet connecting from another Fedora box on my lan works perfectly. In addition I see what appears to be a correct rrq for the snom320.bin file when I look at tcpdump data coming from the snom. This is with the current tftp-server-0.42-4 All suggestions greatfully appreciated. I've two dead snoms at the moment that I'd dearly love to have back on line. -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From jkeating at redhat.com Fri Jul 27 02:15:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 22:15:47 -0400 Subject: please enable XFS in anaconda In-Reply-To: <46A952DB.5020304@redhat.com> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> Message-ID: <20070726221547.451f1cff@ender> On Thu, 26 Jul 2007 21:05:15 -0500 Eric Sandeen wrote: > have you tried lately? It's always been fine on Suse... Anaconda currently refuses to allow it. I was curious if the technical reason has been fixed yet or not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From esandeen at redhat.com Fri Jul 27 02:30:52 2007 From: esandeen at redhat.com (Eric Sandeen) Date: Thu, 26 Jul 2007 21:30:52 -0500 Subject: please enable XFS in anaconda In-Reply-To: <20070726221547.451f1cff@ender> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> <20070726221547.451f1cff@ender> Message-ID: <46A958DC.9000800@redhat.com> Jesse Keating wrote: > On Thu, 26 Jul 2007 21:05:15 -0500 > Eric Sandeen wrote: > >> have you tried lately? It's always been fine on Suse... > > Anaconda currently refuses to allow it. I was curious if the technical > reason has been fixed yet or not. I'm not sure the root cause was ever quite sorted for xfs, but after what I found with ext3, I'm more than willing to blame generic grub problems. :) Hmm wonder how hard it is to spin up an anaconda that allows it, for testing... -Eric From jkeating at redhat.com Fri Jul 27 02:51:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 22:51:40 -0400 Subject: please enable XFS in anaconda In-Reply-To: <46A958DC.9000800@redhat.com> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> <20070726221547.451f1cff@ender> <46A958DC.9000800@redhat.com> Message-ID: <20070726225140.7f68b177@ender> On Thu, 26 Jul 2007 21:30:52 -0500 Eric Sandeen wrote: > Hmm wonder how hard it is to spin up an anaconda that allows it, for > testing... Wouldn't be hard at all. Just find the python file that balks on xfs /boot and modify it, then include it in either RHUpdates/ on an NFS tree, or an updates.img that is loaded at boot time. If you don't get around to it, I may do just that next week after Test1 is baked. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Jul 27 02:46:26 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 26 Jul 2007 21:46:26 -0500 Subject: please enable XFS in anaconda In-Reply-To: <46A958DC.9000800@redhat.com> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> <20070726221547.451f1cff@ender> <46A958DC.9000800@redhat.com> Message-ID: <46A95C82.3080703@filteredperception.org> Eric Sandeen wrote: > Jesse Keating wrote: >> On Thu, 26 Jul 2007 21:05:15 -0500 >> Eric Sandeen wrote: >> >>> have you tried lately? It's always been fine on Suse... >> Anaconda currently refuses to allow it. I was curious if the technical >> reason has been fixed yet or not. > > I'm not sure the root cause was ever quite sorted for xfs, but after > what I found with ext3, I'm more than willing to blame generic grub > problems. :) > > Hmm wonder how hard it is to spin up an anaconda that allows it, for > testing... Perhaps not hard for the non-livecd-install case. But as the livecd installer currently works by copying an ext3 image file, instead of a format and file-level copy, that will be a bit more work. Though in a discussion about optimizing that process, Jeremy Katz did mention he might be looking into implementing that, as an improvement for the case when /usr is on a separate partition. Which would also be what would be needed for the non-ext3 (xfs) case. -dmc From jkeating at redhat.com Fri Jul 27 03:01:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Jul 2007 23:01:57 -0400 Subject: please enable XFS in anaconda In-Reply-To: <20070726225140.7f68b177@ender> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> <20070726221547.451f1cff@ender> <46A958DC.9000800@redhat.com> <20070726225140.7f68b177@ender> Message-ID: <20070726230157.432d9fb1@ender> On Thu, 26 Jul 2007 22:51:40 -0400 Jesse Keating wrote: > Wouldn't be hard at all. Just find the python file that balks on > xfs /boot and modify it, then include it in either RHUpdates/ on an > NFS tree, or an updates.img that is loaded at boot time. If you > don't get around to it, I may do just that next week after Test1 is > baked. In fact it's in partitions.py, round like 1000. Easy enough to strip out for testing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From esandeen at redhat.com Fri Jul 27 03:20:27 2007 From: esandeen at redhat.com (Eric Sandeen) Date: Thu, 26 Jul 2007 22:20:27 -0500 Subject: please enable XFS in anaconda In-Reply-To: <20070726230157.432d9fb1@ender> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> <20070726221547.451f1cff@ender> <46A958DC.9000800@redhat.com> <20070726225140.7f68b177@ender> <20070726230157.432d9fb1@ender> Message-ID: <46A9647B.4050100@redhat.com> Jesse Keating wrote: > On Thu, 26 Jul 2007 22:51:40 -0400 > Jesse Keating wrote: > >> Wouldn't be hard at all. Just find the python file that balks on >> xfs /boot and modify it, then include it in either RHUpdates/ on an >> NFS tree, or an updates.img that is loaded at boot time. If you >> don't get around to it, I may do just that next week after Test1 is >> baked. > > In fact it's in partitions.py, round like 1000. Easy enough to strip > out for testing. Well if I can make time I'd be happy to help investigate. I'm out 'til next Tuesday, I'll catch up then & see if there's any news. :) Thanks guys, -Eric From caolanm at redhat.com Fri Jul 27 06:55:13 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 27 Jul 2007 07:55:13 +0100 Subject: /lib/libxxx.so.x is truncated?? In-Reply-To: <7283.1185487568@laptop13.inf.utfsm.cl> References: <7283.1185487568@laptop13.inf.utfsm.cl> Message-ID: <1185519313.7864.1.camel@Nom> On Thu, 2007-07-26 at 18:06 -0400, Horst H. von Brand wrote: > sean wrote: > > Running yum today I keep seeing errors like this: > > > > ............ > > Updating : metacity ##################### [ 51/265] > > /sbin/ldconfig: file /lib/libpamc.so.0 is truncated > > Same here, only on x86_64. My understanding is this is why there was a mini mass-rebuild yesterday of a pile of stuff built with a given snapshot of gcc C. From fedora at camperquake.de Fri Jul 27 07:37:54 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 27 Jul 2007 09:37:54 +0200 Subject: /lib/libxxx.so.x is truncated?? In-Reply-To: <1185519313.7864.1.camel@Nom> References: <7283.1185487568@laptop13.inf.utfsm.cl> <1185519313.7864.1.camel@Nom> Message-ID: <20070727093754.55f12838@banea.int.addix.net> Hi. On Fri, 27 Jul 2007 07:55:13 +0100, Caolan McNamara wrote: > My understanding is this is why there was a mini mass-rebuild > yesterday of a pile of stuff built with a given snapshot of gcc Was the rebuild the cause of this or was it supposed to fix it? From kwade at redhat.com Fri Jul 27 07:52:16 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 27 Jul 2007 00:52:16 -0700 Subject: Extra Packages for Enterprise Linux (EPEL) Now Open Message-ID: <1185522736.17380.989.camel@erato.phig.org> If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you. Ever find yourself rebuilding one of the high-quality Fedora packages for your EL version because it didn't ship with the EL distro? Friends, there is a new way. May we introduce ... Extra Packages for Enterprise Linux (EPEL) EPEL is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora version. Yet, there room for new packages and contributors. Currently, around 1000 packages are available, and we've been growing at the rate of several dozen packages every week. http://fedoraproject.org/wiki/EPEL How to use EPEL: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse You can look for packages here: http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated Looking for a package not in EPEL or other questions? http://fedoraproject.org/wiki/EPEL/FAQ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri Jul 27 08:31:10 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 10:31:10 +0200 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <20070724223314.13ea9d19@ender> References: <20070724223314.13ea9d19@ender> Message-ID: <200707271031.14144.opensource@till.name> On Wednesday 25 July 2007 04:33:14 Jesse Keating wrote: > We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' cryptsetup-luks before F7 was built statically and beginning in Rawhide it is built dynamically. The problem is that it needs some libs, that are currently in /usr/lib. This will break systems, where /usr is encrypted and afaik blocks the encrypted rootfs feature that is planned for F8. Now I want to file bugs against the following packages to move the regarding libs to /lib, does this interfer with the freeze or can this happen without any problems? /usr/lib/libgcrypt.so.11 -> libgcrypt /usr/lib/libpopt.so.0 -> popt (rpm) /usr/lib/libgpg-error.so.0 -> libgpg-error Regards, Till From mtasaka at ioa.s.u-tokyo.ac.jp Fri Jul 27 08:34:05 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 27 Jul 2007 17:34:05 +0900 Subject: /lib/libxxx.so.x is truncated?? In-Reply-To: <20070727093754.55f12838@banea.int.addix.net> References: <7283.1185487568@laptop13.inf.utfsm.cl> <1185519313.7864.1.camel@Nom> <20070727093754.55f12838@banea.int.addix.net> Message-ID: <46A9ADFD.3010001@ioa.s.u-tokyo.ac.jp> Ralf Ertzinger wrote, at 07/27/2007 04:37 PM +9:00: > Hi. > > On Fri, 27 Jul 2007 07:55:13 +0100, Caolan McNamara wrote: > >> My understanding is this is why there was a mini mass-rebuild >> yesterday of a pile of stuff built with a given snapshot of gcc > > Was the rebuild the cause of this or was it supposed to fix it? > This is already announced. https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01389.html Mamoru From opensource at till.name Fri Jul 27 08:46:36 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 10:46:36 +0200 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <200707271031.14144.opensource@till.name> References: <20070724223314.13ea9d19@ender> <200707271031.14144.opensource@till.name> Message-ID: <200707271046.39055.opensource@till.name> On Friday 27 July 2007 10:31:10 Till Maas wrote: > cryptsetup-luks before F7 was built statically and beginning in Rawhide it > is built dynamically. The problem is that it needs some libs, that are Here ist the coresponding bug report: https://bugzilla.redhat.com/243228 Regards, Till From laroche at redhat.com Fri Jul 27 09:05:51 2007 From: laroche at redhat.com (Florian La Roche) Date: Fri, 27 Jul 2007 11:05:51 +0200 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <200707271046.39055.opensource@till.name> References: <20070724223314.13ea9d19@ender> <200707271031.14144.opensource@till.name> <200707271046.39055.opensource@till.name> Message-ID: <20070727090551.GA13543@dudweiler.stuttgart.redhat.com> On Fri, Jul 27, 2007 at 10:46:36AM +0200, Till Maas wrote: > On Friday 27 July 2007 10:31:10 Till Maas wrote: > > > cryptsetup-luks before F7 was built statically and beginning in Rawhide it > > is built dynamically. The problem is that it needs some libs, that are > > Here ist the coresponding bug report: > https://bugzilla.redhat.com/243228 This should be cloned for all the different rpm packages and also put on F8Target. regards, Florian La Roche From tla at rasmil.dk Fri Jul 27 10:10:36 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 27 Jul 2007 12:10:36 +0200 Subject: Abuse of Fedora trademark In-Reply-To: <46A8991E.3050306@hhs.nl> References: <46A8991E.3050306@hhs.nl> Message-ID: <46A9C49C.4000909@rasmil.dk> Hans de Goede wrote: > Hi All, > > I was reading todays lwn and found this article: > http://lwn.net/Articles/242830/ > > About this piece of software: > http://www.kde-apps.org/content/show.php?content=62829 > > Which is a utility to ease the install of certain software on Fedora. > As you all know I've suggested the inclusion of such a utility into > Fedora, and thus I have nothing against the idea in general, nor to > call something like this easyfedora, as its called. But this software > is released under a proprietary license (according to the webpage). To > me the use of the Fedora Trademark in combination with a proprietary > license is not acceptable and a clear violation of the Fedora > trademark policies. Can those who have the power please kindly request > this person to cease and desist. > > Thanks & Regards, > > Hans > Hi Hans Based on http://fedoraproject.org/wiki/Legal/TrademarkGuidelines , maybe you should send the mail to *trademark*s at redhat.com Best Regards, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.portal at free.fr Fri Jul 27 10:32:53 2007 From: alain.portal at free.fr (Alain PORTAL) Date: Fri, 27 Jul 2007 12:32:53 +0200 Subject: Abuse of Fedora trademark In-Reply-To: <46A9C49C.4000909@rasmil.dk> References: <46A8991E.3050306@hhs.nl> <46A9C49C.4000909@rasmil.dk> Message-ID: <200707271232.54371.alain.portal@free.fr> Le vendredi 27 juillet 2007, Tim Lauridsen a ?crit : > Based on http://fedoraproject.org/wiki/Legal/TrademarkGuidelines , maybe > you should send the mail to *trademark*s at redhat.com > Before using a big hammer to swat a fly, perhaps it should be a nice idea to ask the developer to remove any direct reference (name, logo) to Fedora, don't you think? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From hughsient at gmail.com Fri Jul 27 10:28:50 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 11:28:50 +0100 Subject: Blog post about package management (aimed at fedora) Message-ID: <1185532130.10773.10.camel@work> I've blogged about package management in Fedora (and how it sucks in other distros too) and also discussed abstract per-system package management over DBUS interfaces. I would appreciate feedback on http://hughsient.livejournal.com/31429.html either on the blog as comments, personal email, or just cc'd to the list. This is obviously not a F8 target, more an idea I discussed with some other desktop hackers at GUADEC and FOSDEM earlier this year. "Crack" would be a valid comment but obviously, I would prefer more in depth and reasoned criticism :-) Many thanks, Richard Hughes From buildsys at redhat.com Fri Jul 27 10:42:11 2007 From: buildsys at redhat.com (Build System) Date: Fri, 27 Jul 2007 06:42:11 -0400 Subject: rawhide report: 20070727 changes Message-ID: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> Updated Packages: anaconda-11.3.0.12-1 -------------------- * Thu Jul 26 2007 Bill Nottingham - 11.3.0.12-1 - fix stage2 generation (jkeating) * Thu Jul 26 2007 Jeremy Katz - 11.3.0.11-1 - GPT boot bits (pjones) - Fix loopback clobbering problem - Fix tui installs to not hang (dcantrell) - Fix stage2 generation to use the tree and not configured repos * Wed Jul 25 2007 Jeremy Katz - 11.3.0.10-1 - fix media installs (#249371) kernel-2.6.23-0.49.rc1.git3.fc8 ------------------------------- * Thu Jul 26 2007 Chuck Ebbert - 2.6.23-rc1-git3 * Wed Jul 25 2007 John W. Linville - Update git-wireless-dev.patch (iwlwifi & rt2x00 updates) - Drop git-iwlwifi.patch * Wed Jul 25 2007 Chuck Ebbert - 2.6.23-rc1-git1 m17n-contrib-1.1.3-3.fc8 ------------------------ * Wed Jul 25 2007 Parag Nemade - 1.1.3-3 - Added m17n-contrib as Requires for mk_pkg() macro generating packages. - Added m17b-contrib and m17n-db-lang as Requires for mk_pkg_uses_db() macro generating packages. m17n-db-1.4.0-4.fc8 ------------------- * Wed Jul 25 2007 Parag Nemade - 1.4.0-4 - Added m17n-db as Requires for mk_pkg() macro generating packages. - Added m17b-db and m17n-contrib-lang as Requires for mk_pkg_uses_contrib() macro generating packages. * Wed Jul 25 2007 Jens Petersen - 1.4.0-3 - cleanup summaries and descriptions - make just main package own m17n and icons dir - replace %makeinstall with make install * Tue Jul 24 2007 Parag Nemade - 1.4.0-2.1 - Fix directory ownership issue selinux-policy-3.0.4-1.fc8 -------------------------- * Mon Jul 23 2007 Dan Walsh 3.0.4-1 - Update with latest changes from upstream Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From drago01 at gmail.com Fri Jul 27 10:43:25 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 27 Jul 2007 12:43:25 +0200 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185532130.10773.10.camel@work> References: <1185532130.10773.10.camel@work> Message-ID: <46A9CC4D.6030807@gmail.com> Richard Hughes wrote: > I've blogged about package management in Fedora (and how it sucks in > other distros too) and also discussed abstract per-system package > management over DBUS interfaces. > > I would appreciate feedback on > http://hughsient.livejournal.com/31429.html "Do we have to make the API asynchronous?" YES!!! the best way to fix the progressbar hangs is multithreading. let the gui draw its stuff, while a background thread does the real work. yumex afaik works this way. From drago01 at gmail.com Fri Jul 27 10:47:33 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 27 Jul 2007 12:47:33 +0200 Subject: Abuse of Fedora trademark In-Reply-To: <200707271232.54371.alain.portal@free.fr> References: <46A8991E.3050306@hhs.nl> <46A9C49C.4000909@rasmil.dk> <200707271232.54371.alain.portal@free.fr> Message-ID: <46A9CD45.8010203@gmail.com> Alain PORTAL wrote: > Le vendredi 27 juillet 2007, Tim Lauridsen a ?crit : > > >> Based on http://fedoraproject.org/wiki/Legal/TrademarkGuidelines , maybe >> you should send the mail to *trademark*s at redhat.com >> >> > > Before using a big hammer to swat a fly, perhaps it should be a nice idea to > ask the developer to remove any direct reference (name, logo) to Fedora, > don't you think? > +1 else it might cause the same flamewars as the bcm stuff on the openbsd-list but we also have too tell him not to violate the gpl (see kevin's post) From bob.chiodini at nasa.gov Fri Jul 27 10:57:10 2007 From: bob.chiodini at nasa.gov (Bob Chiodini) Date: Fri, 27 Jul 2007 06:57:10 -0400 Subject: tftp-server -- connection refused issue In-Reply-To: <20070727021539.GA6148@rednote.net> References: <20070727021539.GA6148@rednote.net> Message-ID: <46A9CF86.2020607@nasa.gov> Janina Sajka wrote: > I'm probably asking on the wrong list ... > > I'm getting connection refused in /var/log/messages over tftp when > attempting to download firmware to my snom voip phones. Yet connecting > from another Fedora box on my lan works perfectly. In addition I see > what appears to be a correct rrq for the snom320.bin file when I look at > tcpdump data coming from the snom. > > This is with the current tftp-server-0.42-4 > > All suggestions greatfully appreciated. I've two dead snoms at the > moment that I'd dearly love to have back on line. > > Janina, Are there any other messages in /var/log/messages related to the tftp request? Tcpwrappers, iptables and selinux come to mind and possible culprits. Bob... From sundaram at fedoraproject.org Fri Jul 27 11:03:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 27 Jul 2007 16:33:32 +0530 Subject: Abuse of Fedora trademark In-Reply-To: <200707271232.54371.alain.portal@free.fr> References: <46A8991E.3050306@hhs.nl> <46A9C49C.4000909@rasmil.dk> <200707271232.54371.alain.portal@free.fr> Message-ID: <46A9D104.4050900@fedoraproject.org> Alain PORTAL wrote: > Le vendredi 27 juillet 2007, Tim Lauridsen a ?crit : > >> Based on http://fedoraproject.org/wiki/Legal/TrademarkGuidelines , maybe >> you should send the mail to *trademark*s at redhat.com >> > > Before using a big hammer to swat a fly, perhaps it should be a nice idea to > ask the developer to remove any direct reference (name, logo) to Fedora, > don't you think? > Legal can handle this politely. They have already got this information. Rahul From drago01 at gmail.com Fri Jul 27 11:09:11 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 27 Jul 2007 13:09:11 +0200 Subject: Plan for tomorrows (20070726) FESCO meeting In-Reply-To: <46A8C269.6060904@hhs.nl> References: <1185384324.2807.4.camel@kennedy> <46A853E7.3030303@hhs.nl> <1185461840.14697.464.camel@pmac.infradead.org> <46A8BB05.4080206@leemhuis.info> <1185463585.14697.475.camel@pmac.infradead.org> <46A8C269.6060904@hhs.nl> Message-ID: <46A9D257.7070507@gmail.com> Hans de Goede wrote: > I must say I like this approach, it avoids the whole problem of having > to rebuild kmods all the time and of wether to delay kernel security > updates until all kmods are fixetd etc. I do think however that this > might cause some pain for Dave Jones, whose job already is hard. Maybe > we should ask him what he thinks about this? > well this will cause problems for Dave and Chuck because when one of this modules does not build they either have to fix it or just disable it. 1) creates more work for the kernel maintainers 2) does not solve the problem at all From kagesenshi.87 at gmail.com Fri Jul 27 11:20:50 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 27 Jul 2007 19:20:50 +0800 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: <200707262146.23188.opensource@till.name> References: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> <200707262146.23188.opensource@till.name> Message-ID: On 7/27/07, Till Maas wrote: > On Thursday 26 July 2007 19:13:39 Hikaru Amano wrote: > > import urlgrabber > > import os > > os.environ['https_proxy'] = 'http://160.0.234.1:8080/' > > urlgrabber.urlgrab('https://161.0.2.218/pub/mirror/repos/fedora_i686/repoda > >ta/repomd.xml') > > With another proxy and another https URL above works for me. > > Does this work for you: > curl -x http://160.0.234.1:8080/ > https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml > > Or this: > curl -p http://160.0.234.1:8080/ > https://161.0.2.218/pub/mirror/repos/fedora_i686/repodata/repomd.xml > I forgot to mention, all other applications (wget, curl, firefox, elinks, etc) are able to connect and retrieve the file through the proxy .. but not python-urlgrabber and yum .. -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From billcrawford1970 at gmail.com Fri Jul 27 11:46:24 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 27 Jul 2007 12:46:24 +0100 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: References: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> <200707262146.23188.opensource@till.name> Message-ID: <544eb990707270446s19fea6b7m27cdf8e286a7220e@mail.gmail.com> On 27/07/07, Hikaru Amano wrote: > > I forgot to mention, all other applications (wget, curl, firefox, > elinks, etc) are able to connect and retrieve the file through the > proxy .. but not python-urlgrabber and yum .. > Squid simply won't do it that way (GET with an https: URL). The other programs are presumably doing a CONNECT request, which Squid does support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Fri Jul 27 11:53:48 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 27 Jul 2007 13:53:48 +0200 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: <544eb990707270446s19fea6b7m27cdf8e286a7220e@mail.gmail.com> References: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> <200707262146.23188.opensource@till.name> <544eb990707270446s19fea6b7m27cdf8e286a7220e@mail.gmail.com> Message-ID: <20070727135348.5d3d5a6e@banea.int.addix.net> Hi. On Fri, 27 Jul 2007 12:46:24 +0100, Bill Crawford wrote: > Squid simply won't do it that way (GET with an https: URL). The other > programs are presumably doing a CONNECT request, which Squid does > support. HTTPS must use CONNECT, GET is plain broken for proxyconnects. From mschwendt.tmp0701.nospam at arcor.de Fri Jul 27 12:17:27 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 27 Jul 2007 14:17:27 +0200 Subject: rawhide report: 20070727 changes In-Reply-To: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> References: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> Message-ID: <20070727141727.4a3ba849.mschwendt.tmp0701.nospam@arcor.de> http://koji.fedoraproject.org/koji/buildinfo?buildID=11907 Started Wed, 25 Jul 2007 06:00:48 MST Completed Wed, 25 Jul 2007 06:22:06 MST State complete Task build (dist-f8, devel:grass-6_2_2-1_fc8) Why can this not be found in the repository and build reports from 07-24 to 07-27? From jkeating at redhat.com Fri Jul 27 12:19:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 08:19:45 -0400 Subject: rawhide report: 20070727 changes In-Reply-To: <20070727141727.4a3ba849.mschwendt.tmp0701.nospam@arcor.de> References: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> <20070727141727.4a3ba849.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070727081945.6ab268e9@ender> On Fri, 27 Jul 2007 14:17:27 +0200 Michael Schwendt wrote: > Started Wed, 25 Jul 2007 06:00:48 MST > Completed Wed, 25 Jul 2007 06:22:06 MST > State complete > Task build (dist-f8, devel:grass-6_2_2-1_fc8) > > Why can this not be found in the repository and build reports > from 07-24 to 07-27? Because we're in a freeze, as announced multiple times to fedora-devel-list, which posts to this list, and pointed out multiple times both http://fedoraproject.org/wiki/ReleaseEngineering/Overview#head-f1ce962de535354f76b5103bac7be2d22c9a9045 and http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Fri Jul 27 12:34:23 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 27 Jul 2007 14:34:23 +0200 Subject: rawhide report: 20070727 changes In-Reply-To: <20070727081945.6ab268e9@ender> References: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> <20070727141727.4a3ba849.mschwendt.tmp0701.nospam@arcor.de> <20070727081945.6ab268e9@ender> Message-ID: <20070727143423.082f62e4.mschwendt.tmp0701.nospam@arcor.de> On Fri, 27 Jul 2007 08:19:45 -0400, Jesse Keating wrote: > On Fri, 27 Jul 2007 14:17:27 +0200 > Michael Schwendt wrote: > > > Started Wed, 25 Jul 2007 06:00:48 MST > > Completed Wed, 25 Jul 2007 06:22:06 MST > > State complete > > Task build (dist-f8, devel:grass-6_2_2-1_fc8) > > > > Why can this not be found in the repository and build reports > > from 07-24 to 07-27? > > Because we're in a freeze, as announced multiple times to > fedora-devel-list, which posts to this list, and pointed out multiple > times both > http://fedoraproject.org/wiki/ReleaseEngineering/Overview#head-f1ce962de535354f76b5103bac7be2d22c9a9045 > and http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy Poorly chosen tag names. It could not be more confusing. :( http://koji.fedoraproject.org/koji/tags The package is tagged with "dist-f8", but there's also "dist-rawhide" and "f8-test1", and the last sentence of DevelFreezePolicy says Note that ignoring the freeze process can lead to your package not getting tagged for the freeze tag, and thus not pushed to rawhide and the final release. and that inspite of a package being tagged "dist-f8". Then you, Jesse, announced the following: We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' that is a container for the packages that are destined to be in Test1 (and rawhide until test1 is fully composed and released to mirrors). ^^^^^^^^^^^ Uh? "and rawhide"? Apparently not. It's not my package. But I wonder why the EVR upgrade problems list gets longer? From mschwendt.tmp0701.nospam at arcor.de Fri Jul 27 12:39:46 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 27 Jul 2007 14:39:46 +0200 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <20070724223314.13ea9d19@ender> References: <20070724223314.13ea9d19@ender> Message-ID: <20070727143946.e53bae03.mschwendt.tmp0701.nospam@arcor.de> On Tue, 24 Jul 2007 22:33:14 -0400, Jesse Keating wrote: > We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' > that is a container for the packages that are destined to be in Test1 > (and rawhide until test1 is fully composed and released to mirrors). > As per http://fedoraproject.org/wiki/ReleaseEngineering/Overview , > builds from devel/ will continue to be tagged with 'dist-f8' and will > be picked up by rawhide composes once the freeze is over. If you feel > you must have your build in Test1 and it isn't already tagged with > 'f8-test1', please follow > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy This doesn't match the DevelFreezePolicy page. Note that ignoring the freeze process can lead to your package not getting tagged for the freeze tag, and thus not pushed to rawhide and the final release. What is the "final release" here? F8 Test1 final? Or F8 final? Packagers must mail rel-eng and ask for a package to be tagged "f8-test1" if they want the package to be included in F8 Test 1. But if they don't, the package would appear in Rawhide after the freeze and hence would enter f8-test2, and so on, and F8 final *automatically*. From pmatilai at redhat.com Fri Jul 27 12:40:40 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Fri, 27 Jul 2007 15:40:40 +0300 (EEST) Subject: RPM roadmapping Message-ID: Hey all, I know I'm opening up Pandoras box here but what the heck, it's Friday and I'm feeling slightly bored... With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode, time to start looking forward to next major release. While the focus will be largely in cleaning up and streamlining the codebase, it can't realistically be all about just that. Not everybody is on rpm-maint list and we'd like to hear the wishes of (Fedora) developers/packagers too. So: what have you always wanted to do with rpm, but wasn't able to? Or the other way around: what you always wished rpm would do for you? What always annoyed you out of your mind? Just to kick off the discussion (like it was necessary, this is rpm afterall...), here are a few things that have been brought up in various forums and private discussions, but don't feel constrained by these items, they're just some examples of what's being considered: * Improving automatic dependency extraction - Plugin architecture for internal dependency extractor to avoid having to patch rpm itself for each new language - libtool, pkgconfig requires + provides (easily ported from rpm5.org) - (python for me) library requires + provides discovery - Buildrequires match cross-arch on multilib, not good - -devel package dependencies match cross-arch on multilib, not good * Python bindings - Ever wanted to fully drive a package build from python, without having to resort to screenscraping rpmbuild output etc? I know I have... * Unix philosophy - do just one thing and do it well: - RPM is not a GPG key manager but a package manager. - RPM is not an ftp/http client, it's a package manager. The more specific you can be, the better - "make it not suck" isn't productive. Of course there's no way everything can be done, we want the next major release out before end of the decade... Also this is not a voting where most votes guarantee implementation, but consider it your chance to be heard. I'm listening... :) - Panu - From jkeating at redhat.com Fri Jul 27 12:46:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 08:46:13 -0400 Subject: rawhide report: 20070727 changes In-Reply-To: <20070727143423.082f62e4.mschwendt.tmp0701.nospam@arcor.de> References: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> <20070727141727.4a3ba849.mschwendt.tmp0701.nospam@arcor.de> <20070727081945.6ab268e9@ender> <20070727143423.082f62e4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070727084613.171f67d0@ender> On Fri, 27 Jul 2007 14:34:23 +0200 Michael Schwendt wrote: > Poorly chosen tag names. It could not be more confusing. :( Suggestions? > http://koji.fedoraproject.org/koji/tags > > The package is tagged with "dist-f8", but there's also "dist-rawhide" > and "f8-test1", and the last sentence of DevelFreezePolicy says > > Note that ignoring the freeze process can lead to your package not > getting tagged for the freeze tag, and thus not pushed to rawhide > and the final release. > > and that inspite of a package being tagged "dist-f8". > > Then you, Jesse, announced the following: > > We have frozen for Fedora 8 Test 1. A "freeze" tag exists, > 'f8-test1' that is a container for the packages that are destined to > be in Test1 (and rawhide until test1 is fully composed and released > to mirrors). ^^^^^^^^^^^ > > Uh? "and rawhide"? Apparently not. > > It's not my package. But I wonder why the EVR upgrade problems list > gets longer? So lets see, the package is tagged with 'dist-f8'. I announced that the freeze tag is 'f8-test1', and my mail states that if your package doesn't get tagged with the freeze tag, it won't show up in the test release, nor rawhide during the freeze. Does 'dist-f8' == 'f8-test1' ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 27 12:48:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 08:48:14 -0400 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <20070727143946.e53bae03.mschwendt.tmp0701.nospam@arcor.de> References: <20070724223314.13ea9d19@ender> <20070727143946.e53bae03.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070727084814.474d6844@ender> On Fri, 27 Jul 2007 14:39:46 +0200 Michael Schwendt wrote: > This doesn't match the DevelFreezePolicy page. > > Note that ignoring the freeze process can lead to your package not > getting tagged for the freeze tag, and thus not pushed to rawhide > and the final release. > > What is the "final release" here? F8 Test1 final? Or F8 final? > > Packagers must mail rel-eng and ask for a package to be tagged > "f8-test1" if they want the package to be included in F8 Test 1. But > if they don't, the package would appear in Rawhide after the freeze > and hence would enter f8-test2, and so on, and F8 final > *automatically*. Thank you for pointing out this unclarity. This page has existed for a while, would have bee nice to get feedback before. I'll adjust. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 27 12:49:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 08:49:36 -0400 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <20070727084814.474d6844@ender> References: <20070724223314.13ea9d19@ender> <20070727143946.e53bae03.mschwendt.tmp0701.nospam@arcor.de> <20070727084814.474d6844@ender> Message-ID: <20070727084936.5fecc421@ender> On Fri, 27 Jul 2007 08:48:14 -0400 Jesse Keating wrote: > Thank you for pointing out this unclarity. This page has existed for > a while, would have bee nice to get feedback before. I'll adjust. Actually I see that we probably need another policy page, one specifically for test releases. I'll work on that today. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Fri Jul 27 12:50:23 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 27 Jul 2007 14:50:23 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <46A9EA0F.30405@gmail.com> Panu Matilainen wrote: > > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to > do with rpm, but wasn't able to? Or the other way around: what you > always wished rpm would do for you? What always annoyed you out of > your mind? arch requires and provides ... to end the endless multilib discussions ;) should be automatic until the packager say Requires: foo.arch From opensource at till.name Fri Jul 27 13:01:27 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 15:01:27 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <200707271502.13034.opensource@till.name> On Friday 27 July 2007 14:40:40 Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? I am missing "soft dependencies", e.g. the possibility to make a package suggest which other packages may enhance it, e.g. with plugins. Afaik in debian packages it is called "Suggests:". Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dimi at lattica.com Fri Jul 27 13:20:22 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 27 Jul 2007 09:20:22 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185542422.3928.54.camel@dimi.lattica.com> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? * Version control the meta-information This can't be efficiently done outside RPM, and it would provide an administrator with an invaluable tool (say a malfunction starts at about 4am): - what packages changes are different from yesterday? - what files have changed for package foo between version V and W? - what's the history of package foo on this system? Not very difficult, but quite useful. Every time something breaks on a system (usually via an automatic yum update) I would kill for the ability to run such queries. * Ability to save a pristine copy for the configuration files This would make it a _lot_ simpler to integrate the new .rpmnew files, in a lot of cases being as simple as: diff foo.pristine foo | patch -o foo foo.rpmnew At the very least to provide some sort of mechanism that would permit an external trigger to so easily and efficiently. This maybe already implemented (never checked in depth the transaction triggers), but a mechanism for external tools to hook into the transactions would be great. More generally, the external triggers must be given enough information about the current transaction to be able to know the delta that the transaction introduces without having to scan the entire state of the system. As a litmus test, you should be able to implement the version control idea mentioned above via this mechanism easily and efficiently. -- Dimi Paun Lattica, Inc. From ezigler at superhero.org Fri Jul 27 13:22:04 2007 From: ezigler at superhero.org (Erich Zigler) Date: Fri, 27 Jul 2007 08:22:04 -0500 (CDT) Subject: RPM roadmapping In-Reply-To: References: Message-ID: <46159.192.193.221.141.1185542524.squirrel@mail.superhero.org> On Fri, July 27, 2007 7:40 am, Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? I would like to be able to specify in what order Requires get installed in. From mclasen at redhat.com Fri Jul 27 13:23:52 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 09:23:52 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185542632.3650.11.camel@localhost.localdomain> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? A working %posttrans or equivalent. From fedora at camperquake.de Fri Jul 27 13:29:36 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 27 Jul 2007 15:29:36 +0200 Subject: RPM roadmapping In-Reply-To: <46159.192.193.221.141.1185542524.squirrel@mail.superhero.org> References: <46159.192.193.221.141.1185542524.squirrel@mail.superhero.org> Message-ID: <20070727152936.3523914c@banea.int.addix.net> Hi. On Fri, 27 Jul 2007 08:22:04 -0500 (CDT), Erich Zigler wrote: > I would like to be able to specify in what order Requires get > installed in. I'd argue that if you have to specify that in order for the install to work then your requires are wrong. From mschwendt.tmp0701.nospam at arcor.de Fri Jul 27 13:31:04 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 27 Jul 2007 15:31:04 +0200 Subject: rawhide report: 20070727 changes In-Reply-To: <20070727084613.171f67d0@ender> References: <200707271042.l6RAgBJQ026631@porkchop.devel.redhat.com> <20070727141727.4a3ba849.mschwendt.tmp0701.nospam@arcor.de> <20070727081945.6ab268e9@ender> <20070727143423.082f62e4.mschwendt.tmp0701.nospam@arcor.de> <20070727084613.171f67d0@ender> Message-ID: <20070727153104.5a886bf6.mschwendt.tmp0701.nospam@arcor.de> On Fri, 27 Jul 2007 08:46:13 -0400, Jesse Keating wrote: > > Poorly chosen tag names. It could not be more confusing. :( > > Suggestions? 1) Distinguish tags and build targets. Make the names unique. Why is a build target named dist-f8 and also a tag dist-f8? This also results in strange koji status information. 2) Let all tags start with f7, f8 and so on. Why not give tags the name "f8-devel" or "f8-final"? What is the purpose of the "dist-" prefix on only *some* tags? 3) During the freeze, call the rawhide build report "F8 Test 1 build report". Create a separate build report for all other builds against dist-f8. Concerning the "Frozen for Fedora 8 Test1" message and the Wiki pages, it is difficult to spot the really relevant details. Short step-by-step details and instructions relevant to packagers. F8 Test 1 freeze means: What we see in daily Rawhide is Test 1 work-in-progress until the freeze is over. Ordinary "make build" builds don't enter this Rawhide unless rel-eng is mailed to tag the builds "f8-test1". When the freeze is over, Rawhide switches back to normal f8-devel (currently "dist-f8"), including f8-test1 builds. From ezigler at superhero.org Fri Jul 27 13:29:15 2007 From: ezigler at superhero.org (Erich Zigler) Date: Fri, 27 Jul 2007 08:29:15 -0500 (CDT) Subject: RPM roadmapping In-Reply-To: <20070727152936.3523914c@banea.int.addix.net> References: <46159.192.193.221.141.1185542524.squirrel@mail.superhero.org> <20070727152936.3523914c@banea.int.addix.net> Message-ID: <17801.192.193.221.141.1185542955.squirrel@mail.superhero.org> On Fri, July 27, 2007 8:29 am, Ralf Ertzinger wrote: > I'd argue that if you have to specify that in order for the install to > work then your requires are wrong. I would agree. But with corporations providing RPM's in which you do not have the sources for or .spec files for you cannot always fix them. From nphilipp at redhat.com Fri Jul 27 13:41:44 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 27 Jul 2007 15:41:44 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <46A7337C.70602@leemhuis.info> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185195554.3165.1.camel@weaponx.rchland.ibm.com> <1185293663.20980.18.camel@mccallum.corsepiu.local> <1185293966.2408.123.camel@cutter> <1185304845.20980.87.camel@mccallum.corsepiu.local> <20070724153420.26b167a7@ender> <1185306599.2686.1.camel@laptopd505.fenrus.org> <20070724155745.5fee23d5@localhost.localdomain> <1185360173.6631.56.camel@hopeson> <20070725070557.546b96c6@ender> <46A7337C.70602@leemhuis.info> Message-ID: <1185543704.3325.20.camel@gibraltar.stuttgart.redhat.com> On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote: > > On 25.07.2007 13:05, Jesse Keating wrote: > > On Wed, 25 Jul 2007 06:42:53 -0400 > > Simo Sorce wrote: > > > >> So a tool that marks samba as GPLv3 may raise a high number of false > >> positives. I guess many other projects will fall under the same > >> conditions. > >> [...] > > I think you're missing the point of the task. The task isn't to mark > > perfectly in every spec file exactly what a package contains. Instead > > it can mark the easy cases, and denote something in the hard cases so > > that when an issue arises, we can easily weed out the easy cases and > > focus on the hard ones manually. > > In addition -- in some cases like the quoted one for samba it *might* be > the easiest and cleanest solution for everyone to just put the libs with > a different license into a different (sub)package. This would only be sensible if we had a way to tag the license for the source and the main binary package differently. Unless that exists, we can only put "License: " into such a package because you'd need to cover the source RPM. 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 katzj at redhat.com Fri Jul 27 13:47:41 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 09:47:41 -0400 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <200707271031.14144.opensource@till.name> References: <20070724223314.13ea9d19@ender> <200707271031.14144.opensource@till.name> Message-ID: <1185544061.15991.11.camel@localhost.localdomain> On Fri, 2007-07-27 at 10:31 +0200, Till Maas wrote: > On Wednesday 25 July 2007 04:33:14 Jesse Keating wrote: > > We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' > > cryptsetup-luks before F7 was built statically and beginning in Rawhide it is > built dynamically. The problem is that it needs some libs, that are currently > in /usr/lib. This will break systems, where /usr is encrypted Yes, the libs probably need moving... > and afaik blocks the encrypted rootfs feature that is planned for F8. The initramfs uses dynamically linked binaries these days and will grab the libraries from wherever they are. > Now I want to > file bugs against the following packages to move the regarding libs to /lib, > does this interfer with the freeze or can this happen without any problems? I suspect that we won't be able to get them fixed for test1 purely due to timing (although if they get built early today, there's a slight chance). But having a caveat of "you can only test this if you don't have a separate /usr" isn't terrible for test1. Especially as the rest of the support also requires changes which aren't in packages yet... Jeremy From notting at redhat.com Fri Jul 27 13:53:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 09:53:45 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185532130.10773.10.camel@work> References: <1185532130.10773.10.camel@work> Message-ID: <20070727135345.GH25862@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > I've blogged about package management in Fedora (and how it sucks in > other distros too) and also discussed abstract per-system package > management over DBUS interfaces. > > I would appreciate feedback on > http://hughsient.livejournal.com/31429.html either on the blog as > comments, personal email, or just cc'd to the list. We've actually discussed this before. Basically, with the current state of yum-updatesd: 1) we could make it dumber. Dead simple; doesn't have modes to install updates, etc. All it does is check for new metadata - it's possible that it doesn't even check it against what you have installed. Simple == predictable. 2) we could make it smarter. A full package management system - all tools run unpriveleged and simply call into it. This is more along the lines of what you suggested, albeit tied solely to RPM/yum. Frankly, I don't care as much about it working with .deb, or Solaris pkgadd, or whatever. Others may differ, but I wonder if the effort required to coerce all of them to a common API would a) be sanely possible b) leave you with enough of a common API to do anything useful. Bill From yocum at fnal.gov Fri Jul 27 13:53:43 2007 From: yocum at fnal.gov (Dan Yocum) Date: Fri, 27 Jul 2007 08:53:43 -0500 Subject: please enable XFS in anaconda In-Reply-To: <46A952DB.5020304@redhat.com> References: <46A912EE.9040402@fnal.gov> <20070726190754.68d0316c@ender> <46A952DB.5020304@redhat.com> Message-ID: <46A9F8E7.10302@fnal.gov> Eric Sandeen wrote: > Jesse Keating wrote: >> On Thu, 26 Jul 2007 16:32:30 -0500 >> Dan Yocum wrote: >> >>> It's stable, widely tested, widely deployed, and >>> it's being actively developed and maintained (which is more than can >>> be said of some other filesystems that remain in the default list). >>> It's in the kernel, it shouldn't be "hidden" in the depths of >>> anaconda anymore. >> How's the SELinux support these days? > > Should be fine. Do you know of any outstanding bugs? > (the selinux debacle for FC6 was my fault... I took > the sgi guys' word that a new mkfs option was well tested & optimal for > selinux; turns out that wasn't quite right. Bug was resolved pretty > quickly after working with the sgi xfs team, though). > > >> And why can't I boot from xfs >> yet? > > have you tried lately? It's always been fine on Suse... And I had been booting from XFS since FC3 or so, but after experiencing the problem described by Eric, I moved to ext3 for my /boot partition. Dan -- Dan Yocum Fermilab 630.840.6509 yocum at fnal.gov, http://fermigrid.fnal.gov Fermilab. Just zeros and ones. From notting at redhat.com Fri Jul 27 13:55:00 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 09:55:00 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070727135500.GI25862@nostromo.devel.redhat.com> Panu Matilainen (pmatilai at redhat.com) said: > * Improving automatic dependency extraction > - Plugin architecture for internal dependency extractor to avoid having > to patch rpm itself for each new language Filtering of the provides/requires without disabling the internal dependency generator. (Or, making it external again to simplify this.) Bill From ich at frank-schmitt.net.redhat.com Fri Jul 27 12:14:48 2007 From: ich at frank-schmitt.net.redhat.com (Frank Schmitt) Date: Fri, 27 Jul 2007 14:14:48 +0200 Subject: Blog post about package management (aimed at fedora) References: <1185532130.10773.10.camel@work> Message-ID: Richard Hughes writes: > I've blogged about package management in Fedora (and how it sucks in > other distros too) and also discussed abstract per-system package > management over DBUS interfaces. > > I would appreciate feedback on > http://hughsient.livejournal.com/31429.html either on the blog as > comments, personal email, or just cc'd to the list. If you've got something to say and want feednack from thise reading this list, why don't you just post what you've got to say here? -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From nphilipp at redhat.com Fri Jul 27 13:56:37 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 27 Jul 2007 15:56:37 +0200 Subject: NOTE: Please publicize any license changes to your packages In-Reply-To: <1185293835.20980.22.camel@mccallum.corsepiu.local> References: <20070719184500.GC20184@nostromo.devel.redhat.com> <1184995803.5613.137.camel@mccallum.corsepiu.local> <604aa7910707202332u50812bbfufeff3adafbb0ec57@mail.gmail.com> <1185003394.5613.143.camel@mccallum.corsepiu.local> <20070721145225.397852ff@vader.jdub.homelinux.org> <1185115860.2408.2.camel@cutter> <46A373F4.8050901@leemhuis.info> <604aa7910707222253j5187f07fwc0e7dcc7df095c06@mail.gmail.com> <1185171610.10535.52.camel@mccallum.corsepiu.local> <46A44BB8.4070302@warmcat.com> <1185174635.10535.60.camel@mccallum.corsepiu.local> <1185204325.9305.6.camel@gibraltar.stuttgart.redhat.com> <1185293835.20980.22.camel@mccallum.corsepiu.local> Message-ID: <1185544597.3325.31.camel@gibraltar.stuttgart.redhat.com> On Tue, 2007-07-24 at 18:17 +0200, Ralf Corsepius wrote: > On Mon, 2007-07-23 at 17:25 +0200, Nils Philippsen wrote: > > On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote: > > > On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote: > > > > > > The automated technique is a small burden if it works for most packages. > > > We already _have_ way too much bureaucracy in Fedora. > > > > automation != bureaucracy > Which automation are you referring to? > > The merger with Core (==RH) hasn't brought automation, it has caused > more bureaucracy and further regressions to contributors. Sorry for the late reply. Talking about the merger, you're drifting off into a totally different area here that's been discussed to death already. Andy was talking about the plan that we should be able to automatically (== with tools) check licenses of the packages because it would reduce the burden on the maintainers which should only be in your interest. It's out of the question that we need to ensure that what we distribute is properly licensed. Requiring that every package maintainer regularly checks for license changes in components required by his packages would be a stupid waste of resources. It's much better that maintainers are responsible to inform people if the license of one of their packages (which might be used by other packages) changes. 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 mclasen at redhat.com Fri Jul 27 14:00:08 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 10:00:08 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727135345.GH25862@nostromo.devel.redhat.com> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> Message-ID: <1185544808.3650.13.camel@localhost.localdomain> On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote: > Frankly, I don't care as much about it working with .deb, or Solaris > pkgadd, or whatever. Others may differ, but I wonder if the effort required > to coerce all of them to a common API would a) be sanely possible b) > leave you with enough of a common API to do anything useful. The big thing about this is to get package management tools out of the distro tools ghetto and into shared upstream territory. From dwmw2 at infradead.org Fri Jul 27 14:08:06 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Jul 2007 15:08:06 +0100 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185545286.14697.581.camel@pmac.infradead.org> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Hey all, > > I know I'm opening up Pandoras box here but what the heck, it's Friday and > I'm feeling slightly bored... > > With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode, > time to start looking forward to next major release. While the focus will > be largely in cleaning up and streamlining the codebase, it can't > realistically be all about just that. > > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? > > Just to kick off the discussion (like it was necessary, this is rpm > afterall...), here are a few things that have been brought up in various > forums and private discussions, but don't feel constrained by these items, > they're just some examples of what's being considered: A few of the bugs on https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib are assigned to to RPM. The most important one is probably the lack of arch-specific Requires: and BuildRequires: (#235755). I don't think we'll manage #235757 in time for Fedora 8 but it would be good to get it done (and the packages updated accordingly) for Fedora 9. (Note that comments 3-19 are about the short-term hack we did for F7, not the real subject of the bug). Thoughts on #235758 would be appreciated. -- dwmw2 From skvidal at linux.duke.edu Fri Jul 27 14:06:42 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 10:06:42 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185545202.2409.34.camel@cutter> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Hey all, > > I know I'm opening up Pandoras box here but what the heck, it's Friday and > I'm feeling slightly bored... > > With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode, > time to start looking forward to next major release. While the focus will > be largely in cleaning up and streamlining the codebase, it can't > realistically be all about just that. > 1. expose the rpm verify interface to the python bindings. All we really need is a fast way of getting out the current file status on disk. We could do it all in native python but since rpm already has some of the code to do it.. 2. make it so when I open an rpm from a file I do not need the rpmdb and a transaction set to be open. This also means disconnecting the gpgkeys from the rpmdb, I think. 3. more of what you said - get rid of all the pieces that we don't actually need. -sv From janina at rednote.net Fri Jul 27 14:24:17 2007 From: janina at rednote.net (Janina Sajka) Date: Fri, 27 Jul 2007 10:24:17 -0400 Subject: tftp-server -- connection refused issue In-Reply-To: <46A9CF86.2020607@nasa.gov> References: <20070727021539.GA6148@rednote.net> <46A9CF86.2020607@nasa.gov> Message-ID: <20070727142417.GB6148@rednote.net> Bob Chiodini writes: > > > Janina Sajka wrote: > >I'm probably asking on the wrong list ... > > > >I'm getting connection refused in /var/log/messages over tftp when > >attempting to download firmware to my snom voip phones. Yet connecting > >from another Fedora box on my lan works perfectly. In addition I see > >what appears to be a correct rrq for the snom320.bin file when I look at > >tcpdump data coming from the snom. > > > >This is with the current tftp-server-0.42-4 > > > >All suggestions greatfully appreciated. I've two dead snoms at the > >moment that I'd dearly love to have back on line. > > > > > Janina, > > Are there any other messages in /var/log/messages related to the tftp > request? Tcpwrappers, iptables and selinux come to mind and possible > culprits. > > Bob... Yep, tcpwrappers -- An errant setting in /etc/hosts.allow. Sheesh. Thanks for helping me step through it. Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.XXX.7; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From bpepple at fedoraproject.org Fri Jul 27 14:27:20 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 27 Jul 2007 10:27:20 -0400 Subject: FESCo Meeting Summary for 2007-07-26 Message-ID: <1185546440.2803.1.camel@kennedy> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Warren Togami (warren) * Tom Callaway (spot) * Jesse Keating (f13) * Bill Nottingham (notting) * Jeremy Katz (jeremy) * Christian Iseli (c4chris) * David Woodhouse (dwmw2) * Christopher Aillon (caillon) Members Absent * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) = Summary = == FESCo Chairman == * FESCo elected bpepple as the new chair. == Nodoka Theme == * During the discussion of making Nodoka the default theme for Fedora, M?ir?n Duffy (mizmo) mentioned that the Artwork Team in prior releases didn't have authority over the default theme, icons, etc. for Fedora. * FESCo approved a proposal to give the Artwork Team the authority to decide the default theme, icons, etc. == New Feature Proposals Approvals == * http://fedoraproject.org/wiki/Releases/FeatureBuildId - FESCo approved this proposal. * jeremy - "what it gains is a much easier way of mapping from binary -> debuginfo that will be less processor intensive and that should eventually allow us to do duplicate dwarf info pruning (which will mean smaller debuginfo) and some other things like that." * This feature will necessitate a rebuild of packages. FESCo will look into having this rebuild automated. * http://fedoraproject.org/wiki/Releases/FeaturePolicyKit - FESCo approved this proposal. * http://fedoraproject.org/wiki/Releases/FeatureApport - Will Woods (wwoods) will push this back, and propose this as a feature for F9. * http://fedoraproject.org/wiki/Releases/FeatureTicklessKernel - FESCo approved this proposal. * The remaining feature proposal items for this week will be discussed on the fesco-mailing list, since they ran out of time. These items are: * http://fedoraproject.org/wiki/Releases/FeatureFixWakeups * http://fedoraproject.org/wiki/Releases/FeatureRemovePAMConsole * http://fedoraproject.org/wiki/Releases/FeatureDictionary * http://fedoraproject.org/wiki/Releases/8/Bookmarks * http://fedoraproject.org/wiki/Releases/FeatureBigboard * http://fedoraproject.org/wiki/Releases/FeaturePulseaudio == kmod's == * Ran out of time before being about to discuss Han's question about kmod's. It was mentioned it was just as well, since we wanted some of the kernel guys (davej/cebber) to join in on the discussion. https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01428.html For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070726 Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple 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 rdieter at math.unl.edu Fri Jul 27 14:29:28 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 27 Jul 2007 09:29:28 -0500 Subject: RPM roadmapping References: <1185542632.3650.11.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > >> Not everybody is on rpm-maint list and we'd like to hear the wishes of >> (Fedora) developers/packagers too. So: what have you always wanted to do >> with rpm, but wasn't able to? Or the other way around: what you always >> wished rpm would do for you? What always annoyed you out of your mind? > > A working %posttrans or equivalent. %posttrans works now afaik. Is there something you want that isn't there now? -- Rex From notting at redhat.com Fri Jul 27 14:31:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 10:31:03 -0400 Subject: RPM roadmapping In-Reply-To: References: <1185542632.3650.11.camel@localhost.localdomain> Message-ID: <20070727143103.GB27466@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > > A working %posttrans or equivalent. > > %posttrans works now afaik. Is there something you want that isn't there > now? Ideally, merging of identical %posttrans. Bill From notting at redhat.com Fri Jul 27 14:32:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 10:32:38 -0400 Subject: RPM roadmapping In-Reply-To: <20070727143103.GB27466@nostromo.devel.redhat.com> References: <1185542632.3650.11.camel@localhost.localdomain> <20070727143103.GB27466@nostromo.devel.redhat.com> Message-ID: <20070727143238.GC27466@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > %posttrans works now afaik. Is there something you want that isn't there > > now? > > Ideally, merging of identical %posttrans. ... and, running on uninstall as well. Bill From mclasen at redhat.com Fri Jul 27 14:32:04 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 10:32:04 -0400 Subject: RPM roadmapping In-Reply-To: References: <1185542632.3650.11.camel@localhost.localdomain> Message-ID: <1185546725.3650.28.camel@localhost.localdomain> On Fri, 2007-07-27 at 09:29 -0500, Rex Dieter wrote: > Matthias Clasen wrote: > > > > > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > > > >> Not everybody is on rpm-maint list and we'd like to hear the wishes of > >> (Fedora) developers/packagers too. So: what have you always wanted to do > >> with rpm, but wasn't able to? Or the other way around: what you always > >> wished rpm would do for you? What always annoyed you out of your mind? > > > > A working %posttrans or equivalent. > > %posttrans works now afaik. Is there something you want that isn't there > now? Oh ? That wasn't communicated to me. Whenever I ask about %posttrans I hear that one shouldn't use it, because it doesn't work. If it is fixed now, than maybe the packaging committee should look at coming up with recommendations for icon cache handling (and similar things) using it. From katzj at redhat.com Fri Jul 27 14:33:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 10:33:32 -0400 Subject: RPM roadmapping In-Reply-To: References: <1185542632.3650.11.camel@localhost.localdomain> Message-ID: <1185546812.15991.15.camel@localhost.localdomain> On Fri, 2007-07-27 at 09:29 -0500, Rex Dieter wrote: > Matthias Clasen wrote: > > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > >> Not everybody is on rpm-maint list and we'd like to hear the wishes of > >> (Fedora) developers/packagers too. So: what have you always wanted to do > >> with rpm, but wasn't able to? Or the other way around: what you always > >> wished rpm would do for you? What always annoyed you out of your mind? > > > > A working %posttrans or equivalent. > > %posttrans works now afaik. Is there something you want that isn't there > now? %posttrans is really a bit of a short-term fix and fundamentally not changing anything. We need to get to where we're doing a lot of small transactions rather than one so that things like power failures aren't catastrophic. At which point, the value of %posttrans over %post starts to become far far lower. Jeremy From bruno at wolff.to Fri Jul 27 14:36:32 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 27 Jul 2007 09:36:32 -0500 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070727143632.GA9266@wolff.to> On Fri, Jul 27, 2007 at 15:40:40 +0300, Panu Matilainen wrote: > > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? Since I have switched to using yum with local repostories the following haven't really been a problem, but since you asked and they bugged me in the past I thought I'd mention them. Until the kernel gets changed to allow larger command lines (which might be pretty soon) it would be nice if rpm had a way to read in the list of files to process via standard input or a file. I used to have problems doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs won't work because much of the time several updates need to be done at the same time. From katzj at redhat.com Fri Jul 27 14:37:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 10:37:43 -0400 Subject: RPM roadmapping In-Reply-To: <20070727143632.GA9266@wolff.to> References: <20070727143632.GA9266@wolff.to> Message-ID: <1185547063.15991.20.camel@localhost.localdomain> On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote: > Until the kernel gets changed to allow larger command lines (which might > be pretty soon) it would be nice if rpm had a way to read in the list of > files to process via standard input or a file. I used to have problems > doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs > won't work because much of the time several updates need to be done at > the same time. IIRC, a file listing paths to packages should just work already. Jeremy From katzj at redhat.com Fri Jul 27 14:40:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 10:40:10 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <46A9CC4D.6030807@gmail.com> References: <1185532130.10773.10.camel@work> <46A9CC4D.6030807@gmail.com> Message-ID: <1185547210.15991.27.camel@localhost.localdomain> On Fri, 2007-07-27 at 12:43 +0200, dragoran wrote: > Richard Hughes wrote: > > I've blogged about package management in Fedora (and how it sucks in > > other distros too) and also discussed abstract per-system package > > management over DBUS interfaces. > > > > I would appreciate feedback on > > http://hughsient.livejournal.com/31429.html > "Do we have to make the API asynchronous?" > YES!!! > the best way to fix the progressbar hangs is multithreading. > let the gui draw its stuff, while a background thread does the real work. > yumex afaik works this way. Unfortunately, introducing threading into an environment (rpm + sqlite) which wasn't designed with threading in mind is a recipe for lots of ... interesting problems. Jeremy From walters at redhat.com Fri Jul 27 14:45:59 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 27 Jul 2007 10:45:59 -0400 Subject: RPM roadmapping In-Reply-To: <1185546812.15991.15.camel@localhost.localdomain> References: <1185542632.3650.11.camel@localhost.localdomain> <1185546812.15991.15.camel@localhost.localdomain> Message-ID: <1185547559.3323.11.camel@neutron.verbum.private> On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote: > On Fri, 2007-07-27 at 09:29 -0500, Rex Dieter wrote: > > Matthias Clasen wrote: > > > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > > >> Not everybody is on rpm-maint list and we'd like to hear the wishes of > > >> (Fedora) developers/packagers too. So: what have you always wanted to do > > >> with rpm, but wasn't able to? Or the other way around: what you always > > >> wished rpm would do for you? What always annoyed you out of your mind? > > > > > > A working %posttrans or equivalent. > > > > %posttrans works now afaik. Is there something you want that isn't there > > now? > > %posttrans is really a bit of a short-term fix and fundamentally not > changing anything. We need to get to where we're doing a lot of small > transactions rather than one so that things like power failures aren't > catastrophic. At which point, the value of %posttrans over %post starts > to become far far lower. The other approach for handling the power failure problem is the Stateless cached client: http://fedoraproject.org/wiki/StatelessLinuxCachedClient From hughsient at gmail.com Fri Jul 27 14:49:10 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 15:49:10 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185544808.3650.13.camel@localhost.localdomain> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185544808.3650.13.camel@localhost.localdomain> Message-ID: <1185547750.2494.3.camel@work> On Fri, 2007-07-27 at 10:00 -0400, Matthias Clasen wrote: > On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote: > > > Frankly, I don't care as much about it working with .deb, or Solaris > > pkgadd, or whatever. Others may differ, but I wonder if the effort required > > to coerce all of them to a common API would a) be sanely possible b) > > leave you with enough of a common API to do anything useful. > > The big thing about this is to get package management tools out of the > distro tools ghetto and into shared upstream territory. Sure. This is aimed at people who want to "install OpenOffice" rather than query all the 64bit packages starting with the letter B. Hardcore stuff is done on the command line with distro tools. Being notified of a security update and clicking on a button "install in the background" is all something that should "just work" and be the same for all distros. So far the feedback ratio I'm getting is roughly: 80%: I agree! - let's do it 20%: You are on crack, the existing tools work fine Which is very interesting from a fedora point of view. Richard. From rdieter at math.unl.edu Fri Jul 27 14:54:23 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 27 Jul 2007 09:54:23 -0500 Subject: RPM roadmapping References: <1185542632.3650.11.camel@localhost.localdomain> <20070727143103.GB27466@nostromo.devel.redhat.com> <20070727143238.GC27466@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: >> > %posttrans works now afaik. Is there something you want that isn't >> > there now? >> >> Ideally, merging of identical %posttrans. > > ... and, running on uninstall as well. Ah, that *is* a problem. Yes, please. :) -- Rex From walters at redhat.com Fri Jul 27 14:55:25 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 27 Jul 2007 10:55:25 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185532130.10773.10.camel@work> References: <1185532130.10773.10.camel@work> Message-ID: <1185548125.3323.13.camel@neutron.verbum.private> On Fri, 2007-07-27 at 11:28 +0100, Richard Hughes wrote: > I've blogged about package management in Fedora (and how it sucks in > other distros too) and also discussed abstract per-system package > management over DBUS interfaces. > > I would appreciate feedback on > http://hughsient.livejournal.com/31429.html either on the blog as > comments, personal email, or just cc'd to the list. > > This is obviously not a F8 target, more an idea I discussed with some > other desktop hackers at GUADEC and FOSDEM earlier this year. I think it's a fantastic idea. The Mugshot client has a bit of code a while ago which implements the "Install Now" link on http://mugshot.org/applications that could be used as a starting point: http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-distribution.c From notting at redhat.com Fri Jul 27 14:57:18 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 10:57:18 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185547750.2494.3.camel@work> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185544808.3650.13.camel@localhost.localdomain> <1185547750.2494.3.camel@work> Message-ID: <20070727145718.GA3365@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > Sure. This is aimed at people who want to "install OpenOffice" rather > than query all the 64bit packages starting with the letter B. But for things like that, are you as interested in packages as you are the mugshot-style distributed apps? Bill From hughsient at gmail.com Fri Jul 27 14:54:00 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 15:54:00 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185548125.3323.13.camel@neutron.verbum.private> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> Message-ID: <1185548040.2494.6.camel@work> On Fri, 2007-07-27 at 10:55 -0400, Colin Walters wrote: > I think it's a fantastic idea. The Mugshot client has a bit of code a > while ago which implements the "Install Now" link on > http://mugshot.org/applications that could be used as a starting > point: Yes, there's no reason why stuff like OpenOffice can't have "You want to use clipart, but it is not installed - do you want to install it now?" and then all fedora has to do is patch the name of the rpm package[1] and it can just work. Richard. [1] because we'll never agree on names between distros... From hughsient at gmail.com Fri Jul 27 14:58:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 15:58:19 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727145718.GA3365@nostromo.devel.redhat.com> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185544808.3650.13.camel@localhost.localdomain> <1185547750.2494.3.camel@work> <20070727145718.GA3365@nostromo.devel.redhat.com> Message-ID: <1185548299.2494.8.camel@work> On Fri, 2007-07-27 at 10:57 -0400, Bill Nottingham wrote: > > But for things like that, are you as interested in packages as you are > the mugshot-style distributed apps? Not sure. I figured Colin meant something like "Try Inkscape Now" type link that would just DTRT and install inkscape. Richard. From bruno at wolff.to Fri Jul 27 15:09:47 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 27 Jul 2007 10:09:47 -0500 Subject: RPM roadmapping In-Reply-To: <1185547063.15991.20.camel@localhost.localdomain> References: <20070727143632.GA9266@wolff.to> <1185547063.15991.20.camel@localhost.localdomain> Message-ID: <20070727150947.GA24384@wolff.to> On Fri, Jul 27, 2007 at 10:37:43 -0400, Jeremy Katz wrote: > On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote: > > Until the kernel gets changed to allow larger command lines (which might > > be pretty soon) it would be nice if rpm had a way to read in the list of > > files to process via standard input or a file. I used to have problems > > doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs > > won't work because much of the time several updates need to be done at > > the same time. > > IIRC, a file listing paths to packages should just work already. Do you know what option is used for that? I don't see a way to do that described in the man page. (In particular the -f option is not for a file with a list of rpm names, bhut rather the package(s) that own a particular file.) From hughsient at gmail.com Fri Jul 27 15:07:58 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 16:07:58 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: References: <1185532130.10773.10.camel@work> Message-ID: <1185548878.2494.10.camel@work> On Fri, 2007-07-27 at 14:14 +0200, Frank Schmitt wrote: > If you've got something to say and want feednack from thise reading > this list, why don't you just post what you've got to say here? Because it was a super-long post, and I didn't want to flood everyone with 6 pages of rambling. Point taken tho, I could have added more of an introduction. Richard. From skvidal at linux.duke.edu Fri Jul 27 15:08:22 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 11:08:22 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727135345.GH25862@nostromo.devel.redhat.com> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> Message-ID: <1185548902.2409.53.camel@cutter> On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote: > We've actually discussed this before. Basically, with the current > state of yum-updatesd: > > 1) we could make it dumber. Dead simple; doesn't have modes to install > updates, etc. All it does is check for new metadata - it's possible > that it doesn't even check it against what you have installed. Simple == > predictable. > > 2) we could make it smarter. A full package management system - all tools > run unpriveleged and simply call into it. This is more along the lines > of what you suggested, albeit tied solely to RPM/yum. > > Frankly, I don't care as much about it working with .deb, or Solaris > pkgadd, or whatever. Others may differ, but I wonder if the effort required > to coerce all of them to a common API would a) be sanely possible b) > leave you with enough of a common API to do anything useful. Given the work I did trying to corral the various pkging groups into a single format for just the metadata - I can say that getting an API out that group would be like pulling teeth. When we talked about 2) before the biggest hurdles I recall were: 1. there's a lot of code b/t here and there. Is it worth it? 2. It complicates rescue mode, b/c now either the code has to know how to talk to both the direct sources and the daemon or we have to use (and maintain) different tools. 3. great ANOTHER daemon running, how lovely. -sv From kwizart at gmail.com Fri Jul 27 15:16:36 2007 From: kwizart at gmail.com (KH KH) Date: Fri, 27 Jul 2007 17:16:36 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: 2007/7/27, Panu Matilainen : > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? Hi! I was wondering if rpm can register aliases when it bundles external kernel module (*.ko) like this iwl3945, so it can tell which module (external, in it's own rpm / or internally from the kernel) is a candidate for some specific hardware... Maybe if it can tell more deeply, see that the module is requesting a specific firmware as a dependency (and versionned firmwares is what should be set as as rule, probably not only for intel firmwares ?!) This would be a feature that beginners would appreciate! Nicolas (kwizart) ----------- [root at Kwizatz SOURCES]# modinfo iwl3945 filename: /lib/modules/2.6.22.1-29.fc6/kernel/drivers/net/wireless/mac80211/iwlwifi/iwl3945.ko license: GPL author: Copyright(c) 2003-2007 Intel Corporation version: 0.0.25kd description: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux srcversion: C0D2ED4CF92440B1DFE3BCB This -> alias: pci:v00008086d00004227sv*sd*bc*sc*i* This -> alias: pci:v00008086d00004222sv*sd*bc*sc*i* depends: mac80211 vermagic: 2.6.22.1-29.fc6 SMP mod_unload parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int) parm: disable:manually disable the radio (default 0 [radio on]) (int) parm: hwcrypto:using hardware crypto engine (default 0 [software]) (int) parm: debug:debug output mask (int) parm: disable_hw_scan:disable hardware scanning (default 0) (int) parm: qos_enable:enable all QoS functionality (int) parm: mode:network mode (0=BSS,1=IBSS,2=Monitor) (int) ---------------- From hughsient at gmail.com Fri Jul 27 15:18:33 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 16:18:33 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185548902.2409.53.camel@cutter> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> Message-ID: <1185549513.2494.15.camel@work> On Fri, 2007-07-27 at 11:08 -0400, seth vidal wrote: > 1. there's a lot of code b/t here and there. Is it worth it? I think it's important problem to solve. > 2. It complicates rescue mode, b/c now either the code has to know how > to talk to both the direct sources and the daemon or we have to use (and > maintain) different tools. No, I don't think that's valid. Distro tools like yum can still be run by people who use a "command window" like normal and point and click tools talk to the daemon which blocks until the power-user has finished being geeky :-) > 3. great ANOTHER daemon running, how lovely. Nope, with system activation we only need to start this when a user is trying to _do_ something, and then we can quit when there are no updates scheduled or not in an installer. Richard. From notting at redhat.com Fri Jul 27 15:24:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 11:24:33 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185549513.2494.15.camel@work> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> Message-ID: <20070727152433.GC3365@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > > 3. great ANOTHER daemon running, how lovely. > > Nope, with system activation we only need to start this when a user is > trying to _do_ something, and then we can quit when there are no updates > scheduled or not in an installer. Is system activation really a good interface when the daemon has to: 1) query metadata (download from internet) 2) query installed packages This can introduce a not-insignifcant delay - how does system-activation handle this in general? Bill From katzj at redhat.com Fri Jul 27 15:26:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 11:26:14 -0400 Subject: RPM roadmapping In-Reply-To: <20070727150947.GA24384@wolff.to> References: <20070727143632.GA9266@wolff.to> <1185547063.15991.20.camel@localhost.localdomain> <20070727150947.GA24384@wolff.to> Message-ID: <1185549974.15991.32.camel@localhost.localdomain> On Fri, 2007-07-27 at 10:09 -0500, Bruno Wolff III wrote: > On Fri, Jul 27, 2007 at 10:37:43 -0400, > Jeremy Katz wrote: > > On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote: > > > Until the kernel gets changed to allow larger command lines (which might > > > be pretty soon) it would be nice if rpm had a way to read in the list of > > > files to process via standard input or a file. I used to have problems > > > doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs > > > won't work because much of the time several updates need to be done at > > > the same time. > > > > IIRC, a file listing paths to packages should just work already. > > Do you know what option is used for that? I don't see a way to do that > described in the man page. (In particular the -f option is not for a file > with a list of rpm names, bhut rather the package(s) that own a particular > file.) Just give the manifest file in place of where you'd give teh list of rpm names Jeremy From hughsient at gmail.com Fri Jul 27 15:23:48 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 27 Jul 2007 16:23:48 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727152433.GC3365@nostromo.devel.redhat.com> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> Message-ID: <1185549828.2494.17.camel@work> On Fri, 2007-07-27 at 11:24 -0400, Bill Nottingham wrote: > Richard Hughes (hughsient at gmail.com) said: > > > 3. great ANOTHER daemon running, how lovely. > > > > Nope, with system activation we only need to start this when a user is > > trying to _do_ something, and then we can quit when there are no updates > > scheduled or not in an installer. > > Is system activation really a good interface when the daemon has > to: > > 1) query metadata (download from internet) Starting a service takes a few ms. > 2) query installed packages If the metadata is already okay it should be really quick. Or do I misunderstand your point? Richard. From billcrawford1970 at gmail.com Fri Jul 27 15:29:10 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 27 Jul 2007 16:29:10 +0100 Subject: RPM roadmapping In-Reply-To: <20070727150947.GA24384@wolff.to> References: <20070727143632.GA9266@wolff.to> <1185547063.15991.20.camel@localhost.localdomain> <20070727150947.GA24384@wolff.to> Message-ID: <544eb990707270829u3d55b486g81c01b5eda8d8a7@mail.gmail.com> On 27/07/07, Bruno Wolff III wrote: > On Fri, Jul 27, 2007 at 10:37:43 -0400, > Jeremy Katz wrote: [...] > > IIRC, a file listing paths to packages should just work already. > > Do you know what option is used for that? I don't see a way to do that > described in the man page. (In particular the -f option is not for a file > with a list of rpm names, bhut rather the package(s) that own a particular > file.) There is no option, you just pass it a text file listing the paths to the packages as though it were a package. From katzj at redhat.com Fri Jul 27 15:27:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Jul 2007 11:27:55 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185550075.15991.35.camel@localhost.localdomain> On Fri, 2007-07-27 at 17:16 +0200, KH KH wrote: > 2007/7/27, Panu Matilainen : > > Not everybody is on rpm-maint list and we'd like to hear the wishes of > > (Fedora) developers/packagers too. So: what have you always wanted to do > > with rpm, but wasn't able to? Or the other way around: what you always > > wished rpm would do for you? What always annoyed you out of your mind? > > I was wondering if rpm can register aliases when it bundles external > kernel module (*.ko) like this iwl3945, so it can tell which module > (external, in it's own rpm / or internally from the kernel) is a > candidate for some specific hardware... There's nothing that stops us from adding something to auto-add provides based on modalias. The "problem" is mostly that it ends up adding a substantial number of provides which bloats the amount of data that has to be looked at, downloaded, etc > Maybe if it can tell more deeply, see that the module is requesting a > specific firmware as a dependency (and versionned firmwares is what > should be set as as rule, probably not only for intel firmwares ?!) > This would be a feature that beginners would appreciate! And similarly, firmware info can be extracted as long as the modules export it. The MODULE_FIRMWARE stuff should help there as it gets used in more modules Jeremy From jkeating at redhat.com Fri Jul 27 15:31:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 11:31:23 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185548040.2494.6.camel@work> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> <1185548040.2494.6.camel@work> Message-ID: <20070727113123.26638c99@localhost.localdomain> On Fri, 27 Jul 2007 15:54:00 +0100 Richard Hughes wrote: > and then all fedora has to do is patch the name of the rpm package[1] > and it can just work. > > Richard. > > [1] because we'll never agree on names between distros... Why? yum can understand being passed a file name. OO wants to use that file, that file isn't installed, ask yum to install that file. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Jul 27 15:31:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 11:31:42 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185549828.2494.17.camel@work> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> <1185549828.2494.17.camel@work> Message-ID: <20070727153142.GE3365@nostromo.devel.redhat.com> Richard Hughes (hughsient at gmail.com) said: > > 1) query metadata (download from internet) > > Starting a service takes a few ms. To handle the 'start()' signal, sure. But it depends on the service itself as to when it's ready. I'm mainly just wondering about system activation as an appropriate API for any service that takes a non-trivial amount of time to initialize. > > 2) query installed packages > > If the metadata is already okay it should be really quick. Or do I > misunderstand your point? ... which would require some sort of daemon/automated task to make sure it's up to date. But we're off in the weeds now. Bill From bob.chiodini at nasa.gov Fri Jul 27 15:38:25 2007 From: bob.chiodini at nasa.gov (Bob Chiodini) Date: Fri, 27 Jul 2007 11:38:25 -0400 Subject: tftp-server -- connection refused issue In-Reply-To: <20070727142417.GB6148@rednote.net> References: <20070727021539.GA6148@rednote.net> <46A9CF86.2020607@nasa.gov> <20070727142417.GB6148@rednote.net> Message-ID: <46AA1171.6000402@nasa.gov> Janina Sajka wrote: > Bob Chiodini writes: > >> Janina Sajka wrote: >> >>> I'm probably asking on the wrong list ... >>> >>> I'm getting connection refused in /var/log/messages over tftp when >>> attempting to download firmware to my snom voip phones. Yet connecting >>> >> >from another Fedora box on my lan works perfectly. In addition I see >> >>> what appears to be a correct rrq for the snom320.bin file when I look at >>> tcpdump data coming from the snom. >>> >>> This is with the current tftp-server-0.42-4 >>> >>> All suggestions greatfully appreciated. I've two dead snoms at the >>> moment that I'd dearly love to have back on line. >>> >>> >>> >> Janina, >> >> Are there any other messages in /var/log/messages related to the tftp >> request? Tcpwrappers, iptables and selinux come to mind and possible >> culprits. >> >> Bob... >> > > Yep, tcpwrappers -- An errant setting in /etc/hosts.allow. Sheesh. > > Thanks for helping me step through it. > > Janina > > >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > Janina, You're welcome. Bob... From mclasen at redhat.com Fri Jul 27 15:38:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 11:38:38 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727153142.GE3365@nostromo.devel.redhat.com> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> <1185549828.2494.17.camel@work> <20070727153142.GE3365@nostromo.devel.redhat.com> Message-ID: <1185550719.3650.37.camel@localhost.localdomain> On Fri, 2007-07-27 at 11:31 -0400, Bill Nottingham wrote: > Richard Hughes (hughsient at gmail.com) said: > > > 1) query metadata (download from internet) > > > > Starting a service takes a few ms. > > To handle the 'start()' signal, sure. But it depends on the service > itself as to when it's ready. I'm mainly just wondering about system > activation as an appropriate API for any service that takes a non-trivial > amount of time to initialize. There has been some discussion with Havoc about the need for a 2-phase protocol for taking bus names, to differentiate the use of bus names for locking and for signaling readyness. I guess this is what we are talking about here, on the one hand, the service needs to take the bus name as early as possible to prevent other instances from taking it, on the other hand, it should be ready for service when it takes the bus name. > > > 2) query installed packages > > > > If the metadata is already okay it should be really quick. Or do I > > misunderstand your point? > > ... which would require some sort of daemon/automated task to make > sure it's up to date. But we're off in the weeds now. How so ? Isn't that exactly what yum-updatesd is supposed to do ? From bruno at wolff.to Fri Jul 27 15:41:50 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 27 Jul 2007 10:41:50 -0500 Subject: RPM roadmapping In-Reply-To: <1185549974.15991.32.camel@localhost.localdomain> References: <20070727143632.GA9266@wolff.to> <1185547063.15991.20.camel@localhost.localdomain> <20070727150947.GA24384@wolff.to> <1185549974.15991.32.camel@localhost.localdomain> Message-ID: <20070727154150.GA934@wolff.to> On Fri, Jul 27, 2007 at 11:26:14 -0400, Jeremy Katz wrote: > On Fri, 2007-07-27 at 10:09 -0500, Bruno Wolff III wrote: > > On Fri, Jul 27, 2007 at 10:37:43 -0400, > > Jeremy Katz wrote: > > > On Fri, 2007-07-27 at 09:36 -0500, Bruno Wolff III wrote: > > > > Until the kernel gets changed to allow larger command lines (which might > > > > be pretty soon) it would be nice if rpm had a way to read in the list of > > > > files to process via standard input or a file. I used to have problems > > > > doing rpm -Fvh *.rpm when the number of rpms got to be very large. xargs > > > > won't work because much of the time several updates need to be done at > > > > the same time. > > > > > > IIRC, a file listing paths to packages should just work already. > > > > Do you know what option is used for that? I don't see a way to do that > > described in the man page. (In particular the -f option is not for a file > > with a list of rpm names, bhut rather the package(s) that own a particular > > file.) > > Just give the manifest file in place of where you'd give teh list of rpm > names OK. Is that info in the man page? I tried looking again for something that said you could do that and didn't see anything. If it isn't there then a bug should get filed, but maybe I am just missing it? From skvidal at linux.duke.edu Fri Jul 27 15:35:31 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 11:35:31 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185550719.3650.37.camel@localhost.localdomain> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> <1185549828.2494.17.camel@work> <20070727153142.GE3365@nostromo.devel.redhat.com> <1185550719.3650.37.camel@localhost.localdomain> Message-ID: <1185550531.2409.61.camel@cutter> On Fri, 2007-07-27 at 11:38 -0400, Matthias Clasen wrote: > On Fri, 2007-07-27 at 11:31 -0400, Bill Nottingham wrote: > > Richard Hughes (hughsient at gmail.com) said: > > > > 1) query metadata (download from internet) > > > > > > Starting a service takes a few ms. > > > > > > 2) query installed packages > > > > > > If the metadata is already okay it should be really quick. Or do I > > > misunderstand your point? > > > > ... which would require some sort of daemon/automated task to make > > sure it's up to date. But we're off in the weeds now. > > How so ? Isn't that exactly what yum-updatesd is supposed to do ? if you have a running daemon(yum-updatesd/yumd), why not just use it as a persistent daemon rather than depending on dbus to start it each time? Also - it lets us work with the portion of the market who run servers and like the idea of a daemon they can query for pkg information, but don't run dbus. We turned dbus off everywhere we could - it just used ram and didn't do anything for me running a webserver. -sv From caillon at redhat.com Fri Jul 27 15:50:04 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 27 Jul 2007 11:50:04 -0400 Subject: =?utf-8?q?WTF=E2=81=88_ShowOnlyIn=3DGNOME?= In-Reply-To: References: <20070724201710.70f3a9fa@ender> <20070724214334.5b6eec19@ender> <20070724232757.74adddf6@ender> <20070725204004.4fe96a14@ender> <6e24a8e80707251908s70aaac0apc7a83a0cfa2a9a17@mail.gmail.com> Message-ID: <46AA142C.2070502@redhat.com> Christopher Stone wrote: > On 7/25/07, Mark wrote: >> and can you tell me of a quick way of getting rid of those lines? >> without having to edit each file and without updates that restore it >> again. >> >> Thanx. > > This is an example command to remove the lines: > > # desktop-file-install --remove-only-show-in GNOME > /usr/share/applications/gnome-banshee.desktop > > running this with find twice using GNOME and KDE should fix it, but I > think updates will probably overwrite your changes. You could keep a local cache of .desktop files in $HOME/.local/applications (or if you want them to be elsewhere, export XDG_DATA_DIRS to the directory of your choosing and stick them in $XDG_DATA_DIRS/applications You'd probably need to regenerate the database after that though. From dimi at lattica.com Fri Jul 27 16:05:18 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 27 Jul 2007 12:05:18 -0400 Subject: RPM roadmapping In-Reply-To: <1185546812.15991.15.camel@localhost.localdomain> References: <1185542632.3650.11.camel@localhost.localdomain> <1185546812.15991.15.camel@localhost.localdomain> Message-ID: <1185552318.3928.59.camel@dimi.lattica.com> On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote: > We need to get to where we're doing a lot of small > transactions rather than one so that things like power failures aren't > catastrophic. That would be a step backwards in all but the power-failure scenario. Conceptually, the transactional part of rpm is is a good thing. Now I know we're nowhere close to ACID, but maybe we can improve on that instead of making it even worse. -- Dimi Paun Lattica, Inc. From a.badger at gmail.com Fri Jul 27 16:09:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 27 Jul 2007 09:09:14 -0700 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727135345.GH25862@nostromo.devel.redhat.com> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> Message-ID: <1185552556.19639.142.camel@localhost.localdomain> On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote: > 2) we could make it smarter. A full package management system - all tools > run unpriveleged and simply call into it. This is more along the lines > of what you suggested, albeit tied solely to RPM/yum. > Is this conceptually the same as red carpet daemon? -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 walters at redhat.com Fri Jul 27 16:10:44 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 27 Jul 2007 12:10:44 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185550531.2409.61.camel@cutter> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> <1185549828.2494.17.camel@work> <20070727153142.GE3365@nostromo.devel.redhat.com> <1185550719.3650.37.camel@localhost.localdomain> <1185550531.2409.61.camel@cutter> Message-ID: <1185552644.3323.62.camel@neutron.verbum.private> On Fri, 2007-07-27 at 11:35 -0400, seth vidal wrote: > Also - it lets us work with the portion of the market who run servers > and like the idea of a daemon they can query for pkg information, but > don't run dbus. > > We turned dbus off everywhere we could - it just used ram and didn't do > anything for me running a webserver. Moving forward, it makes a lot of sense to me to do development on the OS assuming that we have a sane way for system components to communicate with one another. dbus-daemon doesn't even show up on the radar for RAM usage on my system... From billcrawford1970 at gmail.com Fri Jul 27 16:11:52 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 27 Jul 2007 17:11:52 +0100 Subject: RPM roadmapping In-Reply-To: <20070727154150.GA934@wolff.to> References: <20070727143632.GA9266@wolff.to> <1185547063.15991.20.camel@localhost.localdomain> <20070727150947.GA24384@wolff.to> <1185549974.15991.32.camel@localhost.localdomain> <20070727154150.GA934@wolff.to> Message-ID: <544eb990707270911l4e4c8085ia2876e8c300ae386@mail.gmail.com> On 27/07/07, Bruno Wolff III wrote: > OK. Is that info in the man page? I tried looking again for something that > said you could do that and didn't see anything. If it isn't there then a bug > should get filed, but maybe I am just missing it? Yeah, just search for "manifest" ... :) it's not that intuitive, but it's there. From skvidal at linux.duke.edu Fri Jul 27 16:03:45 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 12:03:45 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185552556.19639.142.camel@localhost.localdomain> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185552556.19639.142.camel@localhost.localdomain> Message-ID: <1185552226.2409.63.camel@cutter> On Fri, 2007-07-27 at 09:09 -0700, Toshio Kuratomi wrote: > On Fri, 2007-07-27 at 09:53 -0400, Bill Nottingham wrote: > > 2) we could make it smarter. A full package management system - all tools > > run unpriveleged and simply call into it. This is more along the lines > > of what you suggested, albeit tied solely to RPM/yum. > > > Is this conceptually the same as red carpet daemon? > it's not completely off in left field from it, no. -sv From skvidal at linux.duke.edu Fri Jul 27 16:05:17 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 12:05:17 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185552644.3323.62.camel@neutron.verbum.private> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> <1185549828.2494.17.camel@work> <20070727153142.GE3365@nostromo.devel.redhat.com> <1185550719.3650.37.camel@localhost.localdomain> <1185550531.2409.61.camel@cutter> <1185552644.3323.62.camel@neutron.verbum.private> Message-ID: <1185552318.2409.66.camel@cutter> On Fri, 2007-07-27 at 12:10 -0400, Colin Walters wrote: > On Fri, 2007-07-27 at 11:35 -0400, seth vidal wrote: > > > Also - it lets us work with the portion of the market who run servers > > and like the idea of a daemon they can query for pkg information, but > > don't run dbus. > > > > We turned dbus off everywhere we could - it just used ram and didn't do > > anything for me running a webserver. > > Moving forward, it makes a lot of sense to me to do development on the > OS assuming that we have a sane way for system components to communicate > with one another. > > dbus-daemon doesn't even show up on the radar for RAM usage on my > system... as a sysadmin I will say this: 1. if it ain't necessary it is off 2. if nothing deps on it, it gets removed. - now things depend on dbus these days, and that's fine - but on a server with a static ip- even served via dhcp we don't need it - it's just one more thing that can go wrong. -sv From skvidal at linux.duke.edu Fri Jul 27 16:09:14 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 12:09:14 -0400 Subject: RPM roadmapping In-Reply-To: <1185552318.3928.59.camel@dimi.lattica.com> References: <1185542632.3650.11.camel@localhost.localdomain> <1185546812.15991.15.camel@localhost.localdomain> <1185552318.3928.59.camel@dimi.lattica.com> Message-ID: <1185552554.2409.69.camel@cutter> On Fri, 2007-07-27 at 12:05 -0400, Dimi Paun wrote: > On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote: > > We need to get to where we're doing a lot of small > > transactions rather than one so that things like power failures aren't > > catastrophic. > > That would be a step backwards in all but the power-failure scenario. > Conceptually, the transactional part of rpm is is a good thing. Now > I know we're nowhere close to ACID, but maybe we can improve on that > instead of making it even worse. > Well, it would also be good if we could get a bit more state on where we are in the transaction and record that somewhere as much as possible. It'd be nice to know that if we're past stage X that bits are on disk and we just need metadata, or somesuch. a bit finer granularity and instrumentation at the stages a pkg goes through during a transaction would be helpful to verifying our state. -sv From mclasen at redhat.com Fri Jul 27 16:20:53 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 12:20:53 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185553253.3650.39.camel@localhost.localdomain> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? > Another thing I forgot: I'd love if rpm could become smart enough in handling directories, so that we don't need to add tons of artifical dependencies just to manually manage directory ownership. From bruno at wolff.to Fri Jul 27 16:25:43 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 27 Jul 2007 11:25:43 -0500 Subject: RPM roadmapping In-Reply-To: <544eb990707270911l4e4c8085ia2876e8c300ae386@mail.gmail.com> References: <20070727143632.GA9266@wolff.to> <1185547063.15991.20.camel@localhost.localdomain> <20070727150947.GA24384@wolff.to> <1185549974.15991.32.camel@localhost.localdomain> <20070727154150.GA934@wolff.to> <544eb990707270911l4e4c8085ia2876e8c300ae386@mail.gmail.com> Message-ID: <20070727162543.GA21207@wolff.to> On Fri, Jul 27, 2007 at 17:11:52 +0100, Bill Crawford wrote: > On 27/07/07, Bruno Wolff III wrote: > > > OK. Is that info in the man page? I tried looking again for something that > > said you could do that and didn't see anything. If it isn't there then a bug > > should get filed, but maybe I am just missing it? > > Yeah, just search for "manifest" ... :) it's not that intuitive, but it's there. Thanks, I found it now. I think I just never finished that paragraph. From jkeating at redhat.com Fri Jul 27 16:42:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 12:42:19 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070727124219.5712c747@localhost.localdomain> On Fri, 27 Jul 2007 15:40:40 +0300 (EEST) Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes > of (Fedora) developers/packagers too. So: what have you always wanted > to do with rpm, but wasn't able to? Or the other way around: what you > always wished rpm would do for you? What always annoyed you out of > your mind? directory -> symlink upon upgrade, and all the sort of similar fun. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Fri Jul 27 17:05:59 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 27 Jul 2007 13:05:59 -0400 Subject: rawhide report: 20070725 changes In-Reply-To: <1185373421.11828.12.camel@localhost.localdomain> References: <200707250733.l6P7X1dZ001043@porkchop.devel.redhat.com> <1185373421.11828.12.camel@localhost.localdomain> Message-ID: <1185555959.2691.3.camel@zelda.fubar.dk> On Wed, 2007-07-25 at 10:23 -0400, Jeremy Katz wrote: > On Wed, 2007-07-25 at 03:33 -0400, Build System wrote: > > New package yum-updatesd > > Update notification daemon > > FYI -- this is a new and reworked yum-updatesd that should hopefully > help with some of the complaints that I have been had. The *big* change > is that it's bit split into two pieces: > * The actual daemon. This is small, listens to dbus, and doesn't ever > touch the rpmdb, etc. Which should keep its memory footprint low. > * Helper process that's forked off to do actual update checks > (+downloads +installs if so configured). Helper isn't threaded, which > should avoid some of the problems that have been cropping up. Now that we've got system bus activation landing in Rawhide anytime soon (it was recently committed upstream) you probably don't even need to start yum-updatesd at all. David From notting at redhat.com Fri Jul 27 17:51:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Jul 2007 13:51:08 -0400 Subject: RPM roadmapping In-Reply-To: <20070727124219.5712c747@localhost.localdomain> References: <20070727124219.5712c747@localhost.localdomain> Message-ID: <20070727175108.GC7659@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > directory -> symlink upon upgrade, and all the sort of similar fun. I'm sure you can cobble up something in lua for this. Bill From robert at fedoraproject.org Fri Jul 27 17:55:14 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Fri, 27 Jul 2007 19:55:14 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070727175514.GA26347@hurricane.linuxnetz.de> Evening folks, On Fri, 27 Jul 2007, Panu Matilainen wrote: > I know I'm opening up Pandoras box here but what the heck, it's Friday and > I'm feeling slightly bored... looks like you've the wrong job...maybe we should switch ;-) > The more specific you can be, the better - "make it not suck" isn't > productive. Of course there's no way everything can be done, we want the > next major release out before end of the decade... Also this is not a > voting where most votes guarantee implementation, but consider it your > chance to be heard. I'm listening... :) when reading your ideas or how ever you're calling it, it looks as you would like to come up with the same roadmap rpm5.org already has - but just nearly two month later. And when reading rpm5-devel from the last two month, you're proposing more or less the same ideas, the rpm5 team and developers already talked about; read yourself: - http://rpm5.org/roadmap/ - http://rpm5.org/community/rpm-devel/ But I've also one wish regarding the features of rpm.org: Let rpmrc die as soon as possible, please. As you're also at the rpm5-devel mailing list, you should know what I'm talking about here, don't you? On Fri, 27 Jul 2007, dragoran wrote: > arch requires and provides ... to end the endless multilib discussions ;) > should be automatic until the packager say Requires: foo.arch IIRC this feature is already since beginning of May 2007 in rpm5.org, try or e.g. look at http://rpm5.org/cvs/chngview?cn=7070. On Fri, 27 Jul 2007, Till Maas wrote: > I am missing "soft dependencies", e.g. the possibility to make a package > suggest which other packages may enhance it, e.g. with plugins. Afaik in > debian packages it is called "Suggests:". AFAIK, this is part of rpm5.org since end of October 2005 as "Suggests:" and "Enhances:", just read http://rpm5.org/cvs/chngview?cn=6089 and also http://rpm5.org/cvs/chngview?cn=6111, PLD Linux wrote a patch to use these features within yum, but yum upstream refuses this patch without a real answer. On Fri, 27 Jul 2007, Matthias Clasen wrote: > A working %posttrans or equivalent. What is broken/not working at %posttrans? On Fri, 27 Jul 2007, Matthias Clasen wrote: > Another thing I forgot: I'd love if rpm could become smart enough in > handling directories, so that we don't need to add tons of artifical > dependencies just to manually manage directory ownership. Hum? Could you give more details regarding this? Are you thinking about auto-manage ownership of directories? I don't think, this is a good idea, but rpm5.org is able to tell you orphaned parent directories and dangling symlinks since April 2006. IIRC http://rpm5.org/cvs/chngview?cn=6412 or http://rpm5.org/cvs/chngview?cn=6414. On Fri, 27 Jul 2007, Jesse Keating wrote: > directory -> symlink upon upgrade, and all the sort of similar fun. I'm not sure, but I thought, this theme have been aten at rpm5.org. My personal conclusion is, that as of the moment, many expected features are already part of rpm5.org for a longer time. Oh, I forgot, some Red Hat people don't like some rpm5.org team members. But this are just my 2 cents regarding this topic as rpm5.org member and Fedora user... ;-) Greetings, Robert From mclasen at redhat.com Fri Jul 27 18:03:16 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Jul 2007 14:03:16 -0400 Subject: RPM roadmapping In-Reply-To: <20070727175514.GA26347@hurricane.linuxnetz.de> References: <20070727175514.GA26347@hurricane.linuxnetz.de> Message-ID: <1185559396.3650.69.camel@localhost.localdomain> On Fri, 2007-07-27 at 19:55 +0200, Robert Scheck wrote: > > On Fri, 27 Jul 2007, Matthias Clasen wrote: > > A working %posttrans or equivalent. > > What is broken/not working at %posttrans? Read the posts further up in this thread explaining it. > On Fri, 27 Jul 2007, Matthias Clasen wrote: > > Another thing I forgot: I'd love if rpm could become smart enough in > > handling directories, so that we don't need to add tons of artifical > > dependencies just to manually manage directory ownership. > > Hum? Could you give more details regarding this? Are you thinking about > auto-manage ownership of directories? I don't think, this is a good idea, > but rpm5.org is able to tell you orphaned parent directories and dangling > symlinks since April 2006. IIRC http://rpm5.org/cvs/chngview?cn=6412 or > http://rpm5.org/cvs/chngview?cn=6414. > I am talking about - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy I think it would be entirely possible for rpm to differentiate between directories that a) preexisted before any rpm touched them b) were created because an rpm needs to dump a file there c) are explicitly owned by an rpm and manage the creation and deletion of directories accordingly. Refcounting comes to mind... From jspaleta at gmail.com Fri Jul 27 18:12:38 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Jul 2007 10:12:38 -0800 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> On 7/27/07, Panu Matilainen wrote: > The more specific you can be, the better - "make it not suck" isn't > productive. Of course there's no way everything can be done, we want the > next major release out before end of the decade... Also this is not a > voting where most votes guarantee implementation, but consider it your > chance to be heard. I'm listening... :) If I had any ability to hack on rpm..... Is there a way to make the rpmdb smart enough to make auto-removal of package dependencies happen when all packages using that dep were explicitly installed are no longer on the system. Naively, I would think that you could mark individual packages as explicitly installed or not in the rpmdb. So tools which interact with the db could set that flag accordingly and such a demarcation could be queried or used in transactions. Examples yum install ekiga would flag ekiga but any deps pulled into the transaction would not get flagged as explicit. yum install libsexy would flag libsexy as explicit. The explicit mark in the db would be used to protect marked packages from leaf vacuuming, so that we can make common use of leaf vacuuming. -jef"make it not not not suck!"spaleta From skvidal at linux.duke.edu Fri Jul 27 18:10:44 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 14:10:44 -0400 Subject: RPM roadmapping In-Reply-To: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> References: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> Message-ID: <1185559844.2409.79.camel@cutter> On Fri, 2007-07-27 at 10:12 -0800, Jeff Spaleta wrote: > On 7/27/07, Panu Matilainen wrote: > > The more specific you can be, the better - "make it not suck" isn't > > productive. Of course there's no way everything can be done, we want the > > next major release out before end of the decade... Also this is not a > > voting where most votes guarantee implementation, but consider it your > > chance to be heard. I'm listening... :) > > If I had any ability to hack on rpm..... > Is there a way to make the rpmdb smart enough to make auto-removal of > package dependencies happen when all packages using that dep were > explicitly installed are no longer on the system. > > Naively, I would think that you could mark individual packages as > explicitly installed or not in the rpmdb. So tools which interact > with the db could set that flag accordingly and such a demarcation > could be queried or used in transactions. > > Examples yum install ekiga would flag ekiga but any deps pulled into > the transaction would not get flagged as explicit. yum install > libsexy would flag libsexy as explicit. The explicit mark in the db > would be used to protect marked packages from leaf vacuuming, so that > we can make common use of leaf vacuuming. We've kicked around the idea of doing that in a separate db that yum creates but it: 1. would mean that it ignores stuff not installed by yum 2. it would need to remain persistent across upgrades/etc so, you're right doing it in rpm or having a way of labeling them in rpm that way would make it easier. -sv From jspaleta at gmail.com Fri Jul 27 18:26:30 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Jul 2007 10:26:30 -0800 Subject: RPM roadmapping In-Reply-To: <1185559844.2409.79.camel@cutter> References: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> <1185559844.2409.79.camel@cutter> Message-ID: <604aa7910707271126k26d8a330m965c8f4b8d50d0d@mail.gmail.com> On 7/27/07, seth vidal wrote: > so, you're right doing it in rpm or having a way of labeling them in rpm > that way would make it easier. ..but is it worth doing in sane timescale? To make use of it you'd also have to expose setting the flag to external transaction tools like yum. And of course, some gross cmdline way to flag/unflag packages manually for those of us who like stick our fingers into power sockets. -jef From skvidal at linux.duke.edu Fri Jul 27 18:21:35 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 27 Jul 2007 14:21:35 -0400 Subject: RPM roadmapping In-Reply-To: <604aa7910707271126k26d8a330m965c8f4b8d50d0d@mail.gmail.com> References: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> <1185559844.2409.79.camel@cutter> <604aa7910707271126k26d8a330m965c8f4b8d50d0d@mail.gmail.com> Message-ID: <1185560495.2409.81.camel@cutter> On Fri, 2007-07-27 at 10:26 -0800, Jeff Spaleta wrote: > On 7/27/07, seth vidal wrote: > > so, you're right doing it in rpm or having a way of labeling them in rpm > > that way would make it easier. > > ..but is it worth doing in sane timescale? To make use of it you'd > also have to expose setting the flag to external transaction tools > like yum. And of course, some gross cmdline way to flag/unflag > packages manually for those of us who like stick our fingers into > power sockets. given the other suggestions today on this and other lists I don't think anyone is worried about timescale :) -sv From javert42 at cs.byu.edu Fri Jul 27 18:42:06 2007 From: javert42 at cs.byu.edu (Topher) Date: Fri, 27 Jul 2007 12:42:06 -0600 Subject: RPM roadmapping In-Reply-To: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> References: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> Message-ID: <46AA3C7E.1090104@cs.byu.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Spaleta wrote: > If I had any ability to hack on rpm..... > Is there a way to make the rpmdb smart enough to make auto-removal of > package dependencies happen when all packages using that dep were > explicitly installed are no longer on the system. > Couldn't this been done with reference counting, like is done with garbage collection? It seems to me to be applicable, proven, and simple. - -- Topher Fischer GnuPG Fingerprint: 3597 1B8D C7A5 C5AF 2E19 EFF5 2FC3 BE99 D123 6674 javert42 at cs.byu.edu | http://www.thetopher.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGqjx9L8O+mdEjZnQRAnSmAJ9V8OeNm7BFfP/0tuE9qosQ9fFP+gCbBuM0 CIWkvzweQbzcp1G0NGLrbRA= =RSoz -----END PGP SIGNATURE----- From otaylor at redhat.com Fri Jul 27 18:42:33 2007 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 27 Jul 2007 14:42:33 -0400 Subject: RPM roadmapping In-Reply-To: <1185552318.3928.59.camel@dimi.lattica.com> References: <1185542632.3650.11.camel@localhost.localdomain> <1185546812.15991.15.camel@localhost.localdomain> <1185552318.3928.59.camel@dimi.lattica.com> Message-ID: <1185561753.27024.33.camel@fresnel.dumbhippo.com> On Fri, 2007-07-27 at 12:05 -0400, Dimi Paun wrote: > On Fri, 2007-07-27 at 10:33 -0400, Jeremy Katz wrote: > > We need to get to where we're doing a lot of small > > transactions rather than one so that things like power failures aren't > > catastrophic. > > That would be a step backwards in all but the power-failure scenario. > Conceptually, the transactional part of rpm is is a good thing. Now > I know we're nowhere close to ACID, but maybe we can improve on that > instead of making it even worse. The problem is that you need transactions not for the RPM database but for the *system*; if you are installing 20 packages, and the first package install overwrites some file, then something fails as we are running the %post for the 15th package, can we go back and restore that file we overwrote to it's original state? To even start at being able to do that, I think you have to have separate filesystem for the system image that is read-only except for RPM operations. (Yes, RPM could save the files it overwrites in a undo buffer, but you also have system changes done by scripts.) - Owen From jspaleta at gmail.com Fri Jul 27 19:19:51 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Jul 2007 11:19:51 -0800 Subject: RPM roadmapping In-Reply-To: <46AA3C7E.1090104@cs.byu.edu> References: <604aa7910707271112w5022c6fetbe9b211a8e5b4f8d@mail.gmail.com> <46AA3C7E.1090104@cs.byu.edu> Message-ID: <604aa7910707271219r71ca45dape9d60a7d1c3bce50@mail.gmail.com> On 7/27/07, Topher wrote: > Couldn't this been done with reference counting, like is done with > garbage collection? It seems to me to be applicable, proven, and simple. Reference counting what exactly? Keeping up with the number of dependencies on a package is not hard. In fact we already have tools that find leaves in the tree. That's not the problem. The problem is protecting leaves that users care about from auto-cleanup. If we just vacuumed up leaf nodes in the packaging tree willy-nilly normal users would see applications they care about depopulated from the menus. Developers would see libraries and development packages they need depopulated from their workstations. If we had a way to protect certain leaves in the tree from auto-cleanup, then we avoid all of these complications. The only way we know if a user cares about a package is if it was explicitly requested to be installed (or explicitly told the rpmdb to protect that package from auto-cleanup if we want to get picky). Right now the is no way to query rpmdb about whether a package was installed explicitly or was implicitly included through depsolving. That's the key idea here... marking the 10% or so of packages a user/admin/trained-monkey has explicitly asked to be installed/protected so that we can auto garbage collect we aren't throwing out things we care about. -jef From chris.stone at gmail.com Fri Jul 27 19:23:09 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 27 Jul 2007 12:23:09 -0700 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> References: <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> Message-ID: On 7/26/07, Bill Crawford wrote: > I found the package "kmenu-gnome" lurking in the package manager, ... seems > to work, although it only shows two items (grip and "Configuration Editor" > :)) Thanks for the pointer. Ah, okay, well I'm confused. I thought gnome-menus added gnome items to the KDE menu, but I guess it is actually kmenu-gnome. I filed a bug against kmenu-gnome: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249902 From g at socallinuxexpo.org Fri Jul 27 19:35:11 2007 From: g at socallinuxexpo.org (Gareth J. Greenaway) Date: Fri, 27 Jul 2007 12:35:11 -0700 Subject: So Cal Linux Expo Announces Call For Papers Message-ID: <200707271235.11413.g@socallinuxexpo.org> July 27th, 2007 The Linux Expo of Southern California has opened the Call For Papers for the 6th Annual Southern California Linux Expo, to be held February 8th, 9th, & 10th, 2008. As with SCALE 5x, S6x will be held at the Westin Hotel at Los Angeles International Airport. If you?re interested in speaking at SCALE, don?t wait to submit your proposal. Over their last couple of events, the Linux Expo has had many more applications than they have had speaker slots available. See http://socallinuxexpo.org/scale6x/documents/scale6x-cfp.pdf for details on how to apply for a speaking opportunity at SCALE. Likewise, if you know someone who has something interesting to say about Open Source software, pass along the CFP to them and encourage them to apply. -- Gareth J. Greenaway | g at socallinuxexpo.org Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org From tcallawa at redhat.com Fri Jul 27 20:46:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 15:46:40 -0500 Subject: RPM roadmapping In-Reply-To: <46A9EA0F.30405@gmail.com> References: <46A9EA0F.30405@gmail.com> Message-ID: <1185569201.3765.128.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 14:50 +0200, dragoran wrote: > Panu Matilainen wrote: > > > > Not everybody is on rpm-maint list and we'd like to hear the wishes of > > (Fedora) developers/packagers too. So: what have you always wanted to > > do with rpm, but wasn't able to? Or the other way around: what you > > always wished rpm would do for you? What always annoyed you out of > > your mind? > > arch requires and provides ... to end the endless multilib discussions ;) > should be automatic until the packager say Requires: foo.arch Wow, beat me to the punch on that one. +10 ~spot From opensource at till.name Fri Jul 27 19:54:29 2007 From: opensource at till.name (Till Maas) Date: Fri, 27 Jul 2007 21:54:29 +0200 Subject: f8-test1 version in Bugzilla Message-ID: <200707272154.45243.opensource@till.name> Aloas, iirc there was once decided that there should be no "f8-test1" and so on version in Bugzilla, the f8-test1 tracker bug[1] also says: | if you have a problem, file a bug against 'devel' and mark it as blocking | this bug. But still there is a version f8-test1 and also the wiki[2] mentions https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&version=f8test1 instead of https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&blocked=F8Test1 Does everybody agree to change the wiki to use the blocket=F8Test1 URL? Regards, Till [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F8Test1 [2] http://fedoraproject.org/wiki/QA/8/Test1TreeTesting -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dimi at lattica.com Fri Jul 27 19:58:50 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 27 Jul 2007 15:58:50 -0400 Subject: RPM roadmapping In-Reply-To: <1185561753.27024.33.camel@fresnel.dumbhippo.com> References: <1185542632.3650.11.camel@localhost.localdomain> <1185546812.15991.15.camel@localhost.localdomain> <1185552318.3928.59.camel@dimi.lattica.com> <1185561753.27024.33.camel@fresnel.dumbhippo.com> Message-ID: <1185566330.3928.67.camel@dimi.lattica.com> On Fri, 2007-07-27 at 14:42 -0400, Owen Taylor wrote: > > The problem is that you need transactions not for the RPM database > but for the *system*; I understand that, it's not a trivial feature. > To even start at being able to do that, I think you have to have > separate filesystem for the system image that is read-only except > for RPM operations. Working with LVM here provides part of the answer. We'll probably need some more support from LVM if we are to achieve system-level ACIDity, -- Dimi Paun Lattica, Inc. From jkeating at redhat.com Fri Jul 27 20:05:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Jul 2007 16:05:05 -0400 Subject: f8-test1 version in Bugzilla In-Reply-To: <200707272154.45243.opensource@till.name> References: <200707272154.45243.opensource@till.name> Message-ID: <20070727160505.36c88bbc@localhost.localdomain> On Fri, 27 Jul 2007 21:54:29 +0200 Till Maas wrote: > iirc there was once decided that there should be no "f8-test1" and so > on version in Bugzilla, We experimented with not having different test versions. However since they're were old versions there, people were highly confused when there was no new one. So until we cleanse Bugzilla and get a fresh start, we'll continue making new versions. > the f8-test1 tracker bug[1] also says: > > | if you have a problem, file a bug against 'devel' and mark it as > blocking | this bug. > > But still there is a version f8-test1 and also the wiki[2] mentions > > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&version=f8test1 > instead of > https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&blocked=F8Test1 > > Does everybody agree to change the wiki to use the blocket=F8Test1 > URL? > Yeah, probably should change that. Good catch, although it should be product-Fedora at version=devel at blocked=F8Test1 Changing. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Lam at Lam.pl Fri Jul 27 20:22:04 2007 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 27 Jul 2007 22:22:04 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070727222204.6d768b62@pensja.lam.pl> Dnia 2007-07-27, o godz. 15:40:40 Panu Matilainen napisa?(a): > what have you always wanted to do with rpm, but wasn't able to? - Tell if a given package was installed by hand (rpm -i/U/F) or (if installed by yum/apt/whatever) which repository did it come from. Some people suggested to use "Signature:" for that, but that only tells, which repo this pakage was first published on, and I want to know, where did I get it from in reality. - Mark packages "immune", so that I don't have to separately set ignore/keep lists for every depsolver separately (I know, this is stupid, I should make my fixes upstream, but that proved very hard with Fedora maintainers and you've asked about my wishes for RPM...) - Make the transaction journalled with some kind of redo log, so that it's not a problem if some update crashes X, killing pirut/yum/rpm with it. Power failures don't bother me, but crashes do happen upon updating the system, even on Fedora :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Fri Jul 27 20:27:01 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Jul 2007 12:27:01 -0800 Subject: RPM roadmapping In-Reply-To: <20070727222204.6d768b62@pensja.lam.pl> References: <20070727222204.6d768b62@pensja.lam.pl> Message-ID: <604aa7910707271327s204695xea2ff896dfea2f1d@mail.gmail.com> On 7/27/07, Leszek Matok wrote: > - Tell if a given package was installed by hand (rpm -i/U/F) or (if installed > by yum/apt/whatever) which repository did it come from. Some people suggested > to use "Signature:" for that, but that only tells, which repo this pakage was > first published on, and I want to know, where did I get it from in reality. Like the actual url it was pulled from, regardless of which mirror in a dynamicly generated mirrorlist you used in that run? A repository-wide signature/cert referenced in signed repository metadata from the repository might be better in some ways than the full url to a specific mirror. -jef From tjb at unh.edu Fri Jul 27 20:34:50 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 27 Jul 2007 16:34:50 -0400 Subject: Resume problems after suspend on Dell XPS M1210 In-Reply-To: <481292.91013.qm@web60711.mail.yahoo.com> References: <481292.91013.qm@web60711.mail.yahoo.com> Message-ID: <1185568490.13648.0.camel@raptor.sr.unh.edu> On Thu, 2007-07-26 at 16:38 -0700, William Lovaton wrote: > Hi there, > > Regarding this thread on fedora-devel-list: > [] http://www.redhat.com/archives/fedora-devel-list/2007-July/msg01418.html > > I hope you can help me. I happen to have the same laptop but I am > using the nVidia video card with the open source nv driver. TJB > doesn't say what his video card is but I am having a different problem > on resuming after suspending to RAM. Resuming after hibernating > (suspending to disk) works fine for me which is strange. I have intel video and only have problems with suspend/resume screen brightness. I'll try the "pm-suspend --quirk-vbe-post" trick tonight. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From tcallawa at redhat.com Fri Jul 27 21:35:46 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 27 Jul 2007 16:35:46 -0500 Subject: RPM roadmapping In-Reply-To: <1185559396.3650.69.camel@localhost.localdomain> References: <20070727175514.GA26347@hurricane.linuxnetz.de> <1185559396.3650.69.camel@localhost.localdomain> Message-ID: <1185572146.3765.140.camel@dhcp83-168.boston.redhat.com> On Fri, 2007-07-27 at 14:03 -0400, Matthias Clasen wrote: > I think it would be entirely possible for rpm to differentiate between > directories that > a) preexisted before any rpm touched them > b) were created because an rpm needs to dump a file there > c) are explicitly owned by an rpm > and manage the creation and deletion of directories accordingly. > Refcounting comes to mind... Indeed, I would very much like to see rpm handle this correctly on its own, so we can get rid of that guideline. ~spot From d.jacobfeuerborn at conversis.de Fri Jul 27 21:00:48 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Fri, 27 Jul 2007 23:00:48 +0200 Subject: yum dependency resolution problem Message-ID: <46AA5D00.800@conversis.de> I'm upgrading to Rawhide and I seem to be running into a problem with yum. Calling "yum update libwnck" leads to the following output: Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package libwnck.i386 0:2.19.5-3.fc8 set to be updated --> Processing Dependency: libwnck-1.so.18 for package: gnome-system-monitor --> Processing Dependency: libwnck-1.so.18 for package: gnome-applets --> Processing Dependency: gtk2 >= 2.11.3 for package: libwnck --> Processing Dependency: libwnck-1.so.18 for package: gnome-power-manager --> Processing Dependency: libwnck-1.so.18 for package: gnome-panel --> Processing Dependency: libwnck-1.so.18 for package: libwnck-devel --> Processing Dependency: libwnck-1.so.18 for package: notification-daemon --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package libwnck.i386 0:2.19.5-3.fc8 set to be updated ---> Package gtk2.i386 0:2.11.6-3.fc8 set to be updated --> Processing Dependency: libwnck-1.so.18 for package: gnome-system-monitor --> Processing Dependency: libwnck-1.so.18 for package: gnome-applets --> Processing Dependency: libwnck-1.so.18 for package: gnome-power-manager --> Processing Dependency: libwnck-1.so.18 for package: gnome-panel --> Processing Dependency: gtk2 = 2.10.11-7.fc7 for package: gtk2-devel --> Processing Dependency: libwnck-1.so.18 for package: libwnck-devel --> Processing Dependency: libwnck-1.so.18 for package: notification-daemon --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package gtk2-devel.i386 0:2.11.6-3.fc8 set to be updated --> Processing Dependency: libwnck-1.so.18 for package: gnome-system-monitor --> Processing Dependency: libwnck-1.so.18 for package: gnome-applets --> Processing Dependency: libwnck-1.so.18 for package: gnome-power-manager --> Processing Dependency: libwnck-1.so.18 for package: gnome-panel --> Processing Dependency: libwnck-1.so.18 for package: libwnck-devel --> Processing Dependency: libwnck-1.so.18 for package: notification-daemon --> Finished Dependency Resolution Error: Unresolveable requirement libwnck-1.so.18 for gnome-system-monitor Error: Unresolveable requirement libwnck-1.so.18 for gnome-applets Error: Unresolveable requirement libwnck-1.so.18 for gnome-power-manager Error: Unresolveable requirement libwnck-1.so.18 for gnome-panel Error: Unresolveable requirement libwnck-1.so.18 for libwnck-devel Error: Unresolveable requirement libwnck-1.so.18 for notification-daemon There are new versions of all these packages available however and when I force yum to pick them up using "yum update libwnck notification-daemon libwnck-devel gnome-panel gnome-power-manager gnome-applets gnome-system-monitor" then yum no longer complains. Shouldn't yum pick these up automatically? (This is with yum-3.2.2-3.fc8) Regards, Dennis From david at fubar.dk Fri Jul 27 21:55:24 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 27 Jul 2007 17:55:24 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185547210.15991.27.camel@localhost.localdomain> References: <1185532130.10773.10.camel@work> <46A9CC4D.6030807@gmail.com> <1185547210.15991.27.camel@localhost.localdomain> Message-ID: <1185573324.12294.2.camel@zelda.fubar.dk> On Fri, 2007-07-27 at 10:40 -0400, Jeremy Katz wrote: > On Fri, 2007-07-27 at 12:43 +0200, dragoran wrote: > > Richard Hughes wrote: > > > I've blogged about package management in Fedora (and how it sucks in > > > other distros too) and also discussed abstract per-system package > > > management over DBUS interfaces. > > > > > > I would appreciate feedback on > > > http://hughsient.livejournal.com/31429.html > > "Do we have to make the API asynchronous?" > > YES!!! > > the best way to fix the progressbar hangs is multithreading. > > let the gui draw its stuff, while a background thread does the real work. > > yumex afaik works this way. > > Unfortunately, introducing threading into an environment (rpm + sqlite) > which wasn't designed with threading in mind is a recipe for lots of ... > interesting problems. The proposal from Richard was to use IPC between the UI bits and the actual mechanism (yum, apt, whatever) that carries out the work. So the UI client would be a simple single-threaded process that just calls into a D-Bus system service. Async calls doesn't mean multithreaded, it can also means callback from a mainloop. Nothing new here. David From david at fubar.dk Fri Jul 27 22:02:46 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 27 Jul 2007 18:02:46 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185552318.2409.66.camel@cutter> References: <1185532130.10773.10.camel@work> <20070727135345.GH25862@nostromo.devel.redhat.com> <1185548902.2409.53.camel@cutter> <1185549513.2494.15.camel@work> <20070727152433.GC3365@nostromo.devel.redhat.com> <1185549828.2494.17.camel@work> <20070727153142.GE3365@nostromo.devel.redhat.com> <1185550719.3650.37.camel@localhost.localdomain> <1185550531.2409.61.camel@cutter> <1185552644.3323.62.camel@neutron.verbum.private> <1185552318.2409.66.camel@cutter> Message-ID: <1185573766.12294.10.camel@zelda.fubar.dk> On Fri, 2007-07-27 at 12:05 -0400, seth vidal wrote: > as a sysadmin I will say this: > > 1. if it ain't necessary it is off > 2. if nothing deps on it, it gets removed. > > > - now things depend on dbus these days, and that's fine - but on a > server with a static ip- even served via dhcp we don't need it - it's > just one more thing that can go wrong. No-one would prevent you from not installing the bits that provide a simple D-Bus interface for package management. I emphasize "simple", it would be madness to export just half of what yum/apt/whatever is capable of. The design of said interface would be driven by needs from (simple) UI applications. The implementation of said software bits wouldn't even need to come from yum, apt, whatever developers, it could be an abstraction on top of this; of course for this to work in a social context the relevant depsolver people would have to buy in and support the project etc. etc. Which I'm skeptical about but I would loved to be proved wrong. As for you other comment, "yet another daemon", I concur we don't want more daemons / services started than necessary. What Richard is proposing would simply just be started via D-Bus system bus activation. In fact, I think it's madness that there's a yum-updatesd in Fedora at all, it should just be started when needed and kill itself when it's not needed. If you need periodic checks, just use a cronjob and dbus-send(1) to poke the daemon. Thing is, we need to start as little as possible during boot. David From d.jacobfeuerborn at conversis.de Fri Jul 27 22:10:40 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 28 Jul 2007 00:10:40 +0200 Subject: Stability problem in current Rawhide Message-ID: <46AA6D60.7040300@conversis.de> After upgrading to Rawhide nautilus keeps crashing when I try navigate the tree-view. To fix this I had to downgrade to the following packages from FC7: gtk2-2.10.11-7.fc7.i386.rpm gtk2-engines-2.10.0-3.fc7.i386.rpm libgnome-2.18.0-4.fc7 libgnomeui-2.18.1-2.fc7 and for dependencies: gedit-2.18.0-3.fc7.i386.rpm gnome-applets-2.18.0-7.fc7.i386.rpm gnome-panel-2.18.0-9.fc7.i386.rpm gnome-power-manager-2.18.2-4.fc7.i386.rpm gnome-session-2.18.0-7.fc7.i386.rpm gnome-system-monitor-2.18.0-1.fc7.i386.rpm libwnck-2.18.0-3.fc7.i386.rpm notification-daemon-0.3.7-2.fc7.i386.rpm After this the desktop starts working again. I also checked the gnome bugzilla and searched for "libgnomeui" with the result that in the last couple of days/hours there appeared a ton of critical crasher bugs: http://bugzilla.gnome.org/buglist.cgi?query=libgnomeui Strangely I haven't seen any messages about this on the mailinglist. Am I really the only one who gets hit by this? Regards, Dennis From dakingun at gmail.com Fri Jul 27 22:45:31 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 27 Jul 2007 18:45:31 -0400 Subject: Stability problem in current Rawhide In-Reply-To: <46AA6D60.7040300@conversis.de> References: <46AA6D60.7040300@conversis.de> Message-ID: On 7/27/07, Dennis Jacobfeuerborn wrote: > After upgrading to Rawhide nautilus keeps crashing when I try navigate the > tree-view. To fix this I had to downgrade to the following packages from FC7: > It must be this bug, http://bugzilla.gnome.org/show_bug.cgi?id=459221. It has been fixed upstream. Deji From chris.stone at gmail.com Fri Jul 27 22:57:39 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 27 Jul 2007 15:57:39 -0700 Subject: Missing dependencies with glib2-devel? Message-ID: I'm getting the following error when trying to build my package with mock on F7: $ /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-7-x86_64/root install 'glib2-devel' Error: Missing Dependency: libgobject-2.0.so.0 is needed by package glib2-devel Error: Missing Dependency: libgthread-2.0.so.0 is needed by package glib2-devel Error: Missing Dependency: libglib-2.0.so.0 is needed by package glib2-devel Error: Missing Dependency: libgmodule-2.0.so.0 is needed by package glib2-devel My mock configs are unchanged from the default. From mike at miketc.com Fri Jul 27 23:33:53 2007 From: mike at miketc.com (Mike Chambers) Date: Fri, 27 Jul 2007 18:33:53 -0500 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185579233.6017.11.camel@scrappy.miketc.com> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? I don't know if this can be done now, or if at all, and I am not a developer or even really a packager, so this may be something way out in left field. BUT, upon saying all that, is there a way to create, make, or use some sort of restore point, to get rpm back in shape if a library or something gets out of wack? Maybe a rpm --backup option that can be used to backup rpm at a certain point. Then somehow it can be brought back to that state, even if it's a tar'd file, gzipped or whatever? Reason to have it that way is due to rpm not being functional or allowed to do anything because some library or whatever got screwed up, and you have to reinstall the OS instead of just a quick restore. Ok, ugh, as I got back and read what I wrote, it sounds stupid haha. But I guess what I am trying to say, is when the rpm db or whatever (like a library file that makes rpm unusable at all) gets borked, is there a state that rpm can be in, or whatever, to get it back to a working state at least until you can have rpm figure out what packages are installed again and up to par? Maybe I am asking this in the wrong way? I know other users have had these problems before but never really saw a way to fix it, cept for when rpm can be used to rebuild the db, but in this case, you can't even do that. LOL I'll go sit in the corner and shutup, eat a chip and watch the show :P -- Mike Chambers Madisonville, KY "Best little town on Earth!" From mschwendt.tmp0701.nospam at arcor.de Sat Jul 28 00:10:25 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 28 Jul 2007 02:10:25 +0200 Subject: rpms/arm-gp2x-linux-kernel-headers/FC-6 arm-gp2x-linux-kernel-headers.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: <200707272120.l6RLKqBm019770@cvs-int.fedora.redhat.com> References: <200707272120.l6RLKqBm019770@cvs-int.fedora.redhat.com> Message-ID: <20070728021025.83af9177.mschwendt.tmp0701.nospam@arcor.de> On Fri, 27 Jul 2007 17:20:52 -0400, Hans de Goede (jwrdegoede) wrote: > Author: jwrdegoede > > Update of /cvs/extras/rpms/arm-gp2x-linux-kernel-headers/FC-6 > %files > %doc doc/* > %{_prefix}/%{target} %defattr is missing here. From pemboa at gmail.com Sat Jul 28 01:41:19 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 27 Jul 2007 20:41:19 -0500 Subject: RPM roadmapping In-Reply-To: <1185579233.6017.11.camel@scrappy.miketc.com> References: <1185579233.6017.11.camel@scrappy.miketc.com> Message-ID: <16de708d0707271841y2f106fd7o2b857b71e4daf51e@mail.gmail.com> On 7/27/07, Mike Chambers wrote: > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > > > Not everybody is on rpm-maint list and we'd like to hear the wishes of > > (Fedora) developers/packagers too. So: what have you always wanted to do > > with rpm, but wasn't able to? Or the other way around: what you always > > wished rpm would do for you? What always annoyed you out of your mind? > > I don't know if this can be done now, or if at all, and I am not a > developer or even really a packager, so this may be something way out in > left field. > > BUT, upon saying all that, is there a way to create, make, or use some > sort of restore point, to get rpm back in shape if a library or > something gets out of wack? I'm wonder if rpm could rpm -e back to a certain point, then rpm -i --force all lib packages -- Fedora Core 6 and proud From wolfy at nobugconsulting.ro Sat Jul 28 01:45:26 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 28 Jul 2007 04:45:26 +0300 Subject: RPM roadmapping In-Reply-To: <604aa7910707271327s204695xea2ff896dfea2f1d@mail.gmail.com> References: <20070727222204.6d768b62@pensja.lam.pl> <604aa7910707271327s204695xea2ff896dfea2f1d@mail.gmail.com> Message-ID: <46AA9FB6.7020503@nobugconsulting.ro> On 07/27/2007 11:27 PM, Jeff Spaleta wrote: > On 7/27/07, Leszek Matok wrote: > >> - Tell if a given package was installed by hand (rpm -i/U/F) or (if installed >> by yum/apt/whatever) which repository did it come from. Some people suggested >> to use "Signature:" for that, but that only tells, which repo this pakage was >> first published on, and I want to know, where did I get it from in reality. >> > > Like the actual url it was pulled from, regardless of which mirror in > a dynamicly generated mirrorlist you used in that run? A > repository-wide signature/cert referenced in signed repository > metadata from the repository might be better in some ways than the > full url to a specific mirror. +1 for repository signature. Although the vendor tag is close enough that maybe this (coupled with the GPG key) could be used instead. From wolfy at nobugconsulting.ro Sat Jul 28 01:48:52 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 28 Jul 2007 04:48:52 +0300 Subject: RPM roadmapping In-Reply-To: <16de708d0707271841y2f106fd7o2b857b71e4daf51e@mail.gmail.com> References: <1185579233.6017.11.camel@scrappy.miketc.com> <16de708d0707271841y2f106fd7o2b857b71e4daf51e@mail.gmail.com> Message-ID: <46AAA084.7080602@nobugconsulting.ro> On 07/28/2007 04:41 AM, Arthur Pemberton wrote: > On 7/27/07, Mike Chambers wrote: > >> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: >> >> >>> Not everybody is on rpm-maint list and we'd like to hear the wishes of >>> (Fedora) developers/packagers too. So: what have you always wanted to do >>> with rpm, but wasn't able to? Or the other way around: what you always >>> wished rpm would do for you? What always annoyed you out of your mind? >>> >> I don't know if this can be done now, or if at all, and I am not a >> developer or even really a packager, so this may be something way out in >> left field. >> >> BUT, upon saying all that, is there a way to create, make, or use some >> sort of restore point, to get rpm back in shape if a library or >> something gets out of wack? >> > > > I'm wonder if rpm could rpm -e back to a certain point, then rpm -i > --force all lib packages > A --repackage option exists for a very log time. Life saver, sometimes... From hellwolf.misty at gmail.com Sat Jul 28 02:56:09 2007 From: hellwolf.misty at gmail.com (ZC Miao) Date: Sat, 28 Jul 2007 10:56:09 +0800 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185591369.2475.7.camel@cocteau.freehell.org> - Separated summary and description section Since currently package description is mostly written in english, it's not very friendly to non-english people. And the rpm spec is mostly maintained by one person, for whom maintaining i18n-summary such as Summary(zh): Summray(jp) is too hard. Any good ideas? -- http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F Mercury: gpm isn't a very good web browser. fix it. From debarshi.ray at gmail.com Sat Jul 28 03:27:46 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sat, 28 Jul 2007 08:57:46 +0530 Subject: High frequency noise in Fedora 7 In-Reply-To: <20070726203233.GG3673@serv.smile.org.ua> References: <3170f42f0707261216o348cebdcrd32f94c9a3954fe9@mail.gmail.com> <20070726203233.GG3673@serv.smile.org.ua> Message-ID: <3170f42f0707272027u61918acx90d4c2d403f8575@mail.gmail.com> > Did you try to setup ALSA 1.0.14 ? alsa-utils-1.0.14-0.7.fc8 from Rawhide fixed it. Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From tla at rasmil.dk Sat Jul 28 06:13:51 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Sat, 28 Jul 2007 08:13:51 +0200 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185547210.15991.27.camel@localhost.localdomain> References: <1185532130.10773.10.camel@work> <46A9CC4D.6030807@gmail.com> <1185547210.15991.27.camel@localhost.localdomain> Message-ID: <46AADE9F.4040909@rasmil.dk> Jeremy Katz wrote: > On Fri, 2007-07-27 at 12:43 +0200, dragoran wrote: > >> Richard Hughes wrote: >> >>> I've blogged about package management in Fedora (and how it sucks in >>> other distros too) and also discussed abstract per-system package >>> management over DBUS interfaces. >>> >>> I would appreciate feedback on >>> http://hughsient.livejournal.com/31429.html >>> >> "Do we have to make the API asynchronous?" >> YES!!! >> the best way to fix the progressbar hangs is multithreading. >> let the gui draw its stuff, while a background thread does the real work. >> yumex afaik works this way. >> > > Unfortunately, introducing threading into an environment (rpm + sqlite) > which wasn't designed with threading in mind is a recipe for lots of ... > interesting problems. > > Jeremy > > Yes, running yum actions in a background tread was a world of pain, so i have reversed the process and running the yum actions in the foreground and having a background thread refresh the gui. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From kagesenshi.87 at gmail.com Sat Jul 28 07:00:00 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sat, 28 Jul 2007 15:00:00 +0800 Subject: yum , https repo , and proxy : Yum fails .. In-Reply-To: <20070727135348.5d3d5a6e@banea.int.addix.net> References: <3170f42f0707260913w5379ec2cv3e1e921e28fbef1@mail.gmail.com> <200707262146.23188.opensource@till.name> <544eb990707270446s19fea6b7m27cdf8e286a7220e@mail.gmail.com> <20070727135348.5d3d5a6e@banea.int.addix.net> Message-ID: On 7/27/07, Ralf Ertzinger wrote: > Hi. > > On Fri, 27 Jul 2007 12:46:24 +0100, Bill Crawford wrote: > > > Squid simply won't do it that way (GET with an https: URL). The other > > programs are presumably doing a CONNECT request, which Squid does > > support. are you saying urlgrabber uses GET for HTTPS?? .. wtf > > HTTPS must use CONNECT, GET is plain broken for proxyconnects. Agreed .. afaik, HTTPS must use CONNECT and not GET .. why does urlgrabber say it can do https but it doesnt do CONNECT? So, is this a bug or a (weird) feature? ??? -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From rc040203 at freenet.de Sat Jul 28 07:03:58 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 28 Jul 2007 09:03:58 +0200 Subject: yum kernel/kmod update weirdness Message-ID: <1185606238.20980.464.camel@mccallum.corsepiu.local> Hi, Does anybody have an explanation for this? # rpm -qa 'kernel' 'kmod*' kernel-2.6.22.1-27.fc7 kernel-2.6.21-1.3228.fc7 kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7 kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 # yum update Installing: kernel i686 2.6.22.1-33.fc7 updates 16 M kmod-nvidia i686 100.14.11-1.2.6.22.1_33.fc7 livna 2.4 M Updating: kernel-headers i386 2.6.22.1-33.fc7 updates 652 k Removing: kernel i686 2.6.22.1-27.fc7 installed 46 M kmod-nvidia i686 100.14.11-1.2.6.21_1.3228.fc7 installed 7.5 M This would cause the system to end up with this setup: kernel-2.6.22.1-33.fc7 kernel-2.6.21-1.3228.fc7 kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 This doesn't seem right to me. Ralf From michel.sylvan at gmail.com Sat Jul 28 07:59:59 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 28 Jul 2007 15:59:59 +0800 Subject: RPM + packaging bug: many documentation files clobbered Message-ID: Hi all, I noticed something disturbing when trying to look up installed OpenSSL documentation the other day: a lot of packages have their documentation files missing. Running this script on my system: for i in `rpm -qa`; do rpm -V --nomd5 --nosize $i 1>/dev/null 2>&1 || echo $i done generates 283 packages, from acpid and anacron to yp-tools and zip. The cause is three-fold: 1. Said packages put their documentation in %{doc}/%{name}-%{version}, without %{release} 2. The RPM short-cut, triggered on package deletion, that skips the check if a file in /usr/share/ is owned by another package 3. Yum would install the new package, *then* remove the old package As such I am not sure where to file this bug. It is quite disturbing as in the past only 64-bit users who want to remove 32-bit RPMs notice this, but now due to the documentation packaging of some packages, the bug is also triggered on minor updates (version unchanged, release number bumped). Filing a bug against hundreds of packages sure does not look like fun. Suggestions? -- Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Sat Jul 28 08:24:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 28 Jul 2007 10:24:36 +0200 Subject: RPM + packaging bug: many documentation files clobbered In-Reply-To: References: Message-ID: <46AAFD44.6000907@hhs.nl> Michel Salim wrote: > Hi all, > > I noticed something disturbing when trying to look up installed OpenSSL > documentation > the other day: a lot of packages have their documentation files missing. > Running this script on my system: > > for i in `rpm -qa`; do > rpm -V --nomd5 --nosize $i 1>/dev/null 2>&1 || echo $i > done > > generates 283 packages, from acpid and anacron to yp-tools and zip. > > The cause is three-fold: > 1. Said packages put their documentation in %{doc}/%{name}-%{version}, > without %{release} > 2. The RPM short-cut, triggered on package deletion, that skips the check if > a file in /usr/share/ is owned by another package > 3. Yum would install the new package, *then* remove the old package > > As such I am not sure where to file this bug. It is quite disturbing as in > the past only 64-bit users who want to remove 32-bit RPMs notice this, but > now due to the documentation packaging of some packages, the bug is also > triggered on minor updates (version unchanged, release number bumped). > > Filing a bug against hundreds of packages sure does not look like fun. > Suggestions? > This is fixed in rpm-4.4.2.1, which is in rawhide now, and I believe it will be released as an F-7 update too. Regards, Hans From pmatilai at laiskiainen.org Sat Jul 28 08:39:35 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 11:39:35 +0300 (EEST) Subject: RPM + packaging bug: many documentation files clobbered In-Reply-To: References: Message-ID: On Sat, 28 Jul 2007, Michel Salim wrote: > Hi all, > > I noticed something disturbing when trying to look up installed OpenSSL > documentation > the other day: a lot of packages have their documentation files missing. > Running this script on my system: > > for i in `rpm -qa`; do > rpm -V --nomd5 --nosize $i 1>/dev/null 2>&1 || echo $i > done > > generates 283 packages, from acpid and anacron to yp-tools and zip. > > The cause is three-fold: > 1. Said packages put their documentation in %{doc}/%{name}-%{version}, > without %{release} > 2. The RPM short-cut, triggered on package deletion, that skips the check if > a file in /usr/share/ is owned by another package > 3. Yum would install the new package, *then* remove the old package > > As such I am not sure where to file this bug. It is quite disturbing as in > the past only 64-bit users who want to remove 32-bit RPMs notice this, but > now due to the documentation packaging of some packages, the bug is also > triggered on minor updates (version unchanged, release number bumped). > > Filing a bug against hundreds of packages sure does not look like fun. > Suggestions? No need to file hundreds of bugs when rpm is to blame. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247749 - Panu - From buildsys at redhat.com Sat Jul 28 09:20:47 2007 From: buildsys at redhat.com (Build System) Date: Sat, 28 Jul 2007 05:20:47 -0400 Subject: rawhide report: 20070728 changes Message-ID: <200707280920.l6S9KlLC006757@porkchop.devel.redhat.com> Updated Packages: anaconda-11.3.0.14-1 -------------------- * Fri Jul 27 2007 Chris Lumens 11.3.0.14-1 - Fix ppc keymaps (#249881). * Fri Jul 27 2007 Jeremy Katz - 11.3.0.13-1 - fix nfsiso (#249882) fedora-release-7.90-1 --------------------- * Fri Jul 27 2007 Jesse Keating - 7.90-1 - Bump for F8 Test1 * Thu Jun 28 2007 Jesse Keating - 7.89-3 - Cleanups from review - Don't (noreplace) the dist tag macro file * Tue Jun 19 2007 Jesse Keating - 7.89-2 - Define the dist macros in this package since we define everyting else here Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From jospoortvliet at kde.nl Sat Jul 28 09:58:39 2007 From: jospoortvliet at kde.nl (jos poortvliet) Date: Sat, 28 Jul 2007 11:58:39 +0200 Subject: KDE 4 Beta 1 Message-ID: <200707281158.42981.jospoortvliet@kde.nl> Dear people, The KDE project is about to release it's first beta for KDE 4. The package tarballs are available, to allow distributions to package it. We would like to know if your distribution will have packages available at or soon after the official release date, so we can mention it in the announcement. If so, please provide us with a link or location where to find those packages. If you won't have packages right away, you can tell us when they will be available, so we can mention that. Thank you for your co?peration, The KDE promo team kde-promo at kde.org -- Jos Poortvliet KDE-nl http://www.kde.nl http://www.kde.org Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ? ?A: Because it destroys the flow of the conversation ? ?Q: Why is top-posting bad? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From robert at fedoraproject.org Sat Jul 28 09:59:18 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Sat, 28 Jul 2007 11:59:18 +0200 Subject: RPM roadmapping In-Reply-To: <1185579233.6017.11.camel@scrappy.miketc.com> References: <1185579233.6017.11.camel@scrappy.miketc.com> Message-ID: <20070728095918.GA6199@hurricane.linuxnetz.de> Hello Mike, On Fri, 27 Jul 2007, Mike Chambers wrote: > BUT, upon saying all that, is there a way to create, make, or use some > sort of restore point, to get rpm back in shape if a library or > something gets out of wack? Maybe a rpm --backup option that can be > used to backup rpm at a certain point. Then somehow it can be brought > back to that state, even if it's a tar'd file, gzipped or whatever? > Reason to have it that way is due to rpm not being functional or allowed > to do anything because some library or whatever got screwed up, and you > have to reinstall the OS instead of just a quick restore. I think, you're looking for the rollback features being already part of rpm5.org for a longer time. What does this feature do? When you're updating or ereasing a package, it creates a package of the changed one. It's more or less equivalent to your expected tarball or gzipped one. Please notice, that of course this rollback rpm is not the same rpm as installed before, it is just a copy of what was in filesystem and was covered by the package. IIRC this feature was introduced in November 2005 at rpm5.org. You're able to extract things from this package my the help of rpm2cpio/cpio similar to a tarball. It's a nice feature which saved my ass in the past a couple of times, yes. Greetings, Robert From skvidal at linux.duke.edu Sat Jul 28 10:56:05 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 28 Jul 2007 06:56:05 -0400 Subject: yum kernel/kmod update weirdness In-Reply-To: <1185606238.20980.464.camel@mccallum.corsepiu.local> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> Message-ID: <1185620166.2409.114.camel@cutter> On Sat, 2007-07-28 at 09:03 +0200, Ralf Corsepius wrote: > Hi, > > Does anybody have an explanation for this? > > > # rpm -qa 'kernel' 'kmod*' > kernel-2.6.22.1-27.fc7 > kernel-2.6.21-1.3228.fc7 > kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7 > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > # yum update > Installing: > kernel i686 2.6.22.1-33.fc7 updates 16 M > kmod-nvidia i686 100.14.11-1.2.6.22.1_33.fc7 livna 2.4 M > Updating: > kernel-headers i386 2.6.22.1-33.fc7 updates 652 k > Removing: > kernel i686 2.6.22.1-27.fc7 installed 46 M > kmod-nvidia i686 100.14.11-1.2.6.21_1.3228.fc7 installed 7.5 M > > > This would cause the system to end up with this setup: > kernel-2.6.22.1-33.fc7 > kernel-2.6.21-1.3228.fc7 > kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > This doesn't seem right to me. do you have the yum kmod plugin installed? -sv From michel.sylvan at gmail.com Sat Jul 28 12:24:05 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 28 Jul 2007 20:24:05 +0800 Subject: RPM + packaging bug: many documentation files clobbered In-Reply-To: References: Message-ID: On 28/07/07, Panu Matilainen wrote: > > On Sat, 28 Jul 2007, Michel Salim wrote: > > > 1. Said packages put their documentation in %{doc}/%{name}-%{version}, > > without %{release} > > 2. The RPM short-cut, triggered on package deletion, that skips the > check if > > a file in /usr/share/ is owned by another package > > 3. Yum would install the new package, *then* remove the old package > > > > Filing a bug against hundreds of packages sure does not look like fun. > > Suggestions? > > No need to file hundreds of bugs when rpm is to blame. > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247749 It's slightly disturbing to see the bug being marked as low-priority. Hopefully an update will be released for FC6 and RHEL 4/5 too. Regards, -- Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Sat Jul 28 13:20:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 28 Jul 2007 15:20:46 +0200 Subject: yum kernel/kmod update weirdness In-Reply-To: <1185620166.2409.114.camel@cutter> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> <1185620166.2409.114.camel@cutter> Message-ID: <1185628846.4868.1.camel@mccallum.corsepiu.local> On Sat, 2007-07-28 at 06:56 -0400, seth vidal wrote: > On Sat, 2007-07-28 at 09:03 +0200, Ralf Corsepius wrote: > > Hi, > > > > Does anybody have an explanation for this? > > > > > > # rpm -qa 'kernel' 'kmod*' > > kernel-2.6.22.1-27.fc7 > > kernel-2.6.21-1.3228.fc7 > > kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7 > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > # yum update > > Installing: > > kernel i686 2.6.22.1-33.fc7 updates 16 M > > kmod-nvidia i686 100.14.11-1.2.6.22.1_33.fc7 livna 2.4 M > > Updating: > > kernel-headers i386 2.6.22.1-33.fc7 updates 652 k > > Removing: > > kernel i686 2.6.22.1-27.fc7 installed 46 M > > kmod-nvidia i686 100.14.11-1.2.6.21_1.3228.fc7 installed 7.5 M > > > > > > This would cause the system to end up with this setup: > > kernel-2.6.22.1-33.fc7 > > kernel-2.6.21-1.3228.fc7 > > kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > This doesn't seem right to me. > > do you have the yum kmod plugin installed? Nope, just these: # rpm -qa 'yum*' yum-metadata-parser-1.1.0-2.fc7 yum-utils-1.1.5-1.fc7 yum-3.2.1-1.fc7 Ralf From kevin.kofler at chello.at Sat Jul 28 13:24:52 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 28 Jul 2007 13:24:52 +0000 (UTC) Subject: rpms/arm-gp2x-linux-kernel-headers/FC-6 arm-gp2x-linux-kernel-headers.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 References: <200707272120.l6RLKqBm019770@cvs-int.fedora.redhat.com> <20070728021025.83af9177.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > > Update of /cvs/extras/rpms/arm-gp2x-linux-kernel-headers/FC-6 > > > %files > > %doc doc/* > > %{_prefix}/%{target} > > %defattr is missing here. Oops, I missed that one during the review. Sorry for that. Kevin Kofler From d.jacobfeuerborn at conversis.de Sat Jul 28 13:28:09 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 28 Jul 2007 15:28:09 +0200 Subject: Stability problem in current Rawhide In-Reply-To: References: <46AA6D60.7040300@conversis.de> Message-ID: <46AB4469.3030206@conversis.de> Deji Akingunola wrote: > On 7/27/07, Dennis Jacobfeuerborn wrote: >> After upgrading to Rawhide nautilus keeps crashing when I try navigate the >> tree-view. To fix this I had to downgrade to the following packages from FC7: >> > It must be this bug, http://bugzilla.gnome.org/show_bug.cgi?id=459221. > It has been fixed upstream. > Yep, applying this patch to the source rpm fixed things for me. Thanks for the pointer. Regards, Dennis From j.w.r.degoede at hhs.nl Sat Jul 28 13:30:12 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 28 Jul 2007 15:30:12 +0200 Subject: rpms/arm-gp2x-linux-kernel-headers/FC-6 arm-gp2x-linux-kernel-headers.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2 In-Reply-To: References: <200707272120.l6RLKqBm019770@cvs-int.fedora.redhat.com> <20070728021025.83af9177.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46AB44E4.5030909@hhs.nl> Kevin Kofler wrote: > Michael Schwendt arcor.de> writes: >>> Update of /cvs/extras/rpms/arm-gp2x-linux-kernel-headers/FC-6 >>> %files >>> %doc doc/* >>> %{_prefix}/%{target} >> %defattr is missing here. > > Oops, I missed that one during the review. Sorry for that. > Oops from me too, I've checked the build packages and no harm is done. (files owner is still root, root) I'll add the defattr to CVS so that it will be therw with the next build. Regards, Hans From kevin.kofler at chello.at Sat Jul 28 14:52:20 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 28 Jul 2007 14:52:20 +0000 (UTC) Subject: RPM roadmapping References: <1185591369.2475.7.camel@cocteau.freehell.org> Message-ID: ZC Miao gmail.com> writes: > Since currently package description is mostly written in english, it's > not very friendly to non-english people. > And the rpm spec is mostly maintained by one person, for whom > maintaining i18n-summary such as Summary(zh): Summray(jp) is too hard. > > Any good ideas? That's what specspo is supposed to be for, it just doesn't appear to be very actively maintained. Kevin Kofler From chris.stone at gmail.com Sat Jul 28 14:54:31 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 28 Jul 2007 07:54:31 -0700 Subject: Missing dependencies with glib2-devel? In-Reply-To: References: Message-ID: Tried again this morning... still broken....anyone? On 7/27/07, Christopher Stone wrote: > I'm getting the following error when trying to build my package with mock on F7: > > $ /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-7-x86_64/root install 'glib2-devel' > Error: Missing Dependency: libgobject-2.0.so.0 is needed by package glib2-devel > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package glib2-devel > Error: Missing Dependency: libglib-2.0.so.0 is needed by package glib2-devel > Error: Missing Dependency: libgmodule-2.0.so.0 is needed by package glib2-devel > > My mock configs are unchanged from the default. > From kevin.kofler at chello.at Sat Jul 28 14:53:49 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 28 Jul 2007 14:53:49 +0000 (UTC) Subject: RPM roadmapping References: Message-ID: Panu Matilainen redhat.com> writes: > - RPM is not an ftp/http client, it's a package manager. Am I the only one who things that being able to rpm -Uvh http://....rpm is a nice feature? Kevin Kofler From robert at fedoraproject.org Sat Jul 28 15:01:54 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Sat, 28 Jul 2007 17:01:54 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070728150154.GA14079@hurricane.linuxnetz.de> Hello Kevin, On Sat, 28 Jul 2007, Kevin Kofler wrote: > Am I the only one who things that being able to rpm -Uvh http://....rpm > is a nice feature? no you aren't - we're at least two guys. I hope, Panu will not rip out such things, but use an external helper or similar. It's worse enough to see, that openSUSE rips neon support out to replace with a 50 lines hack. Maybe there are chances to optimize this transport. Greetings, Robert From fedora at leemhuis.info Sat Jul 28 15:20:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 28 Jul 2007 17:20:44 +0200 Subject: RPM roadmapping In-Reply-To: <20070728150154.GA14079@hurricane.linuxnetz.de> References: <20070728150154.GA14079@hurricane.linuxnetz.de> Message-ID: <46AB5ECC.2000901@leemhuis.info> On 28.07.2007 17:01, Robert Scheck wrote: > Hello Kevin, > > On Sat, 28 Jul 2007, Kevin Kofler wrote: >> Am I the only one who things that being able to rpm -Uvh http://....rpm >> is a nice feature? > no you aren't - we're at least two guys. Well, afaics most of the other linux command line tools don't support such stuff, so why should rpm? IOW, $ strings http://....rpm | less" doesn't work. But $ wget -O - http://....rpm | strings | less does. So $ wget -O - http://....rpm | rpm -ivh would match the behavior of other tools (but doesn't work afaics -- that maybe should be fixed). Cu thl From martin at bugs.unl.edu.ar Sat Jul 28 16:17:31 2007 From: martin at bugs.unl.edu.ar (Martin Marques) Date: Sat, 28 Jul 2007 13:17:31 -0300 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <46AB6C1B.7010205@bugs.unl.edu.ar> Kevin Kofler escribi?: > Panu Matilainen redhat.com> writes: >> - RPM is not an ftp/http client, it's a package manager. > > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > nice feature? Uhhh?? rpm does this since version 3.x, or before. -- select 'mmarques' || '@' || 'unl.edu.ar' AS email; --------------------------------------------------------- Mart?n Marqu?s | Programador, DBA Centro de Telem?tica | Administrador Universidad Nacional del Litoral --------------------------------------------------------- From emmanuel.seyman at club-internet.fr Sat Jul 28 16:46:26 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sat, 28 Jul 2007 18:46:26 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070728164626.GA32055@orient.maison.lan> * Kevin Kofler [28/07/2007 18:41] : > > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > nice feature? No but then again, I'll live with wget http://....rpm -O foo && rpm -Uvh foo Emmanuel From pmatilai at laiskiainen.org Sat Jul 28 17:19:47 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 20:19:47 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <20070728095918.GA6199@hurricane.linuxnetz.de> References: <1185579233.6017.11.camel@scrappy.miketc.com> <20070728095918.GA6199@hurricane.linuxnetz.de> Message-ID: On Sat, 28 Jul 2007, Robert Scheck wrote: > Hello Mike, > > On Fri, 27 Jul 2007, Mike Chambers wrote: >> BUT, upon saying all that, is there a way to create, make, or use some >> sort of restore point, to get rpm back in shape if a library or >> something gets out of wack? Maybe a rpm --backup option that can be >> used to backup rpm at a certain point. Then somehow it can be brought >> back to that state, even if it's a tar'd file, gzipped or whatever? >> Reason to have it that way is due to rpm not being functional or allowed >> to do anything because some library or whatever got screwed up, and you >> have to reinstall the OS instead of just a quick restore. > > I think, you're looking for the rollback features being already part of > rpm5.org for a longer time. What does this feature do? When you're updating > or ereasing a package, it creates a package of the changed one. It's more > or less equivalent to your expected tarball or gzipped one. Please notice, > that of course this rollback rpm is not the same rpm as installed before, > it is just a copy of what was in filesystem and was covered by the package. > > IIRC this feature was introduced in November 2005 at rpm5.org. You're able > to extract things from this package my the help of rpm2cpio/cpio similar to > a tarball. It's a nice feature which saved my ass in the past a couple of > times, yes. Repackaging for rollback is an *ancient* feature of rpm, goes back all the way to rpm 4.0.0. - Panu - From kevin.kofler at chello.at Sat Jul 28 18:04:55 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 28 Jul 2007 18:04:55 +0000 (UTC) Subject: RPM roadmapping References: <46AB6C1B.7010205@bugs.unl.edu.ar> Message-ID: Martin Marques bugs.unl.edu.ar> writes: > Kevin Kofler escribi?: > > Panu Matilainen redhat.com> writes: > >> - RPM is not an ftp/http client, it's a package manager. > > > > Am I the only one who [thinks] that being able to rpm -Uvh http://....rpm > > is a nice feature? > > Uhhh?? rpm does this since version 3.x, or before. But it appears like this feature is proposed to be axed. Kevin Kofler From cmadams at hiwaay.net Sat Jul 28 18:16:13 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 28 Jul 2007 13:16:13 -0500 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <20070724223314.13ea9d19@ender> References: <20070724223314.13ea9d19@ender> Message-ID: <20070728181613.GC1177976@hiwaay.net> Once upon a time, Jesse Keating said: > If you wish to help us get to Test1, please follow > http://fedoraproject.org/wiki/QA/8/Test1TreeTesting Okay, I was going to give this a try, but there doesn't appear to be an installable tree available. Both i386 and x86_64 are missing the images directory, so there's no kernel, initrd, etc. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pmatilai at laiskiainen.org Sat Jul 28 18:31:05 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 21:31:05 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <1185542422.3928.54.camel@dimi.lattica.com> References: <1185542422.3928.54.camel@dimi.lattica.com> Message-ID: On Fri, 27 Jul 2007, Dimi Paun wrote: > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: >> Or the other way around: what you always >> wished rpm would do for you? What always annoyed you out of your mind? > > * Version control the meta-information > This can't be efficiently done outside RPM, and it would provide > an administrator with an invaluable tool (say a malfunction starts > at about 4am): > - what packages changes are different from yesterday? > - what files have changed for package foo between version V and W? > - what's the history of package foo on this system? > Not very difficult, but quite useful. Every time something breaks > on a system (usually via an automatic yum update) I would kill > for the ability to run such queries. Ah, something fresh for a change :) Most of the things that have come up in this thread, well lets just say I'd been very surprised if they hadn't come up. > * Ability to save a pristine copy for the configuration files > This would make it a _lot_ simpler to integrate the new .rpmnew > files, in a lot of cases being as simple as: > diff foo.pristine foo | patch -o foo foo.rpmnew > At the very least to provide some sort of mechanism that would > permit an external trigger to so easily and efficiently. > > This maybe already implemented (never checked in depth the transaction > triggers), but a mechanism for external tools to hook into the > transactions would be great. More generally, the external triggers must > be given enough information about the current transaction to be able to > know the delta that the transaction introduces without having to scan > the entire state of the system. As a litmus test, you should be able to > implement the version control idea mentioned above via this mechanism > easily and efficiently. I've been thinking of somewhat different use case, but one of my plans is to indeed make information about the current transaction available to (lua-)scripts. I already have written beginnings of lua-rpm bindings, once that's in usable shape and integrated, scripts could look at current transaction member packages, their files etc and do decisions based on that info. - Panu - From sundaram at fedoraproject.org Sat Jul 28 18:50:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 29 Jul 2007 00:20:03 +0530 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <46AB8FDB.6040609@fedoraproject.org> Panu Matilainen wrote: > > Hey all, > > I know I'm opening up Pandoras box here but what the heck, it's Friday > and I'm feeling slightly bored... > > With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode, > time to start looking forward to next major release. While the focus > will be largely in cleaning up and streamlining the codebase, it can't > realistically be all about just that User (as opposed to administrator) installs in their home directories. I could run say Mozilla Firefox extracted from a tarball but having a similar capability in RPM itself would be nice. RPM should also recognize and use library files I have installed through other means. Rahul From pmatilai at laiskiainen.org Sat Jul 28 19:04:41 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 22:04:41 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <20070727143238.GC27466@nostromo.devel.redhat.com> References: <1185542632.3650.11.camel@localhost.localdomain> <20070727143103.GB27466@nostromo.devel.redhat.com> <20070727143238.GC27466@nostromo.devel.redhat.com> Message-ID: On Fri, 27 Jul 2007, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: >>> %posttrans works now afaik. Is there something you want that isn't there >>> now? >> >> Ideally, merging of identical %posttrans. > > ... and, running on uninstall as well. Rather than trying to figure identical %posttrans between packages, I'd like to see a mechanism to allow packages flagging things like "after install/removal I need a) ldconfig run b) icon cache updated" and have them run centrally after everything else has completed (lets call it "%sysposttrans" that gets run after any non-empty transaction has fully completed). Basically what was discussed in this thread: https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00061.html I remember when some years ago something like [ -x /usr/bin/update-foo ] && /usr/bin/update-foo was copy-pasted into dozens of packages, only there was a typo that caused every such scriptlet breaking and needed another mass rebuild to fix. If it had been just a flag to do "update-foo" then the actual update-foo script could've been fixed just once instead of having to copy-paste it into every bleeping package and ran several times during a transaction. Obviously packages have their special needs and not everything can be generalized, but there are plenty enough things where this would be applicaple. - Panu - From Lam at Lam.pl Sat Jul 28 19:05:09 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 28 Jul 2007 21:05:09 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070728210509.5abedb9b@pensja.lam.pl> Dnia 2007-07-28, o godz. 14:53:49 Kevin Kofler napisa?(a): > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > nice feature? It's nice the first time you think of it. But the first time you actually try it, rpm tells you it needs some other packages for dependencies and you have to download the file again. At least it worked that way last time I've tried, maybe it supports some caching now? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Jul 28 19:14:41 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 28 Jul 2007 22:14:41 +0300 Subject: RPM roadmapping In-Reply-To: <46AB5ECC.2000901@leemhuis.info> References: <20070728150154.GA14079@hurricane.linuxnetz.de> <46AB5ECC.2000901@leemhuis.info> Message-ID: <200707282214.41859.ville.skytta@iki.fi> On Saturday 28 July 2007, Thorsten Leemhuis wrote: > On 28.07.2007 17:01, Robert Scheck wrote: > > Hello Kevin, > > > > On Sat, 28 Jul 2007, Kevin Kofler wrote: > >> Am I the only one who things that being able to rpm -Uvh http://....rpm > >> is a nice feature? > > > > no you aren't - we're at least two guys. > > Well, afaics most of the other linux command line tools don't support > such stuff Well, I'd actually prefer if most of them did. But (re-)implementing that everywhere wouldn't probably make sense and not everything works with stdin so things aren't always that easy. Here's a slightly cleaned up version of a helper script I've had locally to help with this for some time: $ urlwrap.sh less -- http://scop.fedorapeople.org/scripts/urlwrap.sh $ urlwrap.sh rpm -Uvh -- http://.../1.rpm http://.../2.rpm From kevin.kofler at chello.at Sat Jul 28 19:29:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 28 Jul 2007 19:29:19 +0000 (UTC) Subject: RPM roadmapping References: <20070728150154.GA14079@hurricane.linuxnetz.de> <46AB5ECC.2000901@leemhuis.info> <200707282214.41859.ville.skytta@iki.fi> Message-ID: Ville Skytt? iki.fi> writes: > Well, I'd actually prefer if most of them did. But (re-)implementing that > everywhere wouldn't probably make sense and not everything works with stdin > so things aren't always that easy. Here's a slightly cleaned up version of a > helper script I've had locally to help with this for some time: > > $ urlwrap.sh less -- http://scop.fedorapeople.org/scripts/urlwrap.sh > $ urlwrap.sh rpm -Uvh -- http://.../1.rpm http://.../2.rpm Hint: You can also use kioexec (part of kdelibs) for this purpose. Kevin Kofler From pmatilai at laiskiainen.org Sat Jul 28 19:48:54 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 28 Jul 2007 22:48:54 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: References: <46AB6C1B.7010205@bugs.unl.edu.ar> Message-ID: On Sat, 28 Jul 2007, Kevin Kofler wrote: > Martin Marques bugs.unl.edu.ar> writes: >> Kevin Kofler escribi?: >>> Panu Matilainen redhat.com> writes: >>>> - RPM is not an ftp/http client, it's a package manager. >>> >>> Am I the only one who [thinks] that being able to rpm -Uvh http://....rpm >>> is a nice feature? >> >> Uhhh?? rpm does this since version 3.x, or before. > > But it appears like this feature is proposed to be axed. To get some perspective into this, look at the following bugs and ask yourself, what does this have to do with package management? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149276 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189107 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206066 It's not the feature I want to axe, but the client code *in* rpm. There's software designed to deal with these kind of things, let them handle the complexities. - Panu - From pemboa at gmail.com Sat Jul 28 19:51:54 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 28 Jul 2007 14:51:54 -0500 Subject: RPM roadmapping In-Reply-To: References: <46AB6C1B.7010205@bugs.unl.edu.ar> Message-ID: <16de708d0707281251s1208624qa41dcc3629b66b6@mail.gmail.com> On 7/28/07, Panu Matilainen wrote: > On Sat, 28 Jul 2007, Kevin Kofler wrote: > > > Martin Marques bugs.unl.edu.ar> writes: > >> Kevin Kofler escribi?: > >>> Panu Matilainen redhat.com> writes: > >>>> - RPM is not an ftp/http client, it's a package manager. > >>> > >>> Am I the only one who [thinks] that being able to rpm -Uvh http://....rpm > >>> is a nice feature? > >> > >> Uhhh?? rpm does this since version 3.x, or before. > > > > But it appears like this feature is proposed to be axed. > > To get some perspective into this, look at the following bugs and ask > yourself, what does this have to do with package management? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149276 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=189107 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206066 > > It's not the feature I want to axe, but the client code *in* rpm. There's > software designed to deal with these kind of things, let them handle the > complexities. >From a programming standpoint, this makes a lot of sense + plus it isn't the unix way, and if it adds even a single bug, it dosn't seem worth it. -- Fedora Core 6 and proud From skvidal at linux.duke.edu Sat Jul 28 19:18:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 28 Jul 2007 15:18:07 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185650287.2409.117.camel@cutter> On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote: > Panu Matilainen redhat.com> writes: > > - RPM is not an ftp/http client, it's a package manager. > > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > nice feature? it's not an issue of it being a nice feature - it is an issue of whether it is a good idea to maintain the code. Keep in mind - rpm has its own http/ftp client included. It's not using curl or wget. All its own code. That seems a bit much to maintain esp when the majority of people using rpm do it through a higher level language that already has a http/ftp client. the best way to make rpm reliable and consistent is to strip out all things that are unnecessary. -sv From skvidal at linux.duke.edu Sat Jul 28 20:09:42 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 28 Jul 2007 16:09:42 -0400 Subject: RPM roadmapping In-Reply-To: <46AB8FDB.6040609@fedoraproject.org> References: <46AB8FDB.6040609@fedoraproject.org> Message-ID: <1185653382.2409.120.camel@cutter> On Sun, 2007-07-29 at 00:20 +0530, Rahul Sundaram wrote: > Panu Matilainen wrote: > > > > Hey all, > > > > I know I'm opening up Pandoras box here but what the heck, it's Friday > > and I'm feeling slightly bored... > > > > With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode, > > time to start looking forward to next major release. While the focus > > will be largely in cleaning up and streamlining the codebase, it can't > > realistically be all about just that > > User (as opposed to administrator) installs in their home directories. I > could run say Mozilla Firefox extracted from a tarball but having a > similar capability in RPM itself would be nice. > > RPM should also recognize and use library files I have installed through > other means. -ENOTSANE It does not make sense to have rpm chase down paths which may or may not be available at any given time. Let alone be able to maintain and verify them. (think security updates) If it is not in the rpmdb then rpm doesn't know about it. I like that rule, it's hard, it's fast and it's simple to understand. If the problem is making it possible for users to install more software then we can pursue other ways to do that. -sv From abo at kth.se Sat Jul 28 20:21:03 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 28 Jul 2007 22:21:03 +0200 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <20070727113123.26638c99@localhost.localdomain> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> <1185548040.2494.6.camel@work> <20070727113123.26638c99@localhost.localdomain> Message-ID: <1185654063.18306.10.camel@home.alexander.bostrom.net> fre 2007-07-27 klockan 11:31 -0400 skrev Jesse Keating: > OO wants to use that file, that file isn't installed, ask yum to > install that file. Maybe this would be a good way to allow bug-buddy to try to get the right debuginfo packages installed before generating the stack trace? /abo From skvidal at linux.duke.edu Sat Jul 28 20:13:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 28 Jul 2007 16:13:00 -0400 Subject: yum kernel/kmod update weirdness In-Reply-To: <1185628846.4868.1.camel@mccallum.corsepiu.local> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> <1185620166.2409.114.camel@cutter> <1185628846.4868.1.camel@mccallum.corsepiu.local> Message-ID: <1185653580.2409.122.camel@cutter> On Sat, 2007-07-28 at 15:20 +0200, Ralf Corsepius wrote: > On Sat, 2007-07-28 at 06:56 -0400, seth vidal wrote: > > On Sat, 2007-07-28 at 09:03 +0200, Ralf Corsepius wrote: > > > Hi, > > > > > > Does anybody have an explanation for this? > > > > > > > > > # rpm -qa 'kernel' 'kmod*' > > > kernel-2.6.22.1-27.fc7 > > > kernel-2.6.21-1.3228.fc7 > > > kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7 > > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > > > # yum update > > > Installing: > > > kernel i686 2.6.22.1-33.fc7 updates 16 M > > > kmod-nvidia i686 100.14.11-1.2.6.22.1_33.fc7 livna 2.4 M > > > Updating: > > > kernel-headers i386 2.6.22.1-33.fc7 updates 652 k > > > Removing: > > > kernel i686 2.6.22.1-27.fc7 installed 46 M > > > kmod-nvidia i686 100.14.11-1.2.6.21_1.3228.fc7 installed 7.5 M > > > > > > > > > This would cause the system to end up with this setup: > > > kernel-2.6.22.1-33.fc7 > > > kernel-2.6.21-1.3228.fc7 > > > kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 > > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > > > This doesn't seem right to me. > > > > do you have the yum kmod plugin installed? > Nope, just these: > > # rpm -qa 'yum*' > yum-metadata-parser-1.1.0-2.fc7 > yum-utils-1.1.5-1.fc7 > yum-3.2.1-1.fc7 > If you install yum-kernel-module does it start doing the right thing? -sv From jima at beer.tclug.org Sat Jul 28 21:12:07 2007 From: jima at beer.tclug.org (Jima) Date: Sat, 28 Jul 2007 16:12:07 -0500 (CDT) Subject: yum kernel/kmod update weirdness In-Reply-To: <1185606238.20980.464.camel@mccallum.corsepiu.local> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> Message-ID: On Sat, 28 Jul 2007, Ralf Corsepius wrote: > Does anybody have an explanation for this? *snip* > This would cause the system to end up with this setup: > kernel-2.6.22.1-33.fc7 > kernel-2.6.21-1.3228.fc7 > kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > This doesn't seem right to me. Out of curiosity, which kernel is running? 2.6.21-1.3228.fc7 or 2.6.22.1-27.fc7? Off the cuff, I'd guessing the former, and yum is trying to make sure it stays installed, but is also trying to make sure only two kmod-nvidia packages are installed, but the logic is telling it to keep the two latest installed instead of the one matching the current-running kernel and the latest (like it's doing with the kernel). Wow, did that even make sense? :-) Just a shot in the dark. (And yes, I would agree that the behavior is non-intuitive.) Jima From pemboa at gmail.com Sat Jul 28 21:14:34 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 28 Jul 2007 16:14:34 -0500 Subject: RPM roadmapping In-Reply-To: <1185650287.2409.117.camel@cutter> References: <1185650287.2409.117.camel@cutter> Message-ID: <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> On 7/28/07, seth vidal wrote: > On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote: > > Panu Matilainen redhat.com> writes: > > > - RPM is not an ftp/http client, it's a package manager. > > > > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > > nice feature? > > it's not an issue of it being a nice feature - it is an issue of whether > it is a good idea to maintain the code. Keep in mind - rpm has its own > http/ftp client included. It's not using curl or wget. All its own code. > That seems a bit much to maintain esp when the majority of people using > rpm do it through a higher level language that already has a http/ftp > client. > > the best way to make rpm reliable and consistent is to strip out all > things that are unnecessary. > > -sv I would imagine this opens RPM up to remote attacks too. -- Fedora Core 6 and proud From opensource at till.name Sat Jul 28 21:35:03 2007 From: opensource at till.name (Till Maas) Date: Sat, 28 Jul 2007 23:35:03 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <200707282335.14256.opensource@till.name> On Friday 27 July 2007 14:40:40 Panu Matilainen wrote: > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? rpmbuild could implement itself all the stuff that is the same in Fedora's specs: - a sane default buildroot definition - Cleaning $RPM_BUILD_ROOT itself in %install (and without any race condition) - A default %clean section with rm -rf $RPM_BUILD_ROOT - %defattr(-,root,root,-) per default in %files This would save at least 5 lines in nearly every spec of Fedora. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From buildsys at redhat.com Sat Jul 28 22:04:01 2007 From: buildsys at redhat.com (Build System) Date: Sat, 28 Jul 2007 18:04:01 -0400 Subject: rawhide report: 20070728 changes Message-ID: <200707282204.l6SM41bY019042@porkchop.devel.redhat.com> Updated Packages: anaconda-11.3.0.14-1 -------------------- * Fri Jul 27 2007 Chris Lumens 11.3.0.14-1 - Fix ppc keymaps (#249881). * Fri Jul 27 2007 Jeremy Katz - 11.3.0.13-1 - fix nfsiso (#249882) fedora-release-7.90-1 --------------------- * Fri Jul 27 2007 Jesse Keating - 7.90-1 - Bump for F8 Test1 * Thu Jun 28 2007 Jesse Keating - 7.89-3 - Cleanups from review - Don't (noreplace) the dist tag macro file * Tue Jun 19 2007 Jesse Keating - 7.89-2 - Define the dist macros in this package since we define everyting else here pungi-0.4.0-1.fc8 ----------------- * Sat Jul 28 2007 Jesse Keating - 0.4.0-1 - split createrepo call to it's own function. This enables rawhide composes to happen once again. Also breaks API. - When raising an error, print the error too Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From dimi at lattica.com Sat Jul 28 22:52:00 2007 From: dimi at lattica.com (Dimi Paun) Date: Sat, 28 Jul 2007 18:52:00 -0400 Subject: RPM roadmapping In-Reply-To: <200707282335.14256.opensource@till.name> References: <200707282335.14256.opensource@till.name> Message-ID: <1185663120.3928.87.camel@dimi.lattica.com> On Sat, 2007-07-28 at 23:35 +0200, Till Maas wrote: > > rpmbuild could implement itself all the stuff that is the same in Fedora's > specs: > > - a sane default buildroot definition > - Cleaning $RPM_BUILD_ROOT itself in %install (and without any race condition) > - A default %clean section with rm -rf $RPM_BUILD_ROOT > - %defattr(-,root,root,-) per default in %files > > This would save at least 5 lines in nearly every spec of Fedora. It's not a matter of saving space, but this is a conceptual problem too -- why should the .spec file know and set the $RPM_BUILD_ROOT? And why should it do the default 'rm -rf $RPM_BUILD_ROOT'??? This _feels_ very, very wrong. It is a clear layering violation that is confusing and counterproductive. rpmbuild should create the root and pass it into the .spec, taking care of cleaning it when appropriate. My proposal is to implement this where it belongs (in rpmbuild), and issue warnings (and ignore) any attempt to set the build root or to rm -rf it from within the spec. -- Dimi Paun Lattica, Inc. From dimi at lattica.com Sat Jul 28 22:57:00 2007 From: dimi at lattica.com (Dimi Paun) Date: Sat, 28 Jul 2007 18:57:00 -0400 Subject: RPM roadmapping In-Reply-To: References: <1185542422.3928.54.camel@dimi.lattica.com> Message-ID: <1185663420.3928.93.camel@dimi.lattica.com> On Sat, 2007-07-28 at 21:31 +0300, Panu Matilainen wrote: > > * Version control the meta-information [...] > Ah, something fresh for a change :) Most of the things that have come up > in this thread, well lets just say I'd been very surprised if they hadn't > come up. Great, since I got no reaction to this idea, I thought maybe I was out to lunch :) Apart from being fresh, do you think it's worth it? Would you consider it for inclusion? Do you think it would be hard to do? > I've been thinking of somewhat different use case, but one of my plans is > to indeed make information about the current transaction available to > (lua-)scripts. I already have written beginnings of lua-rpm bindings, once > that's in usable shape and integrated, scripts could look at current > transaction member packages, their files etc and do decisions based on > that info. I'd be interested in seeing the interface when you have it available. If it could support the features I proposed, I'd still be happy (even though I really think they should be base features in rpm(1) instead of extension scripts, so that people can rely on them everywhere). -- Dimi Paun Lattica, Inc. From cmadams at hiwaay.net Sat Jul 28 23:52:38 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 28 Jul 2007 18:52:38 -0500 Subject: Frozen for Fedora 8 Test1 In-Reply-To: <20070728181613.GC1177976@hiwaay.net> References: <20070724223314.13ea9d19@ender> <20070728181613.GC1177976@hiwaay.net> Message-ID: <20070728235237.GE1177976@hiwaay.net> Once upon a time, Chris Adams said: > Okay, I was going to give this a try, but there doesn't appear to be an > installable tree available. Never mind, I see this afternoon's push. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rc040203 at freenet.de Sun Jul 29 03:43:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 29 Jul 2007 05:43:54 +0200 Subject: yum kernel/kmod update weirdness In-Reply-To: References: <1185606238.20980.464.camel@mccallum.corsepiu.local> Message-ID: <1185680634.4868.27.camel@mccallum.corsepiu.local> On Sat, 2007-07-28 at 16:12 -0500, Jima wrote: > On Sat, 28 Jul 2007, Ralf Corsepius wrote: > > Does anybody have an explanation for this? > *snip* > > This would cause the system to end up with this setup: > > kernel-2.6.22.1-33.fc7 > > kernel-2.6.21-1.3228.fc7 > > kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > This doesn't seem right to me. > > Out of curiosity, which kernel is running? 2.6.21-1.3228.fc7 or > 2.6.22.1-27.fc7? It had been kernel-2.6.21-1.3228.fc7.i686 + kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7.i686 while kernel-2.6.22.1-27.fc7.i686 + kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7.i686 already had been installed. > Off the cuff, I'd guessing the former, You are guessing correct. > and yum is trying > to make sure it stays installed, but is also trying to make sure only two > kmod-nvidia packages are installed, but the logic is telling it to keep > the two latest installed instead of the one matching the current-running > kernel and the latest (like it's doing with the kernel). > Wow, did that even make sense? :-) > Just a shot in the dark. (And yes, I would agree that the behavior is > non-intuitive.) I don't know if the behavior you describe is what is implemented into yum, but your explaination would explain what I observed. The problem with this behavior: Should a kernel update be malfunctioning users end up with a non-functional graphics system should they want to "switch back to the known-to-work kernel+kmods". Ralf From tibbs at math.uh.edu Sun Jul 29 04:26:18 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jul 2007 23:26:18 -0500 Subject: RPM roadmapping In-Reply-To: <1185663120.3928.87.camel@dimi.lattica.com> References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: >>>>> "DP" == Dimi Paun writes: DP> My proposal is to implement this where it belongs (in rpmbuild), I can't disagree with that. DP> and issue warnings (and ignore) any attempt to set the build root DP> or to rm -rf it from within the spec. I must disagree with that; these statements will be required for compatibility with old versions of RPM (see EPEL4) for many years to come. I don't particularly want to fork a different version of my specfiles when there's no need. - J< From pemboa at gmail.com Sun Jul 29 04:56:53 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 28 Jul 2007 23:56:53 -0500 Subject: RPM roadmapping In-Reply-To: References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: <16de708d0707282156k48c35c2fr1f81a068141fd0e@mail.gmail.com> On 28 Jul 2007 23:26:18 -0500, Jason L Tibbitts III wrote: > >>>>> "DP" == Dimi Paun writes: > > DP> My proposal is to implement this where it belongs (in rpmbuild), > > I can't disagree with that. > > DP> and issue warnings (and ignore) any attempt to set the build root > DP> or to rm -rf it from within the spec. > > I must disagree with that; these statements will be required for > compatibility with old versions of RPM (see EPEL4) for many years to > come. I don't particularly want to fork a different version of my > specfiles when there's no need. What is the difference between ignoring it and doing it by default in rpmbuild and what happens now? -- Fedora Core 6 and proud From pemboa at gmail.com Sun Jul 29 05:31:12 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 29 Jul 2007 00:31:12 -0500 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <16de708d0707282231s6fd6bb6eiccdc27cde6ae877@mail.gmail.com> * Rollback and Repair feature (in the idea of Windows Restore, assuming that works) * Easier/clear database repair * installation type status (installed as a dependency, or not) - would make streamlining an installation easier * (this one may exist in some form, i don't know) some way to tag a package as a library, headers, server, client, standalone, so I could essentially yum list servers at some point From hellwolf.misty at gmail.com Sun Jul 29 05:42:02 2007 From: hellwolf.misty at gmail.com (ZC Miao) Date: Sun, 29 Jul 2007 13:42:02 +0800 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185687722.9645.6.camel@cocteau.freehell.org> - What about sandbox support? Currently rpmbuild can destroy data outside $RPM_BUILD_ROOT, /tmp, etc. As in gentoo portage system, ebuild runs in a sandbox, which hacked the glibc open/read/write routine and makes incarefully-written-programs(not malice) unable to destroy other data. -- http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F Showing up is 80% of life. -- Woody Allen From Lam at Lam.pl Sun Jul 29 06:20:46 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 29 Jul 2007 08:20:46 +0200 Subject: RPM roadmapping In-Reply-To: <1185687722.9645.6.camel@cocteau.freehell.org> References: <1185687722.9645.6.camel@cocteau.freehell.org> Message-ID: <20070729082046.039db2b1@pensja.lam.pl> Dnia 2007-07-29, o godz. 13:42:02 ZC Miao napisa?(a): > - What about sandbox support? > > Currently rpmbuild can destroy data outside $RPM_BUILD_ROOT, /tmp, etc. That's why it's always been required to not run rpmbuild as root. We have rpmdev-setuptree exactly for making the sandbox quickly. You can't destroy other users' files in tmp/ if you're not root, you know? OTOH, making /usr/src/redhat owned by an rpmbuild user and setuid()ing to that account automatically would make things simpler for you, but do you really need it? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jul 29 06:42:37 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 29 Jul 2007 08:42:37 +0200 Subject: yum kernel/kmod update weirdness In-Reply-To: <1185653580.2409.122.camel@cutter> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> <1185620166.2409.114.camel@cutter> <1185628846.4868.1.camel@mccallum.corsepiu.local> <1185653580.2409.122.camel@cutter> Message-ID: <1185691357.14763.2.camel@mccallum.corsepiu.local> On Sat, 2007-07-28 at 16:13 -0400, seth vidal wrote: > On Sat, 2007-07-28 at 15:20 +0200, Ralf Corsepius wrote: > > On Sat, 2007-07-28 at 06:56 -0400, seth vidal wrote: > > > On Sat, 2007-07-28 at 09:03 +0200, Ralf Corsepius wrote: > > > > Hi, > > > > > > > > Does anybody have an explanation for this? > > > > > > > > > > > > # rpm -qa 'kernel' 'kmod*' > > > > kernel-2.6.22.1-27.fc7 > > > > kernel-2.6.21-1.3228.fc7 > > > > kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7 > > > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > > > > > # yum update > > > > Installing: > > > > kernel i686 2.6.22.1-33.fc7 updates 16 M > > > > kmod-nvidia i686 100.14.11-1.2.6.22.1_33.fc7 livna 2.4 M > > > > Updating: > > > > kernel-headers i386 2.6.22.1-33.fc7 updates 652 k > > > > Removing: > > > > kernel i686 2.6.22.1-27.fc7 installed 46 M > > > > kmod-nvidia i686 100.14.11-1.2.6.21_1.3228.fc7 installed 7.5 M > > > > > > > > > > > > This would cause the system to end up with this setup: > > > > kernel-2.6.22.1-33.fc7 > > > > kernel-2.6.21-1.3228.fc7 > > > > kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 > > > > kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 > > > > > > > > This doesn't seem right to me. > > > > > > do you have the yum kmod plugin installed? > > Nope, just these: > > > > # rpm -qa 'yum*' > > yum-metadata-parser-1.1.0-2.fc7 > > yum-utils-1.1.5-1.fc7 > > yum-3.2.1-1.fc7 > > > > If you install yum-kernel-module > > does it start doing the right thing? Sorry, I can't try this anymore - Meanwhile, this machine had been updated (by manually invoking rpm). I don't have the old FC7 kernel rpms around to downgrade it again for testing your proposal. Ralf From tla at rasmil.dk Sun Jul 29 06:58:54 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Sun, 29 Jul 2007 08:58:54 +0200 Subject: yum kernel/kmod update weirdness In-Reply-To: <1185653580.2409.122.camel@cutter> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> <1185620166.2409.114.camel@cutter> <1185628846.4868.1.camel@mccallum.corsepiu.local> <1185653580.2409.122.camel@cutter> Message-ID: <46AC3AAE.1030006@rasmil.dk> seth vidal wrote: > On Sat, 2007-07-28 at 15:20 +0200, Ralf Corsepius wrote: > >> On Sat, 2007-07-28 at 06:56 -0400, seth vidal wrote: >> >>> On Sat, 2007-07-28 at 09:03 +0200, Ralf Corsepius wrote: >>> >>>> Hi, >>>> >>>> Does anybody have an explanation for this? >>>> >>>> >>>> # rpm -qa 'kernel' 'kmod*' >>>> kernel-2.6.22.1-27.fc7 >>>> kernel-2.6.21-1.3228.fc7 >>>> kmod-nvidia-100.14.11-1.2.6.21_1.3228.fc7 >>>> kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 >>>> >>>> # yum update >>>> Installing: >>>> kernel i686 2.6.22.1-33.fc7 updates 16 M >>>> kmod-nvidia i686 100.14.11-1.2.6.22.1_33.fc7 livna 2.4 M >>>> Updating: >>>> kernel-headers i386 2.6.22.1-33.fc7 updates 652 k >>>> Removing: >>>> kernel i686 2.6.22.1-27.fc7 installed 46 M >>>> kmod-nvidia i686 100.14.11-1.2.6.21_1.3228.fc7 installed 7.5 M >>>> >>>> >>>> This would cause the system to end up with this setup: >>>> kernel-2.6.22.1-33.fc7 >>>> kernel-2.6.21-1.3228.fc7 >>>> kmod-nvidia-100.14.11-1.2.6.22.1_33.fc7 >>>> kmod-nvidia-100.14.11-1.2.6.22.1_27.fc7 >>>> >>>> This doesn't seem right to me. >>>> >>> do you have the yum kmod plugin installed? >>> >> Nope, just these: >> >> # rpm -qa 'yum*' >> yum-metadata-parser-1.1.0-2.fc7 >> yum-utils-1.1.5-1.fc7 >> yum-3.2.1-1.fc7 >> >> > > If you install yum-kernel-module > > does it start doing the right thing? > > -sv > > > I should be the 'yum-fedorakmod' plugin, if you want to use 'kmod' kernel modules. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Sun Jul 29 08:17:08 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sun, 29 Jul 2007 11:17:08 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: On Sun, 28 Jul 2007, Jason L Tibbitts III wrote: >>>>>> "DP" == Dimi Paun writes: > > DP> My proposal is to implement this where it belongs (in rpmbuild), > > I can't disagree with that. > > DP> and issue warnings (and ignore) any attempt to set the build root > DP> or to rm -rf it from within the spec. > > I must disagree with that; these statements will be required for > compatibility with old versions of RPM (see EPEL4) for many years to > come. I don't particularly want to fork a different version of my > specfiles when there's no need. Welcome to world of rpm: people want progress but no change. See the discussion regarding setting a sane default buildroot: https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-February/000162.html Lots of talk, no real consensus was reached because changing it one way or the other breaks compatibility for somebody. Maybe these things would need a new incompatible "spec 2" format (one that actually has defined grammar etc) that fixes various insanities in the current non-format and forces people to fork the specs for good :) - Panu - From sundaram at fedoraproject.org Sun Jul 29 09:07:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 29 Jul 2007 14:37:38 +0530 Subject: RPM roadmapping In-Reply-To: References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: <46AC58DA.1010706@fedoraproject.org> Panu Matilainen wrote: > Maybe these things would need a new incompatible "spec 2" format (one > that actually has defined grammar etc) that fixes various insanities in > the current non-format and forces people to fork the specs for good :) That would require a major new version of RPM probably parallel installable since we are going to be dealing with the current format for a long time to come anyway. Rahul From fedora at leemhuis.info Sun Jul 29 09:41:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 29 Jul 2007 11:41:24 +0200 Subject: RPM roadmapping In-Reply-To: <46AB8FDB.6040609@fedoraproject.org> References: <46AB8FDB.6040609@fedoraproject.org> Message-ID: <46AC60C4.3060002@leemhuis.info> On 28.07.2007 20:50, Rahul Sundaram wrote: > Panu Matilainen wrote: > >> I know I'm opening up Pandoras box here but what the heck, it's Friday >> and I'm feeling slightly bored... >> >> With RPM 4.4.2.1 fresh out and 4.4.x branched off to maintenance mode, >> time to start looking forward to next major release. While the focus >> will be largely in cleaning up and streamlining the codebase, it can't >> realistically be all about just that > > User (as opposed to administrator) installs in their home directories. I > could run say Mozilla Firefox extracted from a tarball but having a > similar capability in RPM itself would be nice. [...] +1 -- I think that's something that would be really nice to have. But it's likely a "to big" project/idea for now, but maybe something people could keep in mind when designing next generation's rpm, so maybe it's then possible a bit easier with a later generation of rpm. Just my 2 cent (?) CU knurd (?) -- I get yelled at by my girlfirends now and then when I install some experimental stuff for tests on the machine she uses and break her Firefox/Thunderbird/whatever accidentally without noticing... From buildsys at redhat.com Sun Jul 29 09:59:20 2007 From: buildsys at redhat.com (Build System) Date: Sun, 29 Jul 2007 05:59:20 -0400 Subject: rawhide report: 20070729 changes Message-ID: <200707290959.l6T9xKDj024188@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From denis at poolshark.org Sun Jul 29 10:43:18 2007 From: denis at poolshark.org (Denis Leroy) Date: Sun, 29 Jul 2007 12:43:18 +0200 Subject: rawhide report: 20070729 changes In-Reply-To: <200707290959.l6T9xKDj024188@porkchop.devel.redhat.com> References: <200707290959.l6T9xKDj024188@porkchop.devel.redhat.com> Message-ID: <46AC6F46.20502@poolshark.org> Build System wrote: > Updated Packages: > > (none) > Broken deps for i386 > ---------------------------------------------------------- > glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 I build a fix for this 3 days ago, why is it not showing in the rawhide report ? Does it need to be tagged for f8-test1 ? From sundaram at fedoraproject.org Sun Jul 29 10:55:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 29 Jul 2007 16:25:48 +0530 Subject: rawhide report: 20070729 changes In-Reply-To: <46AC6F46.20502@poolshark.org> References: <200707290959.l6T9xKDj024188@porkchop.devel.redhat.com> <46AC6F46.20502@poolshark.org> Message-ID: <46AC7234.80909@fedoraproject.org> Denis Leroy wrote: > Build System wrote: >> Updated Packages: >> >> (none) >> Broken deps for i386 >> ---------------------------------------------------------- >> glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 > > I build a fix for this 3 days ago, why is it not showing in the rawhide > report ? Does it need to be tagged for f8-test1 ? Yes. See the devel announce list and discussions in this list previously for details. Rahul From robert at fedoraproject.org Sun Jul 29 11:15:05 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Sun, 29 Jul 2007 13:15:05 +0200 Subject: RPM roadmapping In-Reply-To: <200707282335.14256.opensource@till.name> References: <200707282335.14256.opensource@till.name> Message-ID: <20070729111505.GA3744@hurricane.linuxnetz.de> Hello Till, On Sat, 28 Jul 2007, Till Maas wrote: > - a sane default buildroot definition > - Cleaning $RPM_BUILD_ROOT itself in %install (and without any race condition) > - A default %clean section with rm -rf $RPM_BUILD_ROOT > - %defattr(-,root,root,-) per default in %files > > This would save at least 5 lines in nearly every spec of Fedora. ever looked to /usr/lib/rpm/redhat/macros or /usr/lib/rpm/macros and asked on the lists why this is not done by obvious reasons like backward compat etc.? IIRC there already was such a discussion maybe half or a year ago... FYI: Currently you can't do a "rm -rf $RPM_BUILD_ROOT" in "%install" automagically, because it breaks rebuilding of the kernel package, looks somebody were to lazy to write something sane. I tried to enable this feature on my rpm5.org installation, but IIRC there is at least one further failure, too. Conclusion: Some Fedora Packaging Maintainers should write sane spec files first, there are other packaging issues, too (e.g. orphaned directories, dangling symlinks). Greetings, Robert From kevin.kofler at chello.at Sun Jul 29 13:24:00 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Jul 2007 13:24:00 +0000 (UTC) Subject: RPM roadmapping References: <1185687722.9645.6.camel@cocteau.freehell.org> Message-ID: ZC Miao gmail.com> writes: > - What about sandbox support? That's what mock is for. Of course, the gain in security from any such sandboxing is relative, because the installation has to be as root anyway, so someone could just trojan the actual programs and/or the post/postun scriptlets instead. Kevin Kofler From markg85 at gmail.com Sun Jul 29 15:01:36 2007 From: markg85 at gmail.com (Mark) Date: Sun, 29 Jul 2007 17:01:36 +0200 Subject: KDE 4 Beta 1 In-Reply-To: <200707281158.42981.jospoortvliet@kde.nl> References: <200707281158.42981.jospoortvliet@kde.nl> Message-ID: <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! btw.. you will have to make them because KDE 4 is planned for Fedora 8 2007/7/28, jos poortvliet : > Dear people, > > The KDE project is about to release it's first beta for KDE 4. The package > tarballs are available, to allow distributions to package it. We would like > to know if your distribution will have packages available at or soon after > the official release date, so we can mention it in the announcement. > > If so, please provide us with a link or location where to find those packages. > If you won't have packages right away, you can tell us when they will be > available, so we can mention that. > > Thank you for your co?peration, > > > The KDE promo team > kde-promo at kde.org > > -- > Jos Poortvliet > KDE-nl > http://www.kde.nl > http://www.kde.org > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > A: Because it destroys the flow of the conversation > Q: Why is top-posting bad? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From sundaram at fedoraproject.org Sun Jul 29 15:07:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 29 Jul 2007 20:37:11 +0530 Subject: KDE 4 Beta 1 In-Reply-To: <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: <46ACAD1F.6090708@fedoraproject.org> Mark wrote: > Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! > btw.. you will have to make them because KDE 4 is planned for Fedora 8 > Stop top posting. The feature plan is described in http://fedoraproject.org/wiki/Releases/FeatureKDE4. The release of KDE 4 in Fedora 8 is dependent on how strict the KDE 4 schedule is. Rahul From snecklifter at gmail.com Sun Jul 29 15:14:42 2007 From: snecklifter at gmail.com (Chris Brown) Date: Sun, 29 Jul 2007 16:14:42 +0100 Subject: KDE 4 Beta 1 In-Reply-To: <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: <364d303b0707290814if5ed3d5u1108c32dee1da94f@mail.gmail.com> Hello Mark, On 29/07/07, Mark wrote: > Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! > btw.. you will have to make them because KDE 4 is planned for Fedora 8 I maintain only one fedora package and have found that a steep learning curve - this is an entire desktop environment. so "have to" is an interesting phrase. This depends on a variety of factors, not least that there is no further slippage in the release schedule. KDE 4 will get into Fedora, no question, but hasty malformed packages for 8 are, IMHO, counter-productive to such an important release and if it is delayed until 9 please be assured that is in the best interests of both the KDE and Fedora projects. Cheers Chris -- http://www.chruz.com From SteveD at redhat.com Sun Jul 29 15:14:17 2007 From: SteveD at redhat.com (Steve Dickson) Date: Sun, 29 Jul 2007 11:14:17 -0400 Subject: check-buildroot failure Message-ID: <46ACAEC9.7050309@RedHat.com> I'm getting the following build error: /usr/lib/rpm/check-buildroot /var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc:prefix=/var/tmp/libgssapi-0.11-root Found '/var/tmp/libgssapi-0.11-root' in installed files; aborting error: Bad exit status from /var/tmp/rpm-tmp.75914 (%install) I've search this list and others, found nothing... In http://fedoraproject.org/wiki/Packaging/Guidelines I did find a section about removing rpaths... even thought the error on the wiki page is different than the one I'm getting I figured I would try... I've tried both suggested ways of removing rpaths with no success. So what exactly do I need to do to get pass this failure? imho... this error message "in installed files; aborting" is completely unacceptable because its meaningless. I'll be opening a bz on this script, but people who author these type of scripts, *PLEASE* be as explicit as possible as to exactly what the problem is. People who have a clue only needed clue to fix the problem... Error messages like leave people who have a clue... clueless... steved. From markg85 at gmail.com Sun Jul 29 14:53:04 2007 From: markg85 at gmail.com (Mark) Date: Sun, 29 Jul 2007 16:53:04 +0200 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: References: <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> Message-ID: <6e24a8e80707290753l20d74e44j4039e4f271216541@mail.gmail.com> perhaps it's better to adjust the KDE menu package (whichever one that might be) and edit it so that it ignores the ShowOnlyIn directive. Than it will display all menu items where they are supposed to be. 2007/7/27, Christopher Stone : > On 7/26/07, Bill Crawford wrote: > > I found the package "kmenu-gnome" lurking in the package manager, ... seems > > to work, although it only shows two items (grip and "Configuration Editor" > > :)) Thanks for the pointer. > > Ah, okay, well I'm confused. I thought gnome-menus added gnome items > to the KDE menu, but I guess it is actually kmenu-gnome. I filed a > bug against kmenu-gnome: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249902 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at camperquake.de Sun Jul 29 14:46:34 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 29 Jul 2007 16:46:34 +0200 Subject: RPM roadmapping In-Reply-To: <46AAA084.7080602@nobugconsulting.ro> References: <1185579233.6017.11.camel@scrappy.miketc.com> <16de708d0707271841y2f106fd7o2b857b71e4daf51e@mail.gmail.com> <46AAA084.7080602@nobugconsulting.ro> Message-ID: <20070729164634.3db07b41@lain.camperquake.de> Hi. On Sat, 28 Jul 2007 04:48:52 +0300, Manuel Wolfshant wrote > A --repackage option exists for a very log time. Life saver, > sometimes... Something I needed some days ago was --repackage without -e. From Lam at Lam.pl Sun Jul 29 15:37:17 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 29 Jul 2007 17:37:17 +0200 Subject: =?utf-8?b?V1RG4oGI?= ShowOnlyIn=GNOME In-Reply-To: <6e24a8e80707290753l20d74e44j4039e4f271216541@mail.gmail.com> References: <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> <6e24a8e80707290753l20d74e44j4039e4f271216541@mail.gmail.com> Message-ID: <20070729173717.0dff00b9@pensja.lam.pl> Dnia 2007-07-29, o godz. 16:53:04 Mark napisa?(a): > perhaps it's better to adjust the KDE menu package (whichever one that > might be) and edit it so that it ignores the ShowOnlyIn directive. > Than it will display all menu items where they are supposed to be. Perhaps you need to propose that option (but as an option) upstream. It's a good idea, let them help their users. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bbbush.yuan at gmail.com Sun Jul 29 13:52:18 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sun, 29 Jul 2007 21:52:18 +0800 Subject: rawhide report: 20070729 changes In-Reply-To: <46AC7234.80909@fedoraproject.org> References: <200707290959.l6T9xKDj024188@porkchop.devel.redhat.com> <46AC6F46.20502@poolshark.org> <46AC7234.80909@fedoraproject.org> Message-ID: <1185717138.4375.2.camel@localhost.localdomain> ? 2007-07-29?? 16:25 +0530?Rahul Sundaram??? > Denis Leroy wrote: > > > > I build a fix for this 3 days ago, why is it not showing in the rawhide > > report ? Does it need to be tagged for f8-test1 ? > > Yes. See the devel announce list and discussions in this list previously > for details. What do you mean by "tagged for f8-test1", wouldn't tag & build in the devel branch solve this? Please be specific, thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: ??????????? URL: From tcallawa at redhat.com Sun Jul 29 16:44:04 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 29 Jul 2007 11:44:04 -0500 Subject: check-buildroot failure In-Reply-To: <46ACAEC9.7050309@RedHat.com> References: <46ACAEC9.7050309@RedHat.com> Message-ID: <1185727444.3765.195.camel@dhcp83-168.boston.redhat.com> On Sun, 2007-07-29 at 11:14 -0400, Steve Dickson wrote: > I'm getting the following build error: > > /usr/lib/rpm/check-buildroot > /var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc:prefix=/var/tmp/libgssapi-0.11-root > Found '/var/tmp/libgssapi-0.11-root' in installed files; aborting > error: Bad exit status from /var/tmp/rpm-tmp.75914 (%install) Steve, Look closely at what you've pasted: The file (/var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc) contains the rpm buildroot inside of it. The script printed the line where the buildroot appears: prefix=/var/tmp/libgssapi-0.11-root Since this is not what you want the prefix to be for the installed package, you need to fixup that .pc file in the %install section of your spec. sed -i "s|${RPM_BUILD_ROOT}||g" $RPM_BUILD_ROOT %{_libdir}/pkgconfig/libgssapi.pc That line should do the trick. ~spot From mschwendt.tmp0701.nospam at arcor.de Sun Jul 29 15:48:19 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 29 Jul 2007 17:48:19 +0200 Subject: check-buildroot failure In-Reply-To: <46ACAEC9.7050309@RedHat.com> References: <46ACAEC9.7050309@RedHat.com> Message-ID: <20070729174819.13a5867e.mschwendt.tmp0701.nospam@arcor.de> On Sun, 29 Jul 2007 11:14:17 -0400, Steve Dickson wrote: > I'm getting the following build error: > > /usr/lib/rpm/check-buildroot > /var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc:prefix=/var/tmp/libgssapi-0.11-root > Found '/var/tmp/libgssapi-0.11-root' in installed files; aborting > error: Bad exit status from /var/tmp/rpm-tmp.75914 (%install) > > I've search this list and others, found nothing... In > http://fedoraproject.org/wiki/Packaging/Guidelines I did find > a section about removing rpaths... even thought the error on the > wiki page is different than the one I'm getting I figured I would > try... I've tried both suggested ways of removing rpaths > with no success. > > So what exactly do I need to do to get pass this failure? > > > imho... this error message "in installed files; aborting" > is completely unacceptable because its meaningless. Hmm? Doesn't it just mean that /var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc in your %buildroot contains prefix=/var/tmp/libgssapi-0.11-root ? > I'll be opening a bz on this script, but people who author > these type of scripts, *PLEASE* be as explicit as possible > as to exactly what the problem is. People who have a > clue only needed clue to fix the problem... Error > messages like leave people who have a clue... clueless... > > > steved. > > From gilboad at gmail.com Sun Jul 29 15:53:51 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 29 Jul 2007 18:53:51 +0300 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185724431.359.13.camel@gilboa-work-dev.localdomain> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > * Unix philosophy - do just one thing and do it well: > - RPM is not a GPG key manager but a package manager. > - RPM is not an ftp/http client, it's a package manager. > ... While I agree with the general UNIX philosophy, RPM's HTTP/FTP support is very useful. How about creating an external plug-in interface that will handle non-standard file URLs instead of doing it in the main code? - Gilboa From gilboad at gmail.com Sun Jul 29 15:48:31 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 29 Jul 2007 18:48:31 +0300 Subject: RPM roadmapping In-Reply-To: References: <1185542632.3650.11.camel@localhost.localdomain> <20070727143103.GB27466@nostromo.devel.redhat.com> <20070727143238.GC27466@nostromo.devel.redhat.com> Message-ID: <1185724111.359.8.camel@gilboa-work-dev.localdomain> On Sat, 2007-07-28 at 22:04 +0300, Panu Matilainen wrote: > On Fri, 27 Jul 2007, Bill Nottingham wrote: > > > Bill Nottingham (notting at redhat.com) said: > >>> %posttrans works now afaik. Is there something you want that isn't there > >>> now? > >> > >> Ideally, merging of identical %posttrans. > > > > ... and, running on uninstall as well. > > Rather than trying to figure identical %posttrans between packages, I'd > like to see a mechanism to allow packages flagging things like "after > install/removal I need a) ldconfig run b) icon cache updated" and > have them run centrally after everything else has completed (lets call it > "%sysposttrans" that gets run after any non-empty transaction has fully > completed). Basically what was discussed in this thread: > https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00061.html > > I remember when some years ago something like > > [ -x /usr/bin/update-foo ] && /usr/bin/update-foo > > was copy-pasted into dozens of packages, only there was a typo that caused > every such scriptlet breaking and needed another mass rebuild to fix. If > it had been just a flag to do "update-foo" then the actual update-foo > script could've been fixed just once instead of having to copy-paste it > into every bleeping package and ran several times during a transaction. > Obviously packages have their special needs and not everything can be > generalized, but there are plenty enough things where this would be > applicaple. > > - Panu - > /+1. icon cache, ldconfig, depmod, etc are common things. No need to copy-paste the same code over and over and over.... and over again. - Gilboa From jaroslav at aster.pl Sun Jul 29 13:47:10 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Sun, 29 Jul 2007 15:47:10 +0200 Subject: F7: KDE issues Message-ID: <200707291547.18788.jaroslav@aster.pl> Hi, since couple of days I'm experiencing some bugs: 1. (250009) kmail indicates old mail as unread [1] 2. (215091) kmail occasionally stops receiving mail [2] 3. (similar to 218001) http_cache_cleaner appears in task bar [3] AD1 is reported by me AD3 this is not exactly this issue, because: a) I'm running KDE, not Gnome, b) http_cache_cleaner.desktop has "X-KDE-StartupNotify=false" Anyway, result is similar - http_cache_cleaner processes are visible in task bar (1 - 4 processes), cursor changes to 'busy' Is anybody else experiencing some/all of this??? This box runs Fedora since April '06 (upgrades: FC5 -> FC6 -> F7). I had no issues with KDE until now ;) Any help appreciated, thanks, [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250009 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215091 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218001 -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From markg85 at gmail.com Sun Jul 29 16:07:57 2007 From: markg85 at gmail.com (Mark) Date: Sun, 29 Jul 2007 18:07:57 +0200 Subject: KDE 4 Beta 1 In-Reply-To: <364d303b0707290814if5ed3d5u1108c32dee1da94f@mail.gmail.com> References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> <364d303b0707290814if5ed3d5u1108c32dee1da94f@mail.gmail.com> Message-ID: <6e24a8e80707290907w2a36b7e2ue3cb7a08a1d08718@mail.gmail.com> 2007/7/29, Chris Brown : > Hello Mark, > Hey > I maintain only one fedora package and have found that a steep > learning curve - this is an entire desktop environment. so "have to" > is an interesting phrase. This depends on a variety of factors, not > least that there is no further slippage in the release schedule. KDE 4 > will get into Fedora, no question, but hasty malformed packages for 8 > are, IMHO, counter-productive to such an important release and if it > is delayed until 9 please be assured that is in the best interests of > both the KDE and Fedora projects. > > Cheers > Chris Well the first upcoming release for Fedora 8 is Test 1. it's not a test to be as stable as possible (would be good but not expected). unstable packages are allowed in test 1 because it's a test release. and you will get alot more feedback about kde 4 if you can get them in fedora 8 asap (so in test 1). but i might be just a little to happy about it because i would like to test out KDE 4 in fedora ^_^ From kevin.kofler at chello.at Sun Jul 29 15:07:53 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Jul 2007 15:07:53 +0000 (UTC) Subject: KDE 4 Beta 1 References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: Mark gmail.com> writes: > Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! Hey, we're working on it! Give us some time, the beta isn't even officially out yet! > btw.. you will have to make them because KDE 4 is planned for Fedora 8 This plan is subject to change, by the way. Given the current state of KDE 4.0, we have some reservations about whether it will be ready for being the default KDE in Fedora 8. Kevin Kofler From SteveD at redhat.com Sun Jul 29 16:09:02 2007 From: SteveD at redhat.com (Steve Dickson) Date: Sun, 29 Jul 2007 12:09:02 -0400 Subject: check-buildroot failure In-Reply-To: <1185727444.3765.195.camel@dhcp83-168.boston.redhat.com> References: <46ACAEC9.7050309@RedHat.com> <1185727444.3765.195.camel@dhcp83-168.boston.redhat.com> Message-ID: <46ACBB9E.50406@RedHat.com> Tom "spot" Callaway wrote: > On Sun, 2007-07-29 at 11:14 -0400, Steve Dickson wrote: >> I'm getting the following build error: >> >> /usr/lib/rpm/check-buildroot >> /var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc:prefix=/var/tmp/libgssapi-0.11-root >> Found '/var/tmp/libgssapi-0.11-root' in installed files; aborting >> error: Bad exit status from /var/tmp/rpm-tmp.75914 (%install) > > Steve, > > Look closely at what you've pasted: > > The file (/var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc) > contains the rpm buildroot inside of it. > > The script printed the line where the buildroot appears: > > prefix=/var/tmp/libgssapi-0.11-root Thanks for the context... because now it makes sense... The problem was I was trying to decipher the 'Found '/var/tmp/libgssapi-0.11-root' in installed files; aborting' line because I thought that was the error... Would it be much clear if the error message was something like: /usr/lib/rpm/check-buildroot Failed do the follow problem(s): Bad prefix setting /var/tmp/libgssapi-0.11-root/usr/lib64/pkgconfig/libgssapi.pc:prefix=/var/tmp/libgssapi-0.11-root At least that would draw my attention to correct line of output.... steved. From opensource at till.name Sun Jul 29 16:13:32 2007 From: opensource at till.name (Till Maas) Date: Sun, 29 Jul 2007 18:13:32 +0200 Subject: RPM roadmapping In-Reply-To: <20070729111505.GA3744@hurricane.linuxnetz.de> References: <200707282335.14256.opensource@till.name> <20070729111505.GA3744@hurricane.linuxnetz.de> Message-ID: <200707291813.40418.opensource@till.name> On Sunday 29 July 2007 13:15:05 Robert Scheck wrote: > ever looked to /usr/lib/rpm/redhat/macros or /usr/lib/rpm/macros and asked > on the lists why this is not done by obvious reasons like backward compat > etc.? IIRC there already was such a discussion maybe half or a year ago... Iirc the problem for too many people with fixing/changing this only in fedora was, that they could not use the spec for other rpm based distributions without using the fedora macros. But when rpm itself gets fixed, there is no need fo these fedora macros. I hope I understood you correctly here, otherwise please explain what you meant. > FYI: Currently you can't do a "rm -rf $RPM_BUILD_ROOT" in "%install" > automagically, because it breaks rebuilding of the kernel package, looks > somebody were to lazy to write something sane. I tried to enable this > feature on my rpm5.org installation, but IIRC there is at least one further > failure, too. I hope the kernel.spec can be fixed to work with this rm invocation, but in case this is not the case, then %install could be defined in such a way that %install --no-clean-buildroot would not clean the buildroot in %install. > Conclusion: Some Fedora Packaging Maintainers should write sane spec files > first, there are other packaging issues, too (e.g. orphaned directories, > dangling symlinks). Is there any technical reason why a package system cannot determine the ownership of directories by itself? Imho a package management system should make it as easy as possible to create a package, i.e. do as much as possible by itself. But what does this have to do with my improvement suggestions? And what insane spec files produce dangling symlinks? Is there a common mistake that creates them? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Sun Jul 29 16:18:16 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 29 Jul 2007 16:18:16 +0000 (UTC) Subject: KDE 4 Beta 1 References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> <364d303b0707290814if5ed3d5u1108c32dee1da94f@mail.gmail.com> <6e24a8e80707290907w2a36b7e2ue3cb7a08a1d08718@mail.gmail.com> Message-ID: Mark gmail.com> writes: > Well the first upcoming release for Fedora 8 is Test 1. it's not a > test to be as stable as possible (would be good but not expected). > unstable packages are allowed in test 1 because it's a test release. > and you will get alot more feedback about kde 4 if you can get them in > fedora 8 asap (so in test 1). but i might be just a little to happy > about it because i would like to test out KDE 4 in fedora ^_^ Sorry, but test1 is already frozen, there's no way KDE 4 is going into it. Kevin Kofler From gilboad at gmail.com Sun Jul 29 16:20:18 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 29 Jul 2007 19:20:18 +0300 Subject: KDE 4 Beta 1 In-Reply-To: References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: <1185726018.359.18.camel@gilboa-work-dev.localdomain> On Sun, 2007-07-29 at 15:07 +0000, Kevin Kofler wrote: > Mark gmail.com> writes: > > Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! > > Hey, we're working on it! Give us some time, the beta isn't even officially out > yet! > > > btw.. you will have to make them because KDE 4 is planned for Fedora 8 > > This plan is subject to change, by the way. Given the current state of KDE 4.0, > we have some reservations about whether it will be ready for being the default > KDE in Fedora 8. > > Kevin Kofler > IMHO, KDE4B2 is released 3 days before F8 feature freeze. As much as I would like to see KDE4 on F8, unless Beta 2 is feature complete (especially Plasma) with little, if no rawhide testing is very risky. Will KDE4 be parallel installable? - Gilboa From markg85 at gmail.com Sun Jul 29 16:36:07 2007 From: markg85 at gmail.com (Mark) Date: Sun, 29 Jul 2007 18:36:07 +0200 Subject: =?utf-8?b?UmU6IFdURuKBiCBTaG93T25seUluPUdOT01F?= In-Reply-To: <20070729173717.0dff00b9@pensja.lam.pl> References: <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> <6e24a8e80707290753l20d74e44j4039e4f271216541@mail.gmail.com> <20070729173717.0dff00b9@pensja.lam.pl> Message-ID: <6e24a8e80707290936n2d918d45o38cc598b0ae4fd0c@mail.gmail.com> 2007/7/29, Leszek Matok : > Dnia 2007-07-29, o godz. 16:53:04 Mark napisa?(a): > > Perhaps you need to propose that option (but as an option) upstream. It's a > good idea, let them help their users. Done: http://bugs.kde.org/show_bug.cgi?id=148335 or a fedora only patch if they don't want to accept it for upstream? the issue is that the kmenu applet doesn't seem to have a configuration place where that option can be made optional. perhaps it has a text file configuration somewhere? From tibbs at math.uh.edu Sun Jul 29 16:56:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Jul 2007 11:56:50 -0500 Subject: RPM roadmapping In-Reply-To: References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: >>>>> "PM" == Panu Matilainen writes: PM> Welcome to world of rpm: people want progress but no change. I don't think that's productive. All I said was "do it but don't warn about it by default". - J< From dimi at lattica.com Sun Jul 29 17:18:28 2007 From: dimi at lattica.com (Dimi Paun) Date: Sun, 29 Jul 2007 13:18:28 -0400 Subject: RPM roadmapping In-Reply-To: References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: <1185729508.3928.97.camel@dimi.lattica.com> On Sun, 2007-07-29 at 11:56 -0500, Jason L Tibbitts III wrote: > I don't think that's productive. All I said was "do it but don't warn > about it by default". True, but that's a minor point anyway. We could enable the warning only with a flag (-Wall or somesuch). Automatic handling of buildroot in rpmbuild is an obvious fix. We can certainly do something about these small concerns. -- Dimi Paun Lattica, Inc. From markg85 at gmail.com Sun Jul 29 18:01:40 2007 From: markg85 at gmail.com (Mark) Date: Sun, 29 Jul 2007 20:01:40 +0200 Subject: F7: KDE issues In-Reply-To: <200707291547.18788.jaroslav@aster.pl> References: <200707291547.18788.jaroslav@aster.pl> Message-ID: <6e24a8e80707291101p29883b2fh2c445938bac62f2@mail.gmail.com> i'm running Fedora 7 with KDE since it's released and i didn't experience any of those bugs. though only the third one could be relevant for me because i'm not using kmail. 2007/7/29, Jaroslaw Gorny : > Hi, > since couple of days I'm experiencing some bugs: > > 1. (250009) kmail indicates old mail as unread [1] > 2. (215091) kmail occasionally stops receiving mail [2] > 3. (similar to 218001) http_cache_cleaner appears in task bar [3] > > AD1 is reported by me > > AD3 this is not exactly this issue, because: > a) I'm running KDE, not Gnome, > b) http_cache_cleaner.desktop has "X-KDE-StartupNotify=false" > Anyway, result is similar - http_cache_cleaner processes are visible in task > bar (1 - 4 processes), cursor changes to 'busy' > > > Is anybody else experiencing some/all of this??? This box runs Fedora since > April '06 (upgrades: FC5 -> FC6 -> F7). I had no issues with KDE until now ;) > > Any help appreciated, > > thanks, > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250009 > [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215091 > [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218001 > > > -- > Jaroslaw Gorny > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From rdieter at math.unl.edu Sun Jul 29 18:41:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 29 Jul 2007 13:41:55 -0500 Subject: KDE 4 Beta 1 References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: Kevin Kofler wrote: > Mark gmail.com> writes: >> Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! > > Hey, we're working on it! Give us some time, the beta isn't even > officially out yet! If you're impatient with the progress being made, you're certainly welcome to help join the effort, http://fedoraproject.org/wiki/SIGs/KDE :) -- Rex From lists at sapience.com Sun Jul 29 18:42:20 2007 From: lists at sapience.com (Mail List) Date: Sun, 29 Jul 2007 14:42:20 -0400 Subject: F7: KDE issues In-Reply-To: <200707291547.18788.jaroslav@aster.pl> References: <200707291547.18788.jaroslav@aster.pl> Message-ID: <200707291442.20919.lists@sapience.com> On Sunday 29 July 2007 09:47:10 am Jaroslaw Gorny wrote: > Hi, > since couple of days I'm experiencing some bugs: > > 1. (250009) kmail indicates old mail as unread [1] > 2. (215091) kmail occasionally stops receiving mail [2] After one of the updates - my kmail no longer updates from exchange via imap - and also does not apply filters - lack of update may be dominating. This is not oaccasional it no now longer works at all. Thunderbird works fine. Non-exchange Imap seems to be ok however. may or may not be related. pop - i have an account set to not update. Clicking on the inbox does not update the mail either - i have to press File->check mail in->xxx. Not sure when this happened but somewhat recently. Is this same for you? From debarshi.ray at gmail.com Sun Jul 29 18:51:59 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 30 Jul 2007 00:21:59 +0530 Subject: Updating microcode_ctl Message-ID: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> $ sudo yum -y --enablerepo=development update microcode_ctl system-config* leads to: Downloading Packages: (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:03 http://ftp.crc.dk/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:02 http://ftp.ps.pl/pub/Linux/fedora-linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:02 http://mirror.pacific.net.au/linux/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:03 http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download I am using yum-3.2.2-2.fc8. Any idea what is happening? Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jaroslav at aster.pl Sun Jul 29 19:02:20 2007 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Sun, 29 Jul 2007 21:02:20 +0200 Subject: F7: KDE issues In-Reply-To: <200707291442.20919.lists@sapience.com> References: <200707291547.18788.jaroslav@aster.pl> <200707291442.20919.lists@sapience.com> Message-ID: <200707292102.29475.jaroslav@aster.pl> Sunday 29 of July 2007 20:42:20 Mail List napisa?(a): > On Sunday 29 July 2007 09:47:10 am Jaroslaw Gorny wrote: > > Hi, > > since couple of days I'm experiencing some bugs: > > > > 1. (250009) kmail indicates old mail as unread [1] > > 2. (215091) kmail occasionally stops receiving mail [2] > > After one of the updates - my kmail no longer updates from exchange via > imap - and also does not apply filters - lack of update may be dominating. > This is not oaccasional it no now longer works at all. Thunderbird works > fine. > > Non-exchange Imap seems to be ok however. > I don't use imap nor exchange, so can't help here. > pop - i have an account set to not update. Clicking on the inbox does > not update the mail either - i have to press File->check mail in->xxx. Not > sure when this happened but somewhat recently. > > Is this same for you? Some sort of. I've got a problem with fetching mail from all servers. No matter if I use "[ctrl]+[L]" shortcut, or a button in kmail's toolbar, or "File -> Check Mail" - this action fails in random cases. I have to manually choose servers, one by one... just like You said. But bug number 1 (250009) is independent from this. -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From SteveD at redhat.com Sun Jul 29 19:25:13 2007 From: SteveD at redhat.com (Steve Dickson) Date: Sun, 29 Jul 2007 15:25:13 -0400 Subject: check-buildroot failure In-Reply-To: <1185727444.3765.195.camel@dhcp83-168.boston.redhat.com> References: <46ACAEC9.7050309@RedHat.com> <1185727444.3765.195.camel@dhcp83-168.boston.redhat.com> Message-ID: <46ACE999.7020709@RedHat.com> Tom "spot" Callaway wrote: > Since this is not what you want the prefix to be for the installed > package, you need to fixup that .pc file in the %install section of your > spec. > > sed -i "s|${RPM_BUILD_ROOT}||g" $RPM_BUILD_ROOT > %{_libdir}/pkgconfig/libgssapi.pc > > That line should do the trick. This did do the trick... thanks you, very much! steved. From pemboa at gmail.com Sun Jul 29 19:38:00 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 29 Jul 2007 14:38:00 -0500 Subject: KDE 4 Beta 1 In-Reply-To: References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: <16de708d0707291238x7947ef0csc4abb5c644488c9d@mail.gmail.com> On 7/29/07, Rex Dieter wrote: > Kevin Kofler wrote: > > > Mark gmail.com> writes: > >> Come on Fedora Packagers.. make those KDE 4 beta 1 rpm's!! > > > > Hey, we're working on it! Give us some time, the beta isn't even > > officially out yet! > > If you're impatient with the progress being made, you're certainly welcome > to help join the effort, > http://fedoraproject.org/wiki/SIGs/KDE > :) > > -- Rex Rex, Could you give us a realistic report of KDE4 in Fedora so we don't go getting our hopes up? I saw your report at Akademy, and I've been hopeful ever since, but I realize that this is no trivial thing. BTW, if KDE4 turns out to be not parallel insalltable, it might be helpful to release a qemu image to facilitate testing. -- Fedora Core 6 and proud From pemboa at gmail.com Sun Jul 29 19:42:40 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 29 Jul 2007 14:42:40 -0500 Subject: RPM roadmapping In-Reply-To: <1185724431.359.13.camel@gilboa-work-dev.localdomain> References: <1185724431.359.13.camel@gilboa-work-dev.localdomain> Message-ID: <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> On 7/29/07, Gilboa Davara wrote: > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > > * Unix philosophy - do just one thing and do it well: > > - RPM is not a GPG key manager but a package manager. > > - RPM is not an ftp/http client, it's a package manager. > > > > ... While I agree with the general UNIX philosophy, RPM's HTTP/FTP > support is very useful. > How about creating an external plug-in interface that will handle > non-standard file URLs instead of doing it in the main code? > > - Gilboa Seems to me, removal of the code doesn't necessarily mean removal of the feature. Future RPM might just depend on wget. -- Fedora Core 6 and proud From vpivaini at cs.helsinki.fi Sun Jul 29 20:00:16 2007 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Sun, 29 Jul 2007 23:00:16 +0300 Subject: F7: KDE issues In-Reply-To: <200707291547.18788.jaroslav@aster.pl> References: <200707291547.18788.jaroslav@aster.pl> Message-ID: <200707292300.23264.vpivaini@cs.helsinki.fi> Jaroslaw Gorny kirjoitti viestiss??n (l?hetysaika sunnuntai, 29. hein?kuu 2007 16:47:10): > since couple of days I'm experiencing some bugs: > > 1. (250009) kmail indicates old mail as unread [1] > 2. (215091) kmail occasionally stops receiving mail [2] Hi, Since we're talking about KMail, I'd like to mention the "imap copy moves files instead of copying" bug, see https://bugs.kde.org/show_bug.cgi?id=144960 I commented on that when I still had FC6 with kde-redhat, now I'm on F7 with the standard Fedora packages and the bug still exists. Of course these are upstream bugs and should be handled there... -- Ville-Pekka Vainio vpivaini at cs.helsinki.fi -------------- next part -------------- A non-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 Sun Jul 29 20:09:01 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 29 Jul 2007 22:09:01 +0200 Subject: rawhide report: 20070729 changes In-Reply-To: <1185717138.4375.2.camel@localhost.localdomain> References: <200707290959.l6T9xKDj024188@porkchop.devel.redhat.com> <46AC6F46.20502@poolshark.org> <46AC7234.80909@fedoraproject.org> <1185717138.4375.2.camel@localhost.localdomain> Message-ID: On 7/29/07, Yuan Yijun wrote: > > What do you mean by "tagged for f8-test1", wouldn't tag & build in the > devel branch solve this? Please be specific, thanks! Jesse Keating wrote few days ago: We have frozen for Fedora 8 Test 1. A "freeze" tag exists, 'f8-test1' that is a container for the packages that are destined to be in Test1 (and rawhide until test1 is fully composed and released to mirrors). As per http://fedoraproject.org/wiki/ReleaseEngineering/Overview , builds from devel/ will continue to be tagged with 'dist-f8' and will be picked up by rawhide composes once the freeze is over. If you feel you must have your build in Test1 and it isn't already tagged with 'f8-test1', please follow http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy HTH Gianluca From mschwendt.tmp0701.nospam at arcor.de Sun Jul 29 21:53:52 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 29 Jul 2007 23:53:52 +0200 Subject: check-buildroot failure In-Reply-To: <46ACE999.7020709@RedHat.com> References: <46ACAEC9.7050309@RedHat.com> <1185727444.3765.195.camel@dhcp83-168.boston.redhat.com> <46ACE999.7020709@RedHat.com> Message-ID: <20070729235352.e106fcea.mschwendt.tmp0701.nospam@arcor.de> On Sun, 29 Jul 2007 15:25:13 -0400, Steve Dickson wrote: > Tom "spot" Callaway wrote: > > Since this is not what you want the prefix to be for the installed > > package, you need to fixup that .pc file in the %install section of your > > spec. > > > > sed -i "s|${RPM_BUILD_ROOT}||g" $RPM_BUILD_ROOT > > %{_libdir}/pkgconfig/libgssapi.pc > > > > That line should do the trick. > This did do the trick... thanks you, very much! > > steved. > %configure --prefix=%{buildroot} is the culprit, however, and something that would not pass an average review. From mschwendt.tmp0701.nospam at arcor.de Sun Jul 29 21:56:34 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 29 Jul 2007 23:56:34 +0200 Subject: Updating microcode_ctl In-Reply-To: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> References: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> Message-ID: <20070729235634.f9d6a1ec.mschwendt.tmp0701.nospam@arcor.de> On Mon, 30 Jul 2007 00:21:59 +0530, Debarshi 'Rishi' Ray wrote: > $ sudo yum -y --enablerepo=development update microcode_ctl > system-config* leads to: > > Downloading Packages: > (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:03 > http://ftp.crc.dk/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:02 > http://ftp.ps.pl/pub/Linux/fedora-linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:02 > http://mirror.pacific.net.au/linux/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:03 > http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > > I am using yum-3.2.2-2.fc8. Any idea what is happening? Remove microcode_ctl-1.17-1.38.fc8.i386.rpm from your /var/cache/yum/development/packages directory and try again. From markg85 at gmail.com Sun Jul 29 22:05:35 2007 From: markg85 at gmail.com (Mark) Date: Mon, 30 Jul 2007 00:05:35 +0200 Subject: KDE 4 Beta 1 In-Reply-To: References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> Message-ID: <6e24a8e80707291505y15e4354ay4c6716737156a0e3@mail.gmail.com> 2007/7/29, Rex Dieter : > Kevin Kofler wrote: > > If you're impatient with the progress being made, you're certainly welcome > to help join the effort, > http://fedoraproject.org/wiki/SIGs/KDE well.. i would like to help but at this time i'm probably not much of a good helping hand with making rpm's. i still need to learn alot about that. From jkeating at redhat.com Sun Jul 29 22:10:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 29 Jul 2007 18:10:10 -0400 Subject: RPM roadmapping In-Reply-To: <200707291813.40418.opensource@till.name> References: <200707282335.14256.opensource@till.name> <20070729111505.GA3744@hurricane.linuxnetz.de> <200707291813.40418.opensource@till.name> Message-ID: <20070729181010.569d3a49@ender> On Sun, 29 Jul 2007 18:13:32 +0200 Till Maas wrote: > And what insane spec files produce dangling symlinks? A large amount of -devel packages have .so symlinks that are dangling within the -devel package itself. However rpm is smart enough to figure out where that link is pointing to and add a hard requires to that file. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sun Jul 29 23:04:54 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 29 Jul 2007 18:04:54 -0500 Subject: KDE 4 Beta 1 References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> <16de708d0707291238x7947ef0csc4abb5c644488c9d@mail.gmail.com> Message-ID: Arthur Pemberton wrote: >> If you're impatient with the progress being made, you're certainly >> welcome to help join the effort, >> http://fedoraproject.org/wiki/SIGs/KDE >> :) > Could you give us a realistic report of KDE4 in Fedora so we don't go > getting our hopes up? I saw your report at Akademy, and I've been > hopeful ever since, but I realize that this is no trivial thing. KDE4 in some shape and form, will undoubtedly be included in F8. Now, whether the kde4 *desktop* makes it... odds are running about 50/50 atm, depending on release schedule and it's quality/regressions, etc... > BTW, if KDE4 turns out to be not parallel insalltable, it might be > helpful to release a qemu image to facilitate testing. It's not directly parallel installable at the moment. Someone interested in helping make such a thing for qemu would be greatly appreciated. :) -- Rex From rdieter at math.unl.edu Sun Jul 29 23:23:55 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 29 Jul 2007 18:23:55 -0500 Subject: KDE 4 Beta 1 References: <200707281158.42981.jospoortvliet@kde.nl> <6e24a8e80707290801q13596e06p9363dec51f5f4752@mail.gmail.com> <6e24a8e80707291505y15e4354ay4c6716737156a0e3@mail.gmail.com> Message-ID: Mark wrote: > 2007/7/29, Rex Dieter : >> Kevin Kofler wrote: >> >> If you're impatient with the progress being made, you're certainly >> welcome to help join the effort, >> http://fedoraproject.org/wiki/SIGs/KDE > > well.. i would like to help but at this time i'm probably not much of > a good helping hand with making rpm's. There's a lot more to this effort than packaging. Testing, Documenting (release notes type stuff, keeping wiki up2date), bug triaging. -- Rex From jima at beer.tclug.org Sun Jul 29 23:26:41 2007 From: jima at beer.tclug.org (Jima) Date: Sun, 29 Jul 2007 18:26:41 -0500 (CDT) Subject: yum kernel/kmod update weirdness In-Reply-To: <1185680634.4868.27.camel@mccallum.corsepiu.local> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> <1185680634.4868.27.camel@mccallum.corsepiu.local> Message-ID: On Sun, 29 Jul 2007, Ralf Corsepius wrote: > The problem with this behavior: Should a kernel update be malfunctioning > users end up with a non-functional graphics system should they want to > "switch back to the known-to-work kernel+kmods". Yeah, I wasn't saying that should be the behavior. The ideal thing would be for the logic in yum for kernel packages to be extended to kmod-* packages. I can only imagine that's effectively what yum-fedorakmod does. Not that I know. Jima From buildsys at fedoraproject.org Sun Jul 29 23:55:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 29 Jul 2007 19:55:35 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-07-29 Message-ID: <20070729235535.BBDBA152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 20 NEW cdogs-data-0.4-1.fc6 : Data files for the CDogs game NEW cdogs-sdl-0.4-1.fc6 : C-Dogs is an arcade shoot-em-up drupal-5.2-1.fc6 eggdrop-1.6.18-9.fc6 GraphicsMagick-1.1.8-2.fc6 gtk2hs-0.9.12-1.fc6 libcdio-0.78.2-2.fc6 lyx-1.4.5.1-1.fc6 NEW mcabber-0.9.3-2.fc6 : Console Jabber instant messaging client mksh-30-1.fc6 NEW paprefs-0.9.5-1.fc6 : Management tool for PulseAudio perl-Algorithm-Dependency-1.103-1.fc6 perl-Class-Accessor-0.31-1.fc6 perl-Clone-0.27-1.fc6 perl-Mozilla-LDAP-1.5.2-1.fc6 NEW qt4-theme-quarticurve-0.0-0.2.beta3.fc6 : Unofficial port of the Bluecurve widget theme to Qt 4 NEW schedtool-1.2.10-4.fc6 : Tool to query or alter process scheduling policy NEW trac-bazaar-plugin-0.2-2.20070717bzr180.fc6 : Bazaar plugin for Trac xl2tpd-1.1.11-2.fc6 xoo-0.7-4.fc6 Changes in Fedora Extras 6: cdogs-data-0.4-1.fc6 -------------------- * Tue Jul 17 2007 Hans de Goede 0.4-1 - Initial Fedora Extras package cdogs-sdl-0.4-1.fc6 ------------------- * Mon Jul 16 2007 Hans de Goede 0.4-1 - Initial Fedora Extras package drupal-5.2-1.fc6 ---------------- * Thu Jul 26 2007 Jon Ciesla - 5.2-1 - Upgrade to 5.2, Cross-site request forgery fix. eggdrop-1.6.18-9.fc6 -------------------- * Sun Jul 29 2007 Robert Scheck 1.6.18-9 - Rebuild for new bind GraphicsMagick-1.1.8-2.fc6 -------------------------- * Sun Jul 29 2007 Andreas Thienemann - 1.1.8-2 - Building without gslib support as it results in segfaults. * Sat Jul 28 2007 Andreas Thienemann - 1.1.8-1 - Update to new maintainance release 1.1.8 * Wed Mar 07 2007 Andreas Thienemann - 1.1.7-7 - Fix potential CVE-2007-0770 issue. - Added perl-devel BuildReq gtk2hs-0.9.12-1.fc6 ------------------- * Fri Jul 27 2007 Bryan O'Sullivan - 0.9.12-1 - update to 0.9.12 release libcdio-0.78.2-2.fc6 -------------------- * Mon Jul 23 2007 Adrian Reber - 0.78.2-2 - updated to 0.78.2 (#221359) (this time for real) * Thu Jan 04 2007 Adrian Reber - 0.78.2-1 - updated to 0.78.2 (#221359) lyx-1.4.5.1-1.fc6 ----------------- * Fri Jul 27 2007 Rex Dieter 1.4.5.1-1 - lyx-1.4.5.1 mcabber-0.9.3-2.fc6 ------------------- * Tue Jul 10 2007 Michael Fleming 0.9.3-2 - Remove broken .desktop file - it's not really needed for a console app. mksh-30-1.fc6 ------------- * Sat Jul 28 2007 Robert Scheck 30-1 - Upgrade to 30 paprefs-0.9.5-1.fc6 ------------------- * Wed Jan 10 2007 Eric Moret 0.9.5-1 - Initial package for Fedora perl-Algorithm-Dependency-1.103-1.fc6 ------------------------------------- * Sun Jul 29 2007 Ralf Cors?pius - 1.103-1 - Upstream update. perl-Class-Accessor-0.31-1.fc6 ------------------------------ * Fri Jul 27 2007 Tom "spot" Callaway 0.31-1 - update for 0.31, hooray for performance patches perl-Clone-0.27-1.fc6 --------------------- * Fri Jul 27 2007 Tom "spot" Callaway 0.27-1 - bump to 0.27 perl-Mozilla-LDAP-1.5.2-1.fc6 ----------------------------- * Fri Jul 27 2007 Rich Megginson - 1.5.2-1 - Fix bugzilla 389731 - crash when a bad URL is passed qt4-theme-quarticurve-0.0-0.2.beta3.fc6 --------------------------------------- * Fri Jul 20 2007 Kevin Kofler - 0.0-0.2.beta3 - Update readme.txt. schedtool-1.2.10-4.fc6 ---------------------- * Tue Jul 24 2007 Adel Gadllah 1.2.10-4 - New upstream tarball * Sat Jul 21 2007 Adel Gadllah 1.2.10-3 - Specfile cleanups (#248857) - Install TODO * Sat Jul 21 2007 Adel Gadllah 1.2.10-2 - Install CHANGES * Fri Jul 20 2007 Adel Gadllah 1.2.10-1 - New upstream version - Dropped patch (merged upstream) - Don't install INSTALL * Thu Jul 19 2007 Adel Gadllah 1.2.9-5 - Fix debuginfo - Fix manpage permission * Thu Jul 19 2007 Adel Gadllah 1.2.9-4 - Fix RPM_OPT_FLAGS not used again - Fix docs permissions - Preserve timestamps * Thu Jul 19 2007 Adel Gadllah 1.2.9-3 - Remove duplicate docs * Thu Jul 19 2007 Adel Gadllah 1.2.9-2 - Use RPM_OPT_FLAGS - Use URL for Source * Thu Jul 19 2007 Adel Gadllah 1.2.9-1 - Initial Build trac-bazaar-plugin-0.2-2.20070717bzr180.fc6 ------------------------------------------- * Wed Jul 18 2007 Toshio Kuratomi - 0.2-2.20070717bzr180 - Fixes from review comments: RH BZ#248815 + Make macros consistent. + Remove extraneous comment. * Wed Jul 18 2007 Toshio Kuratomi - 0.2-1.20070717bzr180 - Initial build. xl2tpd-1.1.11-2.fc6 ------------------- * Sat Jul 28 2007 Paul Wouters 1.1.11-2 - Upgraded to 1.1.11 - Include new split README.* xoo-0.7-4.fc6 ------------- * Sat Jul 28 2007 Paul Wouters 0.7-4 - Fixed patch file * Sat Jul 28 2007 Paul Wouters 0.7-3 - Added neo1973 skins with permission of copyright holder Sean Moss-Pultz For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jcm at redhat.com Mon Jul 30 04:23:47 2007 From: jcm at redhat.com (Jon Masters) Date: Mon, 30 Jul 2007 00:23:47 -0400 Subject: Updating microcode_ctl In-Reply-To: <20070729235634.f9d6a1ec.mschwendt.tmp0701.nospam@arcor.de> References: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> <20070729235634.f9d6a1ec.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1185769427.23029.137.camel@jcmlaptop> On Sun, 2007-07-29 at 23:56 +0200, Michael Schwendt wrote: > Remove microcode_ctl-1.17-1.38.fc8.i386.rpm from your > /var/cache/yum/development/packages directory and try again. Please CC me if this doesn't solve the problem. Jon. From robert at fedoraproject.org Mon Jul 30 06:14:30 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Mon, 30 Jul 2007 08:14:30 +0200 Subject: RPM roadmapping In-Reply-To: <20070729181010.569d3a49@ender> References: <200707282335.14256.opensource@till.name> <20070729111505.GA3744@hurricane.linuxnetz.de> <200707291813.40418.opensource@till.name> <20070729181010.569d3a49@ender> Message-ID: <20070730061430.GA28630@hurricane.linuxnetz.de> Moin Jesse, On Sun, 29 Jul 2007, Jesse Keating wrote: > A large amount of -devel packages have .so symlinks that are dangling > within the -devel package itself. However rpm is smart enough to > figure out where that link is pointing to and add a hard requires to > that file. not only. I was focussed to the point, that there are packaged symlinks pointing to files which are not packaged. A very good example for such ugly things was the docbook-dtds package for a long time. IIRC about one month ago, somebody took care of bug #193475 (just took another year). Finally, this issue was detected by a rpm5.org rpm - like other package insanities. Greetings, Robert From debarshi.ray at gmail.com Mon Jul 30 06:33:46 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 30 Jul 2007 12:03:46 +0530 Subject: Updating microcode_ctl In-Reply-To: <1185769427.23029.137.camel@jcmlaptop> References: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> <20070729235634.f9d6a1ec.mschwendt.tmp0701.nospam@arcor.de> <1185769427.23029.137.camel@jcmlaptop> Message-ID: <3170f42f0707292333uad88306w9d7e2cba568ef2a0@mail.gmail.com> > > Remove microcode_ctl-1.17-1.38.fc8.i386.rpm from your > > /var/cache/yum/development/packages directory and try again. > Please CC me if this doesn't solve the problem. I am away from my machine now. Will try it tonight and let you know. Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From jfrieben at gmx.de Mon Jul 30 06:48:22 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Mon, 30 Jul 2007 08:48:22 +0200 Subject: Updating microcode_ctl In-Reply-To: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> References: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> Message-ID: <20070730064822.28680@gmx.net> > $ sudo yum -y --enablerepo=development update microcode_ctl > system-config* leads to: > > Downloading Packages: > (1/15): microcode_ctl-1.1 100% |=========================| 321 kB 00:03 > ... > I am using yum-3.2.2-2.fc8. Any idea what is happening? This error message usually indicates a mismatch between the repodata and the packages available for download. Some days ago this happened for all updated packages of that day because the repodata hadn't been updated on the server side. Install the already downloaded package from the cache via 'rpm' or clear your 'yum' cache and try again. -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From pmatilai at laiskiainen.org Mon Jul 30 06:49:58 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 30 Jul 2007 09:49:58 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <20070727175514.GA26347@hurricane.linuxnetz.de> References: <20070727175514.GA26347@hurricane.linuxnetz.de> Message-ID: On Fri, 27 Jul 2007, Robert Scheck wrote: > > when reading your ideas or how ever you're calling it, it looks as you > would like to come up with the same roadmap rpm5.org already has - but just > nearly two month later. And when reading rpm5-devel from the last two > month, you're proposing more or less the same ideas, the rpm5 team and > developers already talked about; read yourself: > > - http://rpm5.org/roadmap/ > - http://rpm5.org/community/rpm-devel/ Yes, I'm reasonably well aware of what rpm5.org is doing. I dunno if you've noticed but some (not all by any means) of the things happening there have actually been triggered by rpm.org activities. Incidentally the initial rpm.org roadmap was published two and a half months ago... > But I've also one wish regarding the features of rpm.org: Let rpmrc die as > soon as possible, please. As you're also at the rpm5-devel mailing list, > you should know what I'm talking about here, don't you? I haven't been following that particular discussion in any detail. > My personal conclusion is, that as of the moment, many expected features > are already part of rpm5.org for a longer time. Oh, I forgot, some Red Hat > people don't like some rpm5.org team members. But this are just > my 2 cents regarding this topic as rpm5.org member and Fedora user... ;-) It's not exactly a big secret that rpm5.org has various fixes and additions that make sense for rpm.org as well. There's a large amount of shared code at the moment, and quite obviously a fair bit of common interest areas as well between the two trees. So yes, code exchange does happen between the trees, both ways, that's obvious to anybody who looks at the changelogs. Still, it doesn't mean they share a common roadmap, they actually differ quite a bit if you think about it. - Panu - From caolanm at redhat.com Mon Jul 30 07:21:52 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 30 Jul 2007 08:21:52 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185654063.18306.10.camel@home.alexander.bostrom.net> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> <1185548040.2494.6.camel@work> <20070727113123.26638c99@localhost.localdomain> <1185654063.18306.10.camel@home.alexander.bostrom.net> Message-ID: <1185780112.3213.8.camel@Nom> On Sat, 2007-07-28 at 22:21 +0200, Alexander Bostr?m wrote: > fre 2007-07-27 klockan 11:31 -0400 skrev Jesse Keating: > > > OO wants to use that file, that file isn't installed, ask yum to > > install that file. > > Maybe this would be a good way to allow bug-buddy to try to get the > right debuginfo packages installed before generating the stack trace? FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to download on a crash. And neither OOo or firefox are using bug-buddy. In the case of OOo at least the crash info can be re-annotated offline back to source lines, so we don't loose anything by having no debuginfo installed. Though we don't get local variables etc with offline annotation, but we don't have those with the current crash reporter anyway. C. From pmatilai at laiskiainen.org Mon Jul 30 08:05:19 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 30 Jul 2007 11:05:19 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: References: <200707282335.14256.opensource@till.name> <1185663120.3928.87.camel@dimi.lattica.com> Message-ID: On Sun, 29 Jul 2007, Jason L Tibbitts III wrote: >>>>>> "PM" == Panu Matilainen writes: > > PM> Welcome to world of rpm: people want progress but no change. > > I don't think that's productive. All I said was "do it but don't warn > about it by default". No, it's certainly not productive. Wasn't targeted at you personally, just a generic comment on how these discussions tend to go... - Panu - From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jul 30 09:25:06 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 30 Jul 2007 11:25:06 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070730112506.5131e7fd@python3.es.egwn.lan> Panu Matilainen wrote : > [...] So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? After reading some of the other posts, I remembered something that has often come up, which I would use extensively if it existed : Some automatic cache/copies of all %config files installed, with all untouched versions always available. This would be very useful with some simple tool to diff the current files(s) wit the backup(s), as well as list all locally changed %config files. A sysadmin's dream come true :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.1-27.fc7 Load : 0.34 0.47 0.68 From pemboa at gmail.com Mon Jul 30 09:38:18 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 30 Jul 2007 04:38:18 -0500 Subject: RPM roadmapping In-Reply-To: <20070730112506.5131e7fd@python3.es.egwn.lan> References: <20070730112506.5131e7fd@python3.es.egwn.lan> Message-ID: <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> On 7/30/07, Matthias Saou wrote: > Panu Matilainen wrote : > > > [...] So: what have you always wanted to do > > with rpm, but wasn't able to? Or the other way around: what you always > > wished rpm would do for you? What always annoyed you out of your mind? > > After reading some of the other posts, I remembered something that has > often come up, which I would use extensively if it existed : > > Some automatic cache/copies of all %config files installed, with all > untouched versions always available. This would be very useful with > some simple tool to diff the current files(s) wit the backup(s), as > well as list all locally changed %config files. A sysadmin's dream come > true :-) > > Matthias To be clear, are you thinking of a something like cp *.conf /etc/backupconfs? -- Fedora Core 6 and proud From buildsys at redhat.com Mon Jul 30 09:47:28 2007 From: buildsys at redhat.com (Build System) Date: Mon, 30 Jul 2007 05:47:28 -0400 Subject: rawhide report: 20070730 changes Message-ID: <200707300947.l6U9lSIE022716@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From fedora at leemhuis.info Mon Jul 30 09:51:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Jul 2007 11:51:17 +0200 Subject: RPM roadmapping In-Reply-To: <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> Message-ID: <46ADB495.60206@leemhuis.info> /me would like something like this as well, so I'm jumping in here On 30.07.2007 11:38, Arthur Pemberton wrote: > On 7/30/07, Matthias Saou > > wrote: >> Panu Matilainen wrote : >>> [...] So: what have you always wanted to do >>> with rpm, but wasn't able to? Or the other way around: what you always >>> wished rpm would do for you? What always annoyed you out of your mind? >> After reading some of the other posts, I remembered something that has >> often come up, which I would use extensively if it existed : >> >> Some automatic cache/copies of all %config files installed, with all >> untouched versions always available. This would be very useful with >> some simple tool to diff the current files(s) wit the backup(s), as >> well as list all locally changed %config files. A sysadmin's dream come >> true :-) > To be clear, are you thinking of a something like > > cp *.conf /etc/backupconfs? For me the proper solution would be: (1) let RPM (or the packages itself) ship a copy of all %config files somewhere in a place where they are safe and don't get modified. (2) When the user edited a %config file then let rpm on package update make a copy of the %config file from the *old* package into another save place Why that you ask? Simple, that way I can diff my current config file against the modified one it is based on (the one created in (2) above). Then I can take the current config file (the one from (1) above), copy it in place and (manually) apply the diff I created earlier. CU knurd From pemboa at gmail.com Mon Jul 30 10:14:06 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 30 Jul 2007 05:14:06 -0500 Subject: RPM roadmapping In-Reply-To: <46ADB495.60206@leemhuis.info> References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> <46ADB495.60206@leemhuis.info> Message-ID: <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> On 7/30/07, Thorsten Leemhuis wrote: > /me would like something like this as well, so I'm jumping in here > > On 30.07.2007 11:38, Arthur Pemberton wrote: > > On 7/30/07, Matthias Saou > > > > wrote: > >> Panu Matilainen wrote : > >>> [...] So: what have you always wanted to do > >>> with rpm, but wasn't able to? Or the other way around: what you always > >>> wished rpm would do for you? What always annoyed you out of your mind? > >> After reading some of the other posts, I remembered something that has > >> often come up, which I would use extensively if it existed : > >> > >> Some automatic cache/copies of all %config files installed, with all > >> untouched versions always available. This would be very useful with > >> some simple tool to diff the current files(s) wit the backup(s), as > >> well as list all locally changed %config files. A sysadmin's dream come > >> true :-) > > To be clear, are you thinking of a something like > > > > cp *.conf /etc/backupconfs? > > For me the proper solution would be: (1) let RPM (or the packages > itself) ship a copy of all %config files somewhere in a place where they > are safe and don't get modified. (2) When the user edited a %config file > then let rpm on package update make a copy of the %config file from the > *old* package into another save place > > Why that you ask? Simple, that way I can diff my current config file > against the modified one it is based on (the one created in (2) above). > Then I can take the current config file (the one from (1) above), copy > it in place and (manually) apply the diff I created earlier. > > CU > knurd Seems like a good idea to me. But considering that config files are relatively small, this would be best if done automatically. -- Fedora Core 6 and proud From gilboad at gmail.com Mon Jul 30 10:47:01 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 30 Jul 2007 13:47:01 +0300 Subject: RPM roadmapping In-Reply-To: <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> References: <1185724431.359.13.camel@gilboa-work-dev.localdomain> <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> Message-ID: <1185792421.11828.6.camel@gilboa-work-dev.localdomain> On Sun, 2007-07-29 at 14:42 -0500, Arthur Pemberton wrote: > On 7/29/07, Gilboa Davara wrote: > > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > > > * Unix philosophy - do just one thing and do it well: > > > - RPM is not a GPG key manager but a package manager. > > > - RPM is not an ftp/http client, it's a package manager. > > > > > > > ... While I agree with the general UNIX philosophy, RPM's HTTP/FTP > > support is very useful. > > How about creating an external plug-in interface that will handle > > non-standard file URLs instead of doing it in the main code? > > > > - Gilboa > > Seems to me, removal of the code doesn't necessarily mean removal of > the feature. Future RPM might just depend on wget. > /+1. Wget is a sound option. - Gilboa From Theodore.Papadopoulo at sophia.inria.fr Mon Jul 30 11:31:08 2007 From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo) Date: Mon, 30 Jul 2007 13:31:08 +0200 Subject: RPM roadmapping In-Reply-To: <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> <46ADB495.60206@leemhuis.info> <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> Message-ID: <46ADCBFC.2070706@sophia.inria.fr> Arthur Pemberton wrote: > On 7/30/07, Thorsten Leemhuis wrote: > >> /me would like something like this as well, so I'm jumping in here >> >> On 30.07.2007 11:38, Arthur Pemberton wrote: >> >>> On 7/30/07, Matthias Saou >>> >>> wrote: >>> >>>> Panu Matilainen wrote : >>>> >>>>> [...] So: what have you always wanted to do >>>>> with rpm, but wasn't able to? Or the other way around: what you always >>>>> wished rpm would do for you? What always annoyed you out of your mind? >>>>> >>>> After reading some of the other posts, I remembered something that has >>>> often come up, which I would use extensively if it existed : >>>> >>>> Some automatic cache/copies of all %config files installed, with all >>>> untouched versions always available. This would be very useful with >>>> some simple tool to diff the current files(s) wit the backup(s), as >>>> well as list all locally changed %config files. A sysadmin's dream come >>>> true :-) >>>> >>> To be clear, are you thinking of a something like >>> >>> cp *.conf /etc/backupconfs? >>> >> For me the proper solution would be: (1) let RPM (or the packages >> itself) ship a copy of all %config files somewhere in a place where they >> are safe and don't get modified. (2) When the user edited a %config file >> then let rpm on package update make a copy of the %config file from the >> *old* package into another save place >> >> Why that you ask? Simple, that way I can diff my current config file >> against the modified one it is based on (the one created in (2) above). >> Then I can take the current config file (the one from (1) above), copy >> it in place and (manually) apply the diff I created earlier. >> >> CU >> knurd >> > > > Seems like a good idea to me. But considering that config files are > relatively small, this would be best if done automatically. > Why not directly putting all the config files under a version control system... From jeremy at jeremysanders.net Mon Jul 30 11:49:36 2007 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Mon, 30 Jul 2007 12:49:36 +0100 Subject: RPM roadmapping References: <1185545286.14697.581.camel@pmac.infradead.org> Message-ID: David Woodhouse wrote: > A few of the bugs on > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > are assigned to to RPM. The most important one is probably the lack of > arch-specific Requires: and BuildRequires: (#235755). > > I don't think we'll manage #235757 in time for Fedora 8 but it would be > good to get it done (and the packages updated accordingly) for Fedora 9. > (Note that comments 3-19 are about the short-term hack we did for F7, > not the real subject of the bug). > > Thoughts on #235758 would be appreciated. Obsoletes aren't arch specific too, which is a real pain: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246598 -- http://jeremysanders.net/ From dimi at lattica.com Mon Jul 30 12:02:23 2007 From: dimi at lattica.com (Dimi Paun) Date: Mon, 30 Jul 2007 08:02:23 -0400 Subject: RPM roadmapping In-Reply-To: <20070730112506.5131e7fd@python3.es.egwn.lan> References: <20070730112506.5131e7fd@python3.es.egwn.lan> Message-ID: <1185796943.3928.125.camel@dimi.lattica.com> On Mon, 2007-07-30 at 11:25 +0200, Matthias Saou wrote: > > Some automatic cache/copies of all %config files installed, with all > untouched versions always available. This would be very useful with > some simple tool to diff the current files(s) wit the backup(s), as > well as list all locally changed %config files. A sysadmin's dream > come true :-) Well, this is exactly what I proposed as my second point in my initial post on the subject: https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01543.html But since I got very little to it, I was afraid I was the only one who sees the obvious advantage of having something like this built into rpm. Not only does it look amazingly useful, it also doesn't seem all that complicated to implement. What I had in mind is say for any %config file /a/path/to/the/file.cfg, a copy of the pristine file should be made in /var/lib/rpm/backups/a/path/to/the/file.cfg or something similar. If we have that, the rest is trivial to automate. -- Dimi Paun Lattica, Inc. From ffesti at redhat.com Mon Jul 30 12:10:17 2007 From: ffesti at redhat.com (Florian Festi) Date: Mon, 30 Jul 2007 14:10:17 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <46ADD529.5080904@redhat.com> Hi! Small behavior change for obsoletes: Issue an error if to be installed pkgs are obsoleted by already installed pkgs. As obsoleting pkgs are logically newer "--oldpackage" should be required to install the obsoleted pkg IMHO. Right now obsoleted pkgs are happily installed. Florian From n0dalus+redhat at gmail.com Mon Jul 30 12:17:19 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 30 Jul 2007 21:47:19 +0930 Subject: RPM roadmapping In-Reply-To: <1185792421.11828.6.camel@gilboa-work-dev.localdomain> References: <1185724431.359.13.camel@gilboa-work-dev.localdomain> <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> <1185792421.11828.6.camel@gilboa-work-dev.localdomain> Message-ID: <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> On 7/30/07, Gilboa Davara wrote: > > /+1. Wget is a sound option. > I'm sure that the rpm developers originally considered using an external program but decided that it would be better to have an internal http/ftp client. If we start stripping out various bits of RPM and replacing them with external libraries, we are making bootstrapping a headache. RPM is used to install wget and other external libraries in the first place, so having rpm depend on them makes things messy. Maybe instead of removing the features, they could be left in, but when an external program or library that does the job better is installed, rpm detects it at runtime and uses it instead. This way there is the best of both worlds: - Basic support for x (eg, http) is provided in rpm, allowing you to use x before a more complete implementation is installed. - The code for x can be simplified, since it should no longer be necessary to build in a full x implementation and handle corner cases. - Once a better implementation is installed, rpm uses it by default, and the inbuilt code for it is never executed. n0dalus. From ffesti at redhat.com Mon Jul 30 12:52:44 2007 From: ffesti at redhat.com (Florian Festi) Date: Mon, 30 Jul 2007 14:52:44 +0200 Subject: Future of Yum Message-ID: <46ADDF1C.6040201@redhat.com> Hi! The next generation of yum can be found at http://www.yum4.org And for those who want the future right now: http://www.yum5.org. If you think the content is too boring try using whois. Florian From skvidal at linux.duke.edu Mon Jul 30 12:50:09 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 30 Jul 2007 08:50:09 -0400 Subject: Future of Yum In-Reply-To: <46ADDF1C.6040201@redhat.com> References: <46ADDF1C.6040201@redhat.com> Message-ID: <1185799809.2409.160.camel@cutter> On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: > Hi! > > The next generation of yum can be found at http://www.yum4.org > And for those who want the future right now: http://www.yum5.org. > > If you think the content is too boring try using whois. > Florian, That is hilarious. Thanks for pointing that out. I was thinking from here on out we should just do squares for version number increases: yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum 1853020188851841 what do you think? -sv From oliver at linux-kernel.at Mon Jul 30 13:04:21 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 30 Jul 2007 15:04:21 +0200 Subject: Future of Yum In-Reply-To: <1185799809.2409.160.camel@cutter> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> Message-ID: <46ADE1D5.7050002@linux-kernel.at> On 07/30/2007 02:50 PM, seth vidal wrote: > On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: >> Hi! >> >> The next generation of yum can be found at http://www.yum4.org >> And for those who want the future right now: http://www.yum5.org. >> >> If you think the content is too boring try using whois. >> > > Florian, > That is hilarious. Thanks for pointing that out. > > I was thinking from here on out we should just do squares for version > number increases: > > yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum > 1853020188851841 > > what do you think? Well 1853020188851841 is very long... :-) Use 3.2, 'til the earth stops spinning. :-) I can think of 3.2.1.0.0 as a starting point :-) -of From oliver at linux-kernel.at Mon Jul 30 13:04:21 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 30 Jul 2007 15:04:21 +0200 Subject: Future of Yum In-Reply-To: <1185799809.2409.160.camel@cutter> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> Message-ID: <46ADE1D5.7050002@linux-kernel.at> On 07/30/2007 02:50 PM, seth vidal wrote: > On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: >> Hi! >> >> The next generation of yum can be found at http://www.yum4.org >> And for those who want the future right now: http://www.yum5.org. >> >> If you think the content is too boring try using whois. >> > > Florian, > That is hilarious. Thanks for pointing that out. > > I was thinking from here on out we should just do squares for version > number increases: > > yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum > 1853020188851841 > > what do you think? Well 1853020188851841 is very long... :-) Use 3.2, 'til the earth stops spinning. :-) I can think of 3.2.1.0.0 as a starting point :-) -of From ffesti at redhat.com Mon Jul 30 13:05:34 2007 From: ffesti at redhat.com (Florian Festi) Date: Mon, 30 Jul 2007 15:05:34 +0200 Subject: Future of Yum In-Reply-To: <1185799809.2409.160.camel@cutter> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> Message-ID: <46ADE21E.9000106@redhat.com> seth vidal wrote: > On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: >> Hi! >> >> The next generation of yum can be found at http://www.yum4.org >> And for those who want the future right now: http://www.yum5.org. >> >> If you think the content is too boring try using whois. >> > > Florian, > That is hilarious. Thanks for pointing that out. > > I was thinking from here on out we should just do squares for version > number increases: > > yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum > 1853020188851841 > > what do you think? Sound like a neat idea at first but it - if you did not yet register those domains - does not solve the problem and we are going to run into filename length problems on some file systems soon. Florian From skvidal at linux.duke.edu Mon Jul 30 12:59:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 30 Jul 2007 08:59:32 -0400 Subject: Future of Yum In-Reply-To: <46ADE1D5.7050002@linux-kernel.at> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> <46ADE1D5.7050002@linux-kernel.at> Message-ID: <1185800372.2409.163.camel@cutter> On Mon, 2007-07-30 at 15:04 +0200, Oliver Falk wrote: > On 07/30/2007 02:50 PM, seth vidal wrote: > > On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: > >> Hi! > >> > >> The next generation of yum can be found at http://www.yum4.org > >> And for those who want the future right now: http://www.yum5.org. > >> > >> If you think the content is too boring try using whois. > >> > > > > Florian, > > That is hilarious. Thanks for pointing that out. > > > > I was thinking from here on out we should just do squares for version > > number increases: > > > > yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum > > 1853020188851841 > > > > what do you think? > > Well 1853020188851841 is very long... :-) Use 3.2, 'til the earth stops > spinning. :-) I can think of 3.2.1.0.0 as a starting point :-) > well, we could do 3.e http://antwrp.gsfc.nasa.gov/htmltest/gifcity/e.1mil -sv From jkeating at redhat.com Mon Jul 30 13:29:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Jul 2007 09:29:36 -0400 Subject: RPM roadmapping In-Reply-To: <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> References: <1185724431.359.13.camel@gilboa-work-dev.localdomain> <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> <1185792421.11828.6.camel@gilboa-work-dev.localdomain> <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> Message-ID: <20070730092936.5a288bfc@localhost.localdomain> On Mon, 30 Jul 2007 21:47:19 +0930 n0dalus wrote: > If we start stripping out various bits of RPM and replacing them with > external libraries, we are making bootstrapping a headache. RPM is > used to install wget and other external libraries in the first place, > so having rpm depend on them makes things messy. Rescue environments with tools on disk that allow you to add/remove content from your root via chroot. I see no reason why rpm has to carry the web suite internal. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gilboad at gmail.com Mon Jul 30 13:43:20 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 30 Jul 2007 16:43:20 +0300 Subject: RPM roadmapping In-Reply-To: <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> References: <1185724431.359.13.camel@gilboa-work-dev.localdomain> <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> <1185792421.11828.6.camel@gilboa-work-dev.localdomain> <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> Message-ID: <1185803000.11828.32.camel@gilboa-work-dev.localdomain> On Mon, 2007-07-30 at 21:47 +0930, n0dalus wrote: > On 7/30/07, Gilboa Davara wrote: > > > > /+1. Wget is a sound option. > > > > I'm sure that the rpm developers originally considered using an > external program but decided that it would be better to have an > internal http/ftp client. > > If we start stripping out various bits of RPM and replacing them with > external libraries, we are making bootstrapping a headache. RPM is > used to install wget and other external libraries in the first place, > so having rpm depend on them makes things messy. > n0dalus. By using a plug-in like system, you don't carry extra dependencies when your boot-strapping (or when you're low on resources/storage), you just lose non-critical features. (such as built-in http/ftp client) - Gilboa From gilboad at gmail.com Mon Jul 30 13:51:17 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 30 Jul 2007 16:51:17 +0300 Subject: RPM roadmapping In-Reply-To: <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> Message-ID: <1185803477.11828.36.camel@gilboa-work-dev.localdomain> On Sat, 2007-07-28 at 16:14 -0500, Arthur Pemberton wrote: > On 7/28/07, seth vidal wrote: > > On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote: > > > Panu Matilainen redhat.com> writes: > > > > - RPM is not an ftp/http client, it's a package manager. > > > > > > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > > > nice feature? > > > > it's not an issue of it being a nice feature - it is an issue of whether > > it is a good idea to maintain the code. Keep in mind - rpm has its own > > http/ftp client included. It's not using curl or wget. All its own code. > > That seems a bit much to maintain esp when the majority of people using > > rpm do it through a higher level language that already has a http/ftp > > client. > > > > the best way to make rpm reliable and consistent is to strip out all > > things that are unnecessary. > > > > -sv > > I would imagine this opens RPM up to remote attacks too. I second the above. Running HTTP/FTP client as root is -not- a god idea. Even if HTTP is being pushed to an external plugin that's built around wget, this plug must be executed as user/guest and not as root. - Gilboa From ajackson at redhat.com Mon Jul 30 13:37:37 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 30 Jul 2007 09:37:37 -0400 Subject: RPM roadmapping In-Reply-To: <20070728164626.GA32055@orient.maison.lan> References: <20070728164626.GA32055@orient.maison.lan> Message-ID: <1185802657.2794.169.camel@localhost.localdomain> On Sat, 2007-07-28 at 18:46 +0200, Emmanuel Seyman wrote: > * Kevin Kofler [28/07/2007 18:41] : > > > > Am I the only one who things that being able to rpm -Uvh http://....rpm is a > > nice feature? > > No but then again, I'll live with > wget http://....rpm -O foo && rpm -Uvh foo Change that to a pipe and you've sold me: $ wget -O - http://whatever | rpm -qpi - On closer inspection, this almost works already, if you invoke it as 'rpm -qpi /dev/stdin'. Explicit - for stdin, or just implicit stdin with no args, would just be gravy. - ajax From Axel.Thimm at ATrpms.net Mon Jul 30 14:15:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Jul 2007 16:15:34 +0200 Subject: yum kernel/kmod update weirdness In-Reply-To: <1185680634.4868.27.camel@mccallum.corsepiu.local> References: <1185606238.20980.464.camel@mccallum.corsepiu.local> <1185680634.4868.27.camel@mccallum.corsepiu.local> Message-ID: <20070730141534.GI16551@puariko.nirvana> On Sun, Jul 29, 2007 at 05:43:54AM +0200, Ralf Corsepius wrote: > The problem with this behavior: Should a kernel update be malfunctioning > users end up with a non-functional graphics system should they want to > "switch back to the known-to-work kernel+kmods". In general the kmod system w/ or w/o any plugins does not cope well with supporting old kernels. http://fedoraproject.org/wiki/AxelThimm/kmdls#head-a61a3d3e1f7743ab6054a5563729fb83e30129ea This is a year old, but nothing has changed since. -- 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 vonbrand at inf.utfsm.cl Mon Jul 30 14:21:34 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 30 Jul 2007 10:21:34 -0400 Subject: RPM roadmapping In-Reply-To: <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> References: <1185724431.359.13.camel@gilboa-work-dev.localdomain> <16de708d0707291242o6c8f3b5cgc5d46b91280195ca@mail.gmail.com> <1185792421.11828.6.camel@gilboa-work-dev.localdomain> <6280325c0707300517v3a79f101wc8b2f93b7bef282e@mail.gmail.com> Message-ID: <13716.1185805294@laptop13.inf.utfsm.cl> n0dalus wrote: > On 7/30/07, Gilboa Davara wrote: > > > > /+1. Wget is a sound option. [...] > Maybe instead of removing the features, they could be left in, but > when an external program or library that does the job better is > installed, rpm detects it at runtime and uses it instead. Sort of. Better if you ask for http://...rpm, and wget/curl/... aren't there, just error out. > This way there is the best of both worlds: > - Basic support for x (eg, http) is provided in rpm, allowing you to > use x before a more complete implementation is installed. No need, as the downloading when installing can be handled by external tools (our you are installing from CD/DVD/local disk > - The code for x can be simplified, since it should no longer be > necessary to build in a full x implementation and handle corner cases. And the security problems stay... for exploiting on partially installed systems (i.e., the most vulnerable). Plus "Why should I install just to use URLs with rpm, they work fine without it"... and you are back at square one. -- 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 Axel.Thimm at ATrpms.net Mon Jul 30 14:22:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Jul 2007 16:22:08 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070730142208.GJ16551@puariko.nirvana> On Fri, Jul 27, 2007 at 03:40:40PM +0300, Panu Matilainen wrote: > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? I'd like to be able to really setup chroot w/o any root privilegdes. This already works at 99% using fakeroot/fakechroot. There is some code in rpm that didn't swallow the fake environment. It didn't look too difficult to fix. :) The application is very important: Currently any submitter can take over any builder by placing some code in %post*/%pre* scripts and making this package a BR of another package. Being root makes it easy to escape the chroot and perform root operations at the builder level (unless the builders are properly selinux protected). A secondary benefit of fakeroot/fakechroot support would be that any random student on any random Linux system could deploy a build system under his account and produce nice rpm packages w/o the need for root priviledges on these systems. -- 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 jfrieben at gmx.de Mon Jul 30 14:23:40 2007 From: jfrieben at gmx.de (Joachim Frieben) Date: Mon, 30 Jul 2007 16:23:40 +0200 Subject: Poor SCSI performance for rawhide kernels Message-ID: <20070730142340.116720@gmx.net> While debugging an issue with the aic7xxx driver, I noticed that SCSI performance is quite poor for the current development kernel compared to release kernels. For a U160 disk attached to a 2940UW controller, FAST-20 mode [which, btw, has to be forced manually, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171282] delivers more than 28 MB/s [hdparm -t /dev/sda] for the latest F7 update kernel 2.6.22.1-33.fc7 [compared to the nominal rate of 40 MB/s] whereas it drops by almost 30% to about 20 MB/s for rawhide kernel 2.6.23-0.49.rc1.git3.fc8 which is barely more than in FAST-10 mode. It this difference of the order one would expect? -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail From ivazqueznet at gmail.com Mon Jul 30 14:25:06 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 30 Jul 2007 10:25:06 -0400 Subject: Future of Yum In-Reply-To: <46ADDF1C.6040201@redhat.com> References: <46ADDF1C.6040201@redhat.com> Message-ID: <1185805506.3972.2.camel@ignacio.lan> On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: > The next generation of yum can be found at http://www.yum4.org > And for those who want the future right now: http://www.yum5.org. > > If you think the content is too boring try using whois. *yawn* I'm not interested in allowing his past to affect how I handle my/our future. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-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 Mon Jul 30 14:26:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Jul 2007 10:26:41 -0400 Subject: RPM roadmapping In-Reply-To: <20070730142208.GJ16551@puariko.nirvana> References: <20070730142208.GJ16551@puariko.nirvana> Message-ID: <20070730102641.03ccb637@localhost.localdomain> On Mon, 30 Jul 2007 16:22:08 +0200 Axel Thimm wrote: > I'd like to be able to really setup chroot w/o any root > privilegdes. This already works at 99% using > fakeroot/fakechroot. There is some code in rpm that didn't swallow the > fake environment. It didn't look too difficult to fix. :) > > The application is very important: Currently any submitter can take > over any builder by placing some code in %post*/%pre* scripts and > making this package a BR of another package. Being root makes it easy > to escape the chroot and perform root operations at the builder level > (unless the builders are properly selinux protected). > > A secondary benefit of fakeroot/fakechroot support would be that any > random student on any random Linux system could deploy a build system > under his account and produce nice rpm packages w/o the need for root > priviledges on these systems. We'd like something like this for Koji as well (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon Jul 30 14:19:13 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 30 Jul 2007 10:19:13 -0400 Subject: Future of Yum In-Reply-To: <1185805506.3972.2.camel@ignacio.lan> References: <46ADDF1C.6040201@redhat.com> <1185805506.3972.2.camel@ignacio.lan> Message-ID: <1185805153.12224.0.camel@cutter> On Mon, 2007-07-30 at 10:25 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: > > The next generation of yum can be found at http://www.yum4.org > > And for those who want the future right now: http://www.yum5.org. > > > > If you think the content is too boring try using whois. > > *yawn* I'm not interested in allowing his past to affect how I handle > my/our future. > but just remember: yum.org -> it's all about a pure morning! /me giggles -sv From vonbrand at inf.utfsm.cl Mon Jul 30 14:31:01 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 30 Jul 2007 10:31:01 -0400 Subject: Future of Yum In-Reply-To: <1185799809.2409.160.camel@cutter> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> Message-ID: <14366.1185805861@laptop13.inf.utfsm.cl> seth vidal wrote: > On Mon, 2007-07-30 at 14:52 +0200, Florian Festi wrote: > > Hi! > > > > The next generation of yum can be found at http://www.yum4.org > > And for those who want the future right now: http://www.yum5.org. > > > > If you think the content is too boring try using whois. > > > > Florian, > That is hilarious. Thanks for pointing that out. > > I was thinking from here on out we should just do squares for version > number increases: > > yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum > 1853020188851841 Why not using the (La)TeX idea of an irrational number, adding a digit each round? sqrt(11) = 3.316624... would do. So the next one would be 3.3, then 3.31, 3.316, ... [Sadly, the "nice" numbers \pi, e, \phi are too small now...] -- 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 caillon at redhat.com Mon Jul 30 14:32:26 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 30 Jul 2007 10:32:26 -0400 Subject: =?utf-8?q?WTF=E2=81=88_ShowOnlyIn=3DGNOME?= In-Reply-To: <6e24a8e80707290753l20d74e44j4039e4f271216541@mail.gmail.com> References: <1185100456.4543.2.camel@sb-home> <20070723004934.GA28551@jadzia.bu.edu> <20070723112548.49ffaae0@localhost.localdomain> <645d17210707231328n37f1d1a7s38c327e6d6f4123e@mail.gmail.com> <544eb990707260541y77cff0bauf661ddf4946e3867@mail.gmail.com> <6e24a8e80707290753l20d74e44j4039e4f271216541@mail.gmail.com> Message-ID: <46ADF67A.1080301@redhat.com> Mark wrote: > perhaps it's better to adjust the KDE menu package (whichever one that > might be) and edit it so that it ignores the ShowOnlyIn directive. > Than it will display all menu items where they are supposed to be. Breaking the desktop spec is the wrong thing to do. Get the spec changed, or change the desktop files to not have the ShowOnlyIn. But don't break the spec. From jspaleta at gmail.com Mon Jul 30 16:05:40 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 30 Jul 2007 08:05:40 -0800 Subject: RPM roadmapping In-Reply-To: <20070730112506.5131e7fd@python3.es.egwn.lan> References: <20070730112506.5131e7fd@python3.es.egwn.lan> Message-ID: <604aa7910707300905s65885029w689a20d837649eec@mail.gmail.com> On 7/30/07, Matthias Saou > Some automatic cache/copies of all %config files installed, with all > untouched versions always available. This would be very useful with > some simple tool to diff the current files(s) wit the backup(s), as > well as list all locally changed %config files. A sysadmin's dream come > true :-) actually.. now that i think about it... just having a centralized lookup for rpmsave and rpmnew files rpm created for me as part of transaction information would be keen. I hate having to troll the filesystem just to build my own record of these files for later archiving or garbage collecting. -jef From jspaleta at gmail.com Mon Jul 30 16:12:50 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 30 Jul 2007 08:12:50 -0800 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185780112.3213.8.camel@Nom> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> <1185548040.2494.6.camel@work> <20070727113123.26638c99@localhost.localdomain> <1185654063.18306.10.camel@home.alexander.bostrom.net> <1185780112.3213.8.camel@Nom> Message-ID: <604aa7910707300912yf50962hdae09a109149fe39@mail.gmail.com> On 7/29/07, Caolan McNamara wrote: > FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to > download on a crash. And neither OOo or firefox are using bug-buddy. In > the case of OOo at least the crash info can be re-annotated offline back > to source lines, so we don't loose anything by having no debuginfo > installed. Though we don't get local variables etc with offline > annotation, but we don't have those with the current crash reporter > anyway. I think OOo illustrates that whatever toolized solution to help users install debuginfo packages as needed, would need to be smart enough to blacklist certain packages that are known not to benefit from the debuginfo install. -jef From abo at kth.se Mon Jul 30 16:35:30 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 30 Jul 2007 18:35:30 +0200 Subject: RPM roadmapping In-Reply-To: <1185803477.11828.36.camel@gilboa-work-dev.localdomain> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> Message-ID: <1185813330.31780.109.camel@realdor.ite.kth.se> m?n 2007-07-30 klockan 16:51 +0300 skrev Gilboa Davara: > I second the above. > Running HTTP/FTP client as root is -not- a god idea. > > Even if HTTP is being pushed to an external plugin that's built around > wget, this plug must be executed as user/guest and not as root. Yes, the principle of least privilege does apply here. Though, I would worry more about the fact that rpm -ivh http://... doesn't verify any signatures. It's a good idea to: wget http://... rpm -K foo.rpm Look at the result, and then maybe: rpm -i foo.rpm (rpm -K && rpm -i won't do, since it'll say OK for unsigned packages, IIRC) Or, even: wget http://... yum localinstall foo.rpm Which, in turn, might be possible to simplify? /abo From ianburrell at gmail.com Mon Jul 30 17:59:18 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Mon, 30 Jul 2007 10:59:18 -0700 Subject: RPM roadmapping In-Reply-To: References: Message-ID: It would be nice if rpmbuild could make noarch sub-packages when the main package has an architecture. This would be useful for games and other programs that have large data files in a single source archive. If the data files are not arch-dependent, they could be put in a noarch subpackage which would save space on the repositories. Currently doing this requires building the subpackage from separate source package. - Ian From kevin.kofler at chello.at Mon Jul 30 18:00:22 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 30 Jul 2007 18:00:22 +0000 (UTC) Subject: RPM roadmapping References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <1185813330.31780.109.camel@realdor.ite.kth.se> Message-ID: Alexander Bostr?m kth.se> writes: > Or, even: > > wget http://... > yum localinstall foo.rpm > > Which, in turn, might be possible to simplify? apt-get install http://... :-) (This works with apt-rpm, not with Debian apt.) Though more often than not I end up actually having to disable the signature check (-o RPM::GPG-Check=false) when I do this. RPMs which aren't in a repository tend not to be signed, if they're in a repository I don't have enabled, I don't have the key imported either. Kevin Kofler From ianburrell at gmail.com Mon Jul 30 18:01:42 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Mon, 30 Jul 2007 11:01:42 -0700 Subject: RPM roadmapping In-Reply-To: <46ADCBFC.2070706@sophia.inria.fr> References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> <46ADB495.60206@leemhuis.info> <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> <46ADCBFC.2070706@sophia.inria.fr> Message-ID: On 7/30/07, Theodore Papadopoulo wrote: > Why not directly putting all the config files under a version control > system... > Having the clean config files make it easier to manage them with version control. They can be used for doing a three-way merge or for making the vendor branch. Instead of having rpm do the copy, it might make sense to have a hook. The default hook would copy the files but somebody could have it call a version control system. - Ian From pmatilai at laiskiainen.org Mon Jul 30 18:03:48 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 30 Jul 2007 21:03:48 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <1185813330.31780.109.camel@realdor.ite.kth.se> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <1185813330.31780.109.camel@realdor.ite.kth.se> Message-ID: On Mon, 30 Jul 2007, Alexander Bostr?m wrote: > m?n 2007-07-30 klockan 16:51 +0300 skrev Gilboa Davara: > >> I second the above. >> Running HTTP/FTP client as root is -not- a god idea. >> >> Even if HTTP is being pushed to an external plugin that's built around >> wget, this plug must be executed as user/guest and not as root. > > Yes, the principle of least privilege does apply here. > > Though, I would worry more about the fact that rpm -ivh http://... > doesn't verify any signatures. It's a good idea to: Actually it does verify the signature if one is present, unless you turn it off explicitly. The problem is that rpm doesn't have a meaningful mechanism to *prevent* installation if unsigned and/or signed but untrusted packages are installed. Yes it's .. silly. > wget http://... > rpm -K foo.rpm > Look at the result, and then maybe: > rpm -i foo.rpm > > (rpm -K && rpm -i won't do, since it'll say OK for unsigned packages, > IIRC) > > Or, even: > > wget http://... > yum localinstall foo.rpm > > Which, in turn, might be possible to simplify? Yum could just as well support "yum install http://..../foo.rpm" :) Speaking of that, yum currently accesses package header before verifying the signature, at least in the case of localinstall. I've some fuzzed rpm's here that cause rpm to segfault if signature checking is disabled as yum does... Dunno how exploitable that is in reality but there is a potential vulnerability there anyway. - Panu - From jkeating at redhat.com Mon Jul 30 18:12:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Jul 2007 14:12:08 -0400 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070730141208.79e4aa15@localhost.localdomain> On Fri, 27 Jul 2007 15:40:40 +0300 (EEST) Panu Matilainen wrote: > The more specific you can be, the better - "make it not suck" isn't > productive. Of course there's no way everything can be done, we want > the next major release out before end of the decade... Also this is > not a voting where most votes guarantee implementation, but consider > it your chance to be heard. I'm listening... :) Please allow ExcludeArch and ExclusiveArch to propagate into noarch rpms. We have a multitude of noarch rpms (like python scripts and such) that just plain won't work on some arches, but are themselves not binary. We have ExcludeArch and ExclusiveArch in the spec file to prevent them from being built in an arch where their BR or R wouldn't be met, and we have compose tools that scrape this information out of srpms at compose time, as the noarch rpm doesn't have this information. If it were in the rpm itself it would be much easier for compose tools to deal with. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at laiskiainen.org Mon Jul 30 18:16:18 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 30 Jul 2007 21:16:18 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <1185803477.11828.36.camel@gilboa-work-dev.localdomain> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> Message-ID: On Mon, 30 Jul 2007, Gilboa Davara wrote: > On Sat, 2007-07-28 at 16:14 -0500, Arthur Pemberton wrote: >> On 7/28/07, seth vidal wrote: >>> On Sat, 2007-07-28 at 14:53 +0000, Kevin Kofler wrote: >>>> Panu Matilainen redhat.com> writes: >>>>> - RPM is not an ftp/http client, it's a package manager. >>>> >>>> Am I the only one who things that being able to rpm -Uvh http://....rpm is a >>>> nice feature? >>> >>> it's not an issue of it being a nice feature - it is an issue of whether >>> it is a good idea to maintain the code. Keep in mind - rpm has its own >>> http/ftp client included. It's not using curl or wget. All its own code. >>> That seems a bit much to maintain esp when the majority of people using >>> rpm do it through a higher level language that already has a http/ftp >>> client. >>> >>> the best way to make rpm reliable and consistent is to strip out all >>> things that are unnecessary. >>> >>> -sv >> >> I would imagine this opens RPM up to remote attacks too. > > I second the above. > Running HTTP/FTP client as root is -not- a god idea. Yet that's how all our depsolvers and the associated tools work... - Panu - From robert at fedoraproject.org Mon Jul 30 18:17:02 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Mon, 30 Jul 2007 20:17:02 +0200 Subject: Future of Yum In-Reply-To: <1185800372.2409.163.camel@cutter> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> <46ADE1D5.7050002@linux-kernel.at> <1185800372.2409.163.camel@cutter> Message-ID: <20070730181702.GA12554@hurricane.linuxnetz.de> Evening folks, On Mon, 30 Jul 2007, seth vidal wrote: > > >> The next generation of yum can be found at http://www.yum4.org > > >> And for those who want the future right now: http://www.yum5.org. > > >> > > > yum 3 -> yum 9 -> yum 81 -> yum 6561 -> yum 43046721 -> yum > > > 1853020188851841 > > > > > Well 1853020188851841 is very long... :-) Use 3.2, 'til the earth stops > > spinning. :-) I can think of 3.2.1.0.0 as a starting point :-) > > well, we could do 3.e HAHA! I ever knew, one day RPM will eat all those python programmers (okay, I already know who owns this domains for a longer time now) ;-) Panu...now as yum4 and yum5 will be written in C and not in python (IIRC nobody of rpm5.org would write yum next generation in a script language), wouldn't it be the perfect time to rip out the python support in RPM? This would bring us to a bare RPM like you were suggesting it. No HTTP, no FTP and no python support - what do we need more? Maybe somebody could remove the perl support, too? When yum4 and 5 goes back to the roots, why not RPM also? Unfortunately you all can't see how big my grin is... ...more grin than having face, Robert :-D From jdieter at gmail.com Mon Jul 30 18:29:29 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 30 Jul 2007 21:29:29 +0300 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185820169.3474.3.camel@jndwidescreen.lesbg.loc> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > The more specific you can be, the better - "make it not suck" isn't > productive. Of course there's no way everything can be done, we want the > next major release out before end of the decade... Also this is not a > voting where most votes guarantee implementation, but consider it your > chance to be heard. I'm listening... :) I would love the rpm header to be compressed. Some of the deltarpms we've created have a large part of their filesize being the header (think OOo with a release bump for a minor change); it would be nice if it could be reduced some. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Mon Jul 30 18:31:01 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 30 Jul 2007 11:31:01 -0700 Subject: Fedora Rel-Eng Meeting Recap 2007-jul-30 Message-ID: <46AE2E65.2050800@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jul-30 Please make corrections and clarifications to the wiki page. == F8 Test 1 Status == * So far, not so good * https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F8Test1 * Blocker evaluation * f13 1. 247863 is not; but I do believe we can find somebody with time to bang out a fix for this in short order. So while not a blocker, I'd really like to see this fixed as it is very visible. 1. 249597 is totally blocker (insta-reboot issue) 1. 249908 (adding extra repo at install time) not a blocker, just a /really/ nice to have. 1. 250047 is fixed with new policy, just need to clicky the buttons 1. 250130 is no pata support on ppc mac minis (potentially more ppc32 hardware). * going to spin again this evening with the things we've fixed so far and sync that up too Summary: Decision as to whether we need to slip Fedora 8 Test 1 will be made tomorrow. == Fedora 8 Test 1 - What to deliver == * Release Engineering will produce the following for Fedora 8 Test1 1. Fedora installable spin * i386 * x86_64 * ppc * source 1. Fedora {i386,x86_64} Live image 1. KDE {i386,x86_64 Live} image 1. Everything tree will be provided by standard Rawhide ("development") locations == IRC Transcript == (see wiki) From sundaram at fedoraproject.org Mon Jul 30 18:32:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 31 Jul 2007 00:02:54 +0530 Subject: Future of Yum In-Reply-To: <20070730181702.GA12554@hurricane.linuxnetz.de> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> <46ADE1D5.7050002@linux-kernel.at> <1185800372.2409.163.camel@cutter> <20070730181702.GA12554@hurricane.linuxnetz.de> Message-ID: <46AE2ED6.4000805@fedoraproject.org> Robert Scheck wrote: > > HAHA! I ever knew, one day RPM will eat all those python programmers (okay, > I already know who owns this domains for a longer time now) ;-) > > Panu...now as yum4 and yum5 will be written in C and not in python (IIRC > nobody of rpm5.org would write yum next generation in a script language), > wouldn't it be the perfect time to rip out the python support in RPM? This > would bring us to a bare RPM like you were suggesting it. No HTTP, no FTP > and no python support - what do we need more? Maybe somebody could remove > the perl support, too? When yum4 and 5 goes back to the roots, why not RPM > also? > > Unfortunately you all can't see how big my grin is... If you are rewriting Yum in C on your own, it would be more courteous to call it by a different name instead of simply bumping the version, registering domains silently and generally end up confusing end users. I doubt many developers of Python apps like Zope would really consider it as a scripting language. It isn't described as one officially. HTTP/FTP client support is not really comparable to support for language bindings. Since you are already contributing to a different branch, it is unnecessary to harp on the maintainer's choices here. Rahul From robert at fedoraproject.org Mon Jul 30 19:00:39 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Mon, 30 Jul 2007 21:00:39 +0200 Subject: RPM roadmapping In-Reply-To: References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> Message-ID: <20070730190039.GA17397@hurricane.linuxnetz.de> Evening, On Mon, 30 Jul 2007, Panu Matilainen wrote: >>>> the best way to make rpm reliable and consistent is to strip out all >>>> things that are unnecessary. hm. Looking forward to pyrpm and pyyum or however it is called, is it necessary to keep rpm and yum at all? Neither pyrpm nor the pyyum depend on rpmlib somehow. Isn't it overkill to have two implementations of the same? Guessing a python rpm (written only in that script language) would make many Red Hat people happy, because python is the Red Hat in-house defacto standard, isn't it? >>> I would imagine this opens RPM up to remote attacks too. >> >> I second the above. >> Running HTTP/FTP client as root is -not- a god idea. > > Yet that's how all our depsolvers and the associated tools work... Well. Seen from this point, we should download *all* files in yum and (...) with an unprivileged account, check somehow and afterwards install as root. Eggdrop for example avoids to be executed as root, but when you're hacking this into wget...it's better not to complete this sentence. Finally, having Neon support in RPM is IMHO just the same high or less risk as having Neon support in Subversion. Why to castrate RPM at all? It looks like just to get other non-named tools more deeply involved. And if this is reason, there's from my POV no need to keep RPM in the current form. And a stupid python hack could replace everything and should be written fast; can somebody agree with me or am I already stamped as mailing list clown? Greetings, Robert From sundaram at fedoraproject.org Mon Jul 30 19:08:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 31 Jul 2007 00:38:53 +0530 Subject: RPM roadmapping In-Reply-To: <20070730190039.GA17397@hurricane.linuxnetz.de> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <20070730190039.GA17397@hurricane.linuxnetz.de> Message-ID: <46AE3745.2000607@fedoraproject.org> Robert Scheck wrote: > Evening, > > On Mon, 30 Jul 2007, Panu Matilainen wrote: >>>>> the best way to make rpm reliable and consistent is to strip out all >>>>> things that are unnecessary. > > hm. Looking forward to pyrpm and pyyum or however it is called, is it > necessary to keep rpm and yum at all? Neither pyrpm nor the pyyum depend on > rpmlib somehow. Isn't it overkill to have two implementations of the same? Pyrpm is described as "PyRPM is an experimental project to look at rpm package management". It is a prototyping tool. Not a implementation meant to be used by users currently unlike Yum (which I think is what you are referring to as pyyum). Rahul From robert at fedoraproject.org Mon Jul 30 19:24:52 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Mon, 30 Jul 2007 21:24:52 +0200 Subject: RPM roadmapping In-Reply-To: <46AE3745.2000607@fedoraproject.org> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <20070730190039.GA17397@hurricane.linuxnetz.de> <46AE3745.2000607@fedoraproject.org> Message-ID: <20070730192452.GA20287@hurricane.linuxnetz.de> Hello Rahul, On Tue, 31 Jul 2007, Rahul Sundaram wrote: > Pyrpm is described as "PyRPM is an experimental project to look at rpm > package management". It is a prototyping tool. Not a implementation meant > to be used by users currently unlike Yum (which I think is what you are > referring to as pyyum). okay, you did never use PyRPM. I played with pyrpm and it looks acceptable for different actions and unfortunately I played just less with pyyum which is included there (sorry, I'm to lazy to verifiy whether it's really called pyyum) and it also could be an interesting way. Reading this and reading further on at the list, it already sounds a bit as there's no interest to walk *really* a new and radical way regarding RPM. Why? What is preventing? When looking back e.g. to soft dependencies, I remember that they just were refused for obivious reasons by individuals having the right position at Fedora (or Red Hat). You maybe treat this as flame, but this is what the feedback from that time looked like. The end of the song normally is: Everybody wants new features, nobody wants to implement them or when they're getting implemented nothing should break or change because the packaging management system is very basic, everything has to be 100% backward compatible but in the same way; it should be legacy free as well on the other hand. Wrong world. Maybe you can see, what the real problem behind the doors is. Otherwise, please try to open your eyes. Greetings, Robert From Lam at Lam.pl Mon Jul 30 19:42:52 2007 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 30 Jul 2007 21:42:52 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <20070730214252.56b69847@pensja.lam.pl> Dnia 2007-07-27, o godz. 15:40:40 Panu Matilainen napisa?(a): > What always annoyed you out of your mind? Oh, two more things! Let RPM forget about changelogs of packages, please. Let the changelog stay in the spec, let yum/apt handle fetching it from some special file in the repo, but keep it from being included in the binary package header and stored in my system's rpmdb. For some people it's really a big waste of bandwidth and disk space. And the last annoyance - rpm really likes to become unusable, hanging forever (repeating futex calls) on every run, but starting to work again when I remove those /var/lib/rpm/__db.00* files. I've seen it so many times on so many systems that I almost think it's meant to work that way. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Jul 30 19:50:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 31 Jul 2007 01:20:42 +0530 Subject: RPM roadmapping In-Reply-To: <20070730192452.GA20287@hurricane.linuxnetz.de> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <20070730190039.GA17397@hurricane.linuxnetz.de> <46AE3745.2000607@fedoraproject.org> <20070730192452.GA20287@hurricane.linuxnetz.de> Message-ID: <46AE4112.5070002@fedoraproject.org> Robert Scheck wrote: > Hello Rahul, > > On Tue, 31 Jul 2007, Rahul Sundaram wrote: >> Pyrpm is described as "PyRPM is an experimental project to look at rpm >> package management". It is a prototyping tool. Not a implementation meant >> to be used by users currently unlike Yum (which I think is what you are >> referring to as pyyum). > > okay, you did never use PyRPM. I don't know why you want to assume that. My use is irrelvant to your question on whether pyrpm duplicates yum and RPM. Answer: No. it doesn't. pyrpm is clearly described as a experimental prototype in it's homepage at http://www.jur-linux.org/pyrpm/. That's the first hit in google btw. I played with pyrpm and it looks acceptable > for different actions and unfortunately I played just less with pyyum which > is included there (sorry, I'm to lazy to verifiy whether it's really called > pyyum) and it also could be an interesting way. It is called yum and not pyyum which would a redundant name since the only existing implementation of Yum is in python. If you are a Fedora user, the fact the name is yum should have been obvious. Reading this and reading > further on at the list, it already sounds a bit as there's no interest to > walk *really* a new and radical way regarding RPM. Why? What is preventing? A fork did occur because people have different opinions on the right path. Distributions will eventually decide one way or the other and we can all hopefully have what we wanted. > When looking back e.g. to soft dependencies, I remember that they just were > refused for obivious reasons by individuals having the right position at > Fedora (or Red Hat). You maybe treat this as flame, but this is what the > feedback from that time looked like. Panu did mention that he was considering soft dependencies in rpm-maint list. https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000330.html Many people both Red Hat and non-Red Hat folks have been expressing some concerns over soft dependencies. Rahul From skvidal at linux.duke.edu Mon Jul 30 19:57:45 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 30 Jul 2007 15:57:45 -0400 Subject: RPM roadmapping In-Reply-To: References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <1185813330.31780.109.camel@realdor.ite.kth.se> Message-ID: <1185825465.12224.23.camel@cutter> On Mon, 2007-07-30 at 21:03 +0300, Panu Matilainen wrote: > Yum could just as well support "yum install http://..../foo.rpm" :) > > Speaking of that, yum currently accesses package header before verifying > the signature, at least in the case of localinstall. I've some fuzzed > rpm's here that cause rpm to segfault if signature checking is > disabled as yum does... Dunno how exploitable that is in reality but there > is a potential vulnerability there anyway. 1. Can I get a copy of those rpms? 2. I've heard about the aforementioned mythic case of an exploit but never actually seen one. I could be wrong but I thought the case that was dangerous was not if gpg signature checking was disabled but if header checking in general was disabled. Changing yum's opener for pkgs so it does with hdr checking enabled is pretty simple to do - however, it'd be nice if I had a replicating case to check it out with. Thanks, -sv From chris.stone at gmail.com Mon Jul 30 20:14:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 30 Jul 2007 13:14:11 -0700 Subject: Missing dependencies with glib2-devel? In-Reply-To: References: Message-ID: Still broken here :( Am I the only one getting this error? I went ahead and filed a bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250166 On 7/28/07, Christopher Stone wrote: > Tried again this morning... still broken....anyone? > > On 7/27/07, Christopher Stone wrote: > > I'm getting the following error when trying to build my package with mock on F7: > > > > $ /usr/sbin/mock-helper yum --installroot > > /var/lib/mock/fedora-7-x86_64/root install 'glib2-devel' > > Error: Missing Dependency: libgobject-2.0.so.0 is needed by package glib2-devel > > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package glib2-devel > > Error: Missing Dependency: libglib-2.0.so.0 is needed by package glib2-devel > > Error: Missing Dependency: libgmodule-2.0.so.0 is needed by package glib2-devel > > > > My mock configs are unchanged from the default. > > > From ivazqueznet at gmail.com Mon Jul 30 20:14:08 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 30 Jul 2007 16:14:08 -0400 Subject: Future of Yum In-Reply-To: <20070730181702.GA12554@hurricane.linuxnetz.de> References: <46ADDF1C.6040201@redhat.com> <1185799809.2409.160.camel@cutter> <46ADE1D5.7050002@linux-kernel.at> <1185800372.2409.163.camel@cutter> <20070730181702.GA12554@hurricane.linuxnetz.de> Message-ID: <1185826448.3972.4.camel@ignacio.lan> On Mon, 2007-07-30 at 20:17 +0200, Robert Scheck wrote: > Unfortunately you all can't see how big my grin is... Yeeeah..... you'll let us know when "wnh" is ready... right? -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tonynelson at georgeanelson.com Mon Jul 30 20:14:36 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 30 Jul 2007 16:14:36 -0400 Subject: RPM roadmapping In-Reply-To: <20070730112506.5131e7fd@python3.es.egwn.lan> References: <20070730112506.5131e7fd@python3.es.egwn.lan> Message-ID: At 11:25 AM +0200 7/30/07, Matthias Saou wrote: >Panu Matilainen wrote : > >> [...] So: what have you always wanted to do >> with rpm, but wasn't able to? Or the other way around: what you always >> wished rpm would do for you? What always annoyed you out of your mind? > >After reading some of the other posts, I remembered something that has >often come up, which I would use extensively if it existed : > >Some automatic cache/copies of all %config files installed, with all >untouched versions always available. This would be very useful with >some simple tool to diff the current files(s) wit the backup(s), as >well as list all locally changed %config files. A sysadmin's dream come >true :-) As a sloppy sysadmin myself, I don't always remember to back up config files before editing, so an automatic %config backup on RPM install / upgrade would help me, and, I think, most other Linux users. On package upgrade, I'd like the previous / original config file to be kept as well if a .rpmnew file will be created for the actual config file (and the .rpmnew file should not be created if the files are identical, though that is a known tricky issue). -- ____________________________________________________________________ TonyN.:' ' From pmatilai at laiskiainen.org Mon Jul 30 20:21:31 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 30 Jul 2007 23:21:31 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <1185825465.12224.23.camel@cutter> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <1185813330.31780.109.camel@realdor.ite.kth.se> <1185825465.12224.23.camel@cutter> Message-ID: On Mon, 30 Jul 2007, seth vidal wrote: > On Mon, 2007-07-30 at 21:03 +0300, Panu Matilainen wrote: >> Yum could just as well support "yum install http://..../foo.rpm" :) >> >> Speaking of that, yum currently accesses package header before verifying >> the signature, at least in the case of localinstall. I've some fuzzed >> rpm's here that cause rpm to segfault if signature checking is >> disabled as yum does... Dunno how exploitable that is in reality but there >> is a potential vulnerability there anyway. > > 1. Can I get a copy of those rpms? > 2. I've heard about the aforementioned mythic case of an exploit but > never actually seen one. I could be wrong but I thought the case that > was dangerous was not if gpg signature checking was disabled but if > header checking in general was disabled. Changing yum's opener for pkgs > so it does with hdr checking enabled is pretty simple to do - however, > it'd be nice if I had a replicating case to check it out with. Sure, check out the crash_rpm?.rpm's from comments 1-3 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239557 You'll need to test those with rpm 4.4.2.1 as older ones crash on them with or without signature checking. - Panu - From pmatilai at laiskiainen.org Mon Jul 30 21:15:14 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 31 Jul 2007 00:15:14 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <1185825465.12224.23.camel@cutter> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <1185813330.31780.109.camel@realdor.ite.kth.se> <1185825465.12224.23.camel@cutter> Message-ID: On Mon, 30 Jul 2007, seth vidal wrote: > On Mon, 2007-07-30 at 21:03 +0300, Panu Matilainen wrote: >> Yum could just as well support "yum install http://..../foo.rpm" :) >> >> Speaking of that, yum currently accesses package header before verifying >> the signature, at least in the case of localinstall. I've some fuzzed >> rpm's here that cause rpm to segfault if signature checking is >> disabled as yum does... Dunno how exploitable that is in reality but there >> is a potential vulnerability there anyway. > > 1. Can I get a copy of those rpms? > 2. I've heard about the aforementioned mythic case of an exploit but > never actually seen one. I could be wrong but I thought the case that > was dangerous was not if gpg signature checking was disabled but if > header checking in general was disabled. Changing yum's opener for pkgs > so it does with hdr checking enabled is pretty simple to do - however, > it'd be nice if I had a replicating case to check it out with. BTW if it's of any comfort, apt is guilty of the same thing. Doh :) - Panu - From sundaram at fedoraproject.org Mon Jul 30 21:32:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 31 Jul 2007 03:02:40 +0530 Subject: yum and library dependencies Message-ID: <46AE58F8.6030400@fedoraproject.org> Hi This seems odd... #yum install libartsmodules.so.0 Loading "presto" plugin Setting up Install Process Parsing package install arguments Setting up Presto Reading Presto metadata in from local files Resolving Dependencies --> Running transaction check ---> Package kdemultimedia.i386 6:3.5.7-0.1.fc7 set to be updated --> Processing Dependency: kdebase >= 6:3.5.7 for package: kdemultimedia --> Processing Dependency: libDCOP.so.4 for package: kdemultimedia --> Processing Dependency: libkio.so.4 for package: kdemultimedia --> Processing Dependency: libkdeui.so.4 for package: kdemultimedia --> Processing Dependency: libkdefx.so.4 for package: kdemultimedia --> Processing Dependency: libkmid.so.0 for package: kdemultimedia --> Processing Dependency: libkutils.so.1 for package: kdemultimedia --> Processing Dependency: libartskde.so.1 for package: kdemultimedia --> Processing Dependency: libkparts.so.2 for package: kdemultimedia --> Processing Dependency: libkdecore.so.4 for package: kdemultimedia --> Processing Dependency: libakode.so.2 for package: kdemultimedia --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package akode.i386 0:2.0.1-6.fc7 set to be updated ---> Package kdebase.i386 6:3.5.7-0.1.fc7 set to be updated ---> Package kdemultimedia.i386 6:3.5.7-0.1.fc7 set to be updated ---> Package kdelibs.i386 6:3.5.7-9.fc7 set to be updated --> Processing Dependency: akode-pulseaudio for package: akode --> Processing Dependency: libkdnssd.so.1 for package: kdebase --> Processing Dependency: kde-settings-kdm for package: kdebase --> Processing Dependency: libkdnssd for package: kdelibs --> Processing Dependency: libsensors.so.3 for package: kdebase --> Processing Dependency: libHalf.so.4 for package: kdelibs --> Processing Dependency: redhat-artwork-kde >= 7.0.0-8 for package: kdebase --> Processing Dependency: libjasper.so.1 for package: kdelibs --> Processing Dependency: libIlmImf.so.4 for package: kdelibs --> Processing Dependency: kde-settings >= 3.5 for package: kdelibs --> Processing Dependency: libIlmImf.so.4 for package: kdebase --> Processing Dependency: kde-settings for package: kdebase --> Processing Dependency: htdig for package: kdebase --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package kde-settings-kdm.noarch 0:3.5-30.fc7 set to be updated ---> Package jasper.i386 0:1.900.1-2.fc7 set to be updated ---> Package htdig.i386 3:3.2.0b6-11.fc7 set to be updated ---> Package akode.i386 0:2.0.1-6.fc7 set to be updated ---> Package OpenEXR.i386 0:1.4.0a-3.fc6 set to be updated ---> Package lm_sensors.i386 0:2.10.3-2.fc7 set to be updated ---> Package akode-pulseaudio.i386 0:2.0.1-6.fc7 set to be updated ---> Package kdelibs.i386 6:3.5.7-9.fc7 set to be updated ---> Package kdebase.i386 6:3.5.7-0.1.fc7 set to be updated ---> Package kde-settings.noarch 0:3.5-30.fc7 set to be updated ---> Package redhat-artwork-kde.i386 0:7.0.0-11.fc7 set to be updated ---> Package kdnssd-avahi.i386 0:0.1.3-0.1.20060713svn.fc6 set to be updated --> Processing Dependency: libpulse.so.0 for package: akode-pulseaudio --> Processing Dependency: libfltk_gl.so.1.1 for package: OpenEXR --> Processing Dependency: libfltk.so.1.1 for package: OpenEXR --> Processing Dependency: libpulse-simple.so.0 for package: akode-pulseaudio --> Processing Dependency: xorg-x11-xdm for package: kde-settings-kdm --> Processing Dependency: libavahi-qt3.so.1 for package: kdnssd-avahi --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package kde-settings-kdm.noarch 0:3.5-30.fc7 set to be updated ---> Package avahi-qt3.i386 0:0.6.17-1.fc7 set to be updated ---> Package OpenEXR.i386 0:1.4.0a-3.fc6 set to be updated ---> Package fltk.i386 0:1.1.8-0.3.r5750.fc7 set to be updated ---> Package akode-pulseaudio.i386 0:2.0.1-6.fc7 set to be updated ---> Package pulseaudio-lib.i386 0:0.9.6-2.fc7 set to be updated ---> Package xorg-x11-xdm.i386 1:1.1.3-1.fc7 set to be updated ---> Package kdnssd-avahi.i386 0:0.1.3-0.1.20060713svn.fc6 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kdemultimedia i386 6:3.5.7-0.1.fc7 updates 4.9 M Installing for dependencies: OpenEXR i386 1.4.0a-3.fc6 fedora 416 k akode i386 2.0.1-6.fc7 fedora 100 k akode-pulseaudio i386 2.0.1-6.fc7 fedora 7.6 k avahi-qt3 i386 0.6.17-1.fc7 fedora 17 k fltk i386 1.1.8-0.3.r5750.fc7 fedora 424 k htdig i386 3:3.2.0b6-11.fc7 fedora 1.0 M jasper i386 1.900.1-2.fc7 updates 174 k kde-settings noarch 3.5-30.fc7 updates 13 k kde-settings-kdm noarch 3.5-30.fc7 updates 16 k kdebase i386 6:3.5.7-0.1.fc7 updates 28 M kdelibs i386 6:3.5.7-9.fc7 updates 18 M kdnssd-avahi i386 0.1.3-0.1.20060713svn.fc6 fedora 43 k lm_sensors i386 2.10.3-2.fc7 fedora 512 k pulseaudio-lib i386 0.9.6-2.fc7 updates 122 k redhat-artwork-kde i386 7.0.0-11.fc7 updates 559 k xorg-x11-xdm i386 1:1.1.3-1.fc7 fedora 131 k Transaction Summary ============================================================================= Install 17 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 55 M Rahul From skvidal at linux.duke.edu Mon Jul 30 21:28:10 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 30 Jul 2007 17:28:10 -0400 Subject: yum and library dependencies In-Reply-To: <46AE58F8.6030400@fedoraproject.org> References: <46AE58F8.6030400@fedoraproject.org> Message-ID: <1185830890.12224.37.camel@cutter> On Tue, 2007-07-31 at 03:02 +0530, Rahul Sundaram wrote: > Hi > > This seems odd... > > #yum install libartsmodules.so.0 > > > Loading "presto" plugin > Setting up Install Process > Parsing package install arguments > Setting up Presto > Reading Presto metadata in from local files > Resolving Dependencies > --> Running transaction check > ---> Package kdemultimedia.i386 6:3.5.7-0.1.fc7 set to be updated What in particular is odd about it? What is it you expected it to do? -sv From drago01 at gmail.com Mon Jul 30 21:38:51 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 30 Jul 2007 23:38:51 +0200 Subject: yum and library dependencies In-Reply-To: <46AE58F8.6030400@fedoraproject.org> References: <46AE58F8.6030400@fedoraproject.org> Message-ID: On 7/30/07, Rahul Sundaram wrote: > > Hi > > This seems odd... > > #yum install libartsmodules.so.0 > [...] > > ============================================================================= > Install 17 Package(s) > Update 0 Package(s) > Remove 0 Package(s) > > Total download size: 55 M it has nothing to do with yum... arts depends on kde stuff... -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Mon Jul 30 21:39:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 31 Jul 2007 03:09:11 +0530 Subject: yum and library dependencies In-Reply-To: <1185830890.12224.37.camel@cutter> References: <46AE58F8.6030400@fedoraproject.org> <1185830890.12224.37.camel@cutter> Message-ID: <46AE5A7F.1010405@fedoraproject.org> seth vidal wrote: > On Tue, 2007-07-31 at 03:02 +0530, Rahul Sundaram wrote: >> Hi >> >> This seems odd... >> >> #yum install libartsmodules.so.0 >> >> >> Loading "presto" plugin >> Setting up Install Process >> Parsing package install arguments >> Setting up Presto >> Reading Presto metadata in from local files >> Resolving Dependencies >> --> Running transaction check >> ---> Package kdemultimedia.i386 6:3.5.7-0.1.fc7 set to be updated > > > > > What in particular is odd about it? What is it you expected it to do? Just install the package that provides the library which in this case is probably arts and not pull in the whole bunch of KDE dependencies. Rahul From mschwendt.tmp0701.nospam at arcor.de Mon Jul 30 21:42:39 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 30 Jul 2007 23:42:39 +0200 Subject: Missing dependencies with glib2-devel? In-Reply-To: References: Message-ID: <20070730234239.9a90ba30.mschwendt.tmp0701.nospam@arcor.de> On Mon, 30 Jul 2007 13:14:11 -0700, Christopher Stone wrote: > Still broken here :( > > Am I the only one getting this error? I went ahead and filed a bug > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250166 > > > On 7/28/07, Christopher Stone wrote: > > Tried again this morning... still broken....anyone? > > > > On 7/27/07, Christopher Stone wrote: > > > I'm getting the following error when trying to build my package with mock on F7: > > > > > > $ /usr/sbin/mock-helper yum --installroot > > > /var/lib/mock/fedora-7-x86_64/root install 'glib2-devel' > > > Error: Missing Dependency: libgobject-2.0.so.0 is needed by package glib2-devel > > > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package glib2-devel > > > Error: Missing Dependency: libglib-2.0.so.0 is needed by package glib2-devel > > > Error: Missing Dependency: libgmodule-2.0.so.0 is needed by package glib2-devel > > > > > > My mock configs are unchanged from the default. Not a glib2 fault, since the quoted soname dependencies are 32-bit instead of 64-bit. Your mock/yum does not download the x86_64 packages. From skvidal at linux.duke.edu Mon Jul 30 21:35:58 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 30 Jul 2007 17:35:58 -0400 Subject: yum and library dependencies In-Reply-To: <46AE5A7F.1010405@fedoraproject.org> References: <46AE58F8.6030400@fedoraproject.org> <1185830890.12224.37.camel@cutter> <46AE5A7F.1010405@fedoraproject.org> Message-ID: <1185831358.12224.42.camel@cutter> On Tue, 2007-07-31 at 03:09 +0530, Rahul Sundaram wrote: > Just install the package that provides the library which in this case is > probably arts and not pull in the whole bunch of KDE dependencies. > # yum provides libartsmodules.so.0 kdemultimedia.i386 6:3.5.7-0.1.fc7 updates Matched from: libartsmodules.so.0 # yum deplist kdemultimedia.i386 Finding dependencies: package: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkdeinit_krec.so provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libcdda_paranoia.so.0 provider: cdparanoia-libs.i386 alpha9.8-27.2 dependency: libartsmodulesmixers.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkmidlib.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkparts.so.2 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libm.so.6 provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libakode.so.2 provider: akode.i386 2.0.1-6.fc7 dependency: libstdc++.so.6(GLIBCXX_3.4) provider: libstdc++.i386 4.1.2-12 dependency: libogg.so.0 provider: libogg.i386 2:1.1.3-3.fc7 dependency: libc.so.6(GLIBC_2.1.3) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: rtld(GNU_HASH) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsmodules.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsflow.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libc.so.6(GLIBC_2.4) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsflow_idl.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libtheora.so.0(libtheora.so.1.0) provider: libtheora.i386 1.0alpha7-2.fc7 dependency: libasound.so.2(ALSA_0.9) provider: alsa-lib.i386 1.0.14-0.4.rc3.fc7 dependency: libartsgui_idl.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libvorbisenc.so.2 provider: libvorbis.i386 1:1.1.2-2.fc7 dependency: /bin/sh provider: bash.i386 3.2-9.fc7 dependency: libvorbisfile.so.3 provider: libvorbis.i386 1:1.1.2-2.fc7 dependency: libkmedia2_idl.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libcdda_interface.so.0 provider: cdparanoia-libs.i386 alpha9.8-27.2 dependency: libc.so.6(GLIBC_2.3) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libxine.so.1 provider: xine-lib.i386 1.1.6-2.fc7 provider: xine-lib.i386 1.1.7-1.fc7 dependency: libartsmidi.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libXext.so.6 provider: libXext.i386 1.0.1-2.1 dependency: libkdeinit_kmix.so provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libgcc_s.so.1(GLIBC_2.0) provider: libgcc.i386 4.1.2-12 dependency: libartskde.so.1 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libX11.so.6 provider: libX11.i386 1.0.3-8.fc7 dependency: libkdefx.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libaudiocdplugins.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkcddb.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libstdc++.so.6 provider: libstdc++.i386 4.1.2-12 dependency: libkdecore.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libpthread.so.0 provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libm.so.6(GLIBC_2.0) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libvorbis.so.0 provider: libvorbis.i386 1:1.1.2-2.fc7 dependency: /usr/bin/env provider: coreutils.i386 6.9-2.fc7 provider: coreutils.i386 6.9-3.fc7 dependency: libkdeinit_kmixctrl.so provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsmidi_idl.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libc.so.6(GLIBC_2.2) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libc.so.6(GLIBC_2.3.2) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libtheora.so.0 provider: libtheora.i386 1.0alpha7-2.fc7 dependency: libasound.so.2 provider: alsa-lib.i386 1.0.14-0.4.rc3.fc7 dependency: libarts_audiofile.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libasound.so.2(ALSA_0.9.0rc4) provider: alsa-lib.i386 1.0.14-0.4.rc3.fc7 dependency: libartsmodulescommon.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libpthread.so.0(GLIBC_2.1) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libarts_akode.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia-extras.i386 6:3.5.6-5.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libDCOP.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libaudiofile.so.0 provider: audiofile.i386 1:0.2.6-6.fc7 dependency: libartsbuilder.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkmid.so.0 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libkio.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libgcc_s.so.1(GCC_3.0) provider: libgcc.i386 4.1.2-12 dependency: /sbin/ldconfig provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i686 2.6-4 provider: glibc.i386 2.6-4 dependency: libmcop.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libqt-mt.so.3 provider: qt.i386 1:3.3.8-4.fc7 dependency: libartscontrolapplet.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkdeui.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libc.so.6(GLIBC_2.1) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libc.so.6(GLIBC_2.0) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libpthread.so.0(GLIBC_2.0) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libpthread.so.0(GLIBC_2.3.2) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: /usr/bin/perl provider: perl.i386 4:5.8.8-18.fc7 dependency: libstdc++.so.6(CXXABI_1.3) provider: libstdc++.i386 4.1.2-12 dependency: libc.so.6 provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsc.so.0 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: kdebase >= 6:3.5.7 provider: kdebase.i386 6:3.5.7-0.1.fc7 dependency: libkutils.so.1 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libarts_xine.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia-extras.i386 6:3.5.6-5.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libgcc_s.so.1 provider: libgcc.i386 4.1.2-12 dependency: libtag.so.1 provider: taglib.i386 1.4-5.fc7 dependency: libartsmoduleseffects.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libc.so.6(GLIBC_2.3.4) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsgui.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsgui_kde.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsmodulessynth.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartscontrolsupport.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libqtmcop.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libsoundserver_idl.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 package: kdemultimedia.i386 6:3.5.6-7.fc7 dependency: libkdeinit_krec.so provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libcdda_paranoia.so.0 provider: cdparanoia-libs.i386 alpha9.8-27.2 dependency: libartsmodulesmixers.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkmidlib.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkparts.so.2 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libm.so.6 provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libakode.so.2 provider: akode.i386 2.0.1-6.fc7 dependency: libstdc++.so.6(GLIBCXX_3.4) provider: libstdc++.i386 4.1.2-12 dependency: libogg.so.0 provider: libogg.i386 2:1.1.3-3.fc7 dependency: libc.so.6(GLIBC_2.1.3) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: rtld(GNU_HASH) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsmodules.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsflow.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: kdebase >= 6:3.5.6 provider: kdebase.i386 6:3.5.6-12.fc7 provider: kdebase.i386 6:3.5.7-0.1.fc7 dependency: libc.so.6(GLIBC_2.4) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsflow_idl.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libtheora.so.0(libtheora.so.1.0) provider: libtheora.i386 1.0alpha7-2.fc7 dependency: libasound.so.2(ALSA_0.9) provider: alsa-lib.i386 1.0.14-0.4.rc3.fc7 dependency: libartsgui_idl.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libvorbisenc.so.2 provider: libvorbis.i386 1:1.1.2-2.fc7 dependency: /bin/sh provider: bash.i386 3.2-9.fc7 dependency: libvorbisfile.so.3 provider: libvorbis.i386 1:1.1.2-2.fc7 dependency: libkmedia2_idl.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libcdda_interface.so.0 provider: cdparanoia-libs.i386 alpha9.8-27.2 dependency: libc.so.6(GLIBC_2.3) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libxine.so.1 provider: xine-lib.i386 1.1.6-2.fc7 provider: xine-lib.i386 1.1.7-1.fc7 dependency: libartsmidi.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libXext.so.6 provider: libXext.i386 1.0.1-2.1 dependency: libgcc_s.so.1(GLIBC_2.0) provider: libgcc.i386 4.1.2-12 dependency: libartskde.so.1 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libX11.so.6 provider: libX11.i386 1.0.3-8.fc7 dependency: libkdefx.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libaudiocdplugins.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkcddb.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libstdc++.so.6 provider: libstdc++.i386 4.1.2-12 dependency: libkdecore.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libpthread.so.0 provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libm.so.6(GLIBC_2.0) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libvorbis.so.0 provider: libvorbis.i386 1:1.1.2-2.fc7 dependency: /usr/bin/env provider: coreutils.i386 6.9-2.fc7 provider: coreutils.i386 6.9-3.fc7 dependency: libkdeinit_kmixctrl.so provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsmidi_idl.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libc.so.6(GLIBC_2.2) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libc.so.6(GLIBC_2.3.2) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libtheora.so.0 provider: libtheora.i386 1.0alpha7-2.fc7 dependency: libasound.so.2 provider: alsa-lib.i386 1.0.14-0.4.rc3.fc7 dependency: libarts_audiofile.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libasound.so.2(ALSA_0.9.0rc4) provider: alsa-lib.i386 1.0.14-0.4.rc3.fc7 dependency: libartsmodulescommon.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libpthread.so.0(GLIBC_2.1) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libarts_akode.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia-extras.i386 6:3.5.6-5.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libDCOP.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libaudiofile.so.0 provider: audiofile.i386 1:0.2.6-6.fc7 dependency: libartsbuilder.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkmid.so.0 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libkio.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libgcc_s.so.1(GCC_3.0) provider: libgcc.i386 4.1.2-12 dependency: /sbin/ldconfig provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i686 2.6-4 provider: glibc.i386 2.6-4 dependency: libmcop.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libqt-mt.so.3 provider: qt.i386 1:3.3.8-4.fc7 dependency: libartscontrolapplet.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkdeui.so.4 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libc.so.6(GLIBC_2.1) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libc.so.6(GLIBC_2.0) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libpthread.so.0(GLIBC_2.0) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libpthread.so.0(GLIBC_2.3.2) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: /usr/bin/perl provider: perl.i386 4:5.8.8-18.fc7 dependency: libstdc++.so.6(CXXABI_1.3) provider: libstdc++.i386 4.1.2-12 dependency: libc.so.6 provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsc.so.0 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libkdeinit_kmix.so provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libkutils.so.1 provider: kdelibs.i386 6:3.5.6-9.fc7 provider: kdelibs.i386 6:3.5.7-9.fc7 dependency: libarts_xine.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia-extras.i386 6:3.5.6-5.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libgcc_s.so.1 provider: libgcc.i386 4.1.2-12 dependency: libtag.so.1 provider: taglib.i386 1.4-5.fc7 dependency: libartsmoduleseffects.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libc.so.6(GLIBC_2.3.4) provider: glibc.i386 2.6-3 provider: glibc.i686 2.6-3 provider: glibc.i386 2.6-4 provider: glibc.i686 2.6-4 dependency: libartsgui.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsgui_kde.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartsmodulessynth.so.0 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libartscontrolsupport.so.1 provider: kdemultimedia.i386 6:3.5.6-7.fc7 provider: kdemultimedia.i386 6:3.5.7-0.1.fc7 dependency: libqtmcop.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 dependency: libsoundserver_idl.so.1 provider: arts.i386 8:1.5.6-4.fc7 provider: arts.i386 8:1.5.7-1.fc7 There's the list of every dependency kdemultimedia has an what provides it. I think yum is doing exactly what it is supposed to do. -sv From chris.stone at gmail.com Tue Jul 31 00:25:54 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 30 Jul 2007 17:25:54 -0700 Subject: Missing dependencies with glib2-devel? In-Reply-To: <20070730234239.9a90ba30.mschwendt.tmp0701.nospam@arcor.de> References: <20070730234239.9a90ba30.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On 7/30/07, Michael Schwendt wrote: > On Mon, 30 Jul 2007 13:14:11 -0700, Christopher Stone wrote: > > > Still broken here :( > > > > Am I the only one getting this error? I went ahead and filed a bug > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250166 > > > > > > On 7/28/07, Christopher Stone wrote: > > > Tried again this morning... still broken....anyone? > > > > > > On 7/27/07, Christopher Stone wrote: > > > > I'm getting the following error when trying to build my package with mock on F7: > > > > > > > > $ /usr/sbin/mock-helper yum --installroot > > > > /var/lib/mock/fedora-7-x86_64/root install 'glib2-devel' > > > > Error: Missing Dependency: libgobject-2.0.so.0 is needed by package glib2-devel > > > > Error: Missing Dependency: libgthread-2.0.so.0 is needed by package glib2-devel > > > > Error: Missing Dependency: libglib-2.0.so.0 is needed by package glib2-devel > > > > Error: Missing Dependency: libgmodule-2.0.so.0 is needed by package glib2-devel > > > > > > > > My mock configs are unchanged from the default. > > Not a glib2 fault, since the quoted soname dependencies are 32-bit instead > of 64-bit. Your mock/yum does not download the x86_64 packages. okay, is this a problem with my mock configs? how should i proceed to fix this? I've already filed a bug which obviously now has the wrong component assigned to it. From rdieter at math.unl.edu Tue Jul 31 00:28:24 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 30 Jul 2007 19:28:24 -0500 Subject: yum and library dependencies References: <46AE58F8.6030400@fedoraproject.org> Message-ID: dragoran wrote: > On 7/30/07, Rahul Sundaram wrote: >> #yum install libartsmodules.so.0 ============================================================================= >> Install 17 Package(s) >> Update 0 Package(s) >> Remove 0 Package(s) >> >> Total download size: 55 M > it has nothing to do with yum... > arts depends on kde stuff... Um, no, arts doesn't depend on anything but (mostly) qt. As Seth pointed out, libartsmodules.so.0 is in kdemultimedia, which *does* have quite a few deps. -- Rex From debarshi.ray at gmail.com Tue Jul 31 01:42:00 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 31 Jul 2007 07:12:00 +0530 Subject: Updating microcode_ctl In-Reply-To: <1185769427.23029.137.camel@jcmlaptop> References: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> <20070729235634.f9d6a1ec.mschwendt.tmp0701.nospam@arcor.de> <1185769427.23029.137.camel@jcmlaptop> Message-ID: <3170f42f0707301842j15fb41a8j40057f8827e0b898@mail.gmail.com> > > Remove microcode_ctl-1.17-1.38.fc8.i386.rpm from your > > /var/cache/yum/development/packages directory and try again. I removed it from my cache, and disabled my local repository, but the issue persists. # yum --disablerepo=fedora-local --enablerepo=development install microcode_ctl ... ... (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:02 ftp://alviss.et.tudelft.nl/pub/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:02 ftp://ftp.proxad.net/mirrors/fedora.redhat.com/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:06 http://ftp.heanet.ie/pub/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:03 http://ftp.cica.es/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:03 http://ftp.upjs.sk/pub/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:07 http://ftp.tu-chemnitz.de/pub/linux/fedora-enchilada/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: [Errno -1] Package does not match intended download Trying other mirror. Cheers, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From buildsys at redhat.com Tue Jul 31 04:30:07 2007 From: buildsys at redhat.com (Build System) Date: Tue, 31 Jul 2007 00:30:07 -0400 Subject: rawhide report: 20070731 changes Message-ID: <200707310430.l6V4U75X015292@porkchop.devel.redhat.com> From andy at smile.org.ua Tue Jul 31 05:36:15 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Tue, 31 Jul 2007 08:36:15 +0300 Subject: gcc and PowerPC Message-ID: <20070731053615.GH3673@serv.smile.org.ua> Hello. Is it possible to rebuild at least gcc on ppc (NOT ppc64!) architecture? First of, I found the following lines in the specfile: %ifarch %{multilib_64_archs} sparc ppc # Ensure glibc{,-devel} is installed for both multilib arches BuildRequires: /lib/libc.so.6 /usr/lib/libc.so /lib64/libc.so.6 /usr/lib64/libc.so %endif Second, without above requirements the build process is crashed ... In file included from /usr/include/features.h:351, from /usr/include/stdio.h:28, from ../../gcc/tsystem.h:90, from ../../gcc/crtstuff.c:68: /usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory make[4]: *** [64/crtbegin.o] Error 1 make[3]: *** [extra64] Error 2 make[2]: *** [stmp-multilib] Error 2 make[1]: *** [stage1_build] Error 2 make: *** [profiledbootstrap] Error 2 P.S. Speech about current state of the Fedora 7. And I haven't access to any PowerPC 64bit to use for rebuild some stuff. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From tla at rasmil.dk Tue Jul 31 06:15:05 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 31 Jul 2007 08:15:05 +0200 Subject: Updating microcode_ctl In-Reply-To: <3170f42f0707301842j15fb41a8j40057f8827e0b898@mail.gmail.com> References: <3170f42f0707291151u480e35f5sece70c03a3511c4c@mail.gmail.com> <20070729235634.f9d6a1ec.mschwendt.tmp0701.nospam@arcor.de> <1185769427.23029.137.camel@jcmlaptop> <3170f42f0707301842j15fb41a8j40057f8827e0b898@mail.gmail.com> Message-ID: <46AED369.2010503@rasmil.dk> Debarshi 'Rishi' Ray wrote: >>> Remove microcode_ctl-1.17-1.38.fc8.i386.rpm from your >>> /var/cache/yum/development/packages directory and try again. >>> > > I removed it from my cache, and disabled my local repository, but the > issue persists. > > # yum --disablerepo=fedora-local --enablerepo=development install microcode_ctl > ... > ... > (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:02 > ftp://alviss.et.tudelft.nl/pub/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:02 > ftp://ftp.proxad.net/mirrors/fedora.redhat.com/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:06 > http://ftp.heanet.ie/pub/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:03 > http://ftp.cica.es/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:03 > http://ftp.upjs.sk/pub/fedora/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > (1/1): microcode_ctl-1.17 100% |=========================| 321 kB 00:07 > http://ftp.tu-chemnitz.de/pub/linux/fedora-enchilada/linux/development/i386/os/Fedora/microcode_ctl-1.17-1.38.fc8.i386.rpm: > [Errno -1] Package does not match intended download > Trying other mirror. > > Cheers, > Debarshi > Try: yum --enablerepo=updates-testing update yum (to get yum-3.2.2, there is some issue in with 'yum clean all' in yum-3.2.1) yum clean all yum --disablerepo=fedora-local --enablerepo=development install microcode_ctl Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Tue Jul 31 06:49:43 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 31 Jul 2007 01:49:43 -0500 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <16de708d0707302349t4f91a3ffq58a94becd9b655c3@mail.gmail.com> On 7/27/07, Panu Matilainen wrote: > > Hey all, > > I know I'm opening up Pandoras box here but what the heck, it's Friday and > I'm feeling slightly bored... Not sure if you've been keeping track, but I've attempted to build a list of ideas brought forth. A few quick points * I do not claim any authority over this list * I do no claim this list to be complete * there are a few suggestions I simply couldn't understand enough to transfer to the list * there are a few suggestions that were subjectively argued down and so are not on the list The wiki page is here: http://fedoraproject.org/wiki/Tools/RPMForward Feel free to edit, and I'll attempt to continue following this thread. Peace -- Fedora Core 6 and proud From mmaslano at redhat.com Tue Jul 31 06:53:03 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Tue, 31 Jul 2007 08:53:03 +0200 Subject: New tcl8.4.15 is released Message-ID: <46AEDC4F.8090709@redhat.com> New stable version of tcl-8.4.15 is available. Are maintainers of depended packages interested in upgrade on 8.4.15 or will be better to wait for stable tcl8.5? If no one interested in 8.4.15 version, I'll wait for stable 8.5. Marcela Maslanova From petersen at redhat.com Tue Jul 31 07:13:15 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 31 Jul 2007 17:13:15 +1000 Subject: New tcl8.4.15 is released In-Reply-To: <46AEDC4F.8090709@redhat.com> References: <46AEDC4F.8090709@redhat.com> Message-ID: <46AEE10B.30804@redhat.com> Marcela Maslanova ????????: > New stable version of tcl-8.4.15 is available. Are maintainers of > depended packages interested in upgrade on 8.4.15 or will be better to > wait for stable tcl8.5? > If no one interested in 8.4.15 version, I'll wait for stable 8.5. 8.5 will be a new major release, I think it is a good idea to keep tcl and tk up-to-date with the latest stable releases. Jens From pmatilai at redhat.com Tue Jul 31 07:32:13 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 31 Jul 2007 10:32:13 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <16de708d0707302349t4f91a3ffq58a94becd9b655c3@mail.gmail.com> References: <16de708d0707302349t4f91a3ffq58a94becd9b655c3@mail.gmail.com> Message-ID: On Tue, 31 Jul 2007, Arthur Pemberton wrote: > On 7/27/07, Panu Matilainen wrote: >> >> Hey all, >> >> I know I'm opening up Pandoras box here but what the heck, it's Friday and >> I'm feeling slightly bored... > > Not sure if you've been keeping track, but I've attempted to build a > list of ideas brought forth. A few quick points > * I do not claim any authority over this list > * I do no claim this list to be complete > * there are a few suggestions I simply couldn't understand enough to > transfer to the list > * there are a few suggestions that were subjectively argued down and > so are not on the list > > The wiki page is here: > http://fedoraproject.org/wiki/Tools/RPMForward > > Feel free to edit, and I'll attempt to continue following this thread. I intended to collect the items once the thread quietens, otherwise I'd just forget at least half the suggestions in a week :) Seems you did at least half the work for me already, thank you! I'll fill in details where necessary... - Panu - From pmatilai at redhat.com Tue Jul 31 07:41:57 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 31 Jul 2007 10:41:57 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <20070730142208.GJ16551@puariko.nirvana> References: <20070730142208.GJ16551@puariko.nirvana> Message-ID: On Mon, 30 Jul 2007, Axel Thimm wrote: > On Fri, Jul 27, 2007 at 03:40:40PM +0300, Panu Matilainen wrote: >> Not everybody is on rpm-maint list and we'd like to hear the wishes of >> (Fedora) developers/packagers too. So: what have you always wanted to do >> with rpm, but wasn't able to? Or the other way around: what you always >> wished rpm would do for you? What always annoyed you out of your mind? > > I'd like to be able to really setup chroot w/o any root > privilegdes. This already works at 99% using > fakeroot/fakechroot. There is some code in rpm that didn't swallow the > fake environment. It didn't look too difficult to fix. :) Got a reproducer case for this? (I'm just lazy and would like to avoid having to re-investigate your findings from scratch :) - Panu - From rc040203 at freenet.de Tue Jul 31 07:59:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 31 Jul 2007 09:59:22 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <1185868762.14763.154.camel@mccallum.corsepiu.local> On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: > Hey all, > > I know I'm opening up Pandoras box here but what the heck, it's Friday and > I'm feeling slightly bored... > Not everybody is on rpm-maint list and we'd like to hear the wishes of > (Fedora) developers/packagers too. So: what have you always wanted to do > with rpm, but wasn't able to? Or the other way around: what you always > wished rpm would do for you? What always annoyed you out of your mind? * A usable c/c++-API. The current one is scattered with anachronisms and historic artifacts. * Usable API docs. The current ones don't qualify as such. * Buildable rpm sources. I don't know if you meanwhile cleaned up the rpm.org repo, but last time I checked, it was not even close to be buildable. Ralf From pmatilai at redhat.com Tue Jul 31 08:01:31 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 31 Jul 2007 11:01:31 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <46AE4112.5070002@fedoraproject.org> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <20070730190039.GA17397@hurricane.linuxnetz.de> <46AE3745.2000607@fedoraproject.org> <20070730192452.GA20287@hurricane.linuxnetz.de> <46AE4112.5070002@fedoraproject.org> Message-ID: On Tue, 31 Jul 2007, Rahul Sundaram wrote: > Robert Scheck wrote: >> When looking back e.g. to soft dependencies, I remember that they just were >> refused for obivious reasons by individuals having the right position at >> Fedora (or Red Hat). You maybe treat this as flame, but this is what the >> feedback from that time looked like. > > Panu did mention that he was considering soft dependencies in rpm-maint list. > > https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000330.html > > Many people both Red Hat and non-Red Hat folks have been expressing some > concerns over soft dependencies. Various Red Hat folks have indeed been very much against soft dependencies, but if rpm.org is to have any "independent upstream" credibility like it's supposed to be, we got to remember RPM is not just for Red Hat. Whether rpm.org support soft dependencies and whether Fedora allows using them are two different questions. - Panu - From pmatilai at redhat.com Tue Jul 31 08:20:28 2007 From: pmatilai at redhat.com (Panu Matilainen) Date: Tue, 31 Jul 2007 11:20:28 +0300 (EEST) Subject: RPM roadmapping In-Reply-To: <1185868762.14763.154.camel@mccallum.corsepiu.local> References: <1185868762.14763.154.camel@mccallum.corsepiu.local> Message-ID: On Tue, 31 Jul 2007, Ralf Corsepius wrote: > On Fri, 2007-07-27 at 15:40 +0300, Panu Matilainen wrote: >> Hey all, >> >> I know I'm opening up Pandoras box here but what the heck, it's Friday and >> I'm feeling slightly bored... > >> Not everybody is on rpm-maint list and we'd like to hear the wishes of >> (Fedora) developers/packagers too. So: what have you always wanted to do >> with rpm, but wasn't able to? Or the other way around: what you always >> wished rpm would do for you? What always annoyed you out of your mind? > > * A usable c/c++-API. > The current one is scattered with anachronisms and historic artifacts. Heh, no s*** :) To quote Jeff (from memory so exact wording may differ): "There are (at least) three ways to open rpmdb, none of which take path as argument. RPM API is so baroque..." And yes, cleaning up the API is one of rpm.org roadmap items, has been from the start. > * Usable API docs. > The current ones don't qualify as such. Yup. And what's actually useful in the current ones gets lost in the noise of historic junk that's not supposed to be used etc... > * Buildable rpm sources. > I don't know if you meanwhile cleaned up the rpm.org repo, but last time > I checked, it was not even close to be buildable. A fair bit of work has gone to cleaning up the build, practically all of the compiler warnings (no less than ~650 of them when I started) from core rpm code are gone and the auto*stuff has seen a bit of work too: "make distcheck" now works and rpm itself can now be built with using %configure macro. Lots of work remains before the build can be called "clean" though. BTW Ralf, if you have any interest at all, your auto*tool expertise would be very, very much appreciated at rpm.org. - Panu - From jfontain at free.fr Tue Jul 31 08:51:01 2007 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 31 Jul 2007 10:51:01 +0200 Subject: New tcl8.4.15 is released In-Reply-To: <46AEE10B.30804@redhat.com> References: <46AEDC4F.8090709@redhat.com> <46AEE10B.30804@redhat.com> Message-ID: <46AEF7F5.3030901@free.fr> Jens Petersen wrote: > Marcela Maslanova ????????: >> New stable version of tcl-8.4.15 is available. Are maintainers of >> depended packages interested in upgrade on 8.4.15 or will be better >> to wait for stable tcl8.5? >> If no one interested in 8.4.15 version, I'll wait for stable 8.5. > > 8.5 will be a new major release, I think it is a good idea to keep > tcl and tk up-to-date with the latest stable releases. > > Jens > agreed. -- Jean-Luc Fontaine http://jfontain.free.fr/ From hughsient at gmail.com Tue Jul 31 08:51:33 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 09:51:33 +0100 Subject: Package Management Blows Goats (use cases) Message-ID: <1185871893.2652.5.camel@hughsie-laptop> (from my blog, apologies to anyone that's read this once already) Before ideal system requirements we should talk about use cases and system interactions. I think this is where update systems have gone wrong in the past, closely integrating with the existing package system rather than studying the complete ideal user interactions. Feel free to disagree and correct the interactions. Boot Time Security Update Toby logs into his desktop. A notification area icon with a critical icon appears in the top right and a libnotify popup tells him there are 3 three critical security updates. The libnotify popup has three buttons: ? Update now in the background ? Always do updates automatically ? Ignore for now Toby clicks the first button and the update completes in the background. When completed, after a few minutes, another libnotify popup appears telling Toby that the update was completed and after a few seconds the status icon disappears. Downloading an Unknown Application Suzanne wants to open a word file. She opens the software finder tool and types "office file" into the search box. A list of software appears, with OpenOffice being the top entry. She clicks the OpenOffice entry to highlight it, and clicks "Install now". Suzanne is not an administrator, but because she is locally logged in and the package is from the "fedora GPG signed repository" the root password is not required. A notification area icon appears with a downloading icon and the package manager is closed. When OpenOffice is installed, a libnotify popup tells Suzanne that the software has been downloaded and is now ready to use. Installing files automatically Simon wants to borrow the computer while Suzanne waits for OpenOffice to download. He uses fast-user switching to switch to a new login. He notices the same downloading icon in his session which indicates Suzannes' download is still in progress. He starts Pidgin which then crashes. The bug-buddy window appears which prompts him to install the debuginfo so a valid backtrace can be detected. He clicks yes, and a libnotify windows appears telling Simon that the request has been queued and that he will be notified when the debuginfo has been installed. When installed, the bug-buddy helper continues and submits a valid bug. Installing new features Suzanne switches back to her session and wants to add some clipart to the word file she has just opened. She clicks "Insert" and then "Clipart" and then a windows pops up telling her that clipart is not installed. She clicks "Install" and a progress bar appears and moves across as the clipart is downloaded and then installs. When finished, the dialog disappears and she chooses a picture of a cat. Comments? Richard. From pemboa at gmail.com Tue Jul 31 08:52:03 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 31 Jul 2007 03:52:03 -0500 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <16de708d0707310152pca8e2edo86e3a393a9c052fa@mail.gmail.com> I'm not sure if this really has to do with RPM, but I'll put it out subject to correction: Is there currently any way for the end user to get a summary of what the install scripts of an RPM actually do? For example, is there any way to know that the mysql-server package: * installs the mysql server, all necessary files, and helper applications * installs basic documentation * setups basic configuration * setups mysql server for manual startup * needs to have mysql admin password setup manually Nothing to wordy, but something that a user could choose to view post install (or maybe even pre) so they have a better idea of what's going on. -- Fedora Core 6 and proud From pemboa at gmail.com Tue Jul 31 08:54:30 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 31 Jul 2007 03:54:30 -0500 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185871893.2652.5.camel@hughsie-laptop> References: <1185871893.2652.5.camel@hughsie-laptop> Message-ID: <16de708d0707310154m76f4c817xd1b0c93ef841922c@mail.gmail.com> On 7/31/07, Richard Hughes wrote: > (from my blog, apologies to anyone that's read this once already) > > Before ideal system requirements we should talk about use cases and > system interactions. I think this is where update systems have gone > wrong in the past, closely integrating with the existing package system > rather than studying the complete ideal user interactions. > > Feel free to disagree and correct the interactions. > > Boot Time Security Update > > Toby logs into his desktop. A notification area icon with a critical > icon appears in the top right and a libnotify popup tells him there are > 3 three critical security updates. The libnotify popup has three > buttons: > ? Update now in the background > ? Always do updates automatically > ? Ignore for now > Toby clicks the first button and the update completes in the background. > When completed, after a few minutes, another libnotify popup appears > telling Toby that the update was completed and after a few seconds the > status icon disappears. > > Downloading an Unknown Application > > Suzanne wants to open a word file. She opens the software finder tool > and types "office file" into the search box. A list of software appears, > with OpenOffice being the top entry. She clicks the OpenOffice entry to > highlight it, and clicks "Install now". Suzanne is not an administrator, > but because she is locally logged in and the package is from the "fedora > GPG signed repository" the root password is not required. A notification > area icon appears with a downloading icon and the package manager is > closed. When OpenOffice is installed, a libnotify popup tells Suzanne > that the software has been downloaded and is now ready to use. > > Installing files automatically > > Simon wants to borrow the computer while Suzanne waits for OpenOffice to > download. He uses fast-user switching to switch to a new login. He > notices the same downloading icon in his session which indicates > Suzannes' download is still in progress. He starts Pidgin which then > crashes. The bug-buddy window appears which prompts him to install the > debuginfo so a valid backtrace can be detected. He clicks yes, and a > libnotify windows appears telling Simon that the request has been queued > and that he will be notified when the debuginfo has been installed. When > installed, the bug-buddy helper continues and submits a valid bug. > > Installing new features > > Suzanne switches back to her session and wants to add some clipart to > the word file she has just opened. She clicks "Insert" and then > "Clipart" and then a windows pops up telling her that clipart is not > installed. She clicks "Install" and a progress bar appears and moves > across as the clipart is downloaded and then installs. When finished, > the dialog disappears and she chooses a picture of a cat. > > Comments? > > Richard. The use cases seem logical and important to discuss, but why the inflamatory thread subect? -- Fedora Core 6 and proud From andy at warmcat.com Tue Jul 31 08:56:04 2007 From: andy at warmcat.com (Andy Green) Date: Tue, 31 Jul 2007 09:56:04 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185871893.2652.5.camel@hughsie-laptop> References: <1185871893.2652.5.camel@hughsie-laptop> Message-ID: <46AEF924.9040308@warmcat.com> > Comments? The goats are extremely happy about the existing situation. -Andy From hughsient at gmail.com Tue Jul 31 09:05:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 10:05:19 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <16de708d0707310154m76f4c817xd1b0c93ef841922c@mail.gmail.com> References: <1185871893.2652.5.camel@hughsie-laptop> <16de708d0707310154m76f4c817xd1b0c93ef841922c@mail.gmail.com> Message-ID: <1185872719.2652.9.camel@hughsie-laptop> On Tue, 2007-07-31 at 03:54 -0500, Arthur Pemberton wrote: > The use cases seem logical and important to discuss, but why the > inflamatory thread subect? Ohh, running joke, nothing meant to be insulting. I blame hadess with the project name "Unf*ck my keyboard" that inspired the goats. :-) Richard. From alan at redhat.com Tue Jul 31 09:18:13 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 31 Jul 2007 05:18:13 -0400 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185871893.2652.5.camel@hughsie-laptop> References: <1185871893.2652.5.camel@hughsie-laptop> Message-ID: <20070731091813.GA7676@devserv.devel.redhat.com> On Tue, Jul 31, 2007 at 09:51:33AM +0100, Richard Hughes wrote: > Toby logs into his desktop. A notification area icon with a critical > icon appears in the top right and a libnotify popup tells him there are > 3 three critical security updates. The libnotify popup has three Who is Toby, is he authorised to install updates ? One big problem throughout the Fedora and RHEL code is that nobody has been willing to actually distinguish between install types at install time. That is what causes the limits on automounting file systems, it is what stops us doing Ubuntu type sudo and it is what breaks this. We need to know if the system is - User managed - Centrally managed - Physical access implies control (typical home PC) and ask that in a sane fashion User managed means Toby gets icons, su is the normal path to root etc Centrally managed means Toby gets no say, ... Physical access implies control means less restrictive automounting of USB and other devices, implicit management and control by console user etc > Downloading an Unknown Application > > Suzanne wants to open a word file. She opens the software finder tool > and types "office file" into the search box. A list of software appears, You've got a high opinion of end users. Your 'Susan' user may well know what an office file is but Bob in packing probably doesn't. I'd argue the model is Click file No application is installed which can handle: Microsoft Worm Would you like me to search for one to install Two applications can handle this document OpenOffice.org (recommended) Abiword .. > highlight it, and clicks "Install now". Suzanne is not an administrator, > but because she is locally logged in and the package is from the "fedora > GPG signed repository" the root password is not required. A notification You're security model is wrong. Badly wrong actually. You've elevated every single "system with obscure package X can be compromised" to "any system the user has access to can be compromised" - which takes us back to 'who is toby'. If Toby is the owner/sole real user of a home PC system then its probably a non-issue. If the system is a corporate desktop then its bad news. > Simon wants to borrow the computer while Suzanne waits for OpenOffice to > download. He uses fast-user switching to switch to a new login. He Needs revoke which is getting very slow progress in the kernel side alas but eventually may get there. I have it on my kernel summit big stick including some interesting (non public) demonstrations of why we need it. > Suzannes' download is still in progress. He starts Pidgin which then > crashes. The bug-buddy window appears which prompts him to install the > debuginfo so a valid backtrace can be detected. He clicks yes, and a > libnotify windows appears telling Simon that the request has been queued > and that he will be notified when the debuginfo has been installed. When > installed, the bug-buddy helper continues and submits a valid bug. Yep > Suzanne switches back to her session and wants to add some clipart to > the word file she has just opened. She clicks "Insert" and then > "Clipart" and then a windows pops up telling her that clipart is not > installed. She clicks "Install" and a progress bar appears and moves > across as the clipart is downloaded and then installs. When finished, > the dialog disappears and she chooses a picture of a cat. > > Comments? Very much the right model but not pushed far enough. I'd also expect to be able to see a variety of free web clip art sources offered and usable automatically, along with a youtube or similar video source of tutorials and examples. Alan From emmanuel.seyman at club-internet.fr Tue Jul 31 09:17:06 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 31 Jul 2007 11:17:06 +0200 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185871893.2652.5.camel@hughsie-laptop> References: <1185871893.2652.5.camel@hughsie-laptop> Message-ID: <20070731091706.GA25917@orient.maison.lan> * Richard Hughes [31/07/2007 11:07] : > > Suzanne is not an administrator, > but because she is locally logged in and the package is from the "fedora > GPG signed repository" the root password is not required. I can see how allowing the members of the wheel group to install "trusted" software would be a good thing but extending this to all locally logged-in users sounds like overkill, IMHO. Emmanuel From drago01 at gmail.com Tue Jul 31 09:25:40 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 31 Jul 2007 11:25:40 +0200 Subject: RPM roadmapping In-Reply-To: References: Message-ID: <46AF0014.2010804@gmail.com> Panu Matilainen wrote: > > > The more specific you can be, the better - "make it not suck" isn't > productive. what about not requiring the Buildrequires to be installed when doing rpmbuild -bs ? From hughsient at gmail.com Tue Jul 31 09:27:34 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 10:27:34 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <20070731091706.GA25917@orient.maison.lan> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091706.GA25917@orient.maison.lan> Message-ID: <1185874054.2652.16.camel@hughsie-laptop> On Tue, 2007-07-31 at 11:17 +0200, Emmanuel Seyman wrote: > I can see how allowing the members of the wheel group to install > "trusted" software would be a good thing but extending this to all > locally logged-in users sounds like overkill, IMHO. Sure, this is just policy. The admin can trivially lock down who can do what using a framework such as PolicyKit. Richard. From pnasrat at redhat.com Tue Jul 31 09:32:25 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 31 Jul 2007 10:32:25 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185871893.2652.5.camel@hughsie-laptop> References: <1185871893.2652.5.camel@hughsie-laptop> Message-ID: <1185874345.9310.114.camel@enki.eridu> On Tue, 2007-07-31 at 09:51 +0100, Richard Hughes wrote: > (from my blog, apologies to anyone that's read this once already) Have you read - http://klik.atekon.de/presentation/klik.html it's focussed on the users care about applications and highlights some of the issues with existing pkg/distro universe setup. > Before ideal system requirements we should talk about use cases and > system interactions. OK who do we care about - your subject implies all package management, you don't really cover large systems deployment, your examples are direct user not centrally administered based. > I think this is where update systems have gone > wrong in the past, closely integrating with the existing package > system > rather than studying the complete ideal user interactions. So who are your users based on your cases I'm guessing: Suzanne - non administrator casual user Simon - a more advanced user sharing a machine with Suzanne Toby - a single user/admin However this is really not distinct and clear - please expand. > Boot Time Security Update > > Toby logs into his desktop. A notification area icon with a critical > icon appears in the top right and a libnotify popup tells him there are > 3 three critical security updates. The libnotify popup has three > buttons: > ? Update now in the background > ? Always do updates automatically > ? Ignore for now > Toby clicks the first button and the update completes in the background. > When completed, after a few minutes, another libnotify popup appears > telling Toby that the update was completed and after a few seconds the > status icon disappears. This seems a reasonable one not sure if it's boot time or "scheduled check". Update automatically - you need to be able to not do this if you're using GPRS or some low bandwidth connectivity on the road. Maybe we need a traveller case. > Downloading an Unknown Application > > Suzanne wants to open a word file. She opens the software finder tool > and types "office file" into the search box. A list of software appears, > with OpenOffice being the top entry. She clicks the OpenOffice entry to > highlight it, and clicks "Install now". Suzanne is not an administrator, > but because she is locally logged in and the package is from the "fedora > GPG signed repository" the root password is not required. A notification > area icon appears with a downloading icon and the package manager is > closed. When OpenOffice is installed, a libnotify popup tells Suzanne > that the software has been downloaded and is now ready to use. The search requires much better metadata than we probably have in description/summary right now. Can we use mime/file(1) info to help the search. How do we define trust, how do users add trusted sources - or can only administrators do that. > Installing new features > > Suzanne switches back to her session and wants to add some clipart to > the word file she has just opened. She clicks "Insert" and then > "Clipart" and then a windows pops up telling her that clipart is not > installed. She clicks "Install" and a progress bar appears and moves > across as the clipart is downloaded and then installs. When finished, > the dialog disappears and she chooses a picture of a cat. Trying out a new version in parallel: Simon wants to test with the new beta version of pidgin - although he knows jabber support is broken, Suzanne uses pidgin with jabber to talk to her friends daily. Simon downloads the beta package installs, he uses the beta version, whilst the stable version is still available to Suzanne. Paul From hughsient at gmail.com Tue Jul 31 09:36:41 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 10:36:41 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <20070731091813.GA7676@devserv.devel.redhat.com> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091813.GA7676@devserv.devel.redhat.com> Message-ID: <1185874601.2652.27.camel@hughsie-laptop> On Tue, 2007-07-31 at 05:18 -0400, Alan Cox wrote: > On Tue, Jul 31, 2007 at 09:51:33AM +0100, Richard Hughes wrote: > > Toby logs into his desktop. A notification area icon with a critical > > icon appears in the top right and a libnotify popup tells him there are > > 3 three critical security updates. The libnotify popup has three > > Who is Toby, is he authorised to install updates ? I figured security updates could be installed by anyone. > One big problem throughout the Fedora and RHEL code is that nobody has > been willing to actually distinguish between install types at install > time. That is what causes the limits on automounting file systems, it is > what stops us doing Ubuntu type sudo and it is what breaks this. > > We need to know if the system is > - User managed > - Centrally managed > - Physical access implies control (typical home PC) Sure. Using PolicyKit we can make this type of distinction, although I admit we'll probably need something profile based to avoid having 40 billion checkboxes for each policy decision. > and ask that in a sane fashion Sure. > User managed means Toby gets icons, su is the normal path to root etc > Centrally managed means Toby gets no say, ... > Physical access implies control means less restrictive automounting of > USB and other devices, implicit management and control by console user etc So we define the "management state" of the machine - either locked down restricted priv library type machine, or normal workstation. > > Downloading an Unknown Application > > > > Suzanne wants to open a word file. She opens the software finder tool > > and types "office file" into the search box. A list of software appears, > > You've got a high opinion of end users. Your 'Susan' user may well know > what an office file is but Bob in packing probably doesn't. Well, Bob in packaging probably shouldn't be using the computer and installing software. Even my parents who are complete non-geeks know they need a spreadsheet program to do "tables and stuff". > I'd argue the model is > > Click file > No application is installed which can handle: Microsoft Worm > Would you like me to search for one to install > Two applications can handle this document > > OpenOffice.org (recommended) > Abiword Yes, this makes a lot of sense in my book. > > highlight it, and clicks "Install now". Suzanne is not an administrator, > > but because she is locally logged in and the package is from the "fedora > > GPG signed repository" the root password is not required. A notification > > You're security model is wrong. Badly wrong actually. You've > elevated every single "system with obscure package X can be compromised" > to "any system the user has access to can be compromised" - which takes us > back to 'who is toby'. If Toby is the owner/sole real user of a home > PC system then its probably a non-issue. If the system is a corporate > desktop then its bad news. Sure, this stuff has to be easily configurable by the admin else we are breaking lots of security models. Maybe a better policy would be "any LDAP logged in user is allowed to install software from acme-corporate-rpms but not from fedora" - but you get the idea. > > Simon wants to borrow the computer while Suzanne waits for OpenOffice to > > download. He uses fast-user switching to switch to a new login. He > > Needs revoke which is getting very slow progress in the kernel side > alas but eventually may get there. I have it on my kernel summit big stick > including some interesting (non public) demonstrations of why we need it. Yes. Take a stapler gun and start firing it into the air until it's merged. Seriously tho, even without revoke we can still do 90% of the fast user switch stuff. > > Suzanne switches back to her session and wants to add some clipart to > > the word file she has just opened. She clicks "Insert" and then > > "Clipart" and then a windows pops up telling her that clipart is not > > installed. She clicks "Install" and a progress bar appears and moves > > across as the clipart is downloaded and then installs. When finished, > > the dialog disappears and she chooses a picture of a cat. > > > > Comments? > > Very much the right model but not pushed far enough. I'd also expect to be > able to see a variety of free web clip art sources offered and usable > automatically, along with a youtube or similar video source of tutorials > and examples. Sure, but feature creep :-) Thanks for your feedback, appreciated. Richard. From guichaz at yahoo.fr Tue Jul 31 09:38:48 2007 From: guichaz at yahoo.fr (Guillaume Chazarain) Date: Tue, 31 Jul 2007 11:38:48 +0200 Subject: Making bugzilla indexable Message-ID: <46AF0328.1080909@yahoo.fr> Hi, First, sorry if this is the wrong list for this post as the topic is broader than just Fedora but I could not find a more relevant list in http://www.redhat.com/mailman/listinfo. Now, for the actual message. The redhat bugzilla is an invaluable source of information but it lives in the invisible web as per http://bugzilla.redhat.com/robots.txt. Keeping web spiders out of http://bugzilla.redhat.com seems legitimate. But, as bugzilla sends e-mails each time some content is added, why not sending all of these mails to a mailing list and making the archives of this mailing list public and indexable. Or maybe it is already possible to search bugzilla reports using Google? IMHO, this would simplify Fedora troubleshooting a lot. Thanks for your time. -- Guillaume From mschwendt.tmp0701.nospam at arcor.de Tue Jul 31 09:41:45 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 31 Jul 2007 11:41:45 +0200 Subject: RPM roadmapping In-Reply-To: <46AF0014.2010804@gmail.com> References: <46AF0014.2010804@gmail.com> Message-ID: <20070731114145.e4ba4540.mschwendt.tmp0701.nospam@arcor.de> On Tue, 31 Jul 2007 11:25:40 +0200, dragoran wrote: > Panu Matilainen wrote: > > > > > > The more specific you can be, the better - "make it not suck" isn't > > productive. > what about not requiring the Buildrequires to be installed when doing > rpmbuild -bs ? rpmbuild --nodeps -bs is available already From hughsient at gmail.com Tue Jul 31 09:42:32 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 10:42:32 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185874345.9310.114.camel@enki.eridu> References: <1185871893.2652.5.camel@hughsie-laptop> <1185874345.9310.114.camel@enki.eridu> Message-ID: <1185874952.2652.33.camel@hughsie-laptop> On Tue, 2007-07-31 at 10:32 +0100, Paul Nasrat wrote: > On Tue, 2007-07-31 at 09:51 +0100, Richard Hughes wrote: > > (from my blog, apologies to anyone that's read this once already) > > Have you read - http://klik.atekon.de/presentation/klik.html it's > focussed on the users care about applications and highlights some of the > issues with existing pkg/distro universe setup. Thanks for that, I'll review in detail in a few minutes. > > Before ideal system requirements we should talk about use cases and > > system interactions. > > OK who do we care about - your subject implies all package management, > you don't really cover large systems deployment, your examples are > direct user not centrally administered based. Well, they are the way I've seen Linux being used 1st hand. We need some other use cases for the corporate desktop, and I'm open for adding more :-) > > I think this is where update systems have gone > > wrong in the past, closely integrating with the existing package > > system > > rather than studying the complete ideal user interactions. > > So who are your users based on your cases I'm guessing: > > Suzanne - non administrator casual user > Simon - a more advanced user sharing a machine with Suzanne > Toby - a single user/admin > However this is really not distinct and clear - please expand. Sure, will do. > > Boot Time Security Update > > > > Toby logs into his desktop. A notification area icon with a critical > > icon appears in the top right and a libnotify popup tells him there are > > 3 three critical security updates. The libnotify popup has three > > buttons: > > ? Update now in the background > > ? Always do updates automatically > > ? Ignore for now > > Toby clicks the first button and the update completes in the background. > > When completed, after a few minutes, another libnotify popup appears > > telling Toby that the update was completed and after a few seconds the > > status icon disappears. > > This seems a reasonable one not sure if it's boot time or "scheduled > check". > > Update automatically - you need to be able to not do this if you're > using GPRS or some low bandwidth connectivity on the road. Maybe we need > a traveller case. Sure, this is why I didn't just suggest automatically installing no matter what. You don't want to do a kernel update over a 1$/Mb GPRS link. > The search requires much better metadata than we probably have in > description/summary right now. Can we use mime/file(1) info to help the > search. Yes, we'll have to look at other information sources. > How do we define trust, how do users add trusted sources - or can only > administrators do that. I'm open for ideas. > > Installing new features > > > > Suzanne switches back to her session and wants to add some clipart to > > the word file she has just opened. She clicks "Insert" and then > > "Clipart" and then a windows pops up telling her that clipart is not > > installed. She clicks "Install" and a progress bar appears and moves > > across as the clipart is downloaded and then installs. When finished, > > the dialog disappears and she chooses a picture of a cat. > > Trying out a new version in parallel: I'm not sure that's a good idea. As soon as you start talking about per-user or per-group installs then things get very complicated indeed. Richard. From opensource at till.name Tue Jul 31 09:48:38 2007 From: opensource at till.name (Till Maas) Date: Tue, 31 Jul 2007 11:48:38 +0200 Subject: RPM roadmapping In-Reply-To: <16de708d0707310152pca8e2edo86e3a393a9c052fa@mail.gmail.com> References: <16de708d0707310152pca8e2edo86e3a393a9c052fa@mail.gmail.com> Message-ID: <200707311148.51189.opensource@till.name> On Tuesday 31 July 2007 10:52:03 Arthur Pemberton wrote: > Is there currently any way for the end user to get a summary of what > the install scripts of an RPM actually do? > Nothing to wordy, but something that a user could choose to view post > install (or maybe even pre) so they have a better idea of what's going > on. Is this what you want? Post Install: rpm --scripts -q mysql-server Pre Install: rpm --scripts -qp mysql-server*rpm Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From nicu_fedora at nicubunu.ro Tue Jul 31 09:56:20 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 31 Jul 2007 12:56:20 +0300 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185874345.9310.114.camel@enki.eridu> References: <1185871893.2652.5.camel@hughsie-laptop> <1185874345.9310.114.camel@enki.eridu> Message-ID: <46AF0744.4070304@nicubunu.ro> Paul Nasrat wrote: > On Tue, 2007-07-31 at 09:51 +0100, Richard Hughes wrote: >> >> Suzanne wants to open a word file. She opens the software finder tool >> and types "office file" into the search box. A list of software appears, >> with OpenOffice being the top entry. She clicks the OpenOffice entry to >> highlight it, and clicks "Install now". Suzanne is not an administrator, >> but because she is locally logged in and the package is from the "fedora >> GPG signed repository" the root password is not required. A notification >> area icon appears with a downloading icon and the package manager is >> closed. When OpenOffice is installed, a libnotify popup tells Suzanne >> that the software has been downloaded and is now ready to use. > > The search requires much better metadata than we probably have in > description/summary right now. Can we use mime/file(1) info to help the > search. How about coupling this search and metadata with the application database provided by Mugshot http://mugshot.org/applications ? Metadata for each application [1] can be easily edited [2], wiki-style, it does not include MIME types yet, but I don't see why it can be extended. [1] - http://mugshot.org/application?id=openoffice.org-writer [2] - http://mugshot.org/application-edit?id=openoffice.org-writer -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From aph at redhat.com Tue Jul 31 10:10:43 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Jul 2007 11:10:43 +0100 Subject: gcc and PowerPC In-Reply-To: <20070731053615.GH3673@serv.smile.org.ua> References: <20070731053615.GH3673@serv.smile.org.ua> Message-ID: <18095.2723.149193.244852@zebedee.pink> Andy Shevchenko writes: > Hello. > > Is it possible to rebuild at least gcc on ppc (NOT ppc64!) architecture? > First of, I found the following lines in the specfile: > > %ifarch %{multilib_64_archs} sparc ppc > # Ensure glibc{,-devel} is installed for both multilib arches > BuildRequires: /lib/libc.so.6 /usr/lib/libc.so /lib64/libc.so.6 > /usr/lib64/libc.so > %endif Right, so it's buildong for both multilibs, and therefore it needs glibc-devel packages for both multilibs to build. No mystery there. > Second, without above requirements the build process is crashed > > ... > In file included from /usr/include/features.h:351, > from /usr/include/stdio.h:28, > from ../../gcc/tsystem.h:90, > from ../../gcc/crtstuff.c:68: > /usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: No such file or directory > make[4]: *** [64/crtbegin.o] Error 1 > make[3]: *** [extra64] Error 2 > make[2]: *** [stmp-multilib] Error 2 > make[1]: *** [stage1_build] Error 2 > make: *** [profiledbootstrap] Error 2 Well, yeah. The 64-bit libc-devel is missing, so the multilib doesn't build. > P.S. Speech about current state of the Fedora 7. Sorry? > And I haven't access to any PowerPC 64bit to use for rebuild some > stuff. Configure gcc with --disable-multilib. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From drago01 at gmail.com Tue Jul 31 10:42:41 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 31 Jul 2007 12:42:41 +0200 Subject: RPM roadmapping In-Reply-To: <20070731114145.e4ba4540.mschwendt.tmp0701.nospam@arcor.de> References: <46AF0014.2010804@gmail.com> <20070731114145.e4ba4540.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <46AF1221.9000706@gmail.com> Michael Schwendt wrote: > On Tue, 31 Jul 2007 11:25:40 +0200, dragoran wrote: > > >> Panu Matilainen wrote: >> >>> >>> >>> The more specific you can be, the better - "make it not suck" isn't >>> productive. >>> >> what about not requiring the Buildrequires to be installed when doing >> rpmbuild -bs ? >> > > rpmbuild --nodeps -bs is available already > > ok, thx didn't know that rpmbuild accepts --nodeps From dwmw2 at infradead.org Tue Jul 31 10:55:50 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 31 Jul 2007 11:55:50 +0100 Subject: RPM roadmapping In-Reply-To: References: <1185545286.14697.581.camel@pmac.infradead.org> Message-ID: <1185879350.3083.85.camel@pmac.infradead.org> On Mon, 2007-07-30 at 12:49 +0100, Jeremy Sanders wrote: > David Woodhouse wrote: > > > A few of the bugs on > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > > are assigned to to RPM. The most important one is probably the lack of > > arch-specific Requires: and BuildRequires: (#235755). > > > > I don't think we'll manage #235757 in time for Fedora 8 but it would be > > good to get it done (and the packages updated accordingly) for Fedora 9. > > (Note that comments 3-19 are about the short-term hack we did for F7, > > not the real subject of the bug). > > > > Thoughts on #235758 would be appreciated. > > Obsoletes aren't arch specific too, which is a real pain: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246598 That could be considered to be just another manifestation of bug 235756. The problem is not necessarily the fact that the Obsoletes: wasn't arch-specific. It's that yum went from 'please install digikam to get rid of digikamimageplugins' to 'hey, let's install both the sensible x86_64 version _and_ the unwanted i386 version too'. -- dwmw2 From email.ahmedkamal at googlemail.com Tue Jul 31 11:13:07 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 31 Jul 2007 14:13:07 +0300 Subject: SB600 ATI controller, USB TakeOver failed Message-ID: <3da3b5b40707310413n44c43776w8411c1093a0c80ff@mail.gmail.com> Hi list, I have the unfortunate luck of wanting to install Linux on a Dell optiplex 320. This machine seems to be as anti-linux as they come! Problems faced: 1- Sata disk not recognized WorkAround: pass pci=nomsi, or all-generic-ide (depending on newer/older kernel version) 2- Grub does not boot!! WorkAround: Use lilo 3- Machine doesn't have PS2, only USB keyboard/mouse. USB does not work, the following errors are generated ohci_hcd 0000:00:13.2: OHCI Host Controller ohci_hcd 0000:00:13.2: USB HC TakeOver failed! ohci_hcd 0000:00:13.2: can't reset ohci_hcd 0000:00:13.2: init 0000:00:13.2 fail, -1 ohci_hcd: probe of 0000:00:13.2 failed with error -1 I need to install RHEL4 (much better), or an older Fedora (4?). This is because of the CAD software that will run on this machine. I have not found any work-arounds for such problem (only one that uses ohci-hcd parameter no_handshake, which is not understood by 2.6.9 kernel). If anyone is aware of any un-official kernel patch that solves that issue, kindly let me know. regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.sylvan at gmail.com Tue Jul 31 11:31:56 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 31 Jul 2007 19:31:56 +0800 Subject: LiveCD wiping root partition? Message-ID: I just did a clean install of Fedora 7 from the live CD onto my laptop, which previously had a Fedora install upgraded from one of the F7 test releases, partitioned as suggested by anaconda (LVM, one swap partition, everything else under '/') When reinstalling, I kept the partition layout and specifically told Anaconda *not* to reformat / (having booted in rescue mode beforehand, and removing everything but /home). Anaconda gave a warning that the leftover files might interfere with the installed system, which gave the impression that those files won't actually be removed during installation. As it turns out, however, the old contents are completely gone (I'm trying out different recovery tools now to see if I could rescue some of the data). It's as if the live CD simply used dd to transfer the install image to the hard drive (in which case, how does it actually handle different partition layouts, e.g. /usr, /var, /home on separate partitions -- does it just move the files afterwards?) As it stands it seems that the Live CD is a very dangerous tool, at least as long as 1) the default behaviour of Anaconda is to put everything under / 2) it does not carry more warnings about what it will do to the / partition during installation Could someone let us know how the live CD actually performs its work? It would aid tremendously in the data recovery part. Would 'dd'-ing the entire partition to an external drive, and mounting it on a Windows computer (most recovery tools are unfortunately for that platform) preserve all the data required? I'm assuming that the new installation overwrote the same parts of the disk that was used to hold the OS in the previous install. Thanks, -- Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffesti at redhat.com Tue Jul 31 11:58:04 2007 From: ffesti at redhat.com (Florian Festi) Date: Tue, 31 Jul 2007 13:58:04 +0200 Subject: RPM roadmapping In-Reply-To: <46AE4112.5070002@fedoraproject.org> References: <1185650287.2409.117.camel@cutter> <16de708d0707281414v32a771a7tec0f7eaf2c88b340@mail.gmail.com> <1185803477.11828.36.camel@gilboa-work-dev.localdomain> <20070730190039.GA17397@hurricane.linuxnetz.de> <46AE3745.2000607@fedoraproject.org> <20070730192452.GA20287@hurricane.linuxnetz.de> <46AE4112.5070002@fedoraproject.org> Message-ID: <46AF23CC.8070808@redhat.com> Rahul Sundaram wrote: > Robert Scheck wrote: >> Hello Rahul, >> >> On Tue, 31 Jul 2007, Rahul Sundaram wrote: >>> Pyrpm is described as "PyRPM is an experimental project to look at >>> rpm package management". It is a prototyping tool. Not a >>> implementation meant to be used by users currently unlike Yum (which >>> I think is what you are referring to as pyyum). >> >> okay, you did never use PyRPM. > > I don't know why you want to assume that. My use is irrelvant to your > question on whether pyrpm duplicates yum and RPM. Answer: No. it > doesn't. pyrpm is clearly described as a experimental prototype in it's > homepage at http://www.jur-linux.org/pyrpm/. That's the first hit in > google btw. Your use is relevant when it comes to the question if your opinion is in any way better founded than that of google. > It is called yum and not pyyum which would a redundant name since the > only existing implementation of Yum is in python. If you are a Fedora > user, the fact the name is yum should have been obvious. The PyRPM suite includes pyrpm - a rpm replacement in pure Python, pyrpmyum - a yum reimplementation build on top of the pyrpm libs, pyrpmkickstart - a tool for doing kickstart installations from within a running system into hard drives or disk images. There are also a number of test scripts for checking rpm based distributions for various problems. The whole software suite is written from scratch in pure Python. This was done to be independent from upstream projects (rpm, yum) and to be a rapid prototyping testbed for experimental and/or new features/modifications. It also provides a basis for various large scale tests that were either too complicated or simply not doable with the existing tools. It was (and to some extend still is) experimental in the sense of 1. Developing/using advanced techniques not (yet) found in rpm and yum. This includes better multilib handling, auto eraser, better depsolving, high performance and low memory foot print. I am just now porting the first lessons learned there to yum. 2. Not having a large enough user base to be considered as stable. Due to a large number of tests we have done with that codebase we're now quite confident that we have at least reached a similar stability as the current version of yum. I hope that makes things more clear. Florian From buc at odusz.so-cdu.ru Tue Jul 31 12:44:53 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 31 Jul 2007 16:44:53 +0400 Subject: What TV teletext viewer to choose? Message-ID: <46AF2EC5.7040604@odu.neva.ru> I'm thinking about the adding of some teletext viewer for Fedora (at least for Gnome). Most TV cards support teletext capturing, and this feature is demanded by users. Besides some very old implementations (gnometv, alevt), which seem already stopped, I've found two possible variants: - Enable "mtt" in the "xawtv" package (recently added to Fedora). But enabling of "mtt" will require Motif... - Package Zapping TV viewer (http://zapping.sf.net), which has an advanced teletext viewer (Zapzilla). But Zapping should be stripped first from any mpeg-patented-etc. stuff... Any comments? What is better? Or maybe something else? Regards, http://www.fedoraproject.org/wiki/DmitryButskoy From Theodore.Papadopoulo at sophia.inria.fr Tue Jul 31 14:50:31 2007 From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo) Date: Tue, 31 Jul 2007 16:50:31 +0200 Subject: RPM roadmapping In-Reply-To: References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> <46ADB495.60206@leemhuis.info> <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> <46ADCBFC.2070706@sophia.inria.fr> Message-ID: <46AF4C37.9080100@sophia.inria.fr> Ian Burrell wrote: > Having the clean config files make it easier to manage them with > version control. They can be used for doing a three-way merge or for > making the vendor branch. > > Instead of having rpm do the copy, it might make sense to have a hook. > The default hook would copy the files but somebody could have it call > a version control system. > Considering config files and orthogonally to the version control proposal, a feature I would like to have is a way for a rpm package to override some config files. I'm not sure if it is at all feasible or even whether there is not a tricky way to do it currently. The use case is the "customisation" using rpms of a group of machine for which it is needed to modify some config files belonging to some other rpm. A maybe not too good example would be to modify /etc/yum.repos.d/fedora* to add eg some local mirror. Right now, this is impossible as those files belong to the redhat-release package (as of FC5), so pushing such a modification requires creating a new version of this package, which is definitely not clean. The attribute %config(noreplace) is of no use in such a case. The idea would be something like this. Assume that package A.rpm owns a config file A.conf. Extend rpm so that it is possible to create a special package B.rpm (modifiers rpms or overriders rpms ??) that just contains modifiers or overriders of A.conf. A.conf remains owned by A.rpm. B.rpm obviously should depend on A.rpm. - If A.rpm is removed that means that B.rpm has to be removed. - If A.rpm is updated, there should be a policy of how B.rpm should be managed. The most flexible way would be to allow the spec to decide among various options (block the upgrade, reapply a patch, re-override the config file or keep the new config file, remove B.rpm and emit a warning). I do not know if this is at all feasible in a sensible way, but something allowing the configuration of multiple machines would really be helpful. Theo. From orion at cora.nwra.com Tue Jul 31 15:05:40 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Tue, 31 Jul 2007 09:05:40 -0600 (MDT) Subject: Poor SCSI performance for rawhide kernels In-Reply-To: <20070730142340.116720@gmx.net> References: <20070730142340.116720@gmx.net> Message-ID: <3735.71.208.209.229.1185894340.squirrel@www.cora.nwra.com> > While debugging an issue with the aic7xxx driver, I noticed that SCSI > performance is quite poor for the current development kernel compared to > release kernels. > For a U160 disk attached to a 2940UW controller, FAST-20 mode [which, btw, > has to be forced manually, see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171282] delivers more > than 28 MB/s [hdparm -t /dev/sda] for the latest F7 update kernel > 2.6.22.1-33.fc7 [compared to the nominal rate of 40 MB/s] whereas it drops > by almost 30% to about 20 MB/s for rawhide kernel 2.6.23-0.49.rc1.git3.fc8 > which is barely more than in FAST-10 mode. It this difference of the order > one would expect? I've seen similar results before which I attributed to the added debugging turned on in the rawhide kernels. - orion From vonbrand at inf.utfsm.cl Tue Jul 31 15:29:31 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 31 Jul 2007 11:29:31 -0400 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185871893.2652.5.camel@hughsie-laptop> References: <1185871893.2652.5.camel@hughsie-laptop> Message-ID: <12956.1185895771@laptop13.inf.utfsm.cl> Richard Hughes wrote: > (from my blog, apologies to anyone that's read this once already) > > Before ideal system requirements we should talk about use cases and > system interactions. I think this is where update systems have gone > wrong in the past, closely integrating with the existing package system > rather than studying the complete ideal user interactions. > > Feel free to disagree and correct the interactions. > > Boot Time Security Update > > Toby logs into his desktop. A notification area icon with a critical > icon appears in the top right and a libnotify popup tells him there are > 3 three critical security updates. The libnotify popup has three > buttons: > ? Update now in the background > ? Always do updates automatically > ? Ignore for now > Toby clicks the first button and the update completes in the background. > When completed, after a few minutes, another libnotify popup appears > telling Toby that the update was completed and after a few seconds the > status icon disappears. > > Downloading an Unknown Application > > Suzanne wants to open a word file. She opens the software finder tool > and types "office file" into the search box. A list of software appears, > with OpenOffice being the top entry. She clicks the OpenOffice entry to > highlight it, and clicks "Install now". Suzanne is not an administrator, > but because she is locally logged in and the package is from the "fedora > GPG signed repository" the root password is not required. A notification > area icon appears with a downloading icon and the package manager is > closed. When OpenOffice is installed, a libnotify popup tells Suzanne > that the software has been downloaded and is now ready to use. What if they use a local mirror? What about extraoficial repos? What about locally built packages? What about computer labs (or other places) where "user installs random software" is *not* wellcome? What about packages that require sysadmin configuration (define local configuration, start server, ...)? > Installing files automatically > > Simon wants to borrow the computer while Suzanne waits for OpenOffice to > download. He uses fast-user switching to switch to a new login. He > notices the same downloading icon in his session which indicates > Suzannes' download is still in progress. He starts Pidgin which then > crashes. The bug-buddy window appears which prompts him to install the > debuginfo so a valid backtrace can be detected. He clicks yes, and a > libnotify windows appears telling Simon that the request has been queued > and that he will be notified when the debuginfo has been installed. When > installed, the bug-buddy helper continues and submits a valid bug. This is /not/ "installing automatically", it is another user installing new stuff while another install is running. Now you need to distinguish between users that are allowed to install stuff and those that aren't allowed to do so. A similar case is that Suzanne gets bored waiting for OOo, and asks for a (smallish) game to kill time. Again, what about situations where installing random stuff should not be allowed? How about getting rid of Joe R. User installed stuff later on (might be required for "cleanup" or whatever)? At least a indication of who installed what is needed. > Installing new features > > Suzanne switches back to her session and wants to add some clipart to > the word file she has just opened. She clicks "Insert" and then > "Clipart" and then a windows pops up telling her that clipart is not > installed. She clicks "Install" and a progress bar appears and moves > across as the clipart is downloaded and then installs. When finished, > the dialog disappears and she chooses a picture of a cat. > Comments? All the above presuposes a /huge/ bandwidth to the 'net (or at least to a nearby mirror). Plus nearly unlimited disk space (yes, the sum total of what the users will end up installing by just random twiddling /is/ everything). Not my case, unfortuntely. And I suspect that is the case of lots of Fedora users. As a end user, this is fine (but then, the end user owning the machine has the root password and knows how to use it); as the sysadmin of a bunch of machines (that I want to keep with reasonably {c,}lean configurations, at least for security reasons) this is one of the very first things I'd completely disable. sudo + a configuration that allows running "yum install foo" or "yumex" for assorted users is almost enough for all of the above, plus gives some extra control. I don't see a burning need for any of this, to tell the truth. -- 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 hughsient at gmail.com Tue Jul 31 15:38:18 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 16:38:18 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <12956.1185895771@laptop13.inf.utfsm.cl> References: <1185871893.2652.5.camel@hughsie-laptop> <12956.1185895771@laptop13.inf.utfsm.cl> Message-ID: <1185896298.2674.10.camel@hughsie-laptop> On Tue, 2007-07-31 at 11:29 -0400, Horst H. von Brand wrote: > What about computer labs (or other places) where "user installs random > software" is *not* wellcome? What about packages that require sysadmin > configuration (define local configuration, start server, ...)? Sure, as I've pointed out before this is all fine-grained policy that an admin can set per user or per machine. > > Installing files automatically > > > > Simon wants to borrow the computer while Suzanne waits for OpenOffice to > > download. He uses fast-user switching to switch to a new login. He > > notices the same downloading icon in his session which indicates > > Suzannes' download is still in progress. He starts Pidgin which then > > crashes. The bug-buddy window appears which prompts him to install the > > debuginfo so a valid backtrace can be detected. He clicks yes, and a > > libnotify windows appears telling Simon that the request has been queued > > and that he will be notified when the debuginfo has been installed. When > > installed, the bug-buddy helper continues and submits a valid bug. > > This is /not/ "installing automatically", it is another user installing > new stuff while another install is running. Now you need to distinguish > between users that are allowed to install stuff and those that aren't > allowed to do so. Sure, I don't see that a problem. > A similar case is that Suzanne gets bored waiting for OOo, and asks for > a (smallish) game to kill time. > > Again, what about situations where installing random stuff should not be > allowed? Lock it down using system policy... > All the above presuposes a /huge/ bandwidth to the 'net (or at least to > a nearby mirror). Plus nearly unlimited disk space (yes, the sum total > of what the users will end up installing by just random twiddling /is/ > everything). Not my case, unfortuntely. And I suspect that is the case > of lots of Fedora users. My home desktop system gets a new package a month installed. This use-case isn't spec'ed for the enterprise, but that's configurable to make it valid. > sudo + a configuration that allows running "yum install foo" or "yumex" > for assorted users is almost enough for all of the above, plus gives > some extra control. I don't see a burning need for any of this, to tell > the truth. Sure, I can understand that point of view too. I would also like you to show my non-techy girlfriend how to use yum or yumex when all she wants to do is open a odf file. :-) Richard. From billcrawford1970 at gmail.com Tue Jul 31 16:00:30 2007 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 31 Jul 2007 17:00:30 +0100 Subject: RPM roadmapping In-Reply-To: <46AF4C37.9080100@sophia.inria.fr> References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> <46ADB495.60206@leemhuis.info> <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> <46ADCBFC.2070706@sophia.inria.fr> <46AF4C37.9080100@sophia.inria.fr> Message-ID: <544eb990707310900r32378428q530b9610bce634fd@mail.gmail.com> On 31/07/07, Theodore Papadopoulo wrote: > The use case is the "customisation" using rpms of a group of machine for > which it is needed to modify some config files > belonging to some other rpm. A maybe not too good example would be to > modify /etc/yum.repos.d/fedora* > to add eg some local mirror. Right now, this is impossible as those > files belong to the redhat-release package (as of FC5), so > pushing such a modification requires creating a new version of this > package, which is definitely not clean. This is a good use-case for basically replacing redhat-release with your own locally-rolled config package (and presumably you'd have to Provides: redhat-release = whatever). > The attribute %config(noreplace) is of no use in such a case. It's good if you have it used in the package that provides an original config that you then modify. The best option is of course a search path for files, like the old XFILESEARCHPATH that libXt uses to find app-defaults files and so on. > I do not know if this is at all feasible in a sensible way, but > something allowing the configuration of multiple machines > would really be helpful. I do think you might look at repackaging some of the packages which have files you want to override (basically adding a new Source[n] or Patch[n] to the .spec and rebuild). However, what you're proposing sounds pretty useful too. > Theo. From emmanuel.seyman at club-internet.fr Tue Jul 31 16:26:30 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 31 Jul 2007 18:26:30 +0200 Subject: RPM roadmapping In-Reply-To: <46AF4C37.9080100@sophia.inria.fr> References: <20070730112506.5131e7fd@python3.es.egwn.lan> <16de708d0707300238i2cff3298p2f60c6ebd00ddce4@mail.gmail.com> <46ADB495.60206@leemhuis.info> <16de708d0707300314l233ea130rff6cbf97eabc3534@mail.gmail.com> <46ADCBFC.2070706@sophia.inria.fr> <46AF4C37.9080100@sophia.inria.fr> Message-ID: <20070731162630.GA28371@orient.maison.lan> * Theodore Papadopoulo [31/07/2007 18:05] : > > Considering config files and orthogonally to the version control > proposal, a feature I would like to have is a way for > a rpm package to override some config files. I'm not sure if it is at > all feasible or even whether there is not > a tricky way to do it currently. If the only use case is that of overwriting configuration files, I'ld look into using SOAP or tools like cfengine to centralize policy. Heck, CVS or Subversion will probably be up to the job. > The use case is the "customisation" using rpms of a group of machine for > which it is needed to modify some config files > belonging to some other rpm. A maybe not too good example would be to > modify /etc/yum.repos.d/fedora* > to add eg some local mirror. Right now, this is impossible as those > files belong to the redhat-release package (as of FC5), so > pushing such a modification requires creating a new version of this > package, which is definitely not clean. How is this not clean ? Grab the .src.rpm, apply your changes, update the EVR, rebuild and put the binary rpm in your private repo. I did this for years without any problems. It's a lot cleaner then the other solution which is to make mirrors.fedoraproject.org point to an internal mirror through DNS or /etc/hosts. Emmanuel From pemboa at gmail.com Tue Jul 31 16:36:47 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 31 Jul 2007 11:36:47 -0500 Subject: RPM roadmapping In-Reply-To: <200707311148.51189.opensource@till.name> References: <16de708d0707310152pca8e2edo86e3a393a9c052fa@mail.gmail.com> <200707311148.51189.opensource@till.name> Message-ID: <16de708d0707310936t5ebeba17xe048db386daf2517@mail.gmail.com> On 7/31/07, Till Maas wrote: > On Tuesday 31 July 2007 10:52:03 Arthur Pemberton wrote: > > > Is there currently any way for the end user to get a summary of what > > the install scripts of an RPM actually do? > > > Nothing to wordy, but something that a user could choose to view post > > install (or maybe even pre) so they have a better idea of what's going > > on. > > Is this what you want? > > Post Install: > rpm --scripts -q mysql-server > > Pre Install: > rpm --scripts -qp mysql-server*rpm > > Regards, > Till Nice, but this wouldn't mean much to an end user, and aside from chkconfig, I'm not sure how reliably we could covert it to written language. -- Fedora Core 6 and proud From dmc.fedora at filteredperception.org Tue Jul 31 16:36:11 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 31 Jul 2007 11:36:11 -0500 Subject: LiveCD wiping root partition? In-Reply-To: References: Message-ID: <46AF64FB.3020903@filteredperception.org> Michel Salim wrote: > I just did a clean install of Fedora 7 from the live CD onto my laptop, > which previously had a Fedora install upgraded from one of the F7 test > releases, partitioned as suggested by anaconda (LVM, one swap partition, > everything else under '/') > > When reinstalling, I kept the partition layout and specifically told > Anaconda *not* to reformat / (having booted in rescue mode beforehand, and > removing everything but /home). Anaconda gave a warning that the leftover > files might interfere with the installed system, which gave the impression > that those files won't actually be removed during installation. I don't remember the specific warning, but if it is not clearly indicating that unselecting the format option on '/' is not allowed, then that is a bug that should be fixed either with better user messages, or alternate installation mechanisms. I didn't have anything to do with what's in F7, though I did know enough about it to catch the fact that the 'formatting / filesystem' during the process was meaningless and time consuming, so that will be gone from from F8. > > As it turns out, however, the old contents are completely gone (I'm trying > out different recovery tools now to see if I could rescue some of the data). > It's as if the live CD simply used dd to transfer the install image to the > hard drive (in which case, how does it actually handle different partition > layouts, e.g. /usr, /var, /home on separate partitions -- does it just move > the files afterwards?) > > As it stands it seems that the Live CD is a very dangerous tool, at least as > long as > 1) the default behaviour of Anaconda is to put everything under / > 2) it does not carry more warnings about what it will do to the / partition > during installation > > Could someone let us know how the live CD actually performs its work? It takes a 4.0G ext3 fsimage from the cd, effectively dd's it to the chosen root volume, then does a resize2fs. It > would aid tremendously in the data recovery part. Would 'dd'-ing the entire > partition to an external drive, and mounting it on a Windows computer (most > recovery tools are unfortunately for that platform) preserve all the data > required? I'm assuming that the new installation overwrote the same parts of > the disk that was used to hold the OS in the previous install. As long as you haven't done much, data that was sitting in the first 4.0G of the filesystem will be gone, but data in the rest should be largely untouched. I have no idea how to go about trying to recover it (haven't used any windows tools), except asking for expensive professional date recovery help. Or if all I cared about was a text file, using 'strings' and 'grep' on chunks of the disk data. -dmc From mdehaan at redhat.com Tue Jul 31 16:53:49 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 31 Jul 2007 12:53:49 -0400 Subject: RPM roadmapping In-Reply-To: <200707271502.13034.opensource@till.name> References: <200707271502.13034.opensource@till.name> Message-ID: <46AF691D.1030100@redhat.com> Till Maas wrote: > On Friday 27 July 2007 14:40:40 Panu Matilainen wrote: > > >> Not everybody is on rpm-maint list and we'd like to hear the wishes of >> (Fedora) developers/packagers too. So: what have you always wanted to do >> with rpm, but wasn't able to? Or the other way around: what you always >> wished rpm would do for you? What always annoyed you out of your mind? >> > > I am missing "soft dependencies", e.g. the possibility to make a package > suggest which other packages may enhance it, e.g. with plugins. Afaik in > debian packages it is called "Suggests:". > +1. I would really like to see this, especially for apps that are plugin oriented / modular. It's one of the few things I miss from Debian. > Regards, > Till > From andy at smile.org.ua Tue Jul 31 17:05:44 2007 From: andy at smile.org.ua (Andy Shevchenko) Date: Tue, 31 Jul 2007 20:05:44 +0300 Subject: What TV teletext viewer to choose? In-Reply-To: <46AF2EC5.7040604@odu.neva.ru> References: <46AF2EC5.7040604@odu.neva.ru> Message-ID: <20070731170544.GA18649@serv.smile.org.ua> Hi Dmitry Butskoy! On Tue, Jul 31, 2007 at 04:44:53PM +0400, Dmitry Butskoy wrote next: > I'm thinking about the adding of some teletext viewer for Fedora (at least > for Gnome). > > Most TV cards support teletext capturing, and this feature is demanded by > users. The aletvd is still build within xawtv package. But that solution isn't perfect. -- With best regards, Andy Shevchenko. mailto: andy at smile.org.ua From walters at redhat.com Tue Jul 31 17:22:39 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 31 Jul 2007 13:22:39 -0400 Subject: Package Management Blows Goats (use cases) In-Reply-To: <20070731091813.GA7676@devserv.devel.redhat.com> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091813.GA7676@devserv.devel.redhat.com> Message-ID: <1185902559.16883.6.camel@neutron.verbum.private> On Tue, 2007-07-31 at 05:18 -0400, Alan Cox wrote: > On Tue, Jul 31, 2007 at 09:51:33AM +0100, Richard Hughes wrote: > > Toby logs into his desktop. A notification area icon with a critical > > icon appears in the top right and a libnotify popup tells him there are > > 3 three critical security updates. The libnotify popup has three > > Who is Toby, is he authorised to install updates ? > > One big problem throughout the Fedora and RHEL code is that nobody has > been willing to actually distinguish between install types at install > time. That is what causes the limits on automounting file systems, it is > what stops us doing Ubuntu type sudo and it is what breaks this. > > We need to know if the system is > - User managed > - Centrally managed > - Physical access implies control (typical home PC) > > and ask that in a sane fashion I only see two cases, and neither involves asking. 1) The person at the computer is "responsible" for it 2) Someone else is responsible The solution is simple - default to 1) for CDs downloaded from the Fedora website. For 2), make it convenient for the responsible person can set things up in whatever paranoid fashion they like - say person at computer has to stand on one foot and spin around, then swipe their fingerprint and type four passwords before they can download software. From dmc.fedora at filteredperception.org Tue Jul 31 17:23:00 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 31 Jul 2007 12:23:00 -0500 Subject: LiveCD wiping root partition? In-Reply-To: <46AF64FB.3020903@filteredperception.org> References: <46AF64FB.3020903@filteredperception.org> Message-ID: <46AF6FF4.7060507@filteredperception.org> Douglas McClendon wrote: > Michel Salim wrote: >> I just did a clean install of Fedora 7 from the live CD onto my laptop, >> which previously had a Fedora install upgraded from one of the F7 test >> releases, partitioned as suggested by anaconda (LVM, one swap partition, >> everything else under '/') >> >> When reinstalling, I kept the partition layout and specifically told >> Anaconda *not* to reformat / (having booted in rescue mode beforehand, >> and >> removing everything but /home). Anaconda gave a warning that the leftover >> files might interfere with the installed system, which gave the >> impression >> that those files won't actually be removed during installation. > > I don't remember the specific warning, but if it is not clearly > indicating that unselecting the format option on '/' is not allowed, > then that is a bug that should be fixed either with better user > messages, or alternate installation mechanisms. WOW. I was wrong. There is NO such message. That is a horrible bug. I may try to check to see if it's still in the latest anaconda, and provide some sort of simple patch later today. Also, to answer your question more thoroughly than my first reply- Yes, after the dd, if there is a seperate /usr or other partitions, files are then copied from / to there. This is all very related to my turboLiveInst patch which I recently posted to livecd-list and anaconda-devel. I'm surprised I don't remember hearing about this bug before. I had personally run into the same warning you saw, but that is just a general warning that has nothing to do with the livecd installer case specifically, and the livecd installer will stupidly let you just march along with the / fs not scheduled for formatting, even though it is going to anyway. -dmc > > I didn't have anything to do with what's in F7, though I did know enough > about it to catch the fact that the 'formatting / filesystem' during the > process was meaningless and time consuming, so that will be gone from > from F8. > >> >> As it turns out, however, the old contents are completely gone (I'm >> trying >> out different recovery tools now to see if I could rescue some of the >> data). >> It's as if the live CD simply used dd to transfer the install image to >> the >> hard drive (in which case, how does it actually handle different >> partition >> layouts, e.g. /usr, /var, /home on separate partitions -- does it just >> move >> the files afterwards?) >> >> As it stands it seems that the Live CD is a very dangerous tool, at >> least as >> long as >> 1) the default behaviour of Anaconda is to put everything under / >> 2) it does not carry more warnings about what it will do to the / >> partition >> during installation >> >> Could someone let us know how the live CD actually performs its work? > > > It takes a 4.0G ext3 fsimage from the cd, effectively dd's it to the > chosen root volume, then does a resize2fs. > > > It >> would aid tremendously in the data recovery part. Would 'dd'-ing the >> entire >> partition to an external drive, and mounting it on a Windows computer >> (most >> recovery tools are unfortunately for that platform) preserve all the data >> required? I'm assuming that the new installation overwrote the same >> parts of >> the disk that was used to hold the OS in the previous install. > > As long as you haven't done much, data that was sitting in the first > 4.0G of the filesystem will be gone, but data in the rest should be > largely untouched. I have no idea how to go about trying to recover it > (haven't used any windows tools), except asking for expensive > professional date recovery help. Or if all I cared about was a text > file, using 'strings' and 'grep' on chunks of the disk data. > > -dmc > From hughsient at gmail.com Tue Jul 31 17:33:34 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 18:33:34 +0100 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185902559.16883.6.camel@neutron.verbum.private> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091813.GA7676@devserv.devel.redhat.com> <1185902559.16883.6.camel@neutron.verbum.private> Message-ID: <1185903214.2674.12.camel@hughsie-laptop> On Tue, 2007-07-31 at 13:22 -0400, Colin Walters wrote: > On Tue, 2007-07-31 at 05:18 -0400, Alan Cox wrote: > > On Tue, Jul 31, 2007 at 09:51:33AM +0100, Richard Hughes wrote: > > > Toby logs into his desktop. A notification area icon with a critical > > > icon appears in the top right and a libnotify popup tells him there are > > > 3 three critical security updates. The libnotify popup has three > > > > Who is Toby, is he authorised to install updates ? > > > > One big problem throughout the Fedora and RHEL code is that nobody has > > been willing to actually distinguish between install types at install > > time. That is what causes the limits on automounting file systems, it is > > what stops us doing Ubuntu type sudo and it is what breaks this. > > > > We need to know if the system is > > - User managed > > - Centrally managed > > - Physical access implies control (typical home PC) > > > > and ask that in a sane fashion > > I only see two cases, and neither involves asking. > > 1) The person at the computer is "responsible" for it > 2) Someone else is responsible > > The solution is simple - default to 1) for CDs downloaded from the > Fedora website. > > For 2), make it convenient for the responsible person can set things up > in whatever paranoid fashion they like - say person at computer has to > stand on one foot and spin around, then swipe their fingerprint and type > four passwords before they can download software. Yes, very sane. Could you add this to http://live.gnome.org/PackageKit please? Thanks. Richard. From jkeating at redhat.com Tue Jul 31 17:41:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 31 Jul 2007 13:41:33 -0400 Subject: Package Management Blows Goats (use cases) In-Reply-To: <1185902559.16883.6.camel@neutron.verbum.private> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091813.GA7676@devserv.devel.redhat.com> <1185902559.16883.6.camel@neutron.verbum.private> Message-ID: <20070731134133.5fb3e36f@localhost.localdomain> On Tue, 31 Jul 2007 13:22:39 -0400 Colin Walters wrote: > 1) The person at the computer is "responsible" for it > 2) Someone else is responsible > > The solution is simple - default to 1) for CDs downloaded from the > Fedora website. As opposed to the CDs gotten from where? Are you suggesting that we'd have a different default for content elsewhere? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Tue Jul 31 17:48:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 31 Jul 2007 13:48:59 -0400 Subject: Package Management Blows Goats (use cases) In-Reply-To: <20070731134133.5fb3e36f@localhost.localdomain> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091813.GA7676@devserv.devel.redhat.com> <1185902559.16883.6.camel@neutron.verbum.private> <20070731134133.5fb3e36f@localhost.localdomain> Message-ID: <20070731174859.GA12180@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > 1) The person at the computer is "responsible" for it > > 2) Someone else is responsible > > > > The solution is simple - default to 1) for CDs downloaded from the > > Fedora website. > > As opposed to the CDs gotten from where? Are you suggesting that we'd > have a different default for content elsewhere? No. The idea is that if you're planning a deployment of managed machines, you're already in the position to make global configuration changes such as this. Bill From walters at redhat.com Tue Jul 31 17:52:50 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 31 Jul 2007 13:52:50 -0400 Subject: Package Management Blows Goats (use cases) In-Reply-To: <20070731134133.5fb3e36f@localhost.localdomain> References: <1185871893.2652.5.camel@hughsie-laptop> <20070731091813.GA7676@devserv.devel.redhat.com> <1185902559.16883.6.camel@neutron.verbum.private> <20070731134133.5fb3e36f@localhost.localdomain> Message-ID: <1185904370.16883.12.camel@neutron.verbum.private> On Tue, 2007-07-31 at 13:41 -0400, Jesse Keating wrote: > On Tue, 31 Jul 2007 13:22:39 -0400 > Colin Walters wrote: > > > 1) The person at the computer is "responsible" for it > > 2) Someone else is responsible > > > > The solution is simple - default to 1) for CDs downloaded from the > > Fedora website. > > As opposed to the CDs gotten from where? Are you suggesting that we'd > have a different default for content elsewhere? Certainly I can imagine someone creating the "Internet Cafe" Fedora spin where the defaults would be different. Perhaps even that someone would be people inside Fedora. But that's not what the overwhelmingly vast majority of people landing on fedoraproject.org would want to download, and we wouldn't want to feature it with the same prominence. From buildsys at redhat.com Tue Jul 31 17:54:24 2007 From: buildsys at redhat.com (Build System) Date: Tue, 31 Jul 2007 13:54:24 -0400 Subject: rawhide report: 20070731 changes Message-ID: <200707311754.l6VHsOd1011310@porkchop.devel.redhat.com> From seandarcy2 at gmail.com Tue Jul 31 17:11:52 2007 From: seandarcy2 at gmail.com (gmane) Date: Tue, 31 Jul 2007 13:11:52 -0400 Subject: No networking since July 28! Only w/ Windows Message-ID: Using rawhide as of July 28. All of a sudden, my ethernet won't come up. No link lights. But this is dual-boot machine, and networking works if I boot up Windows XP. I've got a Realtek integrated card, and the kernel finds it: lspci -vv .............. 02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Hewlett-Packard Company Unknown device 2a26 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- References: Message-ID: <46AF7AEF.9070506@warmcat.com> Somebody in the thread at some point said: > Using rawhide as of July 28. > > All of a sudden, my ethernet won't come up. No link lights. But this is > dual-boot machine, and networking works if I boot up Windows XP. > Completely puzzled. Don't know where or whether to file a bug report. Have a look in /proc/interrupts at the number of interrupts related to your ethernet card, if it is broken out on its own line. A box here on 2.6.23-rc1 did the same, with 0 interrupts on the IRQ assigned to the ethernet device, and adding pci=biosirq to the kernel commandline got it up again. -Andy From hughsient at gmail.com Tue Jul 31 18:10:59 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 31 Jul 2007 19:10:59 +0100 Subject: No networking since July 28! Only w/ Windows In-Reply-To: References: Message-ID: <1185905459.2674.14.camel@hughsie-laptop> On Tue, 2007-07-31 at 13:11 -0400, gmane wrote: > > Windows gets the dhcp address from the router. Fedora times out. I've > tried > setting Fedora to a static address, but then I still can't ping > anything, > including the router. OTOH, fedora gives no error about ifup'ing eth0 > with a > static address. For me 2.6.22.1-33.fc7 does the same thing as you describe, whereas 2.6.22.1-27.fc7 worked flawlessly. Richard. From michel.sylvan at gmail.com Tue Jul 31 18:36:22 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 1 Aug 2007 02:36:22 +0800 Subject: LiveCD wiping root partition? In-Reply-To: <46AF6FF4.7060507@filteredperception.org> References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> Message-ID: On 01/08/07, Douglas McClendon wrote: > > Douglas McClendon wrote: > > Michel Salim wrote: > >> I just did a clean install of Fedora 7 from the live CD onto my laptop, > >> which previously had a Fedora install upgraded from one of the F7 test > >> releases, partitioned as suggested by anaconda (LVM, one swap > partition, > >> everything else under '/') > >> > >> When reinstalling, I kept the partition layout and specifically told > >> Anaconda *not* to reformat / (having booted in rescue mode beforehand, > >> and > >> removing everything but /home). Anaconda gave a warning that the > leftover > >> files might interfere with the installed system, which gave the > >> impression > >> that those files won't actually be removed during installation. > > > > I don't remember the specific warning, but if it is not clearly > > indicating that unselecting the format option on '/' is not allowed, > > then that is a bug that should be fixed either with better user > > messages, or alternate installation mechanisms. > > WOW. I was wrong. There is NO such message. That is a horrible bug. I > may > try to check to see if it's still in the latest anaconda, and provide some > sort > of simple patch later today. > > Also, to answer your question more thoroughly than my first reply- Yes, > after > the dd, if there is a seperate /usr or other partitions, files are then > copied > from / to there. This is all very related to my turboLiveInst patch which > I > recently posted to livecd-list and anaconda-devel. Uh. Does it ensure that the root partition is at least 4.0 GB in size, or will it just try to dd the image regardless? I've had esoteric partitioning in the past, with small /, and large /usr and /opt partitions. I'm surprised I don't remember hearing about this bug before. I had > personally > run into the same warning you saw, but that is just a general warning that > has > nothing to do with the livecd installer case specifically, and the livecd > installer will stupidly let you just march along with the / fs not > scheduled for > formatting, even though it is going to anyway. I guess we really need to have different types of updates, where major and potentially data-loss-causing changes need to be more exhaustively tested. No one probably bothered testing a live CD install to a non-formatted partition before.. Still waiting for the dd process to finish backing up the partition to an external drive; will report if anything is salvageable. Wishing I did not blow away the Windows partition, would have made recovery much easier. While we're on the subject of making Anaconda changes, how about putting /home on a separate partition? The BSDs traditionally do that, I think. Thanks, -- Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Tue Jul 31 18:53:22 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 31 Jul 2007 13:53:22 -0500 Subject: LiveCD wiping root partition? In-Reply-To: References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> Message-ID: <46AF8522.2080409@filteredperception.org> Michel Salim wrote: > On 01/08/07, Douglas McClendon wrote: >> Douglas McClendon wrote: >> Also, to answer your question more thoroughly than my first reply- Yes, >> after >> the dd, if there is a seperate /usr or other partitions, files are then >> copied >> from / to there. This is all very related to my turboLiveInst patch which >> I >> recently posted to livecd-list and anaconda-devel. > > > Uh. Does it ensure that the root partition is at least 4.0 GB in size, or > will it just try to dd the image regardless? I've had esoteric partitioning > in the past, with small /, and large /usr and /opt partitions. That it does. Though the aforementioned turboLiveInst patch improves upon that, in that the rootfs only really needs to be 2.1G, which is the size of the uncompressed data that lives in the 4.0G filesystem image. But as mentioned with that patch, that is still technically deficient for the case of separate /usr, where / needn't really even be 2.1G. The solution to that is to have an alternate file level copy installation mechanism, rather than the (fast) block level fsimage copy installation mechanism. This also fixes the potential problem of reintroducing support for non-ext3 (e.g. xfs) target root filesystems. > > I'm surprised I don't remember hearing about this bug before. I had >> personally >> run into the same warning you saw, but that is just a general warning that >> has >> nothing to do with the livecd installer case specifically, and the livecd >> installer will stupidly let you just march along with the / fs not >> scheduled for >> formatting, even though it is going to anyway. > > > I guess we really need to have different types of updates, where major and > potentially data-loss-causing changes need to be more exhaustively tested. > No one probably bothered testing a live CD install to a non-formatted > partition before. F7 was the _first_ fedora release to have a livecd installer. And that generic warning about choosing to not format '/', probably steered most people away from doing that. But I agree, this situation should definitely be a part of some sort of test matrix. > > Still waiting for the dd process to finish backing up the partition to an > external drive; will report if anything is salvageable. Wishing I did not > blow away the Windows partition, would have made recovery much easier. > > While we're on the subject of making Anaconda changes, how about putting > /home on a separate partition? The BSDs traditionally do that, I think. No doubt you mean by default. Personally I've long been a fan of the single large partition (to the extreme of going out of my way to put boot, swap and suspend2 areas on /). Though these days, I tend to favor the 'upgrades are never worth it', and 'wipegrades are the future'. So /home makes more sense for 'wipegrades'. Although with all the version specific cruft that ends up in your homedir (~/.gnome*, blabla) I tend to have a subdirectory under home, and when I wipegrade, I only keep the subdir. If I have any ~/.* files that are important enough, I keep a copy in the subdir, and a script to easily replace them after wipegrade (and gconftool2 to reintroduce all my desktop prefs). Just my strategy, ymmv. -dmc From michel.sylvan at gmail.com Tue Jul 31 19:11:13 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 1 Aug 2007 03:11:13 +0800 Subject: LiveCD wiping root partition? In-Reply-To: <46AF8522.2080409@filteredperception.org> References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> <46AF8522.2080409@filteredperception.org> Message-ID: On 01/08/07, Douglas McClendon wrote: > > Michel Salim wrote: > > On 01/08/07, Douglas McClendon > wrote: > >> Douglas McClendon wrote: > >> Also, to answer your question more thoroughly than my first > reply- Yes, > >> after > >> the dd, if there is a seperate /usr or other partitions, files are then > >> copied > >> from / to there. This is all very related to my turboLiveInst patch > which > >> I > >> recently posted to livecd-list and anaconda-devel. > > > > > > Uh. Does it ensure that the root partition is at least 4.0 GB in size, > or > > will it just try to dd the image regardless? I've had esoteric > partitioning > > in the past, with small /, and large /usr and /opt partitions. > > > That it does. Though the aforementioned turboLiveInst patch improves upon > that, > in that the rootfs only really needs to be 2.1G, which is the size of the > uncompressed data that lives in the 4.0G filesystem image. But as > mentioned > with that patch, that is still technically deficient for the case of > separate > /usr, where / needn't really even be 2.1G. The solution to that is to > have an > alternate file level copy installation mechanism, rather than the (fast) > block > level fsimage copy installation mechanism. This also fixes the potential > problem of reintroducing support for non-ext3 (e.g. xfs) target root > filesystems. > > > > > I'm surprised I don't remember hearing about this bug before. I had > >> personally > >> run into the same warning you saw, but that is just a general warning > that > >> has > >> nothing to do with the livecd installer case specifically, and the > livecd > >> installer will stupidly let you just march along with the / fs not > >> scheduled for > >> formatting, even though it is going to anyway. > > > > > > I guess we really need to have different types of updates, where major > and > > potentially data-loss-causing changes need to be more exhaustively > tested. > > No one probably bothered testing a live CD install to a non-formatted > > partition before. > > F7 was the _first_ fedora release to have a livecd installer. And that > generic > warning about choosing to not format '/', probably steered most people > away from > doing that. But I agree, this situation should definitely be a part of > some > sort of test matrix. > > > > > Still waiting for the dd process to finish backing up the partition to > an > > external drive; will report if anything is salvageable. Wishing I did > not > > blow away the Windows partition, would have made recovery much easier. > > > > While we're on the subject of making Anaconda changes, how about putting > > /home on a separate partition? The BSDs traditionally do that, I think. > > No doubt you mean by default. Personally I've long been a fan of the > single > large partition (to the extreme of going out of my way to put boot, swap > and > suspend2 areas on /). Though these days, I tend to favor the 'upgrades > are > never worth it', and 'wipegrades are the future'. So /home makes more > sense for > 'wipegrades'. Although with all the version specific cruft that ends up > in your > homedir (~/.gnome*, blabla) I tend to have a subdirectory under home, and > when I > wipegrade, I only keep the subdir. If I have any ~/.* files that are > important > enough, I keep a copy in the subdir, and a script to easily replace them > after > wipegrade (and gconftool2 to reintroduce all my desktop prefs). Just my > strategy, ymmv. That's my strategy. Well, wipe the dots (apart from .gaim and a few others) and keep Documents, Music, Pictures, etc. It gets a bit messy because there are things in .gnome2 you definitely don't want to wipe too (epiphany puts its bookmarks there if I'm not mistaken, and there's also Rhythmbox). Writing a small script that chattr +i the important directories under the hidden dirs and then wipe the remainders would do the trick in a more systematic way, I suppose. I guess the partition split does not even have to be / and /home, it just has to be something that logically maps to RPM-managed vs non-RPM-managed. So users that need persistent home directories (local users, basically) should have home dirs in /local/home/ or something. Anyway, hard lesson learned. I wonder how Ubuntu does their live CD install. openSUSE is introducing one too, hopefully for their users the same bug does not occur. -- Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Tue Jul 31 19:19:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 01 Aug 2007 00:49:49 +0530 Subject: LiveCD wiping root partition? In-Reply-To: References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> <46AF8522.2080409@filteredperception.org> Message-ID: <46AF8B55.6000306@fedoraproject.org> Michel Salim wrote: > > Anyway, hard lesson learned. I wonder how Ubuntu does their live CD > install. openSUSE is introducing one too, hopefully for their users the > same bug does not occur. Pretty much every live cd does a dd afaik. Rahul From dmc.fedora at filteredperception.org Tue Jul 31 19:42:27 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 31 Jul 2007 14:42:27 -0500 Subject: LiveCD wiping root partition? In-Reply-To: <46AF8B55.6000306@fedoraproject.org> References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> <46AF8522.2080409@filteredperception.org> <46AF8B55.6000306@fedoraproject.org> Message-ID: <46AF90A3.2080405@filteredperception.org> Rahul Sundaram wrote: > Michel Salim wrote: > >> >> Anyway, hard lesson learned. I wonder how Ubuntu does their live CD >> install. openSUSE is introducing one too, hopefully for their users >> the same bug does not occur. > > Pretty much every live cd does a dd afaik. ubuntu 7.04 keeps their rootfs natively on squashfs (versus fedora which keeps it natively on an ext3 image which lives on a squashfs). Therefore they can't be doing a dd for the install. The reason for the difference is because ubuntu uses unionfs for copy-on-write, whereas fedora uses devicemapper-snapshot for copy-on-write. -dmc From wart at kobold.org Tue Jul 31 20:38:21 2007 From: wart at kobold.org (Michael Thomas) Date: Tue, 31 Jul 2007 15:38:21 -0500 Subject: New tcl8.4.15 is released In-Reply-To: <46AEDC4F.8090709@redhat.com> References: <46AEDC4F.8090709@redhat.com> Message-ID: <46AF9DBD.6030805@kobold.org> Marcela Maslanova wrote: > New stable version of tcl-8.4.15 is available. Are maintainers of > depended packages interested in upgrade on 8.4.15 or will be better to > wait for stable tcl8.5? > If no one interested in 8.4.15 version, I'll wait for stable 8.5. > > Marcela Maslanova I'm certainly interested in upgrading to 8.4.15. I would hope that some of the auto_path patches could be added at the same time (but I won't hold my breath). --Wart From pnasrat at redhat.com Tue Jul 31 21:27:10 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 31 Jul 2007 22:27:10 +0100 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <604aa7910707300912yf50962hdae09a109149fe39@mail.gmail.com> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> <1185548040.2494.6.camel@work> <20070727113123.26638c99@localhost.localdomain> <1185654063.18306.10.camel@home.alexander.bostrom.net> <1185780112.3213.8.camel@Nom> <604aa7910707300912yf50962hdae09a109149fe39@mail.gmail.com> Message-ID: <1185917230.9310.147.camel@enki.eridu> On Mon, 2007-07-30 at 08:12 -0800, Jeff Spaleta wrote: > On 7/29/07, Caolan McNamara wrote: > > FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to > > download on a crash. And neither OOo or firefox are using bug-buddy. In > > the case of OOo at least the crash info can be re-annotated offline back > > to source lines, so we don't loose anything by having no debuginfo > > installed. Though we don't get local variables etc with offline > > annotation, but we don't have those with the current crash reporter > > anyway. > > I think OOo illustrates that whatever toolized solution to help users > install debuginfo packages as needed, would need to be smart enough to > blacklist certain packages that are known not to benefit from the > debuginfo install. I think the use case of users who can cope with submitting a bug with debuginfo are negligible compared to some other use cases. Plus most stuff will need to pull in library debuginfo deps, even if it's just glibc*debuginfo* to make sense of things. Lets not get hung up on the details here but hammer out the use cases rather than caught into a rathole of setting policy prematurely. Paul From ajackson at redhat.com Tue Jul 31 21:15:12 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 31 Jul 2007 17:15:12 -0400 Subject: Blog post about package management (aimed at fedora) In-Reply-To: <1185917230.9310.147.camel@enki.eridu> References: <1185532130.10773.10.camel@work> <1185548125.3323.13.camel@neutron.verbum.private> <1185548040.2494.6.camel@work> <20070727113123.26638c99@localhost.localdomain> <1185654063.18306.10.camel@home.alexander.bostrom.net> <1185780112.3213.8.camel@Nom> <604aa7910707300912yf50962hdae09a109149fe39@mail.gmail.com> <1185917230.9310.147.camel@enki.eridu> Message-ID: <1185916512.2794.200.camel@localhost.localdomain> On Tue, 2007-07-31 at 22:27 +0100, Paul Nasrat wrote: > On Mon, 2007-07-30 at 08:12 -0800, Jeff Spaleta wrote: > > On 7/29/07, Caolan McNamara wrote: > > > FWIW OOo debuginfo is about 450 megs, which is rather sucky to force to > > > download on a crash. And neither OOo or firefox are using bug-buddy. In > > > the case of OOo at least the crash info can be re-annotated offline back > > > to source lines, so we don't loose anything by having no debuginfo > > > installed. Though we don't get local variables etc with offline > > > annotation, but we don't have those with the current crash reporter > > > anyway. > > > > I think OOo illustrates that whatever toolized solution to help users > > install debuginfo packages as needed, would need to be smart enough to > > blacklist certain packages that are known not to benefit from the > > debuginfo install. > > I think the use case of users who can cope with submitting a bug with > debuginfo are negligible compared to some other use cases. Plus most > stuff will need to pull in library debuginfo deps, even if it's just > glibc*debuginfo* to make sense of things. More to the point, asking the user to install debuginfo _ever_ is a failure. You have the NEVRs of all packages involved in the crash. Feed them to the bug machine, let the distro reconstruct the backtrace. That way not only does the user not have to download $huge, but they don't have to go hunt around in koji for the debuginfo that corresponds to whatever outdated version of a given package they still have installed. - ajax From kwade at redhat.com Fri Jul 27 07:53:07 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 27 Jul 2007 00:53:07 -0700 Subject: Extra Packages for Enterprise Linux (EPEL) Now Open Message-ID: <1185522787.17380.992.camel@erato.phig.org> If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you. Ever find yourself rebuilding one of the high-quality Fedora packages for your EL version because it didn't ship with the EL distro? Friends, there is a new way. May we introduce ... Extra Packages for Enterprise Linux (EPEL) EPEL is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora version. Yet, there room for new packages and contributors. Currently, around 1000 packages are available, and we've been growing at the rate of several dozen packages every week. http://fedoraproject.org/wiki/EPEL How to use EPEL: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse You can look for packages here: http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated Looking for a package not in EPEL or other questions? http://fedoraproject.org/wiki/EPEL/FAQ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Tue Jul 31 21:35:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 31 Jul 2007 17:35:04 -0400 Subject: Fedora 8 Test 1 slipping Message-ID: <20070731173504.4a0a704e@localhost.localdomain> Due to an ongoing issue with booting many Dells (and some Toshiba) systems via CD, we've had to delay the release of Test1. The good news is that we've found a solution and a new kernel is building in koji as I type this. The bad news is that there is not enough time to get the output of that build and spin it into a set of trees for release on Thursday. As such, we're slipping the release to Tuesday of next week, August 7. This gives us time to consume the kernel build and generate a release candidate tree early tomorrow, and spend all day, and all of Thursday beating on it for real blocker issues. Friday morning is our Go/No Go point. If all things are Go, we'll be handing it off to mirrors and giving them the weekend and Monday to sync up the release. If we're No Go, we will determine then a new release date. All the gory details can be found at http://fedoraproject.org/wiki/QA/8/Test1TreeTesting Cheers! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From wolfy at nobugconsulting.ro Tue Jul 31 21:46:24 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 01 Aug 2007 00:46:24 +0300 Subject: What TV teletext viewer to choose? In-Reply-To: <46AF2EC5.7040604@odu.neva.ru> References: <46AF2EC5.7040604@odu.neva.ru> Message-ID: <46AFADB0.7010800@nobugconsulting.ro> On 07/31/2007 03:44 PM, Dmitry Butskoy wrote: > I'm thinking about the adding of some teletext viewer for Fedora (at > least for Gnome). > > Most TV cards support teletext capturing, and this feature is demanded > by users. > > Besides some very old implementations (gnometv, alevt), which seem > already stopped, I've found two possible variants: > > - Enable "mtt" in the "xawtv" package (recently added to Fedora). > But enabling of "mtt" will require Motif... > > - Package Zapping TV viewer (http://zapping.sf.net), which has an > advanced teletext viewer (Zapzilla). > But Zapping should be stripped first from any mpeg-patented-etc. > stuff... > > Any comments? > > What is better? Or maybe something else? Please go with zapping if possible + and work with "the other repo" to store whatever is not suited for Fedora. I have friends who claim that zapping is better than xawtv From roland at redhat.com Tue Jul 31 22:08:46 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 31 Jul 2007 15:08:46 -0700 (PDT) Subject: Blog post about package management (aimed at fedora) In-Reply-To: Adam Jackson's message of Tuesday, 31 July 2007 17:15:12 -0400 <1185916512.2794.200.camel@localhost.localdomain> Message-ID: <20070731220846.D90344D04B9@magilla.localdomain> > More to the point, asking the user to install debuginfo _ever_ is a > failure. You have the NEVRs of all packages involved in the crash. > Feed them to the bug machine, let the distro reconstruct the backtrace. In F8 with build IDs, having nothing but the core dump file will be enough to easily determine (offline, later) all the packages that were involved. From orion at cora.nwra.com Tue Jul 31 22:57:48 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 31 Jul 2007 16:57:48 -0600 Subject: Differences in packages installed in mock i386 vs x86_64 Message-ID: <46AFBE6C.80405@cora.nwra.com> The following packages are installed in my x86_64 development mock root by default but not in i386 (as part of the "update" step): audit-libs-python curl graphviz libgfortran libselinux-python libtiff libtiff-devel mesa-libGLU mesa-libGLU-devel mesa-libOSMesa mesa-libOSMesa-devel openmpi openmpi-devel openmpi-libs policycoreutils qt4 qt4-devel qt4-x11 xmlrpc-c Can anyone else confirm this? This is with mock 0.7.2-1.fc7 and yum-3.2.1-1.fc7 on x86_64 -- 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 buildsys at redhat.com Tue Jul 31 23:46:44 2007 From: buildsys at redhat.com (Build System) Date: Tue, 31 Jul 2007 19:46:44 -0400 Subject: rawhide report: 20070731 changes Message-ID: <200707312346.l6VNkid4018475@porkchop.devel.redhat.com> Removed package plib16 Updated Packages: anaconda-11.3.0.15-1 -------------------- * Tue Jul 31 2007 Chris Lumens 11.3.0.15-1 - isys cleanups. - Create device nodes much earlier (#249882). firstboot-1.4.35-5.fc8 ---------------------- * Mon Jul 30 2007 Chris Lumens 1.4.35-5 - Fix conflicts in init script start/stop lines (#250163). gdm-1:2.19.5-1.fc8 ------------------ * Tue Jul 31 2007 Matthias Clasen - 1:2.19.5-1 - Update to 2.19.5 * Mon Jul 30 2007 Matthias Clasen - 1:2.19.4-2 - Add optional gnome-keyring support to the gdm pam stack rhgb-0.17.6-2.fc8 ----------------- * Fri Jul 27 2007 Ray Strode - 0.17.6-2 - don't hard code font path in X server command line (bug 242258) rsyslog-1.17.5-1.fc8 -------------------- * Mon Jul 30 2007 Peter Vrabec 1.17.5-1 - upstream bugfix release - fix typo in provides selinux-policy-3.0.4-3.fc8 -------------------------- * Mon Jul 30 2007 Dan Walsh 3.0.4-3 - Allow xserver to write to ramfs mounted by rhgb * Mon Jul 23 2007 Dan Walsh 3.0.4-2 - Add context for dbus machine id system-config-securitylevel-1.7.0-5.1.fc8 ----------------------------------------- * Tue Jul 31 2007 Thomas Woerner 1.7.0-5.1 - bump because of build system error * Tue Jul 31 2007 Thomas Woerner 1.7.0-5 - fixed lokkit to stop iptables and ip6tables if firewall gets disabled (rhbz#236175) - more fixes to dirty check for firstboot * Mon Jul 30 2007 Thomas Woerner 1.7.0-4 - fixed checkDirty function for use in s-c-ks and firstboot (rhbz#247863) Broken deps for i386 ---------------------------------------------------------- glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-PAE - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.i686 requires kernel-i686 = 0:2.6.23-0.41.rc0.git14.fc8PAE kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i586 requires kernel-i586 = 0:2.6.21-1.3228.fc7 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7 kmod-sysprof-PAE - 1.0.8-1.2.6.21_1.3228.fc7.i686 requires kernel-i686 = 0:2.6.21-1.3228.fc7PAE openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.i386 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.i386 requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.i386 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.i386 requires libiw.so.28 Broken deps for x86_64 ---------------------------------------------------------- glom - 1.4.4-1.fc7.x86_64 requires libgdamm-1.3.so.8()(64bit) glom - 1.4.4-1.fc7.i386 requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.x86_64 requires kernel-x86_64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-sysprof - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7 kmod-sysprof-kdump - 1.0.8-1.2.6.21_1.3228.fc7.x86_64 requires kernel-x86_64 = 0:2.6.21-1.3228.fc7kdump openalpp - 20060714-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.x86_64 requires libosgText.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgFX.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgSim.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgDB.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosg.so.1()(64bit) osgal - 20060903-3.fc7.x86_64 requires libosgGA.so.1()(64bit) osgal - 20060903-3.fc7.i386 requires libosgDB.so.1 osgal - 20060903-3.fc7.i386 requires libosgFX.so.1 osgal - 20060903-3.fc7.i386 requires libosgParticle.so.1 osgal - 20060903-3.fc7.i386 requires libosgProducer.so.1 osgal - 20060903-3.fc7.i386 requires libosgSim.so.1 osgal - 20060903-3.fc7.i386 requires libosgGA.so.1 osgal - 20060903-3.fc7.i386 requires libOpenThreads.so.1 osgal - 20060903-3.fc7.i386 requires libosgText.so.1 osgal - 20060903-3.fc7.i386 requires libosg.so.1 osgal - 20060903-3.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.i386 requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgText.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosg.so.1 osgcal - 0.1.44-4.fc7.i386 requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.x86_64 requires libosgText.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgFX.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgUtil.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgSim.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libOpenThreads.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgDB.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgParticle.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgProducer.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosg.so.1()(64bit) osgcal - 0.1.44-4.fc7.x86_64 requires libosgGA.so.1()(64bit) ruby-gtkmozembed - 0.16.0-6.fc8.x86_64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.x86_64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.x86_64 requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.x86_64 requires libiw.so.28()(64bit) Broken deps for ppc ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 glom - 1.4.4-1.fc7.ppc requires libgdamm-1.3.so.8 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-smp - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc requires kernel-ppc = 0:2.6.23-0.41.rc0.git14.fc8smp openalpp - 20060714-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgDB.so.1 osgal - 20060903-3.fc7.ppc requires libosgFX.so.1 osgal - 20060903-3.fc7.ppc requires libosgParticle.so.1 osgal - 20060903-3.fc7.ppc requires libosgProducer.so.1 osgal - 20060903-3.fc7.ppc requires libosgSim.so.1 osgal - 20060903-3.fc7.ppc requires libosgGA.so.1 osgal - 20060903-3.fc7.ppc requires libOpenThreads.so.1 osgal - 20060903-3.fc7.ppc requires libosgText.so.1 osgal - 20060903-3.fc7.ppc requires libosg.so.1 osgal - 20060903-3.fc7.ppc requires libosgUtil.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgDB.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgFX.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgParticle.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgProducer.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgSim.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgGA.so.1 osgcal - 0.1.44-4.fc7.ppc requires libOpenThreads.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgText.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosg.so.1 osgcal - 0.1.44-4.fc7.ppc requires libosgUtil.so.1 ruby-gtkmozembed - 0.16.0-6.fc8.ppc requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc requires libyaz.so.2 vtk-examples - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc requires vtkdata = 0:5.0.3 xsupplicant - 1.2.8-1.fc7.1.ppc requires libiw.so.28 Broken deps for ppc64 ---------------------------------------------------------- glest-data - 2.0.0-2.fc7.noarch requires glest = 0:2.0.0 kmod-em8300 - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8 kmod-em8300-kdump - 0.16.3-0.6.rc2.2.6.23_0.41.rc0.git14.fc8.ppc64 requires kernel-ppc64 = 0:2.6.23-0.41.rc0.git14.fc8kdump python-vcpx - 0.9.28-3.fc8.noarch requires darcs resapplet - 0.1.1-5.fc7.ppc64 requires system-config-display ruby-gtkmozembed - 0.16.0-6.fc8.ppc64 requires firefox = 0:2.0.0.4 tellico - 1.2.11-1.fc8.ppc64 requires libyaz.so.2()(64bit) vtk-examples - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 vtk-testing - 5.0.3-18.2.fc8.ppc64 requires vtkdata = 0:5.0.3 From no-reply-gw at fcp.surfsite.org Tue Jul 31 08:25:01 2007 From: no-reply-gw at fcp.surfsite.org (=?UTF-8?B?amF5c29uICh0eDMwMDAp?=) Date: Tue, 31 Jul 2007 08:25:01 -0000 Subject: Intel (R) Wireless WiFi 4965AGN Issue ?? Message-ID: <4058328680afcd79e583b8723ca4b9d6@fcp.surfsite.org> Im using loptop Dell Aspiron 640 With dual boot.. Now my Question is Im having Problem with my Intel (R) Wireless WiFi 4965AGN I cant see in my Network manager. Any one can help how to configure my Wireless and how to install ?? Im using Fedora 7 With a new kernel wright now.. Please any one can help me how to connnect my wireless... -- This is an email sent via The Fedora Community Portal https://fcp.surfsite.org https://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=190243&topic_id=41871&forum=11#forumpost190243 If you think, this is spam, please report this to webmaster at fcp.surfsite.org and/or blame ceelike at gmail.com.