New package mod_jk Tomcat mod_jk connector for Apache
New package python-elementtree Fast XML parser and writer
Removed package x3270
Removed package splint
Removed package namazu
Removed package cyrus-imapd
Removed package system-logviewer
Removed package xmms
Updated Packages:
NetworkManager-0.4-6.cvs20050404 -------------------------------- * Mon Apr 04 2005 Dan Williams dcbw@redhat.com 0.4-6.cvs20050404 - #rh153234# NetworkManager quits/cores just as a connection is made
anaconda-10.2.0.40-1 -------------------- * Mon Apr 04 2005 Chris Lumens clumens@redhat.com 10.2.0.40-1 - Add locale information for 'C' to fix RPM building.
* Sat Apr 02 2005 Jeremy Katz katzj@redhat.com - 10.2.0.39-1 - fix makefile deps to fix build
* Fri Apr 01 2005 Chris Lumens clumens@redhat.com 10.2.0.38-1 - Set default language for /etc/sysconfig/i18n (#149688). - Make sure hostname option isn't greyed out if using static IP (#149116). - Remove unused packages, python library bits, and locale info (katzj). - Add missing Indic font packages (katzj). - Various language fixups.
desktop-backgrounds-2.0-28 -------------------------- * Tue Feb 22 2005 Elliot Lee sopwith@redhat.com 2.0-28 - Remove extra backgrounds for now to save space.
dhcp-10:3.0.2-6 --------------- * Mon Apr 04 2005 Jason Vas Dias jvdias@redhat.com - Add '-x' "extended option environment" dhclient argument: - When -x option given to dhclient: - dhclient enables arbitrary option processing by writing information - about user or vendor defined option space options to environment. - - fix bug 153244: dhclient should not use restorecon - fix bug 151023: dhclient no 'headers & libraries' - fix bug 149780: add 'DHCLIENT_IGNORE_GATEWAY' variable - remove all usage of /sbin/route from dhclient-script
* Thu Mar 24 2005 Florian La Roche laroche@redhat.com - add "exit 0" to post script
* Mon Mar 07 2005 Jason Vas Dias jvdias@redhat.com 10.3.0.2-3 - rebuild for gcc4/glibc-2.3.4-14; fix bad memset
eclipse-1:3.1.0_fc-0.M5.17 -------------------------- * Mon Apr 04 2005 Andrew Overholt overholt@redhat.com 3.1.0_fc-0.M5.17 - Actually insert .jar-.jar.so combinations into sub-dbs.
eclipse-bugzilla-1:0.1.0_fc-9 ----------------------------- * Sun Apr 03 2005 Andrew Overholt overholt@redhat.com 0.1.0_fc-9 - Make use of rebuild-gcj-db. - Use system-wide classmap.db.
eclipse-cdt-1:3.0.0_fc-0.M5.3 ----------------------------- * Mon Apr 04 2005 Phil Muldoon pmuldoon@redhat.com 3.0.0_fc-0.M5.3 - Added eclipse-cdt-no-sdkbuild.patch to build for platform only (fc4 space crunch)
* Sun Apr 03 2005 Andrew Overholt overholt@redhat.com 3.0.0_fc-0.M5.2 - Make use of rebuild-gcj-db. - Use system-wide classmap.db.
eclipse-changelog-1:2.0.1_fc-19 ------------------------------- * Sun Apr 03 2005 Andrew Overholt overholt@redhat.com 2.0.1_fc-19 - Make use of rebuild-gcj-db. - Use system-wide classmap.db.
elfutils-0.106-3 ---------------- * Mon Apr 04 2005 Roland McGrath roland@redhat.com - 0.106-3 - fix some bugs in new code, reenable make check
* Mon Apr 04 2005 Roland McGrath roland@redhat.com - 0.106-2 - disable make check for most arches, for now
* Mon Apr 04 2005 Roland McGrath roland@redhat.com - 0.106-1 - update to 0.106
freeradius-1.0.2-1 ------------------ * Mon Apr 04 2005 Thomas Woerner twoerner@redhat.com 1.0.2-1 - new version 1.0.2
glibc-2.3.4-20 -------------- * Mon Apr 04 2005 Jakub Jelinek jakub@redhat.com 2.3.4-20 - move LinuxThreads libraries to /lib64/obsolete/linuxthreads/ and NPTL libraries to /lib64. To run a program against LinuxThreads, LD_ASSUME_KERNEL=2.4.xx LD_LIBRARY_PATH=/lib64/obsolete/linuxthreads/ is now needed - bzip2 ChangeLog* files instead of gzipping them
* Sat Apr 02 2005 Jakub Jelinek jakub@redhat.com 2.3.4-19 - update from CVS - fix nextafterl and several other libm routines on ia64 - fix initgroups (BZ#661) - kill nptl-devel subpackage, add linuxthreads-devel, compile and link by default against NPTL and only with -I/usr/include/linuxthreads -L/usr/lib64/linuxthreads against LinuxThreads - package /usr/lib/debug/lib64/tls/i{5,6}86 symlinks in i386 glibc-debuginfo - limit number of ChangeLog* files in glibc-common %doc to last 2.5 years of changes only to save space
gnome-applets-1:2.10.0-4 ------------------------ * Mon Apr 04 2005 Ray Strode rstrode@redhat.com 1:2.10.0-4 - use old modemlights applet that doesn't depend on gnome-system-tools
* Mon Mar 28 2005 Christopher Aillon caillon@redhat.com 2.10.0-3 - rebuilt
* Fri Mar 25 2005 Christopher Aillon caillon@redhat.com 2.10.0-2 - Update the GTK+ theme icon cache on (un)install
gnome-panel-2.10.1-1 -------------------- * Mon Apr 04 2005 Mark McLoughlin markmc@redhat.com 2.10.1-1 - Update to 2.10.1
gstreamer-plugins-0.8.8-5 ------------------------- * Mon Apr 04 2005 Elliot Lee sopwith@redhat.com - 0.8.8-5 - Remove mikmod support
hal-0.5.0.cvs20050404b-2 ------------------------ * Mon Apr 04 2005 David Zeuthen davidz@redhat.com 0.5.0.cvs20050404b-2 - Rebuild
* Mon Apr 04 2005 David Zeuthen davidz@redhat.com 0.5.0.cvs20050404b-1 - Use new upstream tarball rather than patching configure
* Mon Apr 04 2005 David Zeuthen davidz@redhat.com 0.5.0.cvs20050404-3 - Add libusb checks to configure.in
iiimf-1:12.1.1-11.svn2435 ------------------------- * Mon Apr 04 2005 Akira TAGOH tagoh@redhat.com - 1:12.1.1-11.svn2435 - update to svn2435 - fallback LEs properly with XIM. (#139811) - iiimecf works now with even the unix domain socket. (#143759) - added Provides: iiimf-csconv stuff for iiimf-libs agaist the Package Naming Guidelines. - iiimsf-rh-debuginfo.patch: build with corrent path for -debuginfo. - iiimqcf-rh-build.patch: updated to build iiimqcf. - added epoch to upgrade iiimf-csconv with iiimf-libs correctly. (Jens Petersen)
* Fri Apr 01 2005 Akira TAGOH tagoh@redhat.com - update to svn2421 - fixed the hardcoded IMDIR path. (#131936) - annoying 'status has not been enabled yet' syslog message was gone. (#135284) - fixed the crash issue on GTK+ when it's destroying. (#153020) - call iiimf-le-tools with -g option. - also call iiimf-le-tools with the valid LE path. - these patches are merged into upstream: - iiimsf-rh-gcc4.patch - htt_xbe-rh-gcc4.patch - leif-unit-tamil-phonetic-135035.patch - leif-unit-gu-inscriptfix-140337.patch
* Tue Mar 29 2005 Jens Petersen petersen@redhat.com - iiimf-emacs changes - rename init file to iiimf-init.el - rename elisp subdir to iiimf - set iiimcf-server-control-hostlist to use unix/:9010 by default - build and install udclient - install elisp files mode 644 - just change the ownership of /var/run/iiim/.iiimp-unix and below when upgrading (Akira Tagoh)
iputils-20020927-21 ------------------- * Tue Apr 05 2005 Radek Vokal rvokal@redhat.com 20020927-21 - rdisc init script added (#151614)
kernel-2.6.11-1.1226_FC4 ------------------------ * Fri Apr 01 2005 Dave Jones davej@redhat.com - Make the CFQ elevator the default again.
libselinux-1.23.4-1 ------------------- * Mon Apr 04 2005 Dan Walsh dwalsh@redhat.com 1.23.4-1 - Update from NSA * Merged fix for set_matchpathcon* functions from Andreas Steinmetz. * Merged fix for getconlist utility from Andreas Steinmetz.
man-pages-1.67-7 ---------------- * Mon Apr 04 2005 Jiri Ryska jryska@redhat.com 1.67-7 - io_setup() and io_destroy() pages now refers to header file - fixed types for struct shmid_ds in shmget(2) and shmctl(2) - fixed pages for readv(2) and writev(2)
* Mon Mar 07 2005 Jindrich Novy jnovy@redhat.com 1.67-6 - unify fs.5 patches together to get rid of the bogus fs.5.orig.gz shipped among man5 pages - bump release to 6 to avoid conflicts with RHEL4/FC3 man-pages
* Wed Aug 25 2004 Adrian Havill havill@redhat.com 1.67-3 - make resolver clearer and less bind-focused (#126696)
man-pages-ja-20050315-2 ----------------------- * Tue Apr 05 2005 Akira TAGOH tagoh@redhat.com - 20050315-2 - removed newgrp.1 to avoid a file conflict.
mozplugger-1.7.1-4 ------------------ * Mon Apr 04 2005 Elliot Lee sopwith@redhat.com - 1.7.1-4 - Remove mikmod dep
nasm-0.98.39-3 -------------- * Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 0.98.39-3 - pdf docs are duplication of html, txt and postscript
* Fri Apr 01 2005 Jindrich Novy jnovy@redhat.com 0.98.39-2 - fix yet another vsprintf buffer overflow (#152963)
openmotif-2.2.3-10 ------------------ * Mon Apr 04 2005 Thomas Woerner twoerner@redhat.com 2.2.3-10 - fixed possible libXpm overflows (#151642)
openssh-4.0p1-2 --------------- * Mon Apr 04 2005 Tomas Mraz tmraz@redhat.com 4.0p1-2 - fixed Local/RemoteForward in ssh_config.5 manpage - fix fatal when Local/RemoteForward is used and scp run (#153258) - don't leak user validity when using krb5 authentication
openswan-2.3.0-6 ---------------- * Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 2.3.0-6 - remove some duplicate copies of the docs
perl-DBI-1.48-3 --------------- * Mon Apr 04 2005 Warren Togami wtogami@redhat.com 1.48-3 - filter perl(Apache) (#153673)
php-5.0.4-2 ----------- * Mon Apr 04 2005 Joe Orton jorton@redhat.com 5.0.4-2 - fix PEAR installation and bundle PEAR DB-1.7.5 package
* Fri Apr 01 2005 Joe Orton jorton@redhat.com 5.0.4-1 - update to 5.0.4 (#153068) - add .phps AddType to php.conf (#152973) - better gcc4 fix for libxmlrpc
quagga-0:0.98.3-2 ----------------- * Mon Apr 04 2005 Jay Fenlason fenlason@redhat.com 0.98.3-2 - new upstream verison. - remove the -bug157 patch.
selinux-policy-strict-1.23.6-3 ------------------------------ * Mon Apr 04 2005 Dan Walsh dwalsh@redhat.com 1.23.6-3 - Allow httpd to read content without builtin scripting turned on - Remove policy.18
* Mon Apr 04 2005 Dan Walsh dwalsh@redhat.com 1.23.6-1 - Add boolean httpd_buildin_scripting - Update to latest NSA Policy * Merged cleanup of the Makefile and other stuff from Dan Walsh. Dan's patch includes some desktop changes from Ivan Gyurdiev. * Merged Thomas Bleher's patches which increase the usage of lock_domain() and etc_domain(), changes var_lib_DOMAIN_t usage to DOMAIN_var_lib_t, and removes use of notdevfile_class_set where possible. * Merged Greg Norris's cleanup of fetchmail.
selinux-policy-targeted-1.23.6-3 -------------------------------- * Mon Apr 04 2005 Dan Walsh dwalsh@redhat.com 1.23.6-3 - Allow httpd to read content without builtin scripting turned on - Remove policy.18
* Mon Apr 04 2005 Dan Walsh dwalsh@redhat.com 1.23.6-1 - Add boolean httpd_buildin_scripting - Update to latest NSA Policy * Merged cleanup of the Makefile and other stuff from Dan Walsh. Dan's patch includes some desktop changes from Ivan Gyurdiev. * Merged Thomas Bleher's patches which increase the usage of lock_domain() and etc_domain(), changes var_lib_DOMAIN_t usage to DOMAIN_var_lib_t, and removes use of notdevfile_class_set where possible. * Merged Greg Norris's cleanup of fetchmail.
sound-juicer-2.10.1-1 --------------------- * Mon Apr 04 2005 John (J5) Palmieri johnp@redhat.com 2.10.1-1 - update to upstream 2.10.1 which should fix crashes when clicking extract
sqlite-3.1.2-2 -------------- * Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 3.1.2-2 - disable tcl subpackage
subversion-1.1.4-2 ------------------ * Sun Apr 03 2005 Joe Orton jorton@redhat.com 1.1.4-2 - update to 1.1.4
system-config-bind-4.0.0-7 -------------------------- * Mon Apr 04 2005 Jason Vas Dias jvdias@redhat.com - 4.0.0-7 - fix bug 153035: gtk.FALSE/TRUE deprecation warnings system-config-securitylevel-1.5.5-1 ----------------------------------- * Mon Apr 04 2005 Dan Walsh dwalsh@redhat.com 1.5.5-1 - Add relabel button to selinux system-config-securitylevel - More booleans
system-config-users-1.2.34-1 ---------------------------- * Mon Apr 04 2005 Nils Philippsen nphilipp@redhat.com - 1.2.34-1 - don't crash when displaying non-shadow accounts (#152960)
tzdata-2005h-2 -------------- * Mon Apr 04 2005 Jakub Jelinek jakub@redhat.com 2005h-2 - 2005h - fixes for Kazakhstan
urw-fonts-2.3-1 --------------- * Mon Apr 04 2005 Than Ngo than@redhat.com 2.3-1 - Bump for update to 1.0.7pre40
vim-1:6.3.068-1 --------------- * Thu Mar 31 2005 Karsten Hopp karsten@redhat.de 6.3-068 - pathlevel 68 (can't write when editing symbolic link to compressed file) - remove -s parameter from install, this should fix debuginfo packages
* Mon Mar 28 2005 Christopher Aillon caillon@redhat.com - rebuilt
* Fri Mar 25 2005 Christopher Aillon caillon@redhat.com 6.3.067-2 - Update the GTK+ theme icon cache on (un)install
words-3.0-6 ----------- * Mon Apr 04 2005 Karel Zak kzak@redhat.com 3-6 - fix uniq command usage
* Tue Mar 29 2005 Karel Zak kzak@redhat.com 3-5 - replace word list with much better Moby Project words list (#61395) - revise %description; ispell/aspell no longer uses words
* Mon Sep 27 2004 Adrian Havill havill@redhat.com 2-23 - rebuilt
yelp-2.9.3-4 ------------ * Mon Apr 04 2005 Ray Strode rstrode@redhat.com 2.9.3-4 - rebuilt
yum-2.3.2-1 ----------- * Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 2.3.2-1 - update to 2.3.2, now requires python-elementtree for xml parsing
On Tue, 05 Apr 2005 13:51:13 +0200, Cimmo wrote:
Build System ha scritto:
Removed package xmms
Why???
It would be a fairly obvious decision to continue with stripping down Fedora Core to a real _core_ and moving duplicate functionality into Fedora Extras. XMMS is still GTK+ v1 based and can live fine in Fedora Extras, where it has been imported already. Rhythmbox most likely remains the preferred music player in Fedora Core.
On Tue, 05 Apr 2005 13:51:13 +0200, Cimmo wrote:
Build System ha scritto:
Removed package xmms
Why???
It would be a fairly obvious decision to continue with stripping down Fedora Core to a real _core_ and moving duplicate functionality into Fedora Extras. XMMS is still GTK+ v1 based and can live fine in Fedora Extras, where it has been imported already. Rhythmbox most likely remains the preferred music player in Fedora Core.
Then it would only be fair to strip out HelixPlayer too, or?
On Tue, 2005-04-05 at 14:24 +0200, Arjan van de Ven wrote:
Then it would only be fair to strip out HelixPlayer too, or?
I would second this especially as long as HelixPlayer has execshield disabled...
+1
On Tue, 5 Apr 2005 14:11:33 +0200 (CEST), nodata wrote:
On Tue, 05 Apr 2005 13:51:13 +0200, Cimmo wrote:
Build System ha scritto:
Removed package xmms
Why???
It would be a fairly obvious decision to continue with stripping down Fedora Core to a real _core_ and moving duplicate functionality into Fedora Extras. XMMS is still GTK+ v1 based and can live fine in Fedora Extras, where it has been imported already. Rhythmbox most likely remains the preferred music player in Fedora Core.
Then it would only be fair to strip out HelixPlayer too, or?
IMO, yes. HelixPlayer in Core would make much more sense, if you could add proprietary RealPlayer plugins easily instead of seeing an error dialog that you need to get RealPlayer instead.
Does HelixPlayer work? When I tried to use it, I got the message that I had to use Realplayer. Has anyone ever been able to get HelixPlayer to work without Realplayer?
On Apr 5, 2005 8:44 AM, Michael Schwendt fedora@wir-sind-cool.org wrote:
On Tue, 5 Apr 2005 14:11:33 +0200 (CEST), nodata wrote:
On Tue, 05 Apr 2005 13:51:13 +0200, Cimmo wrote:
Build System ha scritto:
Removed package xmms
Why???
It would be a fairly obvious decision to continue with stripping down Fedora Core to a real _core_ and moving duplicate functionality into Fedora Extras. XMMS is still GTK+ v1 based and can live fine in Fedora Extras, where it has been imported already. Rhythmbox most likely remains the preferred music player in Fedora Core.
Then it would only be fair to strip out HelixPlayer too, or?
IMO, yes. HelixPlayer in Core would make much more sense, if you could add proprietary RealPlayer plugins easily instead of seeing an error dialog that you need to get RealPlayer instead.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Tue, 5 Apr 2005 08:58:12 -0400, Richard Ramson wrote:
Does HelixPlayer work? When I tried to use it, I got the message that I had to use Realplayer. Has anyone ever been able to get HelixPlayer to work without Realplayer?
Please don't top-post.
Yes, HelixPlayer works for the media formats it supports, e.g. Ogg Vorbis Theora.
On Tue, 2005-04-05 at 15:52 +0200, Michael Schwendt wrote:
On Tue, 5 Apr 2005 08:58:12 -0400, Richard Ramson wrote:
Does HelixPlayer work? When I tried to use it, I got the message that I had to use Realplayer. Has anyone ever been able to get HelixPlayer to work without Realplayer?
Please don't top-post.
Yes, HelixPlayer works for the media formats it supports, e.g. Ogg Vorbis Theora.
Which of course begs the question, why does Helix Player offer to play real media formats if it doesn't support them?
Rodd
On Thu, 2005-04-07 at 10:33 +1000, Rodd Clarkson wrote:
On Tue, 2005-04-05 at 15:52 +0200, Michael Schwendt wrote:
On Tue, 5 Apr 2005 08:58:12 -0400, Richard Ramson wrote:
Does HelixPlayer work? When I tried to use it, I got the message that I had to use Realplayer. Has anyone ever been able to get HelixPlayer to work without Realplayer?
Please don't top-post.
Yes, HelixPlayer works for the media formats it supports, e.g. Ogg Vorbis Theora.
Which of course begs the question, why does Helix Player offer to play real media formats if it doesn't support them?
Rodd
that has bewildered me since the first time helix said 'yeah sure let's play this file'...and didn't.
On Thu, 7 Apr 2005, Rodd Clarkson wrote:
On Tue, 2005-04-05 at 15:52 +0200, Michael Schwendt wrote:
On Tue, 5 Apr 2005 08:58:12 -0400, Richard Ramson wrote:
Does HelixPlayer work? When I tried to use it, I got the message that I had to use Realplayer. Has anyone ever been able to get HelixPlayer to work without Realplayer?
Please don't top-post.
Yes, HelixPlayer works for the media formats it supports, e.g. Ogg Vorbis Theora.
Which of course begs the question, why does Helix Player offer to play real media formats if it doesn't support them?
Actually, it prompts the question (sorry, grammatical anal-retentiveness). As for the reason why, I think this press release explains it all:
http://www.realnetworks.com/company/press/releases/2004/real_redhat.html
Personally, I don't get why Fedora doesn't go with Totem and drop Helix. Is Fedora obligated to uphold the same agreement? The way I see it, Helix Player just isn't in demand. see:
Glen.
On Apr 5, 2005 6:00 AM, Michael Schwendt fedora@wir-sind-cool.org wrote:
On Tue, 05 Apr 2005 13:51:13 +0200, Cimmo wrote:
Build System ha scritto:
Removed package xmms
Why???
It would be a fairly obvious decision to continue with stripping down Fedora Core to a real _core_ and moving duplicate functionality into Fedora Extras. XMMS is still GTK+ v1 based and can live fine in Fedora Extras, where it has been imported already. Rhythmbox most likely remains the preferred music player in Fedora Core.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
On Apr 5, 2005 11:07 AM, Justin Conover justin.conover@gmail.com wrote:
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
the xmms in rawhide was actually quite old... i see no evidence that it was rebuilt with gcc4 yet.
-jef
On Tue, 2005-04-05 at 11:25 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:07 AM, Justin Conover justin.conover@gmail.com wrote:
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
the xmms in rawhide was actually quite old... i see no evidence that it was rebuilt with gcc4 yet.
right, it wasn't.
-sv
On Apr 5, 2005 9:30 AM, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-04-05 at 11:25 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:07 AM, Justin Conover justin.conover@gmail.com wrote:
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
the xmms in rawhide was actually quite old... i see no evidence that it was rebuilt with gcc4 yet.
right, it wasn't.
-sv
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
Also, does anyone have a good link to "how to write patches for software" example xmms gcc4.patch
Pretty much something that explains why/when/how you should create a clean patch and all. I'm currently reading/studying c programming and will hit c++ next.
thx
On Tue, 2005-04-05 at 09:51 -0600, Justin Conover wrote:
On Apr 5, 2005 9:30 AM, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-04-05 at 11:25 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:07 AM, Justin Conover justin.conover@gmail.com wrote:
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
the xmms in rawhide was actually quite old... i see no evidence that it was rebuilt with gcc4 yet.
right, it wasn't.
-sv
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
The package will only break when you recompile it with gcc4. So, for xmms, it was last updated _before_ gcc4 was made the default compiler for Fedora. Therefore, if the maintainer were to rebuild it now, since that gcc4 change, it would break and the maintainer would be forced to update the package before it could get into rawhide.
Dan
On Apr 5, 2005 10:01 AM, Dan Williams dcbw@redhat.com wrote:
On Tue, 2005-04-05 at 09:51 -0600, Justin Conover wrote:
On Apr 5, 2005 9:30 AM, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-04-05 at 11:25 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:07 AM, Justin Conover justin.conover@gmail.com wrote:
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
the xmms in rawhide was actually quite old... i see no evidence that it was rebuilt with gcc4 yet.
right, it wasn't.
-sv
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
The package will only break when you recompile it with gcc4. So, for xmms, it was last updated _before_ gcc4 was made the default compiler for Fedora. Therefore, if the maintainer were to rebuild it now, since that gcc4 change, it would break and the maintainer would be forced to update the package before it could get into rawhide.
Dan
So if I use
CC=gcc32 rpmbuild -ba xmms.spec
I should get a clean build and not an error:
checking whether make sets $(MAKE)... yes checking for x86_64-redhat-linux-gnu-gcc... gcc32 checking for C compiler default output... configure: error: C compiler cannot create executables See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.36577 (%build)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.36577 (%build)
On Tue, 2005-04-05 at 10:38 -0600, Justin Conover wrote:
So if I use
CC=gcc32 rpmbuild -ba xmms.spec
I should get a clean build and not an error:
checking whether make sets $(MAKE)... yes checking for x86_64-redhat-linux-gnu-gcc... gcc32 checking for C compiler default output... configure: error: C compiler cannot create executables See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.36577 (%build)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.36577 (%build)
And here's why: gcc3.3 and below accept different compile flags than gcc 3.4 and above. Specifically:
gcc <= 3.3: use -mcpu= gcc >= 3.4: use -mtune=
Neither gcc will accept the other option. And, since you're running on a system with gcc4 installed, the rpm OPTFLAGS macro contains -mtune. So you have to override CFLAGS as well as CC if you want things to continue to compile with gcc 3.2 and rpmbuild on a gcc4 system.
Dan
On Apr 5, 2005 10:43 AM, Dan Williams dcbw@redhat.com wrote:
On Tue, 2005-04-05 at 10:38 -0600, Justin Conover wrote:
So if I use
CC=gcc32 rpmbuild -ba xmms.spec
I should get a clean build and not an error:
checking whether make sets $(MAKE)... yes checking for x86_64-redhat-linux-gnu-gcc... gcc32 checking for C compiler default output... configure: error: C compiler cannot create executables See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.36577 (%build)
RPM build errors: Bad exit status from /var/tmp/rpm-tmp.36577 (%build)
And here's why: gcc3.3 and below accept different compile flags than gcc 3.4 and above. Specifically:
gcc <= 3.3: use -mcpu= gcc >= 3.4: use -mtune=
Neither gcc will accept the other option. And, since you're running on a system with gcc4 installed, the rpm OPTFLAGS macro contains -mtune. So you have to override CFLAGS as well as CC if you want things to continue to compile with gcc 3.2 and rpmbuild on a gcc4 system.
Dan
Yep, that makes sence, mtune vs. mcpu. here is the easy question
Why
compat-gcc-32-3.2.3-47.fc4
and not/also 3.4 ?
On Tue, Apr 05, 2005 at 10:45:29AM -0600, Justin Conover wrote:
Yep, that makes sence, mtune vs. mcpu. here is the easy question
Why
compat-gcc-32-3.2.3-47.fc4
and not/also 3.4 ?
Because there are already too many compilers in FC, and GCC 3.4 is (supposed to be) ABI compatible with GCC 4.0, so there is not much point in shipping 3.4 in addition to 4.0.
Jakub
On Tue, 2005-04-05 at 10:45 -0600, Justin Conover wrote:
And here's why: gcc3.3 and below accept different compile flags than gcc 3.4 and above. Specifically:
gcc <= 3.3: use -mcpu= gcc >= 3.4: use -mtune=
Neither gcc will accept the other option. And, since you're running on a system with gcc4 installed, the rpm OPTFLAGS macro contains -mtune. So you have to override CFLAGS as well as CC if you want things to continue to compile with gcc 3.2 and rpmbuild on a gcc4 system.
Dan
Yep, that makes sence, mtune vs. mcpu. here is the easy question
Why
compat-gcc-32-3.2.3-47.fc4
and not/also 3.4 ?
Because 3.4 is ABI compatible with gcc4. Anything that was built with gcc 3.4 should work with gcc4. 3.2 and 3.3 were ABI compatible, and therefore there is no compat-gcc-33 either, since compat-gcc-32-3.2.3 fulfills that role for 3.3 as well.
Dan
tir, 05.04.2005 kl. 18.38 skrev Justin Conover:
On Apr 5, 2005 10:01 AM, Dan Williams dcbw@redhat.com wrote:
On Tue, 2005-04-05 at 09:51 -0600, Justin Conover wrote:
On Apr 5, 2005 9:30 AM, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-04-05 at 11:25 -0400, Jeff Spaleta wrote:
On Apr 5, 2005 11:07 AM, Justin Conover justin.conover@gmail.com wrote:
What I don't understand is if you grab xmms from "extras" via cvs, it wont build because it needs a gcc4.patch. How was the rawhide build system building these packages if they break when you grab the src.rpm?
the xmms in rawhide was actually quite old... i see no evidence that it was rebuilt with gcc4 yet.
right, it wasn't.
-sv
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
The package will only break when you recompile it with gcc4. So, for xmms, it was last updated _before_ gcc4 was made the default compiler for Fedora. Therefore, if the maintainer were to rebuild it now, since that gcc4 change, it would break and the maintainer would be forced to update the package before it could get into rawhide.
Dan
So if I use
CC=gcc32 rpmbuild -ba xmms.spec
Isn't it:
CC=gcc32 export CC rpmbuild
(i am typing from memory here...)
On Tue, 2005-04-05 at 09:51 -0600, Justin Conover wrote:
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
http://fedoraproject.org/wiki/UsingMach
Pretty neat stuff actually.
On Tue, 05 Apr 2005 12:03:37 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 09:51 -0600, Justin Conover wrote:
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
http://fedoraproject.org/wiki/UsingMach
Pretty neat stuff actually.
That's not the Rawhide build system, however, but a part of the candidate build system for Fedora Extras (mach + yum + helper scripts).
On Tue, 2005-04-05 at 18:42 +0200, Michael Schwendt wrote:
On Tue, 05 Apr 2005 12:03:37 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2005-04-05 at 09:51 -0600, Justin Conover wrote:
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
http://fedoraproject.org/wiki/UsingMach
Pretty neat stuff actually.
That's not the Rawhide build system, however, but a part of the candidate build system for Fedora Extras (mach + yum + helper scripts).
Really? Well, it's still pretty neat.
Justin Conover (justin.conover@gmail.com) said:
Is there a wiki or anything that explains how the rawhide build system works? Just for usefull info to me and maybe many others. I just want to know how it all works.
Packages are built whenever the maintainer decides to, for FC3, FC3 updates, FC4, whatever.
Each day, around 5AM, the build system goes and grabs the latest version of all appropriate packages, whenever they may have been built. It then assembles them into a tree, tries to build a install image, etc.
Bill
It would be better to strip out the pre-beta low-utilisation Eclipse and retain packages that give Fedora a semblence of usefulness.
Hard work may one day make Extras a useful resource but right now - with no coordination, delayed builds and no QA - Extras packages are fourth class citizens which only a marketing suit would claim to be part of Fedora.
--Mike Bird
On Apr 5, 2005 11:29 AM, Mike Bird mgb-fedora@yosemite.net wrote:
Hard work may one day make Extras a useful resource but right now - with no coordination, delayed builds and no QA - Extras packages are fourth class citizens which only a marketing suit would claim to be part of Fedora.
I take it from this post you are volunteering to be a part of the Extras QA team? Great! I look forward to seeing your contributions to package review discussions being held in the fedora-extras-list every day and to you reading your bug reports about Extras packages that make it through the current process that are malformed. I think its a stretch to claim there is no coordination, especially if you aren't actively involved in the Extras specific discussions going on.
Among people actively participating in the Extras process, opinions differ as how QA is to be handled. I personally think ideally there should be more QA than there is right now. But I also realize that there are tradeoffs.. without a significant committment of manhours to the task of QA, the overall process can be stagnated if procedural QA hurtles are put in place that are out of proportion to the available community manpower for the task of QA. In the final analysis the importance of package QA in the Extras process is going to be directly related to the amount of time people are willing to devote to the task over the long haul. If you personally want to see QA be a higher importance.. start getting invovled in the Extras process now by participating in the fedora-extras-list package review discussions.
-jef"un-coordinated"spaleta
On Tue, 2005-04-05 at 08:51, Jeff Spaleta wrote:
I take it from this post you are volunteering to be a part of the Extras QA team?
IIRC, I started with RH6 and tested every release except FC1.
Unit and link level QA are possible in Extras but those are the responsibility of maintainers. System level QA is impossible because Extras/Devel has still not been fully rebuilt with gcc4/python2.4/etc to match FC4t1 - despite the passage of several weeks.
Back when the world was young, ten seconds at the command line would have scheduled all those rebuild jobs.
Then again, there is the problem of packages being removed from Core with the notion that sometime maybe they'll arrive in Extras. If Extras were more than a broken promise, it would be equivalent in all respects to Core - except not shipped on the Core CD's.
--Mike
On Apr 5, 2005 12:38 PM, Mike Bird mgb-fedora@yosemite.net wrote:
IIRC, I started with RH6 and tested every release except FC1.
Thats great! You'll be an excellent addition to the community effort to QA Extras. As soon as your prepared... the fedora-extras-list is there for you to participate in regarding package submissions that need review.
Unit and link level QA are possible in Extras but those are the responsibility of maintainers. System level QA is impossible because Extras/Devel has still not been fully rebuilt with gcc4/python2.4/etc to match FC4t1 - despite the passage of several weeks.
arent you assuming that all of fc4t1 was actually rebuilt with gcc4? xmms is at least one package that was never rebuilt with gcc4 but made it into fc4t1. Packages are built in Extras development when package maintainers request a rebuild, in effect not very different than how core development tree sort of works. I really don't see a big difference between how Core development and Extras development tree operates, as viewed as a package consumer. If you want a package rebuilt in the Extras devel tree.. file a bug or contact the package maintainer and have them make a rebuild request. There is an established process for maintainers to request rebuilds.
Back when the world was young, ten seconds at the command line would have scheduled all those rebuild jobs.
Its a matter of opinion as to whether or not a mass rebuild is worth attempting 'right now.' If you feel strongly about this.. why haven't you chimed in in on the fedora-extras-list when the issue of a mass rebuild came up?
Then again, there is the problem of packages being removed from Core with the notion that sometime maybe they'll arrive in Extras.
Would you prefer they were just dropped and no centralized place for these packages to be maintained? With or without extras.. some decisions to cut packages from Core will have to be made, like they have always been made.
were more than a broken promise, it would be equivalent in all respects to Core - except not shipped on the Core CD's.
You have a choice to make, you can either pitch in and start helping with the Extra process now, or you can walk away. Pointing out that its not yet as good as it could be or it should be isn't as helpful as actually getting invovled in reviewing packages or filing bug reports or talking to maintainers directly to get package build requests into the build que.
-jef
On Tue, 2005-04-05 at 10:48, Jeff Spaleta wrote:
You have a choice to make, you can either pitch in and start helping with the Extra process now, or you can walk away. Pointing out that its not yet as good as it could be or it should be isn't as helpful as actually getting invovled in reviewing packages or filing bug reports or talking to maintainers directly to get package build requests into the build que.
Comparing today's Fedora politburo with my colleagues over the last three decades is a great disappointment. We had such high hopes but you kids just goof around.
You do not understand that beta testers are a valuable resource. You must not waste beta testers. Don't make them spend hours filing rote bug reports against packages which have not even been built to FC4.
Get on the command line, make Core and Extras "equivalent" and rebuild them so all the packages match. That's an hour or two typing and probably a few days for the rebuild depending upon the power of your farm.
Then you can start inviting people to beta FC4, because the jumble you have now is not just pre-beta but pre-alpha.
--Mike Bird
Comparing today's Fedora politburo with my colleagues over the last three decades is a great disappointment. We had such high hopes but you kids just goof around.
okay, I'm tired of this. I'm tired of being patronized.
I've been working my ass off to make the build stuff work, to work on the build system automation, to make yum better and to sysadmin the fedoraproject.org machine, the buildsystems for extras and of course run the torrent tracker for the released.
I'm tired of being treated like shit for it and tired of being told that nothing we do is good enough.
So, I'm going to give you a hearty FUCK YOU.
You do some actual work, then you get to complain. Otherwise you get to the shut the fuck up.
-sv
On Tue, 2005-04-05 at 11:24, seth vidal wrote:
I've been working my ass off to make the build stuff work, to work on the build system automation, to make yum better and to sysadmin the fedoraproject.org machine, the buildsystems for extras and of course run the torrent tracker for the released.
Why is one person, no matter how competent and dedicated, doing all of that? Where the hell is Redhat? Why aren't they providing adequate resources for the people developing RHEL for them for free?
In any event, my criticism was of the release management for FC4t1 - specifically the failure to schedule a rebuild all. I did not criticize the design of the build automation.
--Mike Bird
Why is one person, no matter how competent and dedicated, doing all of that? Where the hell is Redhat? Why aren't they providing adequate resources for the people developing RHEL for them for free?
They're working on a lot of everything else. They have fulltime, jobs, too.
you want more things to happen, to happen faster and to happen better, then do some work. Stop complaining, dig in and get something done.
That's how things get solved.
In any event, my criticism was of the release management for FC4t1 - specifically the failure to schedule a rebuild all. I did not criticize the design of the build automation.
Well the only way for your criticism to reach into something better is to do the work.
Otherwise you're just a dilletante making much noise and useless traffic.
-sv
On Tue, 2005-04-05 at 11:40, seth vidal wrote:
Well the only way for your criticism to reach into something better is to do the work.
I don't have authority to schedule rebuild all.
I don't have authority to coordinate Extras with Core.
Is there anyone here with the necessary authorities?
Wanna delegate?
--Mike Bird
On Tue, 2005-04-05 at 11:52 -0700, Mike Bird wrote:
On Tue, 2005-04-05 at 11:40, seth vidal wrote:
Well the only way for your criticism to reach into something better is to do the work.
I don't have authority to schedule rebuild all.
Which is why I'm working, actively on the build system automation.
I don't have authority to coordinate Extras with Core.
Sure you do, just track changes and coordinate. Get cvs access to extras and you can import things dropped from core to extras on the same day and request a build.
Is there anyone here with the necessary authorities?
yes, YOU.
YOU can get the 'authority' to do that simply by participating.
-sv
On Tue, 5 Apr 2005, Mike Bird wrote:
On Tue, 2005-04-05 at 11:24, seth vidal wrote:
I've been working my ass off to make the build stuff work, to work on the build system automation, to make yum better and to sysadmin the fedoraproject.org machine, the buildsystems for extras and of course run the torrent tracker for the released.
Why is one person, no matter how competent and dedicated, doing all of that? Where the hell is Redhat? Why aren't they providing adequate resources for the people developing RHEL for them for free?
In any event, my criticism was of the release management for FC4t1 - specifically the failure to schedule a rebuild all. I did not criticize the design of the build automation.
Hey Mike,
There are lot of problems with Fedora to be sure. Everyone who is actively involved in Fedora is aware of this problem and umpteen others that need fixing. The main problem is that with so much to do, we have to prioritize. In order to fix the issue you raised, we'd have to stop doing other things that are more important to the long-term success of Fedora.
Getting resources to fix all the problems immediately is just unrealistic. What we can do is continue with our present group, persevering at making improvements so that in the long run things do get to the way you want them to be.
We could use some help to get there a little faster - would you be willing to chip in? -- Elliot
On Apr 5, 2005 2:34 PM, Mike Bird mgb-fedora@yosemite.net wrote:
Why is one person, no matter how competent and dedicated, doing all of that?
Because most of the 'community' are content to sit back and complain without offering to lift a finger? Seth is an example of someone who complained of the slow progress Red Hat was making and volunteered to take on some of the responsibility and burden with the resources he had available to him. If more people out in the community who cared as strongly has he did started to actually pitched in effort things would be further along and everyone would be happier. The current state of affairs, while not ideal, is a farsight better than would you would have if there wasn't anyone from outside the RedHat fenceline pushing things forward to provide packages to users.
Where the hell is Redhat? Why aren't they providing adequate resources for the people developing RHEL for them for free?
Last I heard Red Hat is still working on infrastructure peices for the final buildsystem and contributor facing systems. The cvs server for extras was provided by Red Hat, which allowed for the current buildprocess that seth is coordinating. Either we can wait for all the pieces to be in place for the final RedHat managed build system to be handed down fully formed.. or we make use of each piece as it becomes available via community effort to build a transitional process. If you don't like the incremental, transitional approach and would prefer to wait.. please by all means.. wait. Wait for the perfect buildsystem and the perfect process to produce the perfect packages.
-jef
On Tue, 2005-04-05 at 12:02, Jeff Spaleta wrote:
The cvs server for extras was provided by Red Hat
I made a false assumption. I had assumed that multi-billion-dollar Redhat would have provided the people who work for them for free with a farm capable of rebuilding all Extras in a day or so. My apologies.
Is there anyone here who can speak for Redhat?
Why the stingy hardware allocation?
Why -
Red Hat is still working on infrastructure peices for the final buildsystem and contributor facing systems.
- after all this time? This isn't exactly rocket science.
Why are useful Core packages being thrown into the uncoordinated obscurity of Extras before the system is ready to handle them?
And why oh why throw out popular packages to make room for Eclipse on the Core CD's?!
Oh, and Seth, is it that the Extras system can't rebuild all or that you don't want to schedule one yet?
Thanks,
--Mike Bird
On Apr 5, 2005 3:40 PM, Mike Bird mgb-fedora@yosemite.net wrote: [snip]
Why are useful Core packages being thrown into the uncoordinated obscurity of Extras before the system is ready to handle them?
And why oh why throw out popular packages to make room for Eclipse on the Core CD's?!
Oh, and Seth, is it that the Extras system can't rebuild all or that you don't want to schedule one yet?
Hey Mike, Chill a bit here... Extras is a long way from being "uncoordinated" and obscure.... The intensity of your words is offensive to the people who are working really hard to make extras a reality.
At the same time, I think we can agree that it isn't the same for a package to be in extras as in core. I'm not sure that this is entirely bad, but in some cases I think FC-core style maint would be better..
Here are some reasons that if I were a package, I might not want to be in extras:
1. Much smaller audience (lots of people do install everything in core, but not so with extras today) 2. More difficult distribution model (if someone burns me the DVD ISO redhat provides it has all of core, but none of extras) 3. 'Less reliable'source: When I get a distro from redhat, I'm getting it from people I trust.. When I get extras it's coming from a bunch of people on the internet I dont know. Now it's probably true that core doesn't have that much more redhat oversight on low profile packages, but it's a perception issue. 4. If a package is broken in core is known broken it has some potential for holding up a release. Not so for extras, so there is more incentive to fix a package. 4. Almost no build synchronization. When is a package in extras guaranteed to build on a new version of FC? ... Never. It's possible that a package will effectively drop out of core without any conscious decision. What if a user depends on that package, upgrades to FCn+1, and finds that it no longer works? This is far less likely to happen 'on accident' for packages in core. Should every user have to search for all the apps they use on the varrious discussion lists before upgrading to have a reasonable expectation that everything will work with only minimal fiddling after an upgrade?
All of these issues only matter for packages that are coming out of core.. For a package that never was in core, it is less of an issue... being in Extras is better than nothing at all.
Basically if we carry on in the direction of moving most of the non-essential stuff into extras, and don't provide release stabilizations for extras we will eventually create an environment where RHES is the only option for those who want a redhat distro with some degree of full-system stability... It's nearly useless to say that we've QAed fedora core if we reach a point where every FC user is spending a large part of their using extras packages that haven't been QAed.
At the same time, extras contains a lot of great package for even further out stuff.. software where it just isn't reasonable to have strong QA goals on it... Stuff we would never accept in core.. And thats great.
Perhaps a solution would be to define a subset of extras that belong to a set of more stable/more important. These packages follow the same revision timeline as FC, and perhaps even redhat would agree to delay the release of FC due to problems with something in this subset. Then only remove package from this subset through a process which provides for transparency and discussion, to avoid pulling the rug out from under anyone.
On Tue, 5 Apr 2005 16:14:41 -0400, Gregory Maxwell wrote:
Here are some reasons that if I were a package, I might not want to be in extras:
- Much smaller audience (lots of people do install everything in
core, but not so with extras today)
Moot point, as laziness is the primary reason why Joe User chooses an everything-install in the fear that manual selection of packages would be to complicated or time consuming. Despite the availability of tools like Yum, it's still considered too inconvenient to add missing pieces after installation (and system-config-packages is a dead end with regard to adding software to an up-to-date FC). And do those people only install everything, or do they also use everything? Where is the benefit of users who install everything but use only a fraction of the packages? For most of the Extras users it makes no sense to install every package from Extras.
- More difficult distribution model (if someone burns me the DVD ISO
redhat provides it has all of core, but none of extras)
Does the same "someone" also burn complete Fedora Core Updates onto a separate DVD? That could also be done with a mirrored snapshot of Fedora Extras today. But as pointed out above, Joe User most likely doesn't want another DVD of packages from which to use only a few.
- 'Less reliable'source: When I get a distro from redhat, I'm getting
it from people I trust.. When I get extras it's coming from a bunch of people on the internet I dont know. Now it's probably true that core doesn't have that much more redhat oversight on low profile packages, but it's a perception issue.
That's why fedora.us started with a mandatory QA process which included reviews and approvals by two different persons after verification of source tarball checksums and the recommendation that they are to be compared with packages from big/well-known distributions, too. But I agree, unless a packager follows the source code changes done by the upstream project with every release, there is the risk that an upstream developer goes wild and tries to introduce malicious code if it's not done by a hacker who breaks into a download server and manages to fool the packagers and the community. If you believe in threats like that, you belong to the target group of Fedora Extras commits-list, where you can observe CVS commits.
- If a package is broken in core is known broken it has some
potential for holding up a release. Not so for extras, so there is more incentive to fix a package.
Well, in a community project, anyone who has strong interest in a package, which is found to be broken, can volunteer as the one who provides a quick fix.
- Almost no build synchronization. When is a package in extras
guaranteed to build on a new version of FC? ... Never.
Bad. Unless I'm misinformed, hopefully we still plan to have FC4 Extras ready together with the release of FC4 or shortly after. For that we would need a mass rebuild at least for FC4 Test3, though, to catch remaining packages which don't compile or fail at run-time and which have not been checked by their owners due to lack of a Rawhide or FC4 Test installation. I also think there are a very few package owners still missing.
It's possible that a package will effectively drop out of core without any conscious decision. What if a user depends on that package, upgrades to FCn+1, and finds that it no longer works? This is far less likely to happen 'on accident' for packages in core.
Fedora Extras Development is used to prepare packages for FCn+1, currently. And once more, a user, who _depends on a package_, should invest some time in making sure the package does work in FCn and continues to work in FCn+1.
-snip-
All of these issues only matter for packages that are coming out of core.. For a package that never was in core, it is less of an issue... being in Extras is better than nothing at all.
Packages, which come out of Core and effectively are "dropped on the floor", need to be picked up by the Fedora community. And Fedora Extras development is open enough to allow for participation, and monitoring of development done by others.
Perhaps a solution would be to define a subset of extras that belong to a set of more stable/more important.
Start with a set of packages which you think are not stable or not good enough. File a bug report for each package.
On Apr 5, 2005 5:21 PM, Michael Schwendt fedora@wir-sind-cool.org wrote:
- Much smaller audience (lots of people do install everything in
core, but not so with extras today)
Moot point, as laziness is the primary reason why Joe User chooses an everything-install in the fear that manual selection of packages would be to complicated or time consuming. Despite the availability of tools like Yum, it's still considered too inconvenient to add missing pieces after installation (and system-config-packages is a dead end with regard to adding software to an up-to-date FC). And do those people only install everything, or do they also use everything? Where is the benefit of users who install everything but use only a fraction of the packages? For most of the Extras users it makes no sense to install every package from Extras.
Care to cite some research showing it's just lazyness?
My laptop is often without any sort of internet connection. An everything install has saved my butt multiple times. Not everyone is able to be tied to a fast internet connection, and not everyone who can be are at all times.
An everything install still lets us now if the install of a package blows up the system in some indirect way, even if the user never uses it.
- More difficult distribution model (if someone burns me the DVD ISO
redhat provides it has all of core, but none of extras)
Does the same "someone" also burn complete Fedora Core Updates onto a separate DVD? That could also be done with a mirrored snapshot of Fedora Extras today. But as pointed out above, Joe User most likely doesn't want another DVD of packages from which to use only a few.
Considering the number of times I've been asked to burn a disk with updates here for the small group of users I've adopted in my area (all of who probably have good internet access), I think you're missing something here.
If you believe in threats like that, you belong to the target group of Fedora Extras commits-list, where you can observe CVS commits.
I'll join. :) Though I think threats like that are hopeless, it's always better to have more eyes.
- If a package is broken in core is known broken it has some
potential for holding up a release. Not so for extras, so there is more incentive to fix a package.
Well, in a community project, anyone who has strong interest in a package, which is found to be broken, can volunteer as the one who provides a quick fix.
Presuming that it matters much to people with awayness, time, and ability. I'd be willing to help maintain packages that I don't give a hoot about because I know other people (without the ability to fix them) need them... But I can't do that for all of Extras, because it tends to include many many things that very few people care about. A smaller subset of 'things we think matter' would be fun to contribute to maintaining.
- Almost no build synchronization. When is a package in extras
guaranteed to build on a new version of FC? ... Never.
Bad. Unless I'm misinformed, hopefully we still plan to have FC4 Extras ready together with the release of FC4 or shortly after. For that we would need a mass rebuild at least for FC4 Test3, though, to catch remaining packages which don't compile or fail at run-time and which have not been checked by their owners due to lack of a Rawhide or FC4 Test installation. I also think there are a very few package owners still missing.
Well it's not the case today, ... and it hasn't been the case historically.
Fedora Extras Development is used to prepare packages for FCn+1, currently. And once more, a user, who _depends on a package_, should invest some time in making sure the package does work in FCn and continues to work in FCn+1.
But do we only maintain packages for people with the time and skills to do it themselves? I advocate a subset of things that we, as a community, will commit to supporting for other people even if very few people are directly committed to the member packages of that set.
Perhaps a solution would be to define a subset of extras that belong to a set of more stable/more important.
Start with a set of packages which you think are not stable or not good enough. File a bug report for each package.
Fair enough, but it doesn't correct the systemic lack of polish found in out-of-core packages.
On Tue, 5 Apr 2005 17:37:05 -0400, Gregory Maxwell wrote:
- Much smaller audience (lots of people do install everything in
core, but not so with extras today)
Moot point, as laziness is the primary reason why Joe User chooses an everything-install in the fear that manual selection of packages would be to complicated or time consuming. Despite the availability of tools like Yum, it's still considered too inconvenient to add missing pieces after installation (and system-config-packages is a dead end with regard to adding software to an up-to-date FC). And do those people only install everything, or do they also use everything? Where is the benefit of users who install everything but use only a fraction of the packages? For most of the Extras users it makes no sense to install every package from Extras.
Care to cite some research showing it's just lazyness?
Watch users in relevant message boards. Even the rather simple group based software chooser is seen as being overwhelming and raises questions such as "do I need this" and "do I need that" or "does a minimal installation include A and B"? It's personal experience that users hate an installation where after the first reboot some software is still missing.
My laptop is often without any sort of internet connection. An everything install has saved my butt multiple times. Not everyone is able to be tied to a fast internet connection, and not everyone who can be are at all times.
That does not explain why you installed _everything_ onto your laptop.
An everything install still lets us now if the install of a package blows up the system in some indirect way, even if the user never uses it.
For instance?
- More difficult distribution model (if someone burns me the DVD ISO
redhat provides it has all of core, but none of extras)
Does the same "someone" also burn complete Fedora Core Updates onto a separate DVD? That could also be done with a mirrored snapshot of Fedora Extras today. But as pointed out above, Joe User most likely doesn't want another DVD of packages from which to use only a few.
Considering the number of times I've been asked to burn a disk with updates here for the small group of users I've adopted in my area (all of who probably have good internet access), I think you're missing something here.
No, I've proven that either the users have good Internet access and don't need packages offline on CD/DVD or you are perfectly able to fetch and burn FC Updates onto CD/DVD, but you don't like to do the same with Extras. ;)
I'd be willing to help maintain packages that I don't give a hoot about because I know other people (without the ability to fix them) need them... But I can't do that for all of Extras, because it tends to include many many things that very few people care about. A smaller subset of 'things we think matter' would be fun to contribute to maintaining.
You are not supposed to take care of several hundreds of extra packages yourself. Contribute where you like to help and where you think help is needed and beneficial.
- Almost no build synchronization. When is a package in extras
guaranteed to build on a new version of FC? ... Never.
Bad. Unless I'm misinformed, hopefully we still plan to have FC4 Extras ready together with the release of FC4 or shortly after. For that we would need a mass rebuild at least for FC4 Test3, though, to catch remaining packages which don't compile or fail at run-time and which have not been checked by their owners due to lack of a Rawhide or FC4 Test installation. I also think there are a very few package owners still missing.
Well it's not the case today, ... and it hasn't been the case historically.
Hmm? With a few exceptions, fedora.us had all of FC2 (and older) Extras rebuilt for the last test release and was ready when a FC release was made. Only with FC3 and the transition period to Fedora Extras, delays were introduced. We'll see how things will develop with FC4.
(Obviously, in cases of illegal use of private library interfaces, a package breaks badly and sometimes can only be fixed if the upstream project catches up with API changes.)
Fedora Extras Development is used to prepare packages for FCn+1, currently. And once more, a user, who _depends on a package_, should invest some time in making sure the package does work in FCn and continues to work in FCn+1.
But do we only maintain packages for people with the time and skills to do it themselves?
No. Packages have a maintainer (let us ignore the differences between a "package maintainer" and a "packager" in this context) and should just work. The thing we're seeing in this thread, however, are presumptions with regard to quality of packages in Extras compared with packages in Core. Hence what I'm trying to make clear is, that if a user depends badly on a package (as if it were mission-critical usage), he should follow its development closely, preferably not just in the distribution but also upstream, as to not rely on "unknown package developers".
I advocate a subset of things that we, as a community, will commit to supporting for other people even if very few people are directly committed to the member packages of that set.
Define "support" here.
Perhaps a solution would be to define a subset of extras that belong to a set of more stable/more important.
Start with a set of packages which you think are not stable or not good enough. File a bug report for each package.
Fair enough, but it doesn't correct the systemic lack of polish found in out-of-core packages.
Again, file bug reports about any "lack of polish" you find. Thank you in advance.
Moot point, as laziness is the primary reason why Joe User chooses an everything-install in the fear that manual selection of packages would be to complicated or time consuming. Despite the availability of tools like Yum, it's still considered too inconvenient to add missing pieces after installation (and system-config-packages is a dead end with regard to adding software to an up-to-date FC). And do those people only install everything, or do they also use everything? Where is the benefit of users who install everything but use only a fraction of the packages? For most of the Extras users it makes no sense to install every package from Extras.
When I install Fedora, I usually do an "install everything"... not so much out of laziness, but from ignorance: I don't know what I need or don't need. Often the little micro-descriptions of the packages are too vague to be much real use. Disk space is cheap like borchst, I install it all and let the parts I don't use sit there polarizing little magnetic particles in a predictable fashion.
Not to mention the time it takes to go through all the packages.. never mind.. just install all of it. As I learn more I use more. If parts weren't installed, I may not know about them.
Case in point... ethereal... naw, who needs it? I'm glad I installed it... it's a great tool and it's saved my bacon more than once.
I wish there were an easier way to say "install all packages, but only these languages..." As it is I have installed a lot of language stuff I KNOW I'll never need/use/want.
I think it would be a nice addition if yum/up2date were already configured for extras, so if I learned that I needed/wanted some package (from EXTRAS) I could just say "yum install newpackage" and it would do it.
Not to mention the time it takes to go through all the packages.. never mind.. just install all of it. As I learn more I use more. If parts weren't installed, I may not know about them.
Case in point... ethereal... naw, who needs it? I'm glad I installed it... it's a great tool and it's saved my bacon more than once.
I wish there were an easier way to say "install all packages, but only these languages..." As it is I have installed a lot of language stuff I KNOW I'll never need/use/want.
So I have an idea. What if we wrote a program to copy all the CD contents or ALL repos to a local dir and set it up for you? would that be better for you? Then you wouldn't have to install everything just download it and store it locally.
then presto-change-o, you've got everything at your fingertips!
yum search someword and yum info somepkg
should get you what you want
but wait, if you have a network connection why both? You can do that now!
or in fedora core 4 test 2 you could do:
yum shell search something info somepkg install somepkg run
and still be able to look for the rest of the items, quickly.
wouldn't that be spiffy? Well you can do that! Try out yum 2.3.2 from rawhide.
I think it would be a nice addition if yum/up2date were already configured for extras, so if I learned that I needed/wanted some package (from EXTRAS) I could just say "yum install newpackage" and it would do it.
It is for fc4test2.
-sv
Michael Schwendt wrote:
On Tue, 5 Apr 2005 16:14:41 -0400, Gregory Maxwell wrote:
Here are some reasons that if I were a package, I might not want to be in extras:
- Much smaller audience (lots of people do install everything in
core, but not so with extras today)
Moot point, as laziness is the primary reason why Joe User chooses an everything-install in the fear that manual selection of packages would be to complicated or time consuming.
With no group select feature and not having all potential packages available to select/deselect during the install, it is better for me to do an everything install. You should be able to select every package available during install and there should be a seperate group that relates to the labnguage packages.
After doing an everything install, I ran rpm -e to rmove all of the additional language packages that were installed using an everything install and the languages was the reason that I avoided doing an everything install in the past.
Now with so many packages not available and also so many seperated packages, especially the java packages, an everything install is more attractive than a server, workstation, desktop or custom install.
It is not lazyness as much as the installer being pretty darned scaled down regarding functionality in these later days.
Despite the availability of tools like
Yum, it's still considered too inconvenient to add missing pieces after installation (and system-config-packages is a dead end with regard to adding software to an up-to-date FC). And do those people only install everything, or do they also use everything? Where is the benefit of users who install everything but use only a fraction of the packages? For most of the Extras users it makes no sense to install every package from Extras.
Yum for development usage is pretty much a tool that needs a lot of special steps to get it to be useful. I came up with a script tht I use after it fails to install programs because of it not doing its best, then feeding you a list of unresolved programs. I have not tried the yum shell feature yet, since I get that you cannot run commands like yum shell do-your-best in the shell and commands like list unresolved packages or similar useful features.
- More difficult distribution model (if someone burns me the DVD ISO
redhat provides it has all of core, but none of extras)
Being that extras has so many worthy packages, it would be great if these packages could be available during install, as an additional CD/DVD or included on the Core DVD version
Does the same "someone" also burn complete Fedora Core Updates onto a separate DVD?
Because of the possibility of needing to install a fresh system and then needing to downloading an enormous amount of additional rpms, I have saved the downloaded packages from such an instance for usage on future clean installed systems. Providing an ISO which included the updates might not be a bad venture.
Extras has a lot of programs that I use and trust to use. I don't see any deflection in quality, but more creative and fun to use programs than core.
I'll stop here.
Jim
I made a false assumption. I had assumed that multi-billion-dollar Redhat would have provided the people who work for them for free with a farm capable of rebuilding all Extras in a day or so. My apologies.
Is there anyone here who can speak for Redhat?
Why the stingy hardware allocation?
there's money involved and process. Moreover there's sarbanes-oxely which makes giving out user accounts on machines, difficult.
I do not speak for red hat but I know there's difficulties for them to do things immediately, just like with any big company, this is why I've been managing many things for extras build stuff b/c it's easier/faster in some ways for me to do it. We're working on getting rid of that complexity though.
Why are useful Core packages being thrown into the uncoordinated obscurity of Extras before the system is ready to handle them?
boy, glad you're not trying to be over the top here.
sheesh.
Oh, and Seth, is it that the Extras system can't rebuild all or that you don't want to schedule one yet?
b/c rebuilding the packages on rawhide with the exact same n-e-v-r's is not a good plan for real mgmt of the systems. I've rebuilt a lot of them now and once I'm happy that the buildsystem stuff is ready we won't have to 'schedule' a rebuild, one will just happen.
but to be fair - not everything in core gets rebuilt every time. Look at xmms for an example. It hasn't been rebuilt in core since the introduction of gcc4. We know this b/c it won't build under gcc4 w/o a patch that has not been applied.
But now that xmms is in extras we don't have to wait for the maintainer inside red hat to do it, you can help maintain it if you so desire.
-sv
On Tue, 05 Apr 2005 17:58:40 -0400, seth vidal wrote:
Oh, and Seth, is it that the Extras system can't rebuild all or that you don't want to schedule one yet?
b/c rebuilding the packages on rawhide with the exact same n-e-v-r's is not a good plan for real mgmt of the systems.
Just for the record, I've volunteered twice to do a clean and verified release bump on all of them right after the FC-3 split.
On Wed, 2005-04-06 at 00:58 +0200, Michael Schwendt wrote:
On Tue, 05 Apr 2005 17:58:40 -0400, seth vidal wrote:
Oh, and Seth, is it that the Extras system can't rebuild all or that you don't want to schedule one yet?
b/c rebuilding the packages on rawhide with the exact same n-e-v-r's is not a good plan for real mgmt of the systems.
Just for the record, I've volunteered twice to do a clean and verified release bump on all of them right after the FC-3 split.
Yah, I asked you about bumping all the release fields for just such a thing. Did that happen and I missed it?
-sv
On Tue, 05 Apr 2005 20:45:25 -0400, seth vidal wrote:
b/c rebuilding the packages on rawhide with the exact same n-e-v-r's is not a good plan for real mgmt of the systems.
Just for the record, I've volunteered twice to do a clean and verified release bump on all of them right after the FC-3 split.
Yah, I asked you about bumping all the release fields for just such a thing. Did that happen and I missed it?
Hmm, this is news to me. In the February "rawhide/fc4 extras builds" thread on fedora-maintainers you were pretty much against it and pushed your own five steps of how to prepare for FC4/Rawhide, getting every packager to do version bumps manually. Near the end of the thread there has not been a clear aye or nay from you.
So, since that was over a month ago, here's my final proposal:
Fedora Extras CVS "devel" release bump of all packages, which have an E:V-R equal to "FC-3" branch, will happen today 22:00 UTC (0:00 CEST), Subscribers may want to disable commits-list mail delivery to avoid the "spam". ;)
Hmm, this is news to me. In the February "rawhide/fc4 extras builds" thread on fedora-maintainers you were pretty much against it and pushed your own five steps of how to prepare for FC4/Rawhide, getting every packager to do version bumps manually. Near the end of the thread there has not been a clear aye or nay from you.
So, since that was over a month ago, here's my final proposal:
Fedora Extras CVS "devel" release bump of all packages, which have an E:V-R equal to "FC-3" branch, will happen today 22:00 UTC (0:00 CEST), Subscribers may want to disable commits-list mail delivery to avoid the "spam". ;)
okay, are you going to screen out the things that have already been bumped and rebuilt or do you want a global rebuild.
if the latter, that's fine. I'll spawn off a big build on x86 and x86_64.
I don't have the ppc box up yet but it should be here today.
-sv
On Wed, 06 Apr 2005 09:32:40 -0400, seth vidal wrote:
okay, are you going to screen out the things that have already been bumped and rebuilt or do you want a global rebuild.
if the latter, that's fine. I'll spawn off a big build on x86 and x86_64.
I don't have the ppc box up yet but it should be here today.
Well, where are we now?
FE Devel repo is filled with a broken mixture of FC3 binaries and Rawhide binaries. Which packages need a rebuild? And when?
What is the plan? To continue with that and try a single mass rebuild no sooner than FC4T3 or FC4 RC ISOs?
I've asked before as how we proceed.
GCC 4 is there. We could try rebuilds of all packages which have not been rebuilt since FC3 and then continue to fix things gradually and try to stay in sync with FC Devel (for upgrades like FLAC).
Or is it necessary to rebuild _everything_ once more near the end of FC4 development period?
My proposal is to bump all packages which have not been rebuilt since FC3, attempt to rebuild them, and give the community something to test. Packages, which have been touched and rebuilt two weeks ago, surely are kept in shape by a package maintainer who tracks Rawhide.
My proposal is to bump all packages which have not been rebuilt since FC3, attempt to rebuild them, and give the community something to test. Packages, which have been touched and rebuilt two weeks ago, surely are kept in shape by a package maintainer who tracks Rawhide.
great.
-sv
Or is it necessary to rebuild _everything_ once more near the end of FC4 development period?
I think we'll want to build again. We should get access to mostly-final FC4 about a week before the release.
-sv
seth vidal wrote:
Hmm, this is news to me. In the February "rawhide/fc4 extras builds" thread on fedora-maintainers you were pretty much against it and pushed your own five steps of how to prepare for FC4/Rawhide, getting every packager to do version bumps manually. Near the end of the thread there has not been a clear aye or nay from you.
So, since that was over a month ago, here's my final proposal:
Fedora Extras CVS "devel" release bump of all packages, which have an E:V-R equal to "FC-3" branch, will happen today 22:00 UTC (0:00 CEST), Subscribers may want to disable commits-list mail delivery to avoid the "spam". ;)
okay, are you going to screen out the things that have already been bumped and rebuilt or do you want a global rebuild.
if the latter, that's fine. I'll spawn off a big build on x86 and x86_64.
I don't have the ppc box up yet but it should be here today.
-sv
Completely off-topic, but I have to ask... What will the PPC Box be?
-Sean
Thanks to everyone who helped clarify the situation today.
Redhat developers bumping useful packages out of Core are giving the impression that Extras are just a yum away. This is false but Redhat developers may not yet be aware that this is false.
Extras lag in being rebuilt to match Core. Real world testing of Extras is not possible until much later in the cycle, if at all. Extras quality obviously suffers, but that's not all.
Core also gets less real world testing, because it's not possible to upgrade as many systems to test releases until the Extras come along. Thus the artificial partition also hurts Core quality.
Creating a separate Extras environment is counter-productive. Extras should be as close as possible to Core in order to benefit from synergies and existing tools and to improve coordination.
Extras should be first class packages in the same environment and using the same tools as Core. Maintainer access controls would apply, and dependency checks to ensure that Core is self-contained. The key differences would be but two:
(1) Core CD's would be available without Extras CD's.
(2) Extras packages should have varying but clearly specified degrees of testing, perhaps in three tiers:
Gold - As good as Core but not shipped with Core. Silver - Rebuilt and tested in coordination with Core. Bronze - Rebuilt with core but QA has not signed off.
--Mike Bird
On Apr 5, 2005 10:25 PM, Mike Bird mgb-fedora@yosemite.net wrote:
Creating a separate Extras environment is counter-productive. Extras should be as close as possible to Core in order to benefit from synergies and existing tools and to improve coordination.
I think everyone is aware of the ideal situation. Shall we collectively hold our breath waiting for it to be ideal? You aren't telling anyone anything they aren't aware of.. but thanks for the recap never-the-less. "as-close-to-possible" right now.. is exactly what we have. It will get better in the future. If its not good enough for you yet.. you can either pitch in and help with the tasks at hand making it easier for the people who are actively participating to work on other items that need doing or you can wait. The continued rehashing of the current problems isn't particular constructive.
(2) Extras packages should have varying but clearly specified degrees of testing, perhaps in three tiers: Gold - As good as Core but not shipped with Core. Silver - Rebuilt and tested in coordination with Core. Bronze - Rebuilt with core but QA has not signed off.
as good as core? wtf does that mean exactly? why is core automatically assumed to be better than all extras packages? if you want a QA sign off that takes manpower....manpower that is currently lacking. I don't even think Core has a package by package QA signoff at this point before a release. Please someone correct me if I'm wrong about that.
I CHALLENGE you to get invovled with Extras QA discussion in fedora-extras-list and start providing the manpower that can be counted on later as part of your ideal process statement. If manpower to do QA signoff doesn't show up, i seriously doubt QA signoff is going to be enshrined as part of the Extras process. If QA signoff is important to you, then you need to start digging into the current package review process and showing to everyone currently contributing to Extras that you are committed to your ideal.
-jef"I'm going to hold my breath waiting for this thread to end"spaleta
On Tue, 2005-04-05 at 19:54, Jeff Spaleta wrote:
I think everyone is aware of the ideal situation. Shall we collectively hold our breath waiting for it to be ideal? You aren't telling anyone anything they aren't aware of.. but thanks for the recap never-the-less. "as-close-to-possible" right now.. is exactly what we have. It will get better in the future.
We're moving in the wrong direction. It will not get better unless we change course.
Redhat needs to merge Extras packages into the Core build system, flagging Extras as non-Core but otherwise managing and building them on equal footing with Core packages.
Integration is much less work than reinventing a "separate but unequal" Extras environment.
The resulting products will be of higher quality because of the greater opportunities for real world testing.
--Mike Bird
On Apr 5, 2005 11:23 PM, Mike Bird mgb-fedora@yosemite.net wrote:
We're moving in the wrong direction. It will not get better unless we change course.
Your opinion, and I don't think its an informed opinion. I personally think things are moving forward. And perhaps more importantly Seth thinks things are moving in the right direction and is is far more aware than either of us about the technical specifics of what needs work in terms of the buildsystem. And clearly from the responses in this thread, he is in communication with people inside the RedHat fenceline about working towards an integrated solution.
Integration is much less work than reinventing a "separate but unequal" Extras environment.
Who exactly is saying integration isn't the goal? Who is saying that what Seth is working on right now isn't an important piece of the path to integration? And who to say that its not Core thats going to be eventually using what is being worked on now for Extras? Again.. you seem to have a very good grasp of the long term goal that everyone is working on.. but i don't think you have a good understanding of what the reality is in Core or in Extras right now in terms of available tools/systems/processes and their limitations. What RedHat has been using as a buildsystem internally is not going to scale out to contributors. The system has to be re-engineered to allow for contributors in the system and I see absolutely no evidence that the work Seth is doing is duplicating internal RedHat work beyond a superficial comparison.
-jef"I'm not going to be satified until the Fedora buildsystem can build me a pony"spaleta
On Tue, Apr 05, 2005 at 08:23:00PM -0700, Mike Bird wrote:
Redhat needs to merge Extras packages into the Core build system, flagging Extras as non-Core but otherwise managing and building them on equal footing with Core packages.
The perception of footing is in the users heads. Nowhere else. That will only change as extras gets up to speed and the kinks get knocked out of it
Alan
On 04/05/2005 07:25:06 PM, Mike Bird wrote:
Thanks to everyone who helped clarify the situation today.
Redhat developers bumping useful packages out of Core are giving the impression that Extras are just a yum away. This is false but Redhat developers may not yet be aware that this is false.
I don't think it is false.
There may be some packages that don't get picked up, but if someone really cares about it, it will be picked up by someone in extras - and maybe even better maintained.
I reported in FC3T2 that the balsa package had problems solved by one point release from upstream - but that didn't make FC3 for whatever reason. I'm betting that in Extras it will get better attention because it will be maintained by someone who cares enough about balsa to do so.
Moving stuff to Extras is good for everyone because it reduces the load on Red Hat allowing them to focus on putting out the best of the mainstrain packages (OO.o, Evolution, etc.) and allows the enthusiasts who prefer the alternatives to test and use and give feedback on what isn't being pushed (at the moment) by Fedora/Redhat as their mainstream packages.
In fact - that's the very reason I voiced for AbiWord/Gnumeric/Balsa being moved to Extras - For me, they are an epiphany of what Gnome office apps should be, OO.o and Evolution I personally think are bloated - I don't want to have to buy new hardware, there's enough industrial waste ... But for functionallity that I don't need but corporate does, OO.o and Evolution will be the mainstream apps in Fedora for some time, so I'm guessing they will get better attention in Extras than they do in Core.
-=-
I also want to note that I have seen the Extras people quite responsive on the Extras list when things are brought up - I asked about some perl packages and was quickly responded to with some links to Extras developers who had builds of them, they weren't submitted to Extras - but they were there for someone to grab and look at who did want to submit them.
I also mentioned some confusion on the wiki and it was fixed the very next day.
That list, btw, is where discussion about Extras and how it can be improved should be taking place.
What's currently in the Extras repository for Fedora is not all that there is, check out (and participate) in the Extras mailing list - I mostly lurk there, but there is a lot going on - it is moving - and it is better to do something the right way than to have to do it twice.
On Apr 5, 2005 2:24 PM, seth vidal skvidal@phy.duke.edu wrote:
So, I'm going to give you a hearty FUCK YOU.
You do some actual work, then you get to complain. Otherwise you get to the shut the fuck up. -sv
Seth, ... It is possible for someone to point out faults with the current state of affairs without making a personal attack against you.
I don't think anyone here is placing any direct fault on you, and I think it is really unproductive for you to respond to every concern people have about EXTRAS with this kind of temper tantrum.
Your work is both valuable and appreciated.
The idea of moving components from core to extras appears to be a solid idea.
But there are some concerns that arise from the differing maintains and development realities of core and extras that need to be discussed, and hopefully be resolved.
Rather than being insulted when the inevitable discussions occur, why not ask "What am I doing wrong?", "What other important project would you like me to drop in order to fix this?", and "Is there any consensus that this is important, or even a problem?". If you would like others to avoid discussing matters that they don't have solutions for, or are unwilling to work towards a solution for... then you should set an example by either being constructive or avoiding the discussions youself.
Seth, ... It is possible for someone to point out faults with the current state of affairs without making a personal attack against you.
Yes, it is possible, but typically only when it is constructive criticism. Not when it's just petty insulting crap about 'goof off kids'.
I don't think anyone here is placing any direct fault on you, and I think it is really unproductive for you to respond to every concern people have about EXTRAS with this kind of temper tantrum.
I think I've never responded to anything about extras with that sort of temper tantrum. I think I was told I was called a 'goof off kid' and told that my work was barely pre-alpha.
I think that was insulting, incorrect and not-constructive.
Rather than being insulted when the inevitable discussions occur, why not ask "What am I doing wrong?", "What other important project would you like me to drop in order to fix this?", and "Is there any consensus that this is important, or even a problem?". If you would like others to avoid discussing matters that they don't have solutions for, or are unwilling to work towards a solution for... then you should set an example by either being constructive or avoiding the discussions youself.
why not ask "what can you do to fix it, other than just complain?"
I think that's a better question.
-sv
On Tue, 2005-04-05 at 14:36 -0400, Gregory Maxwell wrote:
I don't think anyone here is placing any direct fault on you, and I think it is really unproductive for you to respond to every concern people have about EXTRAS with this kind of temper tantrum.
That's actually the *first* temper tantrum I've yet seen from Seth, so "every" is a hugely inappropriate term for it. Besides, in this case there *was* a direct shot at "kids goofing off" and such.
Ideally, one would avoid such responses... but I can hardly fault any human for blowing his top once in the last few years I've known him.
Cheers,
On Apr 5, 2005 5:09 PM, Rodolfo J. Paiz rpaiz@simpaticus.com wrote:
On Tue, 2005-04-05 at 14:36 -0400, Gregory Maxwell wrote:
I don't think anyone here is placing any direct fault on you, and I think it is really unproductive for you to respond to every concern people have about EXTRAS with this kind of temper tantrum.
That's actually the *first* temper tantrum I've yet seen from Seth, so "every" is a hugely inappropriate term for it. Besides, in this case there *was* a direct shot at "kids goofing off" and such.
My perspective, since he went off in frustration (thought not as badily) when I called packages in extras second class citizens a few weeks ago.
Ideally, one would avoid such responses... but I can hardly fault any human for blowing his top once in the last few years I've known him.
No fault, but lets work towards making everything better.
My perspective, since he went off in frustration (thought not as badily) when I called packages in extras second class citizens a few weeks ago.
Ideally, one would avoid such responses... but I can hardly fault any human for blowing his top once in the last few years I've known him.
No fault, but lets work towards making everything better.
Hear, Hear!.
So start looking at the orphaned packages pages and signing up. or review packages and file bugs, etc, etc, etc.
-sv
On Apr 5, 2005 2:17 PM, Mike Bird mgb-fedora@yosemite.net wrote:
Then you can start inviting people to beta FC4, because the jumble you have now is not just pre-beta but pre-alpha.
Fine, you feel your talents are being wasted. Perfectly acceptible way to feel. You feel the situation is pre-alpha, again a perfectly accessible way to feel. I disagree on both counts, so I stick with it. If i felt as you did I'd probably just walk away and check back in in the fc5 timeframe. Its pefectly reasonable to walk away, if you feel you can't make a positive contribution right now. But please, don't don't stick around just to take potshots at the people who are attempting to grind things forward. Slow progress doesn't become fast progress simply because you are willing to complain. Actively participate or walk away. There are people who are actively invovled who care about some of the issues you seem concerned about and I'm sure they would appeciate more help.
-jef
On Tue, 2005-04-05 at 11:31, Jeff Spaleta wrote:
Fine, you feel your talents are being wasted.
*ALL* beta testers are being wasted.
Fix the problem: (1) Coordinate Extras with Core. (2) Rebuild All.
If you don't have the authority bug your PHB, or reroute my emails at your procmail.
Don't waste beta testers.
--Mike Bird
On Tue, 2005-04-05 at 11:39 -0700, Mike Bird wrote:
On Tue, 2005-04-05 at 11:31, Jeff Spaleta wrote:
Fine, you feel your talents are being wasted.
*ALL* beta testers are being wasted.
I disagree. I think we're getting somewhere and I've been following this since the VERY beginning.
Fix the problem: (1) Coordinate Extras with Core. (2) Rebuild All.
If you don't have the authority bug your PHB, or reroute my emails at your procmail.
Don't waste beta testers.
If you don't have the skills to actually do the work, then test things and report bugs, and don't send emails of invective and snide remarks.
Don't waste developers.
-sv
On Tue, 2005-04-05 at 13:48 -0400, Jeff Spaleta wrote:
IIRC, I started with RH6 and tested every release except FC1.
Thats great! You'll be an excellent addition to the community effort to QA Extras. As soon as your prepared... the fedora-extras-list is there for you to participate in regarding package submissions that need review.
/me smells triage here...
Care to re-jig Fedora Triage, Michal? QA & Bugzilla triage is real fun and can help grow the community (because you don't need much technical leeway to become a useful contributor)
On Thu, 2005-04-07 at 16:56 +1000, Colin Charles wrote:
Care to re-jig Fedora Triage, Michal? QA & Bugzilla triage is real fun and can help grow the community (because you don't need much technical leeway to become a useful contributor)
More details, Colin? I'd like to contribute more to devel work, but although I'm fairly knowledgeable about Fedora and in general, I have nearly zero coding skills anymore. So stuff that does not require lots of highly-technical ability is interesting...
Cheers,
On Thu, 2005-04-07 at 07:56 -0600, Rodolfo J. Paiz wrote:
Care to re-jig Fedora Triage, Michal? QA & Bugzilla triage is real
fun
and can help grow the community (because you don't need much
technical
leeway to become a useful contributor)
More details, Colin? I'd like to contribute more to devel work, but although I'm fairly knowledgeable about Fedora and in general, I have nearly zero coding skills anymore. So stuff that does not require lots of highly-technical ability is interesting...
Tools triage - http://fedoraproject.org/wiki/ToolsTriage (this never happened but uli and others were definitely interested - read the list archives)
Some history down memory lane: http://www.fedora.us/wiki/FedoraTriage
This happened successfully for a while even... If anyone wants to re-jig this for Core/Extras, I'd be interested to hear this. Its definitely something that would be cool to have around
(also, please keep me in some CC loop if you do)
On Fri, 2005-04-08 at 00:19 +1000, Colin Charles wrote:
Tools triage - http://fedoraproject.org/wiki/ToolsTriage (this never happened but uli and others were definitely interested - read the list archives)
Some history down memory lane: http://www.fedora.us/wiki/FedoraTriage
After reviewing this material, I would say that the effort required at this point is beyond what I can commit to doing. However, if this gets up and running then I'd reevaluate whether I can make any contribution. It sounds like a good idea... and I might be able to participate (and if so, I would be happy to do so). But I don't think I can help set it up.
Cheers,
On Tue, 2005-04-05 at 08:29 -0700, Mike Bird wrote:
Hard work may one day make Extras a useful resource but right now - with no coordination, delayed builds and no QA
Okay, delayed builds right now are a little annoying. But I don't really think they're a huge problem since realistically, Seth builds things about as often as the devel tree for Core gets pushed so ... :) Work is very much underway to get this fixed, hopefully in time for test3.
No coordination. I think there's at least as much coordination as there is for Core. Where are you seeing a lack here and we'll do what we can to fix the problem.
No QA -- frankly, there's more QA for most of the packages in Extras right now than Core. People *actively* review everything that's being committed to Extras and do test builds and check the functionality.
Jeremy
On Tue, Apr 05, 2005 at 02:00:54PM +0200, Michael Schwendt wrote:
Rhythmbox most likely remains the preferred music player in Fedora Core.
It would be nice if "the preferred music player" would work somehow in the first place. I did not see such event yet and I even cannot tell if awful problems on an interface are just bugs or they are designed that way. Rhythmbox has twelve bugs open, all of them in a NEW state, and nothing happened for the last half year on such obvious show-stoppers like bug #139293.
Michal
On Tue, Apr 05, 2005 at 07:36:05AM -0400, Build System wrote:
New package python-elementtree Fast XML parser and writer
[...]
yum-2.3.2-1
- Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 2.3.2-1
- update to 2.3.2, now requires python-elementtree for xml parsing
Why yet another XML library ? What is so special about that library and yum ?
Daniel
[...]
yum-2.3.2-1
- Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 2.3.2-1
- update to 2.3.2, now requires python-elementtree for xml parsing
Why yet another XML library ? What is so special about that library and yum ?
We've moved to elementTree for parsing the xml metadata from libxml2.
The tests we've done have shown a 2-3x speed improvement with a lighter memory footprint.
-sv
On Tue, Apr 05, 2005 at 09:10:06AM -0400, seth vidal wrote:
[...]
yum-2.3.2-1
- Mon Apr 04 2005 Jeremy Katz katzj@redhat.com - 2.3.2-1
- update to 2.3.2, now requires python-elementtree for xml parsing
Why yet another XML library ? What is so special about that library and yum ?
We've moved to elementTree for parsing the xml metadata from libxml2.
The tests we've done have shown a 2-3x speed improvement with a lighter memory footprint.
Is that worth adding yet another XML Parser package to the distribution used by a single tool ? Is there a compatibility layer to still use libxml2 ? If I remember correctly, the performance problem wasn't libxml2 itself but the specific usage within yum, i.e. collecting the data, libxml2 by itself is parsing the megabyte sized file in less than a tenth of a second. I'm surprized the solution ends up going to use a python specific library instead of trying to find why the interface between libxml2 and yum generated that problem. I don't remember you saying you would switch library as a result.
Daniel
Is that worth adding yet another XML Parser package to the distribution used by a single tool ? Is there a compatibility layer to still use libxml2 ? If I remember correctly, the performance problem wasn't libxml2 itself but the specific usage within yum, i.e. collecting the data, libxml2 by itself is parsing the megabyte sized file in less than a tenth of a second. I'm surprized the solution ends up going to use a python specific library instead of trying to find why the interface between libxml2 and yum generated that problem. I don't remember you saying you would switch library as a result.
well what happened was this: Icon was working on repoview and decided to try out CelementTree b/c he was using kid anyway and it used it. After some preliminary tests it showed up as significantly faster parsing the metadata. For primary.xml.gz the times went from 21s for 1800ish pkgs to 7s. Then when he switched it to use iterparse() the memory footprint dropped below 10M for the whole parse.
Check out the numbers on the cElementTree webpage. They're fairly compelling.
The biggest reason I've not talked to you about it much is that for the last few weeks I've been in kinda deep-hack mode and not communicating as much as I have in the past.
Sorry for the problems.
-sv
On Tue, Apr 05, 2005 at 11:35:35AM -0400, seth vidal wrote:
Is that worth adding yet another XML Parser package to the distribution used by a single tool ? Is there a compatibility layer to still use libxml2 ? If I remember correctly, the performance problem wasn't libxml2 itself but the specific usage within yum, i.e. collecting the data, libxml2 by itself is parsing the megabyte sized file in less than a tenth of a second. I'm surprized the solution ends up going to use a python specific library instead of trying to find why the interface between libxml2 and yum generated that problem. I don't remember you saying you would switch library as a result.
well what happened was this: Icon was working on repoview and decided to try out CelementTree b/c he was using kid anyway and it used it. After some preliminary tests it showed up as significantly faster parsing the metadata. For primary.xml.gz the times went from 21s for 1800ish pkgs to 7s. Then when he switched it to use iterparse() the memory footprint dropped below 10M for the whole parse.
libxml2 should be able to work for parsing on constant memory, if you use the reader and you use it for primary.xml.gz, if you used the tree then freeing the trees after imports are teh best way.
Check out the numbers on the cElementTree webpage. They're fairly compelling.
There have been lot of rambling even within the Python community about those numbers. One thing is sure, it never took 21 seconds to parse any of the primary.xml.gz on any of my boxes at any point in time, with any of the yum versions I ever used !
The biggest reason I've not talked to you about it much is that for the last few weeks I've been in kinda deep-hack mode and not communicating as much as I have in the past.
Is a lack of communication a reason to push a new duplicate package on Fedora Core ?
Daniel
On Tue, Apr 05, 2005 at 11:35:35AM -0400, seth vidal wrote:
After some preliminary tests it showed up as significantly faster parsing the metadata. For primary.xml.gz the times went from 21s for 1800ish pkgs to 7s.
These numbers smell very suspicious to me from my practical yum experience but I never did any measurements so I cannot be sure. But ever if they are correct this is really not the place where yum is spending its time. Running test transactions seems to be a big time sink and dependency resolution as well. In a comparison with that shaving some few seconds on parsing, which is really not noticable in the whole operation, sounds like a completely a lopsided trade-off for one more extra XML parser and resulting dependencies.
Check out the numbers on the cElementTree webpage. They're fairly compelling.
In the whole context? I doubt it. Unless you have some other uses for that.
Michal
rom 21s for 1800ish pkgs to 7s.
These numbers smell very suspicious to me from my practical yum experience but I never did any measurements so I cannot be sure. But ever if they are correct this is really not the place where yum is spending its time. Running test transactions
that's funny. B/c the transaction test is one call in yum.
ts.run() with a test-only callback.
that's it.
yum does NOTHING while rpm is testing the transaction.
seems to be a big time sink and dependency resolution as well. In a comparison with that shaving some few seconds on parsing, which is really not noticable in the whole operation, sounds like a completely a lopsided trade-off for one more extra XML parser and resulting dependencies.
Excuse the hell out of taking optimizations where they were available and didn't result in worse code.
In the whole context? I doubt it. Unless you have some other uses for that.
repoview.
-sv
On Tue, Apr 05, 2005 at 01:30:30PM -0400, seth vidal wrote:
But ever if they are correct this is really not the place where yum is spending its time. Running test transactions
yum does NOTHING while rpm is testing the transaction.
Ok, so this an accounting issue but the fact that you can charge time elsewhere does not mean very much from POV of a yum _user_. One starts yum and waits for it to finish. That detail that really some subprocess is busy instead does not make an overall wait shorter. If yum itself is responsible only for a small fraction of that time then optimizing it has a negligible overall on its practical use.
Michal
Ok, so this an accounting issue but the fact that you can charge time elsewhere does not mean very much from POV of a yum _user_. One starts yum and waits for it to finish. That detail that really some subprocess is busy instead does not make an overall wait shorter. If yum itself is responsible only for a small fraction of that time then optimizing it has a negligible overall on its practical use.
So I should go see if I can make the transaction test faster in rpm, too.
Well I'm glad that in addition to working on my own program I have to go hunt down any issues I have in every other library, too.
Sounds like fun. wait wait no, no it doesn't.
:)
-sv
On Tue, Apr 05, 2005 at 02:46:57PM -0400, seth vidal wrote:
If yum itself is responsible only for a small fraction of that time then optimizing it has a negligible overall on its practical use.
So I should go see if I can make the transaction test faster in rpm, too.
Why this conclusion? From the fact that some optimization efforts seem to be, ahem, somewhat misdirected and have doubtful tradeoffs does not follow that the whole world is your baby.
Michal
On Tue, 2005-04-05 at 12:53 -0600, Michal Jaegermann wrote:
On Tue, Apr 05, 2005 at 02:46:57PM -0400, seth vidal wrote:
If yum itself is responsible only for a small fraction of that time then optimizing it has a negligible overall on its practical use.
So I should go see if I can make the transaction test faster in rpm, too.
Why this conclusion? From the fact that some optimization efforts seem to be, ahem, somewhat misdirected and have doubtful tradeoffs does not follow that the whole world is your baby.
no, but what should I do in this situation? I've not got the time to spend on seeing if there is any place for optimization of the test transaction in rpm. Not right now, at least. When I get the 'build all fedora extras' stuff off my plate and summer hits I hope to have some time to profile the heck out of yum. You wanna work on the rpm transaction test and figuring out how to make it faster, easier, capable of more interactivity/callbacks.
That'd be cool. If you do - go to rpm-devel list or rpm-python list or heck, even yum-devel - but fedora-test-list is probably not the best place for that discussion. -sv
On Tue, 2005-04-05 at 12:40 -0600, Michal Jaegermann wrote:
On Tue, Apr 05, 2005 at 01:30:30PM -0400, seth vidal wrote:
But ever if they are correct this is really not the place where yum is spending its time. Running test transactions
yum does NOTHING while rpm is testing the transaction.
Ok, so this an accounting issue but the fact that you can charge time elsewhere does not mean very much from POV of a yum _user_. One starts yum and waits for it to finish. That detail that really some subprocess is busy instead does not make an overall wait shorter. If yum itself is responsible only for a small fraction of that time then optimizing it has a negligible overall on its practical use.
Perhaps it's negligible to you right now. I prefer to see it as thinking ahead to the next bottleneck. The bottleneck of the test transaction isn't being ignored, it's just a harder problem that's going to take longer to fix. Slow, steady and incremental progress while that's being done still helps.
Also, yum has uses other uses than just installing the packages. In those cases, this change can provide a much more noticeable boost.
Jeremy
Removed package xmms
xmms has already been imported into extras. Should I go ahead and build it for devel?
-sv
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
and how about cyrus-imapd?
Roger
Roger Grosswiler wrote:
Removed package xmms
xmms has already been imported into extras. Should I go ahead and build it for devel?
and how about cyrus-imapd?
cyrus-imapd in extras would be great, switching from wu-imap -> dovecot -> cyrus-imapd -> dovecot is annoying.
clamav was never in fedora but ... ... how about clamav-0.83. http://www.clamav.net/stable.php#pagestart
i am not always uptodate but clamav-0.71-2 is since a long time out of date. http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/...
-
Alan Cox -
Arjan van de Ven -
Bill Nottingham -
Build System -
Cimmo -
Colin Charles -
Dan Williams -
Daniel Veillard -
David Woodhouse -
Don Russell -
Elliot Lee -
Glen Kim -
Gregory Maxwell -
Ignacio Vazquez-Abrams -
Jakub Jelinek -
Jef Spaleta -
Jeremy Katz -
Jim Cornette -
Justin Conover -
Kyrre Ness Sjobak -
Michael A. Peters -
Michael Schwendt -
Michal Jaegermann -
Mike Bird -
nodata -
Richard Ramson -
Rodd Clarkson -
Rodolfo J. Paiz -
Roger Grosswiler -
Sean Earp -
seth vidal -
shrek-m＠gmx.de -
Tomas Mraz -
W. Guy Thomas