kvm failing to install.
Hi, I download the latest kvm-88 from http://sourceforge.net/projects/kvm/files/ . But when i did /'make'/ its failing for following error, CC [M] /dl/kvm-88/kvm/kernel/x86/x86.o In file included from /dl/kvm-88/kvm/kernel/x86/trace.h:355, from /dl/kvm-88/kvm/kernel/x86/x86.c:83: include/trace/define_trace.h:53:43: error: arch/x86/kvm/trace.h: No such file or directory make[4]: *** [/dl/kvm-88/kvm/kernel/x86/x86.o] Error 1 make[3]: *** [/dl/kvm-88/kvm/kernel/x86] Error 2 make[2]: *** [_module_/dl/kvm-88/kvm/kernel] Error 2 make[1]: *** [all] Error 2 make: *** [kvm-kmod] Error 2 I have AMD processor supported '/svm/' Is this known error? - Nilesh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [KDE] Which Phonon? Phonon backend - GStreamer or Xine?
On Thursday 01 October 2009 03:02:04 Kevin Kofler wrote: Jaroslav Reznik wrote: That's not about standardize on GTK+ That was just an example of how one size fits it all doesn't always work when it comes to libraries, there will always be more than one library for some purposes. We should choose better technology over politics. That's exactly why I voted for Phonon-Xine in the meeting. ;-) All the world must use GStreamer == politics Phonon-Xine is considered by Phonon upstream to be the better technology. By one developer who admits that Phonon is dying slowly and not developed anymore ;-) No, I don't want one multimedia framework rule them all but currently it's the best what we have (I'm not talking about Phonon backend - just GStreamer). In case of better framework in the future I believe I'd be one of first supporters (even it could bring troubles to Fedora). Jaroslav Kevin Kofler -- Jaroslav Řezník jrez...@redhat.com Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Wed, 2009-09-30 at 23:40 +0200, Florian Festi wrote: On 09/30/2009 07:43 PM, Michael Schroeder wrote: Fedora's rpm used to have a modified copy of zlib so that the created rpms were more rsync friendly. As deltarpm needs to recreate the same compressed payload I also had to support this. Always nice to see how insanity leads to even more insanity. And nice to see that we can remove it now. Not to be distrusting but I am also going to watch out and see how easily we might break something, just for nazi-like mindset in enforcing a policy. Mind you, I am not against the policy itself, I think it is a good policy, and I am not trying to ask for exceptions for rsync,. But we also need to reasonable, and unless someone volunteers to do the actual work *without* breaking the tool in the process, I think a policy like this need to be evaluated case by case and not just blindly and rigidly enforced. Simo. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Thu, 2009-10-01 at 04:46 -0400, Simo Sorce wrote: But we also need to reasonable, and unless someone volunteers to do the actual work *without* breaking the tool in the process, I think a policy like this need to be evaluated case by case and not just blindly and rigidly enforced. And, in that vein, I'd like to say a huge thank you to Toshio for fixing deltarpm to use the system zlib library *without* breaking it (at least as far as my testing has gone). It is hugely appreciated! Jonathan signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: Jeff Garzik jgar...@pobox.com writes: The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. This was my problem too with PPC builds - it's hard to get time on a PPC/PPC64 machine to fix the problems. Is there another big-endian platform that is on the upswing? Is ARM big endian? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Kevin Kofler, Thu, 01 Oct 2009 02:58:15 +0200: Yes. It slowed down builds, and it often triggered bizarre build failures which were NOT bugs in the program, but in the toolchain or in some core library like glibc, which in turn delayed important updates to the affected packages. I.e., it was discovering bugs ... not in your program but in glibc, gcc, etc. (I have experienced this couple of times with pspp on Sparc). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Tom Lane wrote: [ ppc64 horror story snipped ] Well, I'm by no means wedded to ppc64; I just want *some* BE architecture in the primary set. Maybe a reasonable compromise would be to include ppc but not ppc64? That would cover basic BE portability issues, if not the occasional BE-and-64-bit bug. And it would halve the present workload of the PPC builders, which might help the build time issue. Well, AFAIK ppc32 also has this TOC mess I was complaining about, it just has room for twice as many entries because pointers are half the size, so in practice projects trigger the awfully low ppc64 limit first. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Richard W.M. Jones píše v Čt 01. 10. 2009 v 10:29 +0100: On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: Jeff Garzik jgar...@pobox.com writes: The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. This was my problem too with PPC builds - it's hard to get time on a PPC/PPC64 machine to fix the problems. Is there another big-endian platform that is on the upswing? Is ARM big endian? The chips can usually do both endians, but Fedora/ARM is built as little endian, because the targeted HW is little endian. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: Maybe removing the Final Development part and replace it with something like Beta Freeze (Bug Fixes ONLY) might have helped. Well my problem with the current state is that it is not Bug Fixes ONLY, we are getting to acks (Red Hat people know what I am talking about) by somebody who is neither PM, nor developer, nor QA. Oh well, at least finally I know for whom not to vote in the elections. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik, Wed, 30 Sep 2009 18:55:56 -0400: Both ppc and ppc64 have been excellent at catching software bugs in my projects that long went unnoticed on i386/x86-64. The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I don't think it is that bad with secondary archs ... I maintain PSPP (I didn't know what I've fallen into when I packaged that ;)) and we are routinely finding bugs on SPARC ... in pspp as well as in glibc, gcc, and other places. PSPP by its nature has quite extensive unit tests, so it is catching a lot of stuff which otherwise goes unnoticed. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 11:32:59AM +0200, Kevin Kofler wrote: Tom Lane wrote: [ ppc64 horror story snipped ] Well, I'm by no means wedded to ppc64; I just want *some* BE architecture in the primary set. Maybe a reasonable compromise would be to include ppc but not ppc64? That would cover basic BE portability issues, if not the occasional BE-and-64-bit bug. And it would halve the present workload of the PPC builders, which might help the build time issue. Well, AFAIK ppc32 also has this TOC mess I was complaining about, it just has room for twice as many entries because pointers are half the size, so in practice projects trigger the awfully low ppc64 limit first. And many other targets have similar limitations. Even x86-64 has them, just big enough that you rarely notice (you need to go over 2GB of code/data to start having issues there, and even then there are code models that allow larger code). In some cases it is just -fpic vs. -fPIC, but in other cases the limitations are more severe. Most of the limitations are related to the encoding of instructions, what immediates they allow and what addressing modes they support. It is actually very desirable if developers don't think all the world is i386/x86_64, that leads to horribly unportable code and many bugs go unnoticed. In the OpenBabel case just using an array, or changing the generator to spit more smaller sources, etc. would be desirable for portability. So I think making PPC a secondary arch is a very bad idea and will hurt Fedora quality. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
2009/9/14 Adam Williamson awill...@redhat.com Hi, everyone. We - the QA group - have recently been researching the feasibility of using zsync to reduce the size of live image downloads. This has hit a roadblock in the form of the problem where both rsync and zsync use forked zlibs rather than linking against the system copy. Imho, allow zsync for fedora. If you can solve the zlib-problem of rsync, the problem of zsync will be solved as well, cause the integrity of zsync in fedora fails on rsync-compatibility, which needs a forked zlib. -- Josephine Fine Tannhäuser 2.6.29.6-213.fc11.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Thu, Oct 01, 2009 at 09:34:38AM +, Matej Cepl wrote: Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: Maybe removing the Final Development part and replace it with something like Beta Freeze (Bug Fixes ONLY) might have helped. Well my problem with the current state is that it is not Bug Fixes ONLY, we are getting to acks (Red Hat people know what I am talking about) by somebody who is neither PM, nor developer, nor QA. Could you elaborate there? Rel-eng is comprised of several people with varying backgrounds, and there are certianly developers and QA oriented people in that group... Oh well, at least finally I know for whom not to vote in the elections. Rel-eng isn't elected... again confused. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Richard W.M. Jones rjo...@redhat.com writes: Is ARM big endian? It can be either. Intel's IXP4xx networking chips are usually running BE since their internal network engines are BE-only and it's thus more efficient. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On 10/01/2009 05:34 AM, Matej Cepl wrote: Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: Maybe removing the Final Development part and replace it with something like Beta Freeze (Bug Fixes ONLY) might have helped. Well my problem with the current state is that it is not Bug Fixes ONLY, we are getting to acks (Red Hat people know what I am talking about) by somebody who is neither PM, nor developer, nor QA. I thought about this as well... what might be better than Bug Fixes ONLY is CVS commits turned off which is more accurate to what happens... steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091001 changes
Compose started at Thu Oct 1 06:15:05 UTC 2009 Broken deps for i386 -- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.i586 requires libpcap.so.0.9 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 labrea-2.5.1-2.fc10.i386 requires libpcap.so.0.9 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfagent.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidclient.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidcommon.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfagent.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidclient.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfcommon.so.2 network-manager-netbook-1.2-5.fc12.i686 requires libnm_glib.so.0 ngrep-1.45-5.fc11.i586 requires libpcap.so.0.9 perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin = 0:0.5.3-30 yersinia-0.7.1-3.fc11.i586 requires libpcap.so.0.9 Broken deps for x86_64 -- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public argus-2.0.6.fixes.1-16.fc11.x86_64 requires libpcap.so.0.9()(64bit) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-gtk-0.9) glom-1.10.1-1.fc12.x86_64 requires libgdamm-4.0.so.11()(64bit) glom-libs-1.10.1-1.fc12.i586 requires libgdamm-4.0.so.11 glom-libs-1.10.1-1.fc12.x86_64 requires libgdamm-4.0.so.11()(64bit) labrea-2.5.1-2.fc10.x86_64 requires libpcap.so.0.9()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfagent.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqmfcommon.so.2()(64bit) libvirt-qpid-0.2.17-0.fc12.x86_64 requires libqpidclient.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqpidcommon.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqmfagent.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqmfcommon.so.2()(64bit) matahari-0.0.4-5.fc12.x86_64 requires libqpidclient.so.2()(64bit) network-manager-netbook-1.2-5.fc12.x86_64 requires libnm_glib.so.0()(64bit) ngrep-1.45-5.fc11.x86_64 requires libpcap.so.0.9()(64bit) perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin = 0:0.5.3-30 yersinia-0.7.1-3.fc11.x86_64 requires libpcap.so.0.9()(64bit) Broken deps for ppc -- PolicyKit-olpc-1.2-2.fc11.noarch requires /var/lib/PolicyKit-public
Re: status of forked zlibs in rsync and zsync
On Thu, 1 Oct 2009, Simo Sorce wrote: see that we can remove it now. Not to be distrusting but I am also going to watch out and see how easily we might break something, just for nazi-like mindset in enforcing a policy. Godwin's law? Really? This early in the thread? Maybe we should cool off the dramatic statements all around... -sv Your friendly neighborhood hall-monitor. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/30/2009 08:47 PM, Jesse Keating wrote: On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? Ric -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Matej Cepl wrote: I.e., it was discovering bugs ... not in your program but in glibc, gcc, etc. (I have experienced this couple of times with pspp on Sparc). But usually in target-specific code. Plus, it's not the toolchain's updates which get stalled, but the updates for some package which just happens to trigger the toolchain bug. Having the arches be secondary allows to at least proceed with building things on the primary arches while the bug on the secondary arch is being fixed. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Oct 1, 2009, at 6:49, Ric Wheeler rwhee...@redhat.com wrote: On 09/30/2009 08:47 PM, Jesse Keating wrote: On Wed, 2009-09-30 at 20:26 -0400, Jeff Garzik wrote: Was ppc really such a burden? When it breaks and only it breaks, slowing down or delaying a release, yes. I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? Ric No. They heard that here would be a secondary arch effort and seemed to think oh, they will fix it for us. Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Oct 1, 2009, at 2:28, Kevin Kofler kevin.kof...@chello.at wrote: Josh Boyer wrote: http://meetbot.fedoraproject.org/fedora-meeting/2009-06-12/fedora- meeting.2009-06-12-17.01.html Ah, there it is, I must have missed it when going through the summaries, sorry. :-( So I'll have to blame the previous FESCo for voting this through with practically no feedback, as they observed themselves before the vote: 17:14:04 nirik has there been any feedback on lists or wiki? 17:14:15 * nirik just sees one 'sounds fine to me' comment on the discussion page 17:14:25 notting yeah, haven't seen much But in any case, I don't think any of us realized the amount of maintainer confusion this would cause (I know I didn't or I would have complained on the mailing list right when this was proposed). In hindsight, it was definitely a mistake. This thread is just one of the examples of maintainers having been led to believe they have more time to develop their features than they actually do, I've seen several more while sitting in FESCo feature meetings. We should fix the mistake at the first opportunity (Fedora 13). Or we should correct this that got confused and move on rather than continuing to use our own made up meanings for otherwise industry standard words or worse our own made up words. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? No. They heard that here would be a secondary arch effort and seemed to think oh, they will fix it for us. Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. s/nonserver/desktop Lots of embedded PPC still out there (yes, running Linux). josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Oct 1, 2009, at 7:58, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? No. They heard that here would be a secondary arch effort and seemed to think oh, they will fix it for us. Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. s/nonserver/desktop Lots of embedded PPC still out there (yes, running Linux). Fair point! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
Jeff Garzik (jgar...@pobox.com) said: But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. Sure, but it's not like M, in a sizeable percentage of cases, is particularly useful in this regard. In any case: - ppc has very few users. This is demonstratable by smolt stats and download stats. - ppc has declining hardware availability, unless you're counting increased scavenging via dumpsters. - ppc has no one looking at the actual bugs in any case. LiveCDs have been broken on PPC for *years*, for example, and no one cares. Graphics drivers have been broken on PPC throughout the F11 release and no one cares. In essence, if the bug doesn't affect the build or install environment, it *doesn't get noticed*, in most regards. Given that ppc32 and ppc64 (or pick your BE platform) have demonstrated an ability to detect problems not found on LE, it seems like this policy change will directly lead to missed bugs, and an attendent decline in software quality. If you feel that this is the case, *step up and join the PPC secondary arch effort*. They could use the help. But I don't see the logic in making Fedora a charity case. As to the RHEL argument, well, that's a RHEL problem. If Red Hat (or anyone, really) feels that it's worth a significant effort to have an up-to-date, maintained, PPC tree, then they should pony up for that effort. Saying Fedora should do this! and not providing real resources to accomplish that; well, I don't think Fedora necessarily should be a charity for cases there's no community for. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 11:10:51AM -0400, Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. Sure, but it's not like M, in a sizeable percentage of cases, is particularly useful in this regard. In any case: - ppc has no one looking at the actual bugs in any case. LiveCDs have been broken on PPC for *years*, for example, and no one cares. Graphics drivers have been broken on PPC throughout the F11 release and no one cares. Going to counter this one. I look at bugs. I know David look(s/ed) at bugs. We just can't get to all of them. This echos your point about community, but I didn't want you to get away with saying that nobody is trying. LiveCDs are pretty useless because demand for them is non-existent. So yes, it is broken and I don't think it works even after some of the recent fixes I sent to livecd-tools. So yeah, no one cares on that. I know I don't, mostly because I'm actually busy with the other stuff. I file bugs on graphics drivers regularly. I know Dave A has been pretty great about helping me get him info to fix the Radeon stuff. I have a bug opened against nouveau right now as well and Ben has been helpful there too (need to get back to that.) If you mean some other driver, then yeah maybe. I can only test/file bugs on hardware I have. that; well, I don't think Fedora necessarily should be a charity for cases there's no community for. s/no/a small. Pretending we don't exist isn't exactly kind, but I will admit the few of us that participate are limited in time and resources. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Matej Cepl wrote: Well, RHEL commits (hopefully I am not leaking some NDA-covered information ;)) have to have something like fixes #123435 in the commit message. We could do the same easily but requesting that updates in bodhi have to be just bugfixes. I can make a bug out of almost everything. All this bureaucracy would lead to is lots of Bugzilla bug reports to justify updates. Heck, even the existing automated FEver New version available bugs would qualify. Requiring bug references for Bodhi updates would make no sense whatsoever. Please let maintainers decide, most of us know what we're doing. ;-) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 10/01/2009 03:10 AM, Josephine Tannhäuser wrote: 2009/9/14 Adam Williamson awill...@redhat.com Hi, everyone. We - the QA group - have recently been researching the feasibility of using zsync to reduce the size of live image downloads. This has hit a roadblock in the form of the problem where both rsync and zsync use forked zlibs rather than linking against the system copy. Imho, allow zsync for fedora. If you can solve the zlib-problem of rsync, the problem of zsync will be solved as well, cause the integrity of zsync in fedora fails on rsync-compatibility, which needs a forked zlib. If you want it in, do the work. I've outlined the possibilities several times: A) You're a coder and want to get your hands dirty with the rsync protocol. Check out how librsync manages to use the system zlib and if possible to do this compatibly, apply it to zsync and rsync, possible as a build time option. Push the changes upstream if possible. If it's impossible to apply the librsync strategy, having a good explanation of what librsync is doing and why it can't work for rsync/zsync would be great for crossing this option off the list. B) You're a sometime coder and good with talking to other people. Try to convince zlib to take the patches from rsync (and the zlib-rsyncable patches while you're at it). zlib has a mailing list that's open to developers and testers of zlib. AFAICS from looking at subjects in the entire archive, neither of these patches have gone to that mailing list. Since the mailing list archives aren't wide open, I'm thinking that the patches went directly to one of the developers mailboxes where it was ignored or forgotten. Getting them to the mailing list would be a good first start. http://zlib.net/mailman/listinfo/zlib-devel_madler.net C) You're a coder and want to be responsible for maintaining a new, more forward moving zlib. Pull the zlib code out of rsync, start a new upstream for it, package it for Fedora. You can also pull other requested features in (like the zlib-rsyncable patches that were in the zlib I just pulled out of deltarpm). Get someone to announce to other distributions that this library exists. D) You're good with build scripts like autoconf and configure and good with talking to other people. Work on the rsync build so that it builds and installs the bundled zlib as a shared library with a new name. Push the changes to the rsync upstream so they maintain the fork. Asking for an exception when: 1) I just spent all of yesterday dealing with a security flaw due to a bundled zlib and 2) a request for an exception has already been turned down is beating on a dead horse with a wet noodle. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
2009/10/1 Toshio Kuratomi a.bad...@gmail.com: On 10/01/2009 03:10 AM, Josephine Tannhäuser wrote: 2009/9/14 Adam Williamson awill...@redhat.com Hi, everyone. We - the QA group - have recently been researching the feasibility of using zsync to reduce the size of live image downloads. This has hit a roadblock in the form of the problem where both rsync and zsync use forked zlibs rather than linking against the system copy. Imho, allow zsync for fedora. If you can solve the zlib-problem of rsync, the problem of zsync will be solved as well, cause the integrity of zsync in fedora fails on rsync-compatibility, which needs a forked zlib. If you want it in, do the work. I've outlined the possibilities several times: A) You're a coder and want to get your hands dirty with the rsync protocol. Check out how librsync manages to use the system zlib and if possible to do this compatibly, apply it to zsync and rsync, possible as a build time option. Push the changes upstream if possible. If it's impossible to apply the librsync strategy, having a good explanation of what librsync is doing and why it can't work for rsync/zsync would be great for crossing this option off the list. librsync is not wire compatible with rsync, and also hasn't kept up to date with rsync protocol changes, so it may not be as straightforward to lift ideas from librsync. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 10/01/2009 09:42 AM, Jonathan Underwood wrote: 2009/10/1 Toshio Kuratomi a.bad...@gmail.com: A) You're a coder and want to get your hands dirty with the rsync protocol. Check out how librsync manages to use the system zlib and if possible to do this compatibly, apply it to zsync and rsync, possible as a build time option. Push the changes upstream if possible. If it's impossible to apply the librsync strategy, having a good explanation of what librsync is doing and why it can't work for rsync/zsync would be great for crossing this option off the list. librsync is not wire compatible with rsync, and also hasn't kept up to date with rsync protocol changes, so it may not be as straightforward to lift ideas from librsync. Good to know. So we can cross this one off the list. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 1, 2009 at 10:45 AM, Jesse Keating jkeat...@j2solutions.net wrote: I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? Ric No. They heard that here would be a secondary arch effort and seemed to think oh, they will fix it for us. Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. That is sadly true, even of Apple (PPC support is dropped from Snow Leopard, and their LLVM framework is more buggy on PPC -- fastcall does not work, etc. A lot of maintainers probably do care that their software does not have broken assumptions about endianness, so it would be nice that, for a given package N-V-R, we can see both the primary and secondary Kojis' build results. Regards, -- Michel Alexandre Salim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposal: Python 3 in Fedora 13
Proposal: Python 3 in Fedora 13
Evolutionary, not revolutionary: build a python 3 stack
parallel-installable with the python 2 stack.
= High-level summary =
- Python 3.0 was released almost 10 months ago, on 2008-12-03, and the
latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
- Other distros have python 3, though not necessarily with anything
on top resembling the full python 2 stack.
- We have a working, valuable python 2 stack, which is used by
critical system components (yum and anaconda): we must not destabilize
the python 2 stack.
- Python 3 is sufficiently different from python 2 that we need them
to be independent software stacks.
- I plan to spend a large chunk of my $DAYJOB over the next few months
trying to build a useful Python 3 stack for Fedora 13, for some
definition of useful (help will be appreciated!)
- I don't want to add extra work for package maintainers: if you
maintain an SRPM of a python 2 module that's working for you, you
shouldn't feel obligated to own a separate SRPM for python 3. If
someone has a need for the module on python 3, they can take on that
work.
= Background =
Python 3 is intended by upstream to be the future of Python, but we have
many critical components that use Python 2. Python 2 and Python 3 are
sufficiently different that we need both (try writing print in each).
Python 2 will be around for a long time.
An interesting summary of Python 3 adoption can be seen here:
http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html
An earlier proposal about python 3 in Fedora is here:
https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
Going forward, I will have plenty of time to spend, as part of my
dayjob, on Python in Fedora [1]
= Proposal =
I want to get python 3 into Fedora, but I don't want to break yum or
anaconda (or anything else, for that matter!)
How to do this? I propose that Fedora shall have separate,
parallel-installable Python 2 and Python 3 stacks. I believe we can get
things to the point where on a Fedora box you'd be able to install both
stacks, and have some processes running python 2 code, and some running
python 3, simultaneously.
Where I would draw the line is on having both python 2 and python 3
running within the same _process_: the two libraries share most of their
symbol names, but with differing implementations, and the result of
trying to dynamically link the two into the same address space would be
highly unstable.
As an example, you'd be able to install both mod_python and mod_python3
rpms, but you wouldn't be able to (sanely) configure httpd to have both
running simultaneously (I guess we should add a run-time warning for
this case)
Scoping:
- this work would target Fedora 13. I'd avoid pushing it into F12
until it's proven safe to do so
- the proposal is for python 2 vs python 3. It could be extended to
support having multiple minor-versions of Python as well, but that's a
big extension of the work involved and not something I'm planning to
work on myself.
= Details =
We should split python 2 and python 3 at the source RPM level, where
possible.
The easy case is when upstream release separate tarballs for the python
2 and python 3 versions of code. For example, given package
python-foo in packaging CVS, there would be a separate python3-foo
for the python 3 version. There would be no expectation that the two
would need to upgrade in lock-step. (The two SRPMS could have different
maintainers within Fedora: the packager of a python 2 module might not
yet have any interest in python 3)
The more difficult case is when the python module is emitted as part of
the build of a larger module. Some examples:
- the build of rpm itself emits an rpm-python subpackage.
- Another example is the postgres srpm, which emits a
postgresql-python subpackage.
In a quick attempt at seeing other examples, on my laptop (F11), here
are the packages installed that provide python modules where the package
name differs from the srpm name:
$ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v is not owned |
sort | uniq | xargs rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}
%{SOURCERPM}\n | sed -es/.src.rpm// | squeal -f table col0, col1 from
- where col0 != col1
col0| col1|
+--+
at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11|
audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11|
cracklib-python-2.8.13-4| cracklib-2.8.13-4|
gamin-python-0.1.10-4.fc11| gamin-0.1.10-4.fc11|
hplip-libs-3.9.8-12.fc11| hplip-3.9.8-12.fc11|
libproxy-python-0.2.3-10.fc11|libproxy-0.2.3-10.fc11|
libselinux-python-2.0.80-1.fc11| libselinux-2.0.80-1.fc11|
Re: yum update vs. blender
and the solution is ? have you reported that on bugzilla against kde ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
2009/10/1 Kevin Kofler kevin.kof...@chello.at:
Jeff Garzik wrote:
Was ppc really such a burden?
Yes. It slowed down builds, and it often triggered bizarre build failures
which were NOT bugs in the program, but in the toolchain or in some core
library like glibc, which in turn delayed important updates to the affected
packages.
In fact, my favorite ppc64 issue was a problem with OpenBabel hitting a
limitation in the ppc64 toolchain: there's a table of contents which can
grow only to a small fixed size, so large compilation units just don't
compile on ppc64, while being perfectly valid C/C++ and compiling fine on
all other architectures. (And that's already with the minimal TOC. Without
it, the limit is for the whole executable!) OpenBabel's SWIG-generated
bindings exceeded that limit. We were the only ones hitting it as no other
distribution is insane enough to build their packages for ppc64. (The
binaries don't even get actually used as ppc32 is the preferred multilib on
64-bit PowerPC!) I played around with both compiler and SWIG flags to reduce
the amount of TOC entries, which worked for 2 beta releases (requiring
additional tweaking for the second one), but then it overflowed again. This
was a big annoyance because the new OpenBabel betas were required for new
kdeedu betas in Rawhide, so this stalled our KDE work. In the end, upstream
removed some things from their bindings to get them to build, a quite
suboptimal solution. IMHO the ppc64 ABI is just completely broken and needs
to be redesigned from scratch.
Kevin Kofler
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
You absolutely *cannot* build Eclipse plugins on ppc64 hosts because
of this beauty. The current workaround is to just keep resubmitting
the build until Koji picks an i386, x86_64 or ppc host. (Nothing to do
with Eclipse either, BTW, seems like an RPM or mock problem.)
--
Mat Booth
A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CalDAV Calendar (BedeWork)
2009/10/1 Trever L. Adams trever.ad...@gmail.com: Kevin Kofler wrote: Actually, new packages can be pushed as updates. You can add them even to F11, and F10 if you're really quick (new packages are accepted in F10 until 1 month before its end of life, which is basically the day of F12's release, as the end of life for Fedora n is 1 month after Fedora n+2's release). Kevin Kofler As I said, I have a lot to learn. I need help from Java package experts so that I can get up and running quickly. Thank you, Trever There is a Fedora Java Devel mailing list at https://www.redhat.com/mailman/listinfo/fedora-devel-java-list -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CalDAV Calendar (BedeWork)
2009/10/1 Trever L. Adams trever.ad...@gmail.com: Hello all, About a year ago, I suggested that BedeWork (http://bedework.org) be included. I offered to package it with some help. I unfortunately ran out of time. I now have time to package it and hopefully maintain the package. Unfortunately, I haven't written an Java code in a decade or so. I have never messed with Java packages. The problems I have: This package has a bunch of property files that you have to edit before you build the program. (http://www.bedework.org/downloads/3.5/BedeworkManual-3.5.pdf#page=18) These include database names, locations, user/passwords for the database, etc. I do not know if this is normal or not. I do not know how to package this, how to suggest people customize this information, etc. Also, setting usernames and passwords at compile time is definitely not normal for *any* kind of application. Are you sure they are not runtime properties? -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Oct 1, 2009, at 11:00, Tom Lane t...@redhat.com wrote:
Mat Booth fed...@matbooth.co.uk writes:
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
You absolutely *cannot* build Eclipse plugins on ppc64 hosts because
of this beauty. The current workaround is to just keep resubmitting
the build until Koji picks an i386, x86_64 or ppc host. (Nothing to
do
with Eclipse either, BTW, seems like an RPM or mock problem.)
Sweet ... and of course removing PPC64 from the primary arch set does
nothing to help you on this, since those machines are still in the
build
farm, and will have to stay there for at least another year to support
F11/F12.
Actually when removed as a primary arch I do believe no build will be
done (even noarch) on a ppc builder. It cannot init a buildroot as
there are no archful packages for ppc.
--
Jes
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Once upon a time, Josh Boyer jwbo...@gmail.com said: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. Yeah, we seem to have too much churn going with some things as it is during a release. What possible reason would there be to push a major new component into an existing release? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
John Reiser jrei...@bitwagon.com writes: The IXP4xx networking engine operates big endian only. Nevertheless many NSLU2 machines run little-endian and still use that networking hardware. With a performance penalty since all buffers have to be swapped. Little- endian operation of the CPU offers the advantage that an unaligned fetch from memory gives results that are usable after quick fixup. An unaligned fetch in big-endian mode essentially gives junk. Both BE and LE obviously have advantages and disadvantages. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning argus
Jan Klepek wrote: On Wed, 2009-09-30 at 09:58 -0400, L. Gabriel Somlo wrote: Not using argus anymore, and no cycles to do right by it. I will take it. Please make sure you fix the broken dependency in F-12 (on an old version of libpcap) as soon as possible and get the fixed package tagged into the release (request tagging at https://fedorahosted.org/rel-eng/newticket – explain it's to fix a broken dependency). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On 10/01/2009 11:11 AM, Jesse Keating wrote: On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. I disagree. The proposal is really treating python3 as a new language. We can and do push such things into a released Fedora. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:07 -0500, Chris Adams wrote: Once upon a time, Josh Boyer jwbo...@gmail.com said: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. Yeah, we seem to have too much churn going with some things as it is during a release. What possible reason would there be to push a major new component into an existing release? Agreed. This part of my post was clumsy. I think what I meant to say was that I'd want to veto anyone wanting to push it into F12, that they'd have a significant burden of proof of safety before such an action could occur. I don't have any interest in such a backport. Sorry Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote:
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}'
repeated several times.
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 11:23 -0700, Toshio Kuratomi wrote: On 10/01/2009 11:11 AM, Jesse Keating wrote: On Oct 1, 2009, at 10:59, Josh Boyer jwbo...@gmail.com wrote: On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh Ditto. This is not something you would push as an update to a released product. I disagree. The proposal is really treating python3 as a new language. We can and do push such things into a released Fedora. Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 1 Oct 2009, David Malcolm wrote: Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Now- perhaps a repo with your package in it that someone could consume on f12 would be a straightforward goal... if you need extra space on fedorapeople.org for this - let me know. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 2:39 PM, David Malcolm dmalc...@redhat.com wrote: I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Which brings up a useful point in that the critical path has two components; the closure of their Requires, and the closure of their BuildRequires. However - this still seems like low risk to me because the builders only build with what's specified in BuildRequires, so you'd have to have quite a contortion to get python3-devel in there. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On 10/01/2009 10:15 AM, David Malcolm wrote: Proposal: Python 3 in Fedora 13 Evolutionary, not revolutionary: build a python 3 stack parallel-installable with the python 2 stack. First: Overall +1. Note: liberally snipped, throughout. = Proposal = Where I would draw the line is on having both python 2 and python 3 running within the same _process_: the two libraries share most of their symbol names, but with differing implementations, and the result of trying to dynamically link the two into the same address space would be highly unstable. As an example, you'd be able to install both mod_python and mod_python3 rpms, but you wouldn't be able to (sanely) configure httpd to have both running simultaneously (I guess we should add a run-time warning for this case) I don't see any way around this atm but it is something to think about possibilities more. For instance, if we get TurboGears2 ported to python3 while TurboGears1 is still on python2 people will need to run two apache servers (one with python2-mod_wsgi and one with python3-mod_wsgi). Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so There's value in pushing the interpreter to F12 as it opens up porting of code from python2 to python3 to more people. I don't think porting applications to python3 in F12 is of great benefit. Pushing libraries back is somewhere in-between. Of course, at some point this is a matter of maintainers doing what's interesting to them. - the proposal is for python 2 vs python 3. It could be extended to support having multiple minor-versions of Python as well, but that's a big extension of the work involved and not something I'm planning to work on myself. Unless someone actively wants to work on this right now, I'd like to keep that a separate issue as it just makes matters more confusing. The more difficult case is when the python module is emitted as part of the build of a larger module. Some examples: - the build of rpm itself emits an rpm-python subpackage. - Another example is the postgres srpm, which emits a postgresql-python subpackage. There's another case where this exists: upstream plans to do automated translation using a tool like 2to3. This has seemed a bit of a fragile strategy to me but it is recommended by upstream python. Naming convention proposal: How does this sound: - an rpm with a python- prefix means a python 2 rpm, of the default python 2 minor version (for Fedora this will be the most recent stable upstream minor release, for EPEL it will be the minor release of 2 that came with the distro, so 2.4 for EPEL5) - an rpm with a python3- prefix means a python 3 rpm, of the default python 3 minor version (for Fedora this will be the most recent stable upstream release) What about packages without a python- prefix? Proposal: If upstream has a naming convention for python2 vs python3, use it. Otherwise, add a python3- prefix to make things clear. I'm not sure about the details here. Examples? +1 to the basics. There are a lot of details to work out: This seems fine even though it's a bit redundant: python3-pygtk2 and python3-pygpgme. What to do with things that have python in their suffix: gstreamer-python = gstreamer-python3? Or python3-gstreamer? Or python3-gstreamer-python? Most of these are subpackages of existing packages. A cornercase is the gnome-python2 package. These are python bindings to gnome2. gnome-python2 is the upstream name. For python3, do we want python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? A rough plan for Fedora 13 might be: - get python3 packaged in a manner compatible with the above - (persuade /usr/lib/rpm/brp-python-bytecompile to use the correct python when building rpms containing .py files) - get rpm bindings working with python3 - get some useful components working e.g. a web stack: Django, TurboGears etc (though e.g. Django's py3k support is a long way off IIRC); ideas? I'm going to go out on a limb and say this is a bigger goal than we'll be able to achieve for F13 but I like it :-) - solidify packaging guidelines for python 2 vs python 3 once we've got some experience with the above and hopefully proven the techniques Speaking from FPC experience, +1 to this. - look at porting major components over to python3 (but probably don't actually do this for F13; leave python 2 as the critical component, I suspect): - yum (rpm) - anaconda However no plan survives contact with the enemy, we'll see how things turn out in reality when trying to get a full integrated stack working. Future work (F14?) could involve cutting over the major components, so that the base install would bring in python3, and python would become optional. Obviously there's a _lot_ to be done before that can be done sanely. I'm going to say we'll be beyond F14 when this happens. F14 is
Re: PPC/PPC64 disabled in Koji for dist-f13
2009/10/1 Josh Boyer jwbo...@gmail.com:
On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote:
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}'
repeated several times.
Eclipse is an archful package and that plonks files in %{_libdir} that
are needed during the build of plugins that may or may not be noarch.
--
Mat Booth
A: Because it destroys the order of the conversation.
Q: Why shouldn't you do it?
A: Posting your reply above the original message.
Q: What is top-posting?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
HOWTO debug dracut
* read the dracut man page * remove rhgb from the kernel command line and maybe quiet * add rdshell to the kernel command line and you are dropped to a shell * add rdshell rdinitdebug to the kernel command line and dracut shell commands are printed as they are executed * with dracut = 002-11 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Test-Announce] F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT)
When: Friday, 2009-10-02 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers on irc.freenode.net Join us this Friday for another alliterative installment of ... drumroll ... the Beta Blocker Bug review. Previous reviews have been successful at keeping the blocker bug list active. Let's continue this trend by reviewing the current list of unresolved F12Beta bugs [1]. The list of Fedora 12 Beta blocker bugs [1] includes: * 516042 - MODIFIED - Unable to add NFS yum repo during installation * 524599 - MODIFIED - Https repository problems * 519237 - ASSIGNED - bash: cannot set terminal process group (-1): Inappropriate ioctl for device * 522675 - ASSIGNED - mouse,keyboard don't work when boot from LiveCD * 526158 - NEW - font of f12 beta terminal is very big * 526208 - ASSIGNED - preupgrade failed from old release (f10, f11) * 526320 - ASSIGNED - ppc64.img and ppc32.img missing from tree * 526380 - NEW - Xorg update kills graphics * 526470 - NEW - NFSv3 mounting broken in dracut netboot Have an issue you'd like to propose for F12Beta? Please consider the following criteria when escalating an issue: * Can this issue be fixed with a future rawhide update or is it part of the critical path? [2] * Is this defect a high (or greater) severity [3] with no, or an unreasonable, workaround? * Does the presence of this bug dramatically reduce beta test coverage? See you there! James [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Betahide_resolved=1 [2] https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#When_and_how_to_determine_packages_within_the_path [3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity signature.asc Description: This is a digitally signed message part ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: preupgrade from f11 to rawhide broken? python traceback
On Mon, Sep 28, 2009 at 01:01:32PM -0400, Seth Vidal wrote: On Sat, 26 Sep 2009, Pasi Kärkkäinen wrote: Hello, I have fully updated Fedora 11 x86_64 system, and when I run preupgrade-cli I get this: .. .. Saving Primary metadata Saving file lists metadata Saving other metadata Generating sqlite DBs (process:1779): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Parsing primary.xml error: Couldn't find end of Start Tag rpm:entry line 99665 Traceback (most recent call last): File /usr/share/preupgrade/preupgrade-cli.py, line 305, in module pu.main(myrelease) File /usr/share/preupgrade/preupgrade-cli.py, line 270, in main self.generate_repo(cachedir, comps) # TODO: callback? File /usr/lib/python2.6/site-packages/preupgrade/__init__.py, line 651, in generate_repo misc.generate_repodata(dir,comps,callback) File /usr/lib/python2.6/site-packages/preupgrade/misc.py, line 131, in generate_repodata generate_repodata(dir, comps, callback) File /usr/lib/python2.6/site-packages/preupgrade/misc.py, line 148, in generate_repodata_f9 mdgen.doRepoMetadata() File /usr/lib/python2.6/site-packages/createrepo/__init__.py, line 829, in doRepoMetadata rp.getPrimary(complete_path, csum) File /usr/lib64/python2.6/site-packages/sqlitecachec.py, line 45, in getPrimary self.repoid)) TypeError: Parsing primary.xml error: attributes construct error Known problem? How to fix it? this is the second time I've seen this one - if you can find the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate seeing it. # ls /var/cache/yum fedora preupgrade updates # cd /var/cache/yum # find -iname '*primary*' ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite ./preupgrade/.repodata/primary.xml.gz ./preupgrade/.repodata/primary.xml.gz.sqlite ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite I put it available online here: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Firefox complains about it btw.. XML Parsing Error: not well-formed Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Line Number 42622, Column 68: rpm:entry name=group(saslauth) flags=EQ epoch=0 ver=Saslauthd/ ---^ -- Pasi -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
Am 01.10.2009 21:35, schrieb Harald Hoyer: * read the dracut man page * remove rhgb from the kernel command line and maybe quiet * add rdshell to the kernel command line and you are dropped to a shell * add rdshell rdinitdebug to the kernel command line and dracut shell commands are printed as they are executed * with dracut = 002-11 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less oh, and you might be able to * mount /boot or * ifup eth0 and nfs mount a share to copy over /init.log or the whole dmesg output -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote: * read the dracut man page * remove rhgb from the kernel command line and maybe quiet * add rdshell to the kernel command line and you are dropped to a shell * add rdshell rdinitdebug to the kernel command line and dracut shell commands are printed as they are executed * with dracut = 002-11 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less It could probably use some more polish, but I've added your comments to https://fedoraproject.org/wiki/How_to_debug_Dracut_problems Thanks, James signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote: * read the dracut man page * remove rhgb from the kernel command line and maybe quiet * add rdshell to the kernel command line and you are dropped to a shell * add rdshell rdinitdebug to the kernel command line and dracut shell commands are printed as they are executed * with dracut = 002-11 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Jesse Keating wrote: Ditto. This is not something you would push as an update to a released product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 23:21 +0200, Kevin Kofler wrote: Jesse Keating wrote: Ditto. This is not something you would push as an update to a released product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Kevin Kofler The potential to disrupt the regular python, which is critically important to Fedora, makes me very wary of doing something like this on a release that is supposed to be and stay stable. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
Kevin Kofler said the following on 10/01/2009 02:28 AM Pacific Time: So I'll have to blame the previous FESCo for voting this through with practically no feedback, as they observed themselves before the vote: 17:14:04 nirik has there been any feedback on lists or wiki? 17:14:15 * nirik just sees one 'sounds fine to me' comment on the discussion page 17:14:25 notting yeah, haven't seen much The current FESCo might also want to consider taking more of a leadership role in monitoring the release processes, tracking the schedule, and evaluating the quality of the release under development and our ability to release on time. As the group responsible for guiding the technical direction of our releases I think this is something they should be more involved in. I'd be glad to help gather data they might need to do this and there might be others who would be willing to help too. I'm suggesting more proactive leadership from FESCo and clear initiatives to take Fedora to the next level versus only being responsible for approving features, proven packagers, and policy matters. This is also my vision for the Fedora Board. But in any case, I don't think any of us realized the amount of maintainer confusion this would cause (I know I didn't or I would have complained on the mailing list right when this was proposed). In hindsight, it was definitely a mistake. This thread is just one of the examples of maintainers having been led to believe they have more time to develop their features than they actually do, I've seen several more while sitting in FESCo feature meetings. We should fix the mistake at the first opportunity (Fedora 13). In other threads developers complained that the schedule was greatly shortened (not completely true either). It is unreasonable to assume that before the change to Alpha and Beta for Fedora 12, that EVERYONE was clear what happened in Alpha, Beta, and Preview in the previous releases. That has never been the case. Labeling Alpha, Beta, and Preview were not evaluated based on their actual industry meanings but were relabeled from the original test1, test2, and test3, which were equally unclear. At the same time, when the change for Fedora 12 was proposed it was based on a variety of experiences and reactions to our previous test phases and schedule changes for Fedora 12. It lacked hard data and we still don't have any clear criteria to determine which way is better or measure the results. So it is hard to argue that switching back would be any better, though my gut says it would... I know other guts will disagree ;-) We need some guiding criteria or we're just going to keep going around in circles. This is one reason I believe defining our target audience and defining what we want to create and be (separate board thread on fedora-advisory-board list) matters a great deal. John -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Jesse Keating wrote: Ditto. This is not something you would push as an update to a released product. I don't see why a parallel-installable python3/python3000 would cause any problems as an update. Are you able to guarantee that it will in no way interfere with python2 (including in the build root)? Major changes like that during a release are what get Fedora considered a rolling beta quality distribution. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On 10/01/2009 08:02 PM, Adam Williamson wrote:
On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote:
* read the dracut man page
* remove rhgb from the kernel command line and maybe quiet
* add rdshell to the kernel command line and you are dropped to a shell
* add rdshell rdinitdebug to the kernel command line and dracut shell commands
are printed as they are executed
* with dracut= 002-11 (
http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect
the rdinitdebug output with:
# less /init.log
and
# dmesg | less
Please also see
https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the
permanent reference for this topic. I'll add anything in Harald's mail
that's not currently on that page to it. Thanks.
Is this the new format/path of debugging pages for a given component
how_to_debug_component_problem as opposed to
https://fedoraproject.org/wiki/Dracut/Debugging or
component/Debugging and are we going to move all debugging pages
under how_to_debug??
Who ever changed the original one should take the time and update
https://fedoraproject.org/wiki/Dracut/Options to current options listen
in git logs or atleast the man page and remove all pre and {{admon}}
to make it consistent with the new debugging page..
JBG
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On Thu, 2009-10-01 at 22:09 +, Jóhann B. Guðmundsson wrote:
Please also see
https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the
permanent reference for this topic. I'll add anything in Harald's mail
that's not currently on that page to it. Thanks.
Is this the new format/path of debugging pages for a given component
how_to_debug_component_problem as opposed to
https://fedoraproject.org/wiki/Dracut/Debugging or
component/Debugging and are we going to move all debugging pages
under how_to_debug??
It hasn't been officially discussed anywhere - I was using
Bug_info_componentname myself - but I think it's a good choice by
whoever came up with it. It also fits in with the request of the Wiki
admin team that we use flat page names, not nested ones.
Who ever changed the original one should take the time and update
https://fedoraproject.org/wiki/Dracut/Options to current options listen
in git logs or atleast the man page and remove all pre and {{admon}}
to make it consistent with the new debugging page..
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
John Poelstra wrote: The current FESCo might also want to consider taking more of a leadership role in monitoring the release processes, tracking the schedule, and evaluating the quality of the release under development and our ability to release on time. As the group responsible for guiding the technical direction of our releases I think this is something they should be more involved in. I'd be glad to help gather data they might need to do this and there might be others who would be willing to help too. I'm suggesting more proactive leadership from FESCo and clear initiatives to take Fedora to the next level versus only being responsible for approving features, proven packagers, and policy matters. And when should we find the time for that? Our meetings already usually take 2 hours, and during the rest of the week, we have other things to do as well. Being on FESCo is not a paid full-time job! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote: On 10/01/2009 10:15 AM, David Malcolm wrote: Proposal: Python 3 in Fedora 13 Evolutionary, not revolutionary: build a python 3 stack parallel-installable with the python 2 stack. First: Overall +1. Note: liberally snipped, throughout. [likewise snipped lots of stuff] Naming convention proposal: How does this sound: - an rpm with a python- prefix means a python 2 rpm, of the default python 2 minor version (for Fedora this will be the most recent stable upstream minor release, for EPEL it will be the minor release of 2 that came with the distro, so 2.4 for EPEL5) - an rpm with a python3- prefix means a python 3 rpm, of the default python 3 minor version (for Fedora this will be the most recent stable upstream release) What about packages without a python- prefix? Proposal: If upstream has a naming convention for python2 vs python3, use it. Otherwise, add a python3- prefix to make things clear. I'm not sure about the details here. Examples? +1 to the basics. There are a lot of details to work out: [snip the details] Thanks. Given that, I went ahead and created a Feature page for this: https://fedoraproject.org/wiki/Features/Python3F13 So far it's mostly just a restatement of my post, though I've started fleshing out some sections e.g. how to test. I've assumed the naming convention from my post python3 for the srpm, and for the symlink to the binary. Feel free to dive in and edit. I marked myself as owner of the feature as I know I'm going to be able to devote a big chunk of time to this. Hope that's OK. We now have 3 competing srpms for Python 3: (i) the one from ivazquez: http://ivazquez.fedorapeople.org/packages/python3000/ (python3000) (ii) the one by Andrew McNabb: https://bugzilla.redhat.com/show_bug.cgi?id=526126 (named python3) (iii) and the one I did, also named python3: http://people.redhat.com/dmalcolm/python3/python3.spec and an SRPM here: http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm I was just going to suggest you contact ivazquez :-) he's done a lot of work, both to get a python3 package working and on the update from python2.5 to python2.6. I'm assuming ivazquez is seeing these emails (I _think_ he said he'd seen it on IRC earlier today), and I added a link to my email to the review bug above so hopefully Andrew is seeing this. I hope to have a look at the commonality/differences between the 3 efforts tomorrow. I think python3 is a better name (if nothing else, it's shorter to type!). I'd like it if the eventually python 3 specfile could resemble the python 2 specfile so that we can meaningfully look at the textual diffs between them (but it may be necessary to clean up the python specfile to achieve this! I'll try to have a look at the merge-review) Thanks for the feedback; hope this all sounds sane Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Malcolm wrote:
Naming convention proposal:
How does this sound:
- an rpm with a python- prefix means a python 2 rpm, of
the
default python 2 minor version (for Fedora this will be the
most
recent stable upstream minor release, for EPEL it will be the
minor
release of 2 that came with the distro, so 2.4 for EPEL5)
- an rpm with a python3- prefix means a python 3 rpm, of
the
default python 3 minor version (for Fedora this will be the
most
recent stable upstream release)
(we could extend this to have specific minor-releases (e.g.
use
python24- for a python 2.4 stack, in case some brave soul
wants to get
zope/plone running. But may be better to try to fix the
zope/2.6
incompatibility at that point (caveat: haven't looked at the
details of
the issue). I don't intend to work on such versions))
What about packages without a python- prefix? Proposal: If
upstream
has a naming convention for python2 vs python3, use it.
Otherwise, add
a python3- prefix to make things clear. I'm not sure about
the
details here. Examples?
There have been various discussions upstream about what to
call the
python 3 binary. My favorite quote on the subject is from
Guido,
http://mail.python.org/pipermail/python-3000/2008-
March/012421.html :
During the next 3 years or so, installing Py3k as the default
python
will be a deed of utter irresponsibility and is likely to
break your
system in subtle ways (both OSX and Linux these days use
Python for
certain system tasks). If you *really* want to shoot yourself
in the
foot this way, go ahead and explicitly use make altinstall
bininstall or link it yourself.
I propose that for Fedora we have /usr/bin/python3 for the
system/default version of python 3 and /usr/bin/python for
the
system/default version of python 2. Both would be symlinks to
a binary
with the minor-release embedded in the name
(/usr/bin/python3.1 and
/usr/bin/python/2.6).
As I understand things, this should make us broadly in
agreement with
upstream; see e.g.:
http://mail.python.org/pipermail/python-dev/2009-
April/088862.html
http://mail.python.org/pipermail/python-dev/2009-
April/04.html
Could we do something similar to what qt and kdelibs packages
have done? While qt3 was default, the 'qt' package points to qt3
and qt4 is an entirely separate package. When qt4 became
default, qt3 was the one with the explicit version on it (and
qt4 still exists, but the default 'qt' is qt4 now). This would
mean that python2 packages grow 'Provides: python2-foo =
%{version}-%{release}'. When python3 is the default, then have
python point to python3 (and we can drop the Provides/Obsoletes
for python3- prefixed packages later if wanted).
My thought process is that I would not like, after python3 is
the default, to still have to put the explicit 3 on there
because python is still python2. Just thinking ahead here.
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCAAGBQJKxTdfAAoJEKaxavVX4C1Xdf0QANdjkM1iZhZfnxSLErl8qsrr
Eqhg51xTZdolE/8/Z08DTxE3EF5yj5BsfGPgTfiyTgzqiFgMYpAxU6NYKRZI0WmL
C3eC8oHMINRJGotklzHZiTnyUbZd2MZQuPWhMljOchOGOTktT9oaXZND/co1Aixo
xNVqXLYQAYWAlF0A0fjVJ12x2eq4jcG8d2rDaOmiXMj4UTI1ZfVFyofBHm++4hUB
dQ6JNrN11Tzd7fOnGZKvLUgvfEOXlP8K51dFKiaZI+iBxvU14GnU4e7p3ri4CEjT
CKk8AzSKkwLcKk8ipCwN3+BvLCMvq91RtBoh1amhevCg2FgULnbe2ZWv9qhZkpJg
EG4HVCbhXgeMvIbX6prGMtcDAe4X8QNesMX2C7OCqwwkFDea9qSNCb7ZLVscGCZQ
OeRKfgD7DN1XnH/6F2a6p5lxNQF6EQ0G7oWjloSwWtOCNLTU+pDI1waTPM74yh/Y
1sabs31wYUi+gbW3sFqfWoMnkAisKRLXeKzxsZvotz4R87+GEwoV1ZZJNL+NWvZz
V+IGhU+B6PTu8Jo6KfV2xJ6Y0kx8qKSlk9LdiZ9RKTyxgnZVaxj3YJceeUv1TSI/
U8xVwEjcMxDdink2NBlyGkd+its4+9ZlShHLMOKdYIAnibov72WlMLKXYNr8plpO
kQYYB0B/z9A1fXFxNqKu
=dgBR
-END PGP SIGNATURE-
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Malcolm wrote:
Naming convention proposal:
How does this sound:
- an rpm with a python- prefix means a python 2 rpm, of
the
default python 2 minor version (for Fedora this will be the
most
recent stable upstream minor release, for EPEL it will be the
minor
release of 2 that came with the distro, so 2.4 for EPEL5)
- an rpm with a python3- prefix means a python 3 rpm, of
the
default python 3 minor version (for Fedora this will be the
most
recent stable upstream release)
(we could extend this to have specific minor-releases (e.g.
use
python24- for a python 2.4 stack, in case some brave soul
wants to get
zope/plone running. But may be better to try to fix the
zope/2.6
incompatibility at that point (caveat: haven't looked at the
details of
the issue). I don't intend to work on such versions))
What about packages without a python- prefix? Proposal: If
upstream
has a naming convention for python2 vs python3, use it.
Otherwise, add
a python3- prefix to make things clear. I'm not sure about
the
details here. Examples?
There have been various discussions upstream about what to
call the
python 3 binary. My favorite quote on the subject is from
Guido,
http://mail.python.org/pipermail/python-3000/2008-
March/012421.html :
During the next 3 years or so, installing Py3k as the default
python
will be a deed of utter irresponsibility and is likely to
break your
system in subtle ways (both OSX and Linux these days use
Python for
certain system tasks). If you *really* want to shoot yourself
in the
foot this way, go ahead and explicitly use make altinstall
bininstall or link it yourself.
I propose that for Fedora we have /usr/bin/python3 for the
system/default version of python 3 and /usr/bin/python for
the
system/default version of python 2. Both would be symlinks to
a binary
with the minor-release embedded in the name
(/usr/bin/python3.1 and
/usr/bin/python/2.6).
As I understand things, this should make us broadly in
agreement with
upstream; see e.g.:
http://mail.python.org/pipermail/python-dev/2009-
April/088862.html
http://mail.python.org/pipermail/python-dev/2009-
April/04.html
Could we do something similar to what qt and kdelibs packages
have done? While qt3 was default, the 'qt' package points to qt3
and qt4 is an entirely separate package. When qt4 became
default, qt3 was the one with the explicit version on it (and
qt4 still exists, but the default 'qt' is qt4 now). This would
mean that python2 packages grow 'Provides: python2-foo =
%{version}-%{release}'. When python3 is the default, then have
python point to python3 (and we can drop the Provides/Obsoletes
for python3- prefixed packages later if wanted).
My thought process is that I would not like, after python3 is
the default, to still have to put the explicit 3 on there
because python is still python2. Just thinking ahead here.
Thanks! If I'm correctly reading your mail, this approach is one I did
think of, but I'm not fond of it.
I think that anyone dealing with Python is going to have to be thinking
is this python 2 or python 3 for some years to come, so having an
explicit python3- prefix is probably not too painful.
What I think would be painful in your suggestion is the flag day where
we'd change the meaning of python- in RPM names. Currently in Fedora
and EPEL, python- implies the system-supplied minor release of python
2, be it in Fedora (2.6), or in EPEL (2.4). I worry that changing it to
imply the system-supplied minor release of Python 3 (3.1, or 3.2/3.3? by
that point) would be thoroughly confusing, since we'd have to update
everything all at once. It wouldn't fly within EPEL, since the
pre-existing Enterprise downstreams of Fedora aren't going to change
(far too disruptive).
One middle ground might be to start using python2- explicitly for
_new_ packages. That wouldn't break anything, but could easily be
confusing as well. I think I prefer keeping things consistent.
Perhaps at some point we could cut over /usr/bin/python from being
Python 2 to Python 3, but I refer you again to this quote from Guido:
http://mail.python.org/pipermail/python-3000/2008-March/012421.html
(The other fun thing to do might be to package Unladen Swallow. Not at
all sure what to call _that_ though!)
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On 10/01/2009 10:26 PM, Adam Williamson wrote: On Thu, 2009-10-01 at 22:09 +, Jóhann B. Guðmundsson wrote: Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks. Is this the new format/path of debugging pages for a given component how_to_debug_component_problem as opposed to https://fedoraproject.org/wiki/Dracut/Debugging or component/Debugging and are we going to move all debugging pages under how_to_debug?? It hasn't been officially discussed anywhere - I was using Bug_info_componentname myself - but I think it's a good choice by whoever came up with it. It also fits in with the request of the Wiki admin team that we use flat page names, not nested ones. Well I think the documentation team ( doc list cc-ed ) should provide us with rules and regulation ( or templates ) on how component page should be written including bug reporting etc.. and who the target audience is so at-least some consistency exist in the wiki, I personally write pages targeted at novice end user so they tend to be more step by step oriented since I believe that we should expose testing of a component to as wide audience as possible regardless of the individual skill ( it might be a kid taking his first step into the linux, Fedora community and participate or it might be an experienced user ) set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community. When an indvidual changes the layout of my wiki written pages ( other than simply fix my ken-lee English ) I believe ( since he thinks he does a better job than me delivering the content of the page to well what he sees as the target audience ) that he will maintain the given component pages and keep it update to upstream documentation. ( since he has the time to totally rewrite the page he should have the time to do the necessary research and keep it updated to upstream documentation/changes/git logs ). It's not enough simply write those pages they need to be maintained and updated as well and I for one don't participate in wiki writing ping pong game.. JBG -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On Thu, 2009-10-01 at 23:39 +, Jóhann B. Guðmundsson wrote: set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community I think you're setting up a straw man here. I haven't seen anyone on this list suggest any such thing, and I don't see that any of the existing pages are intentionally written in this way. It would be good to have consistent styles for such pages, but there's no need to set it up in such a confrontational way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Malcolm wrote:
On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
Could we do something similar to what qt and kdelibs packages
have done? While qt3 was default, the 'qt' package points to
qt3
and qt4 is an entirely separate package. When qt4 became
default, qt3 was the one with the explicit version on it (and
qt4 still exists, but the default 'qt' is qt4 now). This
would
mean that python2 packages grow 'Provides: python2-foo =
%{version}-%{release}'. When python3 is the default, then
have
python point to python3 (and we can drop the
Provides/Obsoletes
for python3- prefixed packages later if wanted).
My thought process is that I would not like, after python3 is
the default, to still have to put the explicit 3 on there
because python is still python2. Just thinking ahead here.
Thanks! If I'm correctly reading your mail, this approach is
one I did
think of, but I'm not fond of it.
I think that anyone dealing with Python is going to have to be
thinking
is this python 2 or python 3 for some years to come, so
having an
explicit python3- prefix is probably not too painful.
Package names wouldn't change for some time. Guido says 2--3
years, so python meaning python3 is some time away yet.
What I think would be painful in your suggestion is the flag
day where
we'd change the meaning of python- in RPM names. Currently
in Fedora
and EPEL, python- implies the system-supplied minor release
of python
2, be it in Fedora (2.6), or in EPEL (2.4). I worry that
changing it to
imply the system-supplied minor release of Python 3 (3.1, or
3.2/3.3? by
that point) would be thoroughly confusing, since we'd have to
update
everything all at once. It wouldn't fly within EPEL, since
the
pre-existing Enterprise downstreams of Fedora aren't going to
change
(far too disruptive).
This is where the 'Provides: python2-foo' kicks in. 'Requires:'
in other packages would be updated to point to the python2-foo
Provides for dependency solving. Over time, packages should be
updated and if some deadline isn't met, start opening bugs, then
finally using provenpackager when another deadline is hit. Even
after the change, python3 packages would Provides/Obsoletes
their old python3- names but would be moved to have the main
package name be python-. Dependency chains should hold as long
as the python2- and python3- Requires are used instead of the
python- ones.
One middle ground might be to start using python2-
explicitly for
_new_ packages. That wouldn't break anything, but could
easily be
confusing as well. I think I prefer keeping things
consistent.
This would still leave python2 to hold claim to the python-
prefix and python3- left with the 3 in it. And I am for
consistency here.
Perhaps at some point we could cut over /usr/bin/python from
being
Python 2 to Python 3, but I refer you again to this quote from
Guido:
http://mail.python.org/pipermail/python-3000/2008-
March/012421.html
Yes, and after that time, what? Always use python3? I'd like to
start a transition route worked out now before we start down
towards python3 so that things aren't rushed later.
(The other fun thing to do might be to package Unladen
Swallow. Not at
all sure what to call _that_ though!)
Hopefully these changes will get merged some day. A faster
python is on my list of wants for python (as well as a debugger
and a valgrind-like tool to see where loose references are being
kept).
Dave
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCAAGBQJKxUjTAAoJEKaxavVX4C1XuycQANByZEaH5Z0894ajjQKkEaaE
IG35V4n1WBVVR/77UPh5sBtJtRvsYXIGduYDdZZL/cwAq8LXS8Kn0j8yOB8Y0V0z
bU6WzAb6UAyZqxRYVL1DKsELAbzonqSTHr9g1as3bGiEsZchKjKNLM+C+RRGMpGr
mgkWCZyyuCEUzt+fZSaQ11TMat2eWApLyDuNupmSkCIxzG7EI5R8ovYT2jiQ732W
YUfnclY9sU3T/KhRUHsHCDsGsJOJMzt3SfZxrCgKzfdh3C/RuIi7v3u//1szGLk4
eK0XTruPwNrmkd7/kOwkjyFDVI/HnGWwvGnljz2bMfPC9he3qJdmPC03X1a91hTR
M6Bljqd4m52X/IebPx+O4i9oEXByaK+UwYkvliEqUqPXdjYijGogTha0KQP8F1RU
b0LFuPy1/MZ99Vizl++gwIKu5cXRuOu00H+G7sRbb0SnhY8qZUcz8HvgAR141lwY
d34f8jnxCXlu0KorxHhg6qMstD6EoATA0wfPeGwPv8MWB6YD3ar5q8vkLykb6qQ/
VJONpAwNLMGGv03IzC60HG+s0kDlcJkdRjPzs20lj1siKS8N4Oza0FvBFFCcyCA5
G1w3BEzAILv2SbxCs9KRrvdUSjVmjC2HKnmYcT2wlv8Hv8Ec5BsN19i/UaYIAD/1
P5VAEUJafmJPovLw2oR6
=GaN9
-END PGP SIGNATURE-
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Fri, Oct 02, 2009 at 12:53:21AM +0200, Kevin Kofler wrote: John Poelstra wrote: The current FESCo might also want to consider taking more of a leadership role in monitoring the release processes, tracking the schedule, and evaluating the quality of the release under development and our ability to release on time. As the group responsible for guiding the technical direction of our releases I think this is something they should be more involved in. I'd be glad to help gather data they might need to do this and there might be others who would be willing to help too. I'm suggesting more proactive leadership from FESCo and clear initiatives to take Fedora to the next level versus only being responsible for approving features, proven packagers, and policy matters. And when should we find the time for that? Our meetings already usually take 2 hours, and during the rest of the week, we have other things to do as How about starting now? Our last two meetings took about 20 min combined. We're through the Feature process mostly, and we're entering the part of the development cycle that people need help with, reminders for, planning, etc. I actually agree with some of what John said. I had a discussion with someone earlier today that echoed many of those sentiments. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On 10/01/2009 11:53 PM, Adam Williamson wrote: On Thu, 2009-10-01 at 23:39 +, Jóhann B. Guðmundsson wrote: set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community I think you're setting up a straw man here. I haven't seen anyone on this list suggest any such thing, and I don't see that any of the existing pages are intentionally written in this way. It would be good to have consistent styles for such pages, but there's no need to set it up in such a confrontational way. As I said other voices I never said they resided on this list ( I dont keep tap who's on this list or any other list for that matter ) however you should recall atleast one such debate when we rewrote/redesigned the QA frontpage on the wiki.. I feel we definitively needs some wiki rules and regulations. When I started to write wiki pages I was pointed out that I should write those pages on my name space followed by pointing other members of the community to that page and if the community was happy with the content/layout it would be move to the front if not I should A) rewrite the page according to suggestion and resubmit or B) those that did not agree with the content layout of that page should draft what ever they think it should look like and submit that. if I would change an already published wiki page I should comment in the page it self why I made those changes . Now I had barely finished wikifying for example Sysrq ( Now https://fedoraproject.org/wiki/QA/Sysrq ) and was waiting for feed back from the community ( for example if it was simple/clear enough ) when it got yanked out of my personal space and dump where it resides now ( which probably not where the wiki admins want it to reside ). Either we create pages at will submit them when accepted they get move to the front then if a rewriting ( other than minor changes such as typo fixing etc ) occurs the individual that wants to rewrite the current page does so on his own name space and submits his changes or everybody hack everything everywhere on the wiki and constantly play wiki rewriting ping pong game of how their perception on how things should look/be written. One half says user your own namespace and submit your suggestion comment when changing.the other halfs says wanna change something on the wiki change it. I think the community needs to agree on which way it should be. JBG PS. Good coders make crappy documents. If and when they find the time to write them they usually tend to be to technical/development oriented even tho the indented audience is the end user. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20091002) FESCo meeting
Sorry for the late notice. There's only one agenda item for tomorrow's FESCo meeting, and that's the dropping of features that are not yet 100% complete. The meeting will be held tomorrow at 17:00UTC (13:00EDT) in #fedora-meeting on irc.freenode.net I've also copied the relevant feature owners, in the hopes this winds up in their inbox :) The features proposed to be dropped (also in FESCo ticket 254): https://fedoraproject.org/wiki/Features/DisplayPort https://fedoraproject.org/wiki/Features/LowerProcessCapabilities https://fedoraproject.org/wiki/Features/NFSv4Default -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 3:17 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I don't see any way around this atm but it is something to think about possibilities more. One way around this that I use at $DAYJOB (to minimize exposure of a PHP enabled webserver, thus minimizing attack surface, and also allowing apache to fail for a site without taking 15 unrelated sites with it), is to actually have two separate instances of httpd running, one with mod_python, and the other with mod_python3. Of course this requires manual intervention on the part of the local admin, but I would think that any admin that wanted to do this would be sufficiently competent to handle the intricacies of that choice. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Thu, Oct 1, 2009 at 8:51 PM, Josh Boyer jwbo...@gmail.com wrote: How about starting now? Our last two meetings took about 20 min combined. We're through the Feature process mostly, and we're entering the part of the development cycle that people need help with, reminders for, planning, etc. I actually agree with some of what John said. I had a discussion with someone earlier today that echoed many of those sentiments. +1. I've been sorta lax in this area, due to a whole bunch of things, a large one of which is $DAYJOB, which keeps me *quite* busy. However, for the original topic of this thread, I 100% agree that we should have noticed that NFSv4 mounts weren't the default and pestered Steve about that. This is a Big Thing(TM) that someone with the visibility that we have into the feature process should have noticed, since that was the entire point of the feature! At $DAYJOB I get to harp on the proactive vs. reactive bit. I think it's about the same that we do the same, where we can, in Fedora as well. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: HOWTO debug dracut
On Fri, 2009-10-02 at 01:35 +, Jóhann B. Guðmundsson wrote: As I said other voices I never said they resided on this list ( I dont keep tap who's on this list or any other list for that matter ) however you should recall atleast one such debate when we rewrote/redesigned the QA frontpage on the wiki.. I feel we definitively needs some wiki rules It would help if you'd split things into paragraphs, my eyes keep glazing over after four lines... and regulations. When I started to write wiki pages I was pointed out that I should write those pages on my name space followed by pointing other members of the community to that page and if the community was happy with the content/layout it would be move to the front if not I should A) rewrite the page according to suggestion and resubmit or B) those that did not agree with the content layout of that page should draft what ever they think it should look like and submit that. That's the procedure we follow for particularly significant and important pages - like the most popular few pages for a group (the Bugzappers front page, joining page etc). It doesn't scale to _every page in the Wiki_, there just aren't the resources to review everything. For a less significant page like this, it doesn't need review. if I would change an already published wiki page I should comment in the page it self why I made those changes . That's not correct, you should explain in the comment box when you make the change. If you need a longer justification than that space allows, put it on the Talk page. Now I had barely finished wikifying for example Sysrq ( Now https://fedoraproject.org/wiki/QA/Sysrq ) and was waiting for feed back from the community ( for example if it was simple/clear enough ) when it got yanked out of my personal space and dump where it resides now ( which probably not where the wiki admins want it to reside ). That sounds strange, I didn't know anything about it happening at the time. Who moved it? What was the rationale? Having said that, that's probably an example of a page it's fine to just create directly - it's not crucial enough to require drafting and formal review, though of course it's always good to get other people's opinions on the page if you can :) Either we create pages at will submit them when accepted they get move to the front then if a rewriting ( other than minor changes such as typo fixing etc ) occurs the individual that wants to rewrite the current page does so on his own name space and submits his changes or everybody hack everything everywhere on the wiki and constantly play wiki rewriting ping pong game of how their perception on how things should look/be written. In practice, it's usually easy to compromise. Since everyone's basically pointing in the same direction here, and it's easy to collaborate, that kind of ping-ponging doesn't happen too often. When it does get started, we can agree to bring both perspectives to a meeting or ML discussion and decide on the best approach with the approval of the rest of the group. One half says user your own namespace and submit your suggestion comment when changing.the other halfs says wanna change something on the wiki change it. I think the community needs to agree on which way it should be. As I said, I don't think this is an area where there needs to be One True Way. Different groups and different pages can take different approaches. As long as the information gets out there in the end, it's okay. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Broken dependencies: perl-POE-Component-Client-HTTP
perl-POE-Component-Client-HTTP has broken dependencies in the development tree: On ppc: perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 On x86_64: perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 On i386: perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 On ppc64: perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Broken dependencies: perl-POE-Component-Client-HTTP
Hello, perl-POE-Component-Client-HTTP has broken dependencies in the development tree: perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) = 0:0.0901 who knows what the development tree is? Anyway, dist-f12 and dist-f13 are ok, AFAIK, but I noticed that no *-Keepalive is in f12-beta after my untags, so I tagged the latest one from dist-f12 there: koji tag-pkg f12-beta perl-POE-Component-Client-Keepalive-0.2500-3.fc12 Hope this fixes it. Stepan -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
