Re: Buyer Beware: A Major Change in NFS is about to happen
Jesse Keating, Thu, 01 Oct 2009 07:39:16 -0700: We've stopped caring about anything outside of the critical path. Thanks for clarifying it. At least I know now that I should give up on maintaining Fedora packages because nobody cares about them. Will do next week. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE-SIG weekly report (40/2009)
On Thursday 01 October 2009 20:38:30 Sebastian Vahl wrote: Am Mittwoch 30 September 2009 schrieb Jaroslav Reznik: o future of Phonon * Upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately. * Mandriva developments integrating pulseaudio support (and improving gstreamer backend). [1] * We will move back to building a standalone phonon SRPM. * The vote for the default backend is split 3:3, needs the 7th vote from svahl. Sorry for the delay. Was a bit busy and not at home. I tend to xine as default backend for several reasons: - It worked fine for me for several releases (and according to bugs for other too) - It is recommend by upstream. - We won't get trouble with the amarok guys. :) - At least on one system I have no sound with gstreamer (maybe caused by other issues, have to re-check that). So I'm a bit conservative here, but +1 for xine. Hi Svahl, thanks for your vote. So it's now 4:3 for Xine backend. So what are the required steps now? As we already missed freeze but we can work it out with rel engs. I like idea of shipping both backends as proposed rdieter but set the Xine one as default one. But first we should fix bug with switching backends... Distant future: I'll try to look at GStreamer backend more deeply later as I think it's the future - not only for Fedora but for upstream too and I hope we can get it at least to the the point to be comparable with Xine one. Then we can reconsider this decision. Sebastian Jaroslav -- 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
Problems building kernel
I'm trying to build an old(ish) kernel (2.6.29.1-46-fc11.i586) on an up-to-date F-11 system, but I keep getting a build failure. I have tracked it down to the following. At the beginning of the %install stage, it executes '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' / '] rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 but there are already files in that directory that have been created earlier in the build process and are needed for the install (see extract of build log below). I notice that when kernels are build in koji, this rm ... does not get executed, but also, looking at other packages' build.log in koji (the example I took was rpm itself), then the equivalent rm command is executed. I cannot see where the rm ... command comes from, or how to stop it. Can anyone give me some pointers? Q mkdir -p /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/usr/src/kernels + mv /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386//usr/src/kernels/2.6.29.1-46.fc11.i586 + ln -sf ../../../usr/src/kernels/2.6.29.1-46.fc11.i586 /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.NR0ESi + umask 022 + cd /u/home/hsn/rpmbuild/BUILD + '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' / ']' + rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 ++ dirname /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 + mkdir -p /u/home/hsn/rpmbuild/BUILDROOT + mkdir /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 + cd kernel-2.6.29 + LANG=C + export LANG + unset DISPLAY + cd linux-2.6.29.i586 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Problems building kernel
I'm trying to build an old(ish) kernel (2.6.29.1-46-fc11.i586) on an up-to-date F-11 system, but I keep getting a build failure. I have tracked it down to the following. At the beginning of the %install stage, it executes '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' / '] rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 but there are already files in that directory that have been created earlier in the build process and are needed for the install (see extract of build log below). I notice that when kernels are build in koji, this rm ... does not get executed, but also, looking at other packages' build.log in koji (the example I took was rpm itself), then the equivalent rm command is executed. I cannot see where the rm ... command comes from, or how t mkdir -p /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/usr/src/kernels + mv /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386//usr/src/kernels/2.6.29.1-46.fc11.i586 + ln -sf ../../../usr/src/kernels/2.6.29.1-46.fc11.i586 /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386/lib/modules/2.6.29.1-46.fc11.i586/build + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.NR0ESi + umask 022 + cd /u/home/hsn/rpmbuild/BUILD + '[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' / ']' + rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 ++ dirname /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 + mkdir -p /u/home/hsn/rpmbuild/BUILDROOT + mkdir /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 + cd kernel-2.6.29 + LANG=C + export LANG + unset DISPLAY + cd linux-2.6.29.i586 -- 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 19:15, David Malcolm dmalc...@redhat.com wrote: - 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. Do we have an idea how far our stack is from working on python3 ? And how far all the rest of python packages is? I think at one point the decision to switch to python3 has do be done and some packages will be left behind (at least for a while). It is just a question when the switch will happen. A parallel python3 stack now would mostly be usable for people using python3 for work and for these a separate repo would be enough, they probably will need this for RHEL/CentOS too. Cheers, Christof -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Problems building kernel
Quentin Armitage wrote, at 10/02/2009 04:43 PM +9:00:
I'm trying to build an old(ish) kernel (2.6.29.1-46-fc11.i586) on an
up-to-date F-11 system, but I keep getting a build failure. I have
tracked it down to the following.
At the beginning of the %install stage, it executes
'[' /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386 '!=' /
']
rm -rf /u/home/hsn/rpmbuild/BUILDROOT/kernel-2.6.29.1-46.fc11.i386
but there are already files in that directory that have been created
earlier in the build process and are needed for the install (see
extract of build log below).
I notice that when kernels are build in koji, this rm ... does not get
executed, but also, looking at other packages' build.log in koji (the
example I took was rpm itself), then the equivalent rm command is
executed.
I cannot see where the rm ... command comes from, or how t
This change (i.e. deleting %buildroot tree at the beginning of %install)
comes from the change in redhat-rpm-config
(see $ rpm -q --changelog redhat-rpm-config and the file
/usr/lib/rpm/redhat/macros )
Recent kernel.spec has the following lines at the top to prevent this
behavior.
---
# We have to override the new %%install behavior because, well... the kernel is
special.
%global __spec_install_pre %{___build_pre}
---
Regards,
Mamoru
--
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
Dne Fri, 2 Oct 2009 06:08:16 + (UTC) Matej Cepl napsal(a): Jesse Keating, Thu, 01 Oct 2009 07:39:16 -0700: We've stopped caring about anything outside of the critical path. Thanks for clarifying it. At least I know now that I should give up on maintaining Fedora packages because nobody cares about them. You're misinterpreting Jesse's quote out of context. I'm sure the intent was NOT nobody cares about your packages. I read it as: We (rel-eng) will always approve your tag request for a non-critical package because we trust you as a packager that the package is a bugfix. We will be more careful with critical path packages though, because of the inherent risk of breaking the release. Michal -- 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
Le 02/10/2009 09:46, Christof Damian a écrit : Do we have an idea how far our stack is from working on python3 ? And how far all the rest of python packages is? Not much, there are few external modules working though the list is slowly growing (pyqt4, openCV etc, libxml...). Here are some python3 modules hosted on PyPI http://pypi.python.org/pypi?:action=browsec=533show=all I think at one point the decision to switch to python3 has do be done and some packages will be left behind (at least for a while). It is just a question when the switch will happen. There should be no discussion of switching to python3 as default interpreter before the upcoming python 2.7. Python 2.7 is planned to the last offspring of python2.x and to further reduce the gap between python2 and python3. A parallel python3 stack now would mostly be usable for people using python3 for work and for these a separate repo would be enough, they probably will need this for RHEL/CentOS too. It won't. *BSD, fellow GNU/Linux distro like Debian, Mandriva, Ubuntu even macports are able to ship multiples python stacks and we (Fedora) are not ? Isn't Fedora supposed to lead ? Since Python is parallel installable by design, our main issues are to deal with packaging guidelines (naming, possible conflicts, etc ...) and considering porting our own python modules and/or fixing them to ease the port. Though a separate repo would help to identify and fix possible conflicts, we should be able to provide a minimal python3 stack for F-13 (and maybe F-12 through updates) and eventually few blessed third-party modules. After all, others are already shipping it or will ship it in their next release. Besides, that would encourage python modules maintainers to port and test their modules on python3. Besides, the longer we wait, the harder/longer the transition will be. H. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-doc, -devel and -examples sub-packages question
I've pack library ne7ssh https://bugzilla.redhat.com/show_bug.cgi?id=521909 . History in two words: It contain 6 examples files and Makefile to built it. I've package it into ne7ssh-examples sub-package. Michael Schwendt say what it should not be separate sub-package, and right point me what other documentation have minor size and candidate to -doc sub-package. I done that. But for right dependency include Require: ne7ssh-devel, without that examples filed to built. It was also treated as wrong. I wasn't agree with solution place all docs into -doc but examples in -devel. I think it is incorrect. I also treat presents of source files to end-user with known result - missing build dependency is not correct maintainer decision. Also I agree what -devel dependency in -doc too is not best... So, is there any guidelines, policy or something else on this case? With best wishes, Pavel Alexeev aka Pahan-Hubbitus. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-doc, -examples sub-packages creation question
I've pack library ne7ssh https://bugzilla.redhat.com/show_bug.cgi?id=521909 . History in two words: It contain 6 examples files and Makefile to built it. I've package it into ne7ssh-examples sub-package. Michael Schwendt say what it should not be separate sub-package, and right point me what other documentation have minor size and candidate to -doc sub-package. I done that. But for right dependency include Require: ne7ssh-devel, without that examples filed to built. It was also treated as wrong. I wasn't agree with solution place all docs into -doc but examples in -devel. I think it is incorrect. I also treat presents of source files to end-user with known result - missing build dependency is not correct maintainer decision. Also I agree what -devel dependency in -doc too is not best... So, is there any guidelines, policy or something else on this case? With best wishes, Pavel Alexeev aka Pahan-Hubbitus. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-doc, -examples sub-packages creation question
I'm package library ne7ssh https://bugzilla.redhat.com/show_bug.cgi?id=521909 . History in two words: It contain 6 examples files and Makefile to built it. I've package it into ne7ssh-examples sub-package. Michael Schwendt say what it should not be separate sub-package, and right point me what other documentation have minor size and candidate to -doc sub-package. I done that. But for right dependency include Require: ne7ssh-devel, without that examples filed to built. It was also treated as wrong. I wasn't agree with solution place all docs into -doc but examples in -devel. I think it is incorrect. I also treat presents of source files to end-user with known result - missing build dependency is not correct maintainer decision. Also I agree what -devel dependency in -doc too is not best... So, is there any guidelines, policy or something else on this case? With best wishes, Pavel Alexeev aka Pahan-Hubbitus. -- 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, 2 Oct 2009, Matej Cepl wrote: Jesse Keating, Thu, 01 Oct 2009 07:39:16 -0700: We've stopped caring about anything outside of the critical path. Thanks for clarifying it. At least I know now that I should give up on maintaining Fedora packages because nobody cares about them. Will do next week. Oh the drama. A little less hyperbole and a little more understanding would probably help everyone. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091002 changes
Compose started at Fri Oct 2 06:15:09 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) labrea-2.5.1-2.fc10.i386 requires libpcap.so.0.9 libvirt-qpid-0.2.17-0.fc12.i686 requires libqpidclient.so.2 libvirt-qpid-0.2.17-0.fc12.i686 requires libqmfagent.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 libqpidclient.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfagent.so.2 matahari-0.0.4-5.fc12.i686 requires libqpidcommon.so.2 matahari-0.0.4-5.fc12.i686 requires libqmfcommon.so.2 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) 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) 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 argus-2.0.6.fixes.1-16.fc11.ppc requires libpcap.so.0.9 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) labrea-2.5.1-2.fc10.ppc requires libpcap.so.0.9 libvirt-qpid-0.2.17-0.fc12.ppc requires libqpidclient.so.2 libvirt-qpid-0.2.17-0.fc12.ppc requires libqmfagent.so.2 libvirt-qpid-0.2.17-0.fc12.ppc requires libqpidcommon.so.2 libvirt-qpid-0.2.17-0.fc12.ppc requires libqmfcommon.so.2 matahari-0.0.4-5.fc12.ppc requires libqpidclient.so.2 matahari-0.0.4-5.fc12.ppc requires libqmfagent.so.2 matahari-0.0.4-5.fc12.ppc requires libqpidcommon.so.2 matahari-0.0.4-5.fc12.ppc requires libqmfcommon.so.2 rhn-check-0.7.3-1.fc12.noarch requires yum-rhn-plugin = 0:0.5.3-30 yersinia-0.7.1-3.fc11.ppc requires libpcap.so.0.9 Broken deps for ppc64
Trying to build zkt 0.99c on Fedora 11
I'm trying to build zkt 0.99c on Fedora 11 (x86_64) and am running into the following error: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -g -DHAVE_CONFIG_H -I. -Wall -Wmissing-prototypes -c -o soaserial.o soaserial.c In file included from /usr/include/sys/syslog.h:207, from /usr/include/syslog.h:1, from log.h:43, from nscomm.h:44, from nscomm.c:46: /usr/include/bits/syslog.h: In function 'syslog': /usr/include/bits/syslog.h:32: error: invalid use of '__builtin_va_arg_pack ()' Google tells me this has more to do with changes in newer GCC versions to improve compile-time error detection, but I'm unable to figure out what the right solution is. Can anyone help out here? I've successfully compiled older versions of zkt on older versions of Fedora - this is the first time I've tried it on Fedora 11. I've attached the spec file that I'm using to build the RPM package. -- Jeff Ollie zkt.spec Description: Binary data -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: CalDAV Calendar (BedeWork)
Mat Booth wrote: 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) 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? I do not know if it is just part of the package or at compile time. If you read the referenced url, you will see. I am taking this to the Java list as suggested. Trever 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
Taking a step back to look at a broader picture, what is determined here might be helpful when migrating other packages such as : perl6 php6 java2 ( or whatever Sunacle calls it officially ) ruby2 Although none of those are as central to the operation of Fedora as python, they all will suffer migration pains, and likely will require some type of parallel install of old and new versions, as well as migration of requires and provides. perl 6 is in F12 as I recall, under a pseudonym. Keeping python2 around ( and perl5, etc. ) named that way and not moving to compat-python2 or compat-perl5 may not be a bad thing. Using compat-* as a naming convention does signal don't use this unless you have to however is it really required ? I know, it may be too early to think about when python2 moves to a compat-* status, but as slowly as the migration to python3 is going, there may be a need for parallel installs of python2, python3, and python4. I know, ick, but possible. It might be best to keep the major version number as part of the package name(s) permanent. -- Charles Dostale -- 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
Le Ven 2 octobre 2009 17:07, chasd a écrit : java2 ( or whatever Sunacle calls it officially ) We use our own naming for this because SUN changed its mind too often on how it should be named. So now we ignore upstream naming and use our own consistent one. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
(intentionally breaking the thread so this is not burried somewhere in depths) Michal Schmidt, Fri, 02 Oct 2009 10:15:30 +0200: You're misinterpreting Jesse's quote out of context. I am misunderstanding them (in case your interpretation is more correct). So that's just that rel-eng doesn't have enough work to do (otherwise, why they do not control only critical path components?). So, this is not in protest of the current policy (this was just the last straw which broke me to do The Right Thing™ finally) and I don't want to make a drama from this (quoting Seth). However, for personal reasons I need to decrease my personal involvment in non-work related Fedora work. So, I am orphaning these packages: pspp -- A program for statistical analysis of sampled data (simple free clone of SPSS statistical package) syncevolution -- SyncML client for evolution jbrout -- Photo manager, written in python/pygtk pyexiv2 -- Python binding to exiv2 (used by jbrout) cycle -- Calendar program for women ldapvi -- An interactive LDAP client I really care about these packages, so please somebody take them. I am willing to comaintain (meaning probably mostly to advice on the ways how the community around them works), and if nobody will step up to maintain them, I will probably stay maintaining them. pspp is close to the new release, I was building for Rawhide all prereleases (it mostly involves filing a bug report upstream for reach rebuild, because pspp seems to be hitting many issues with our super-new gcc and glibc). syncevolution was just released and upgraded in Fedora. I also wish to orphan these packages, and frankly I care about them much less, so if nobody steps up, I will probably just let them die. JSDoc -- Produces javadoc-style documentation from JavaScript sourcefiles nimbus -- Desktop theme originally from Sun python-libasyncns -- Python binding for libasyncns python-urllib2_kerberos -- Kerberos over HTTP Negotiate/SPNEGO support for urllib2 vim-vimoutliner -- Script for building an outline editor on top of Vim All my packages are in good shape and I don't see any serious outstanding issue in them. Thanks a lot for anybody taking these. Matěj -- 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 Fri, Oct 2, 2009 at 17:07, chasd ch...@silveroaks.com wrote: Taking a step back to look at a broader picture, what is determined here might be helpful when migrating other packages such as : perl6 php6 java2 ( or whatever Sunacle calls it officially ) ruby2 the good thing is that they then can end up in EPEL too. This would make a lot of PHP users happy, which are currently living in the RHEL PHP stone age. (or use some other repo) Christof -- 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
perl6 That's already a Fedora 12 feature. https://fedoraproject.org/wiki/Features/Rakudo_Perl_6 -- Mathieu Bridon (bochecha) -- 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 Fri, Oct 2, 2009 at 9:20 AM, Haïkel Guémar karlthe...@gmail.com wrote: *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples python stacks In Debian's case of course there are actually *two* separate Python systems ;) http://wiki.debian.org/DebianPythonFAQ I didn't understand either and was quite confused trying to debug one of my Python applications on Debian, but if they're useful we might consider adopting one of them rather than reinventing another parallel install system. -- 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, 01 Oct 2009 14:35:33 -0700 John Poelstra poels...@redhat.com wrote: ...snip... 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 would love to. Can you show me the 28 hour days so I have some extra hours? :) Seriously tho, I think many of the FESCo folks _DO_ stay involved in lots of things, some of them might not be as visible as people think they would be. Or did you mean at some higher level? 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. I think move involvement wherever we can get it great, but I don't think we should try and force people to do X hours of work on Y. Also, if we want to require fesco and/or the board to be more involved and proactive, we should note these requirements for the next election. A possible idea for the next cycle: - Wait until we have the list of approved features. - Divide them up amoung fesco and have a 'point contact' for each that is a fesco member. - Each member is responsible for testing/tracking/talking to the feature owner and getting them what they need to get things done as well as knowing if something is not ready/etc. I don't know how feasible this is given the large list of features however. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On Fri, 2009-10-02 at 15:26 +, Matej Cepl wrote: I am misunderstanding them (in case your interpretation is more correct). So that's just that rel-eng doesn't have enough work to do (otherwise, why they do not control only critical path components?). Releng and QA are very small groups. The Fedora package set is extremely large. Over 8K packages. The rate of change is far too grate to provide second guessing over every package. So releng/qa decided to draw a line around the packages that are critical to everybody, and those that are critical to select few. For the packages that are critical to everybdoy, releng/qa will promise to take a second look at them before allowing them to break freeze. This is to prevent things like the dbus fiasco last release (sorry to keep picking on dbus). We just simply cannot do that for the rest of the package set. Also, the most important thing in a Fedora release is that it installs, it boots, and the user can get online and get updates after that. Anything outside of that is less critical and can be fixed by updates, so when gearing up for a release, that is where our efforts will be focused on for testing. Is this any clearer now? -- 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: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
2009/10/2 Matej Cepl mc...@redhat.com: pspp -- A program for statistical analysis of sampled data I can take care of if. jbrout -- Photo manager, written in python/pygtk pyexiv2 -- Python binding to exiv2 (used by jbrout) I'm using it, so I'll take care of it.. -- With best regards, Peter Lemenkov. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
Jesse Keating jkeating at redhat.com writes: Releng and QA are very small groups. The Fedora package set is extremely large. Over 8K packages. The rate of change is far too grate to provide second guessing over every package. That's why I am surprised you want to click through all those requests for fixes in non-essential packages. Why not leave them open (or allow updates only when bug number is attached)? Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESCo meeting summary for 2009-10-02
=== #fedora-meeting: FESCo meeting 20091002 === Meeting started by jds2001 at 17:00:47 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2009-10-02/fedora-meeting.2009-10-02-17.00.log.html . Meeting summary --- * incomplete features (jds2001, 17:04:12) * AGREED: DisplayPort feature is punted to F13, unles sthere's some other information we don't have (jds2001, 17:14:30) * LINK: http://marc.info/?l=linux-bluetoothm=125447683916247w=2 (sgrubb, 17:17:31) * AGREED: Lower Porcess Capabilities is retained, dbus changes are being committed to complet the feature. (jds2001, 17:38:58) * AGREED: NFSv4Default feature is deferred to F13, will land very early (like now-ish :) ) (jds2001, 17:45:46) * open floor (jds2001, 17:53:28) Meeting ended at 17:54:44 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * jds2001 (74) * sgrubb (44) * Kevin_Kofler (43) * nirik (41) * notting (12) * walters (11) * steved (8) * dgilmore (8) * zodbot (7) * sharkcz (3) * skvidal (2) * j-rod (2) * buggbot (2) * Oxf13 (2) * jwb (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
Am Freitag, den 02.10.2009, 15:26 + schrieb Matej Cepl: I also wish to orphan these packages, and frankly I care about them much less, so if nobody steps up, I will probably just let them die. JSDoc -- Produces javadoc-style documentation from JavaScript sourcefiles nimbus -- Desktop theme originally from Sun Hi Matěj, I'm going to take over nimbus. I already reviewed it and you asked me for co-maintenance. Sorry I didn't find the time to look into the EPEL build error sooner, it's still on my todo list. Please release ownership in pkg-db, so I can claim it. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
creating a updated DVD with fedora install
anyone can help ? it's possible to create a updated DVD with fedora install ? how ? -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
NFS and slow boot
Hi, I'm building custom Fedora remix with some packages from RPMFusion and updated Fedora packages. Last Live USB image I created booted really slow (over 5 minutes). I tracked down the issue to nfs service. Even when this ISO image is used for installing Fedora to HDD the same issue is present. After stopping nfs service boot time was around 30 seconds! Did anybody else experience this issue? Should I report this as a bug agaings NFS or livecd-creator? Cheers. -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Switching to Native Upstart Scripts?
I was wondering what the consensus on switching to native Upstart scripts (/etc/event.d/*) vs. keeping the traditional SysV init scripts (/etc/rc.d/init.d) for daemons was? I was looking at switching Asterisk over and have an Upstart script that seems to work fairly well. I would be making the change for F-13... -- Jeff Ollie asterisk Description: Binary data -- 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:15 -0400, David Malcolm wrote: [snip] (replying to self, with some archive links) An earlier proposal about python 3 in Fedora is here: https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html ...which was the Let's make a plan for python3.0 in Fedora 10+ thread. FWIW, looking back in the logs there was also: python-2.6 and python-3.x ( https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html ) and further back: The looming Python 3(000) monster https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html [snip] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: creating a updated DVD with fedora install
it's possible to create a updated DVD with fedora install ? yum install pungi man pungi VERSION=12 DESTDIR=/my_destination_directory/Fedora$VERSION ARCH=i386 # These are for re-using the destination directory(ies) # such as when using the destination by more than one $ARCH. rm -rf $DESTDIR/work/$ARCH rm -rf $DESTDIR/$VERSION/$ARCH mkdir -p $DESTDIR/work/$ARCH/tmp export TMPDIR=$DESTDIR/work/$ARCH/tmp /usr/sbin/setenforce 0 pungi -c /usr/share/pungi/rawhide-fedora.ks --destdir=$DESTDIR --name Fedora --ver $VERSION --nosource It will download and cache all the packages (about 2000 or more.) It requires about three times as much disk space as the final DVD, plus about an hour after download. -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching to Native Upstart Scripts?
Jeffrey Ollie (j...@ocjtech.us) said: I was wondering what the consensus on switching to native Upstart scripts (/etc/event.d/*) vs. keeping the traditional SysV init scripts (/etc/rc.d/init.d) for daemons was? I was looking at switching Asterisk over and have an Upstart script that seems to work fairly well. I would be making the change for F-13... 1) Likely for F-13 we're moving to upstart 0.6.x. This will likely require changes (if nothing else, to the script location), so you're best holding off until after then. 2) We currently have no mechanism for the following: - not starting services automatically that happen to have jobs installed (i.e., chkconfig service off) - enforcing dependencies between SysV and upstart scripts - if a package that provides a service that a SysV service depends on (via LSB headers) changes to an upstart script, things go wrong. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NFS and slow boot
On Fri, 02 Oct 2009 18:13:42 +, Valent Turkovic wrote: After stopping nfs service boot time was around 30 seconds! I ment to say before stoping, sorry. -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching to Native Upstart Scripts?
On Fri, Oct 2, 2009 at 1:42 PM, Bill Nottingham nott...@redhat.com wrote: 1) Likely for F-13 we're moving to upstart 0.6.x. 2) We currently have no mechanism for the following: - not starting services automatically that happen to have jobs installed - enforcing dependencies between SysV and upstart scripts Sounds the plan for now is to add the upstart script as a %doc until these issues get sorted out. -- Jeff Ollie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) - Recap
On Thu, 2009-10-01 at 15:43 -0400, James Laska wrote: When: Friday, 2009-10-02 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers on irc.freenode.net Thanks to all in attendance! See below for the meeting summary. #fedora-bugzappers: F-12 Beta Blocker Bug Review Meeting started by jlaska at 14:58:39 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-bugzappers/2009-10-02/fedora-bugzappers.2009-10-02-14.58.log.html . Meeting summary --- * Gathering warm bodies ... (jlaska, 14:59:05) * LINK: https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Betahide_resolved=1 (jlaska, 15:04:34) * https://bugzilla.redhat.com/show_bug.cgi?id=516042 (jlaska, 15:04:56) * ACTION: jlaska to retest using anaconda-12.32 and post feedback into 516042 (jlaska, 15:07:18) * ACTION: kparal to assist with filing any additional failures on the repo dialogs next week (jlaska, 15:07:39) * https://bugzilla.redhat.com/show_bug.cgi?id=519237 (jlaska, 15:08:00) * ACTION: jlaska to retest updated util-linux packages in 519237 using a rebuilt initrd (jlaska, 15:10:32) * AGREED: keep 519237 on the F12Beta list ... impacts developers and servers (jlaska, 15:21:04) * ACTION: jlaska will retest after rebuilding the initrd with the updated packages installed (jlaska, 15:21:22) * AGREED: keep 519237 on the F12Beta list ... impacts developers and servers (jlaska, 15:22:17) * https://bugzilla.redhat.com/show_bug.cgi?id=522675 (jlaska, 15:22:27) * HELP: anyone experiencing problems with USB keyboard/mouse ... please add thoughts to bug#522675 (jlaska, 15:26:09) * ACTION: remove from F12Beta and continue working this issue (jlaska, 15:27:48) * https://bugzilla.redhat.com/show_bug.cgi?id=526158 (jlaska, 15:28:56) * AGREED: remove bug#526158 from F12Beta ... reasonable workaround exists and specific to VGA on ppc64 (jlaska, 15:32:49) * ACTION: jlaska to remove 526158 from F12Beta (jlaska, 15:33:10) * https://bugzilla.redhat.com/show_bug.cgi?id=526208 (jlaska, 15:34:05) * LINK: http://docs.fedoraproject.org/drafts.html (stickster, 15:37:19) * LINK: http://docs.fedoraproject.org/install-guide/f12/en-US/html-single/#d0e17809 (jlaska, 15:38:34) * HELP: Help testing preupgrade from F-11 - rawhide is needed ... please update bug#526208 with your findings (jlaska, 15:44:52) * AGREED: Bug#526208 remains on the list and awaits additional testing to provide traceback (jlaska, 15:45:46) * https://bugzilla.redhat.com/show_bug.cgi?id=526320 (jlaska, 15:46:00) * AGREED: Bug#526320 remains a F12Beta blocker - can't have install images go missing for a primary arch (jlaska, 15:48:24) * ACTION: Oxf13 will continue working 526320 for root cause (jlaska, 15:48:46) * https://bugzilla.redhat.com/show_bug.cgi?id=526380 (jlaska, 15:49:02) * AGREED: bug#526380 remains on blocker list ... newer package already tagged (jlaska, 15:51:44) * ACTION: move 526380 to CLOSED - RAWHIDE as a newer package is already available (jlaska, 15:52:00) * LINK: https://fedorahosted.org/rel-eng/ticket/2250 (Oxf13, 15:53:02) * https://bugzilla.redhat.com/show_bug.cgi?id=526470 (jlaska, 15:54:12) * AGREED: bug#526470 represents a larger issue related to the nfs-utils defaulting to v4 mounts (and then reverting). This issue should remain a blocker and needs retesting (jlaska, 16:07:49) * ACTION: Provide test root=nfs:... test feedback for bug 526470 (jlaska, 16:08:30) * https://bugzilla.redhat.com/show_bug.cgi?id=517260 (jlaska, 16:09:12) * AGREED: reopened bug 517260 is a valid blocker (jlaska, 16:11:20) * ACTION: denise will help gather some devel feedback on the issue (jlaska, 16:11:39) * https://bugzilla.redhat.com/show_bug.cgi?id=523862 (jlaska, 16:11:49) * AGREED: bug 523862 is a valid beta blocker (jlaska, 16:14:39) * ACTION: feedback needed from dledford on 523862 (jlaska, 16:15:37) * ACTION: denise and jlaska reaching out for helpers (jlaska, 16:17:23) * https://bugzilla.redhat.com/show_bug.cgi?id=526535 (jlaska, 16:17:50) * AGREED: after good discussion around related changes, the group agreed to accept a fix for bug#526535 and several other NM changes that would be good to get broad testing from beta testers (jlaska, 16:36:46) * open discussion (jlaska, 16:38:53) * ACTION: dcbw will fix keys not shown as well, then rebuild pacakges, then follow up on the jlaska's mail with link to packages (jlaska, 16:39:38) * https://bugzilla.redhat.com/show_bug.cgi?id=526652 (jlaska, 16:40:44) * ACTION: twaugh going to retest 526652 to further isolate the root cause (jlaska, 16:52:10) * https://bugzilla.redhat.com/show_bug.cgi?id=518880 (jlaska, 16:52:45) * AGREED: 518880 remains a final F12Blocker but isn't
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On Fri, Oct 02, 2009 at 17:37:18 +, Matěj Cepl mc...@redhat.com wrote: Jesse Keating jkeating at redhat.com writes: Releng and QA are very small groups. The Fedora package set is extremely large. Over 8K packages. The rate of change is far too grate to provide second guessing over every package. That's why I am surprised you want to click through all those requests for fixes in non-essential packages. Why not leave them open (or allow updates only when bug number is attached)? Bugs can include RFEs as well as actual brokeness. I don't think that really buys you anything. And a bad maintainer could just file an RFE for an upgrade and refer to that bug when they provide the upgrade. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching to Native Upstart Scripts?
On Friday 02 October 2009 02:42:43 pm Bill Nottingham wrote: enforcing dependencies between SysV and upstart scripts - if a package that provides a service that a SysV service depends on (via LSB headers) changes to an upstart script, things go wrong. Also last time I checked, they still have not specified an audit facility. They have one for syslog, but not audit. And yes this matters. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
- Bruno Wolff III br...@wolff.to wrote: Bugs can include RFEs as well as actual brokeness. I don't think that really buys you anything. And a bad maintainer could just file an RFE for an upgrade and refer to that bug when they provide the upgrade. Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NFS and slow boot
On 10/02/2009 02:13 PM, Valent Turkovic wrote: Hi, I'm building custom Fedora remix with some packages from RPMFusion and updated Fedora packages. Last Live USB image I created booted really slow (over 5 minutes). I tracked down the issue to nfs service. Even when this ISO image is used for installing Fedora to HDD the same issue is present. After stopping nfs service boot time was around 30 seconds! Did anybody else experience this issue? Should I report this as a bug agaings NFS or livecd-creator? Against livecd-creator of course!! ;-) Is there any kind of a error being logged in /var/log/messages? steved. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NFS and slow boot
On Fri, Oct 2, 2009 at 6:53 PM, Steve Dickson ste...@redhat.com wrote: Is there any kind of a error being logged in /var/log/messages? Wild guess; nfs client service is trying to look up the hostname (possibly repeatedly), but it's broken. I think in F11 something regressed in anaconda/NetworkManager which no longer caused custom hostnames to be written to /etc/hosts. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NFS and slow boot
On Fri, 02 Oct 2009 18:59:11 +, Colin Walters wrote: Wild guess; nfs client service is trying to look up the hostname (possibly repeatedly), but it's broken. I think in F11 something regressed in Here you can see the bootchart from freshly built Fedora 11 updated packages: http://dl.getdropbox.com/u/184632/bootchart-slow.png and this is with nfs service turned off: http://dl.getdropbox.com/u/184632/bootchart.png -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On 10/02/2009 08:48 AM, Colin Walters wrote: On Fri, Oct 2, 2009 at 9:20 AM, Haïkel Guémar karlthe...@gmail.com wrote: *BSD, fellow GNU/Linux distro like Debian [...] are able to ship multiples python stacks In Debian's case of course there are actually *two* separate Python systems ;) http://wiki.debian.org/DebianPythonFAQ I didn't understand either and was quite confused trying to debug one of my Python applications on Debian, but if they're useful we might consider adopting one of them rather than reinventing another parallel install system. I brought up Debian's parallel install system before (I believe the last time python24 python2 python3 came up) and someone did a quick anaysis and said it wasn't a good idea. Beyond that, I know that it won't work for managing python2 and python3. The languages have diverged too much. It can manage things like python24 python25 python26 but that's not at issue right now. -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: creating a updated DVD with fedora install
we in ojuba.org have produced an updated Fedora-11-based distro + rpmfusion + extra Arabic/Islamic software this was on 2009/09/16 you may like to give it a try. http://distrowatch.com/ojuba http://www.ojuba.org/wiki/news/14300926-en as mentioned by John Reiser we have used pungi -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On Fri, Oct 2, 2009 at 8:51 PM, Matej Cepl mc...@redhat.com wrote: - Bruno Wolff III br...@wolff.to wrote: Bugs can include RFEs as well as actual brokeness. I don't think that really buys you anything. And a bad maintainer could just file an RFE for an upgrade and refer to that bug when they provide the upgrade. Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon. Well but doesn't this defeats the purpose of most have a bug attached ? If we trust maintainers to apply common sense a hard policy should not be needed. Also if you are unhappy with a process you should at least try to fix it before drawing consequences like this (orphaning packages). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On Fri, 2009-10-02 at 17:37 +, Matěj Cepl wrote: That's why I am surprised you want to click through all those requests for fixes in non-essential packages. Why not leave them open (or allow updates only when bug number is attached)? Because we don't have the infrastructure to handle only freezing some packages at this point. We're working on rolling that into bodhi, so that once we freeze, bodhi is the tool used to propose freeze breaks, publish proposed freeze breaks, and move things into the proper tags. The critical path packages will just require QA/releng to sign off on them before they get moved. So freeze breaks will be treated just like updates. -- 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: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 1:15 PM, David Malcolm dmalc...@redhat.com wrote: Proposal: Python 3 in Fedora 13 [snip] - 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. In the case of a Python binding produced as part of a larger package, though, how do we go about doing this? Seems like the sensible way is to have the person wanting to do the work sign up as co-maintainer, and take charge of the Rawhide branch of the package. Care must then be taken to make sure the F-12 and rawhide packages don't diverge much, apart from any Python 3 fixes required. Any fix that is 2.x-compatible should probably be merged to the F-12 build as well, and upstreamed. 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. We could then %prep the rpm build for each of the above so that the python 3 support is built as a parallel component of the build, independently of the python 2 support e.g. by copying the python2 support into a separate dir, then applying a patch as necessary (and somehow wiring up the configuration/make so it builds both...) The caveat here is that I haven't tried actually doing this yet for any of these packages. Issues with this approach: - I don't yet know if autoconfiguration will work well with both -devel packages installed - It will probably involve actually doing the porting work for each package (yay, we get to be leaders!) - Whoever does this for a package needs to work closely with the upstream for that package Since yum is available during build, this would work (but is fugly): - build as normal - push out python2 files to buildroot - after everything else is done, yum remove python-devel yum install python3-devel - build python3 modules Regards, -- Michel Alexandre Salim -- 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/02/2009 02:28 PM, Michel Alexandre Salim wrote: Since yum is available during build, this would work (but is fugly): - build as normal - push out python2 files to buildroot - after everything else is done, yum remove python-devel yum install python3-devel - build python3 modules There used to be locking issues with running from inside of the spec. Don't know if that still applies. We may also be denying network access to processes running inside of the buildroot. (AFAIK, the buildroot is constructed from outside. Then we chroot into it and run the build). Even if those aren't problems, we're probably better off going with the traditional, build once, move build files to a new location, build a second time. install both sets of built files route. (For instance, vim-minimal and vim-enhanced) -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 Fri, Oct 2, 2009 at 8:19 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I brought up Debian's parallel install system before (I believe the last time python24 python2 python3 came up) and someone did a quick anaysis and said it wasn't a good idea. Fair enough, just wanted to be sure it was at least looked at. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
Am Freitag, den 02.10.2009, 15:26 + schrieb Matej Cepl: syncevolution -- SyncML client for evolution I would like to maintain this package then. Regards, Dominic -- Dominic Hopf dma...@gmail.com http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- 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 Fenzi said the following on 10/02/2009 08:49 AM Pacific Time: On Thu, 01 Oct 2009 14:35:33 -0700 John Poelstra poels...@redhat.com wrote: ...snip... 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 would love to. Can you show me the 28 hour days so I have some extra hours? :) Seriously tho, I think many of the FESCo folks _DO_ stay involved in lots of things, some of them might not be as visible as people think they would be. Or did you mean at some higher level? I was thinking at a higher level and no, I wasn't trying to imply that nobody is working hard enough of needs to do more. As I think about this more it was a suggestion of trading some things out and replacing them with others. I'm also not intending to tell FESCo how to do their job or say that they are doing it wrong :-) This came out of the original thread about people not understanding the milestones, etc. It occurred to me that we might have a gap in our processes and I wondered who is responsible for all the maintainers knowing what the process and policies are around our important milestones. Some of this happens naturally when I have to send out my email nags about stale feature pages, but what if in a perfect world there were no stale feature pages and thus my messages never went out? :) FWIW I am hoping to update some of our wiki pages and send out more email reminders during Fedora 13. Hopefully it will be helpful and not be considered spam. 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. I think move involvement wherever we can get it great, but I don't think we should try and force people to do X hours of work on Y. Absolutely agree. It becomes more a matter of how we spend the same amount of time we are already. It is easy to get really focused on managing the stuff we are already doing vs. looking for ways to stop doing some things (so meetings don't run two hours) and taking a broader view of asking if we are going in the direction we want to with the distro. Are our releases getting better? Are we meeting the needs of the community we are trying to build and serve? How will we know if we are or are not? Also, if we want to require fesco and/or the board to be more involved and proactive, we should note these requirements for the next election. I'm not sure if it is a requirement so much as it is a mindset that I am advocating. A possible idea for the next cycle: - Wait until we have the list of approved features. - Divide them up amoung fesco and have a 'point contact' for each that is a fesco member. - Each member is responsible for testing/tracking/talking to the feature owner and getting them what they need to get things done as well as knowing if something is not ready/etc. I don't know how feasible this is given the large list of features however. Sounds great to me, but would other members go for it? :) Maybe this is along the lines of the Features SIG that someone suggested a ways back. John -- 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/03/2009 05:20 AM, John Poelstra wrote: Sounds great to me, but would other members go for it? :) Maybe this is along the lines of the Features SIG that someone suggested a ways back. A important oddness of the feature process is that it is not actually necessary for the feature to be in the distribution. So you send a nag mail, feature owners ignores it, you drop the feature and the functionality is still there. So unless the feature owner is actually convinced it is worth the effort, he or she can let the feature be dropped and continue just working on whatever they are. I don't know whether this can be fixed or is considered a problem but I think we should see if we can do it in a different way. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching to Native Upstart Scripts?
On 10/03/2009 12:21 AM, Steve Grubb wrote: On Friday 02 October 2009 02:42:43 pm Bill Nottingham wrote: enforcing dependencies between SysV and upstart scripts - if a package that provides a service that a SysV service depends on (via LSB headers) changes to an upstart script, things go wrong. Also last time I checked, they still have not specified an audit facility. They have one for syslog, but not audit. And yes this matters. Have you talked to upstream about it? Upstart has been in the distribution for quite sometime already. If there are particular requirements for Fedora, we should have already communicated that. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NFS and slow boot
Am Freitag, den 02.10.2009, 19:39 + schrieb Valent Turkovic: Here you can see the bootchart from freshly built Fedora 11 updated packages: http://dl.getdropbox.com/u/184632/bootchart-slow.png I didn't know that akmods are part of a freshly installed Fedora. ;) Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F-12 Beta Blocker Meeting 2009-10-02 @ 15:00 UTC (11 AM EDT) - Recap
On Fri, 2009-10-02 at 14:47 -0400, James Laska wrote: * https://bugzilla.redhat.com/show_bug.cgi?id=526535 (jlaska, 16:17:50) * AGREED: after good discussion around related changes, the group agreed to accept a fix for bug#526535 and several other NM changes that would be good to get broad testing from beta testers (jlaska, 16:36:46) * open discussion (jlaska, 16:38:53) * ACTION: dcbw will fix keys not shown as well, then rebuild pacakges, then follow up on the jlaska's mail with link to packages (jlaska, 16:39:38) http://koji.fedoraproject.org/koji/taskinfo?taskID=1725454 * Fri Oct 2 2009 Dan Williams d...@redhat.com - 0.7.996-4.git20091002 - install: fix -gnome package %pre script failures (rh #526519) - nm: fix failures validating private keys when using the NSS crypto backend - applet: fix crashes when clicking on menu but not associated (rh #526535) - editor: fix crash editing wired 802.1x settings - editor: fix secrets retrieval when editing connections Testing much appreciated. Thanks! Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On Fri, Oct 02, 2009 at 14:51:15 -0400, Matej Cepl mc...@redhat.com wrote: - Bruno Wolff III br...@wolff.to wrote: Bugs can include RFEs as well as actual brokeness. I don't think that really buys you anything. And a bad maintainer could just file an RFE for an upgrade and refer to that bug when they provide the upgrade. Yes, of course, but I expect Fedora maintainers to be adults, so they would behave at least reasonably responsibly and not fluke rules we agree upon. Which was sort of my point. If you trust them to behave, why not trust them to do only appropriate updates? It could be argued that requiring a bug number is a reminder that they should only be doing bug fixes. It still seems like an unnecessary hoop to jump through if one wants to push out an upstream bugfix release for which no open bugs exist. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 526872] New: Update to rt 3.6.9
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Update to rt 3.6.9 https://bugzilla.redhat.com/show_bug.cgi?id=526872 Summary: Update to rt 3.6.9 Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: rt3 AssignedTo: xav...@bachelot.org ReportedBy: xav...@bachelot.org QAContact: extras...@fedoraproject.org CC: xav...@bachelot.org, rc040...@freenet.de, fedora-perl-devel-list@redhat.com, mma...@redhat.com Classification: Fedora Description of problem: All versions of RT from 3.4.6 to 3.8.4 are vulnerable to an escaping bug in the display of Custom Fields that could allow injection of javascript into the RT UI. http://lists.bestpractical.com/pipermail/rt-announce/2009-September/000172.html -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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
rpms/rt3/EL-5 .cvsignore, 1.7, 1.8 rt3.spec, 1.26, 1.27 sources, 1.9, 1.10
Author: xavierb
Update of /cvs/pkgs/rpms/rt3/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17270
Modified Files:
.cvsignore rt3.spec sources
Log Message:
update to 3.6.9
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/rt3/EL-5/.cvsignore,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- .cvsignore 16 Jun 2009 12:28:42 - 1.7
+++ .cvsignore 2 Oct 2009 08:58:02 - 1.8
@@ -1 +1 @@
-rt-3.6.8.tar.gz
+rt-3.6.9.tar.gz
Index: rt3.spec
===
RCS file: /cvs/pkgs/rpms/rt3/EL-5/rt3.spec,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -p -r1.26 -r1.27
--- rt3.spec16 Jun 2009 12:28:42 - 1.26
+++ rt3.spec2 Oct 2009 08:58:02 - 1.27
@@ -12,7 +12,7 @@
%define RT3_LOCALSTATEDIR %{_localstatedir}/lib/rt3
Name: rt3
-Version: 3.6.8
+Version: 3.6.9
Release: 1%{?dist}
Summary: Request tracker 3
@@ -280,6 +280,9 @@ fi
%{_mandir}/man1/rt-mailgate*
%changelog
+* Fri Oct 02 2009 Xavier Bachelot xav...@bachelot.org - 3.6.9-1
+- Update to 3.6.9 [SECURITY] (BZ #526872).
+
* Tue Jun 16 2009 Xavier Bachelot xav...@bachelot.org - 3.6.8-1
- Update to 3.6.8 (BZ #506236):
- Updated italian translation from Nicola Murino.
Index: sources
===
RCS file: /cvs/pkgs/rpms/rt3/EL-5/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 16 Jun 2009 12:28:42 - 1.9
+++ sources 2 Oct 2009 08:58:02 - 1.10
@@ -1 +1 @@
-d2233737a6fec3b990a0afeb121deb29 rt-3.6.8.tar.gz
+0426548efc55281f610d628cf56870f0 rt-3.6.9.tar.gz
--
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
Python 2.6.3 for Fedora 13?
Python 2.6.3 was just released [1]. I think we'll want this in F13
(seems far too late to me for F12).
I tried rebuilding our devel branch with the 2.6.3 tarball, and it
built with no changes to the existing patches. I haven't gone through
the upstream changes in detail though. Caveat: this was on an F11 box,
not in Koji.
I'm running with 2.6.3 rpms on my F11 box, I'll see if anything
unexpected happens. yum seems to still work.
Attached is a patch to the devel branch FWIW.
I've just requested watchbugzilla watchcommits and commit rights
for python's devel and F12 branches. Is there a process I need to go
through for this, e.g. to establish trustworthiness?
Hope this is helpful
Dave
PS I'm about to be unreachable electronically, until October 12th
(vacation). I plan to start running rawhide when I'm back.
[1] http://www.python.org/download/releases/2.6.3/
? .build-2.6.2-2.fc12.log
? .build-2.6.3-1.fc13.log
? bump-python-devel-to-2.6.3.patch
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/python/devel/.cvsignore,v
retrieving revision 1.20
diff -u -p -r1.20 .cvsignore
--- .cvsignore 30 Jul 2009 20:57:27 - 1.20
+++ .cvsignore 2 Oct 2009 21:00:23 -
@@ -1 +1,2 @@
Python-2.6.2.tar.bz2
+Python-2.6.3.tar.bz2
Index: python.spec
===
RCS file: /cvs/pkgs/rpms/python/devel/python.spec,v
retrieving revision 1.152
diff -u -p -r1.152 python.spec
--- python.spec 21 Aug 2009 15:34:49 - 1.152
+++ python.spec 2 Oct 2009 21:00:23 -
@@ -21,8 +21,8 @@
Summary: An interpreted, interactive, object-oriented programming language
Name: %{python}
-Version: 2.6.2
-Release: 2%{?dist}
+Version: 2.6.3
+Release: 1%{?dist}
License: Python
Group: Development/Languages
Provides: python-abi = %{pybasever}
@@ -538,6 +538,9 @@ rm -fr $RPM_BUILD_ROOT
%{_libdir}/python%{pybasever}/lib-dynload/_testcapimodule.so
%changelog
+* Fri Oct 2 2009 David Malcolm dmalc...@redhat.com - 2.6.3-1
+- Update to 2.6.3
+
* Fri Aug 21 2009 Tomas Mraz tm...@redhat.com - 2.6.2-2
- rebuilt with new openssl
Index: sources
===
RCS file: /cvs/pkgs/rpms/python/devel/sources,v
retrieving revision 1.20
diff -u -p -r1.20 sources
--- sources 30 Jul 2009 20:57:27 - 1.20
+++ sources 2 Oct 2009 21:00:23 -
@@ -1 +1,2 @@
245db9f1e0f09ab7e0faaa0cf7301011 Python-2.6.2.tar.bz2
+8755fc03075b1701ca3f13932e6ade9f Python-2.6.3.tar.bz2
___
Fedora-python-devel-list mailing list
Fedora-python-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
Re: Python 2.6.3 for Fedora 13?
On Fri, 2009-10-02 at 17:17 -0400, David Malcolm wrote: Python 2.6.3 was just released [1]. I think we'll want this in F13 (seems far too late to me for F12). I tried rebuilding our devel branch with the 2.6.3 tarball, and it built with no changes to the existing patches. I haven't gone through the upstream changes in detail though. Caveat: this was on an F11 box, not in Koji. Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1725285 [snip] ___ Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
