From smooge at gmail.com Sun Dec 4 15:28:29 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sun, 4 Dec 2005 08:28:29 -0700 Subject: Core BrainStorm In-Reply-To: <1133122591.21208.47.camel@cutter> References: <1133122591.21208.47.camel@cutter> Message-ID: <80d7e4090512040728k72435190hcd1ce2132a526be2@mail.gmail.com> On 11/27/05, seth vidal wrote: > Hi Folks, > I setup a wiki page to get some ideas together about defining criteria > for what is and is not core: > > http://fedoraproject.org/wiki/CoreBrainStorm > > > What'd I'd love to see here is more help defining the criteria for what > makes a package core. Then we can apply those criteria to each package > in core and see if it still belongs there. Ok the BIG question that I do not see on this or the CoreVsExtras is Who Are the Architects? A project needs to have some idea of who the benevolent dictators are for the various sub-projects. They would be the ones who say that a package can be added to their "Chain" of items in Core, Extra, RepoMadness (a name for a dedicated layer of repos for specialized projects like Beowulf, DISA_Secure Architecture, etc.). Currently I have a better idea of how I could get something checked in the kernel than I do with Fedora... and I do not do kernel work. I need to know who they are, AND what they are looking for/expectations for their part of the REPO. Beyond that I threw some rough ideas of what architects would be looking for and what might be their responsibilities. Overall Core Architect/Dictator Base Architect The sub-strata that everything relies on. Desktop Architect Office Tools WSYWIG Editors Spreadsheets Presentation Small-database Email Calender Browser Lifestyle Tools Music Games Movies Development Architect Languages Compilers Libraries Debuggers IDE Server Architect Services to be supported HTTP FTP Email In my mind, the core set may be smaller than that but would allow for installation from Extras and RepoMadness Cluster Repo CCS GFS etc. Web Communication Services Repo Zope/Plone Moin Webmail Etc Authorization/Authentication Server Repo LDAP Kerberos tools Etc -- Stephen J Smoogen. CSIRT/Linux System Administrator From mattdm at mattdm.org Sun Dec 4 16:56:04 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 4 Dec 2005 11:56:04 -0500 Subject: Core BrainStorm In-Reply-To: <80d7e4090512040728k72435190hcd1ce2132a526be2@mail.gmail.com> References: <1133122591.21208.47.camel@cutter> <80d7e4090512040728k72435190hcd1ce2132a526be2@mail.gmail.com> Message-ID: <20051204165604.GA3689@jadzia.bu.edu> On Sun, Dec 04, 2005 at 08:28:29AM -0700, Stephen J. Smoogen wrote: > Ok the BIG question that I do not see on this or the CoreVsExtras is > Who Are the Architects? You rock -- excellent post. Can you put this in the wiki (as a brainstorm, at least)? [...] > Office Tools > WSYWIG Editors What Sorta You Wanted I Got? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From smooge at gmail.com Mon Dec 5 16:27:15 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 5 Dec 2005 09:27:15 -0700 Subject: Core BrainStorm In-Reply-To: <20051204165604.GA3689@jadzia.bu.edu> References: <1133122591.21208.47.camel@cutter> <80d7e4090512040728k72435190hcd1ce2132a526be2@mail.gmail.com> <20051204165604.GA3689@jadzia.bu.edu> Message-ID: <80d7e4090512050827l12f3c22ft90fd607f62fb80d6@mail.gmail.com> On 12/4/05, Matthew Miller wrote: > On Sun, Dec 04, 2005 at 08:28:29AM -0700, Stephen J. Smoogen wrote: > > Ok the BIG question that I do not see on this or the CoreVsExtras is > > Who Are the Architects? > > You rock -- excellent post. Can you put this in the wiki (as a brainstorm, > at least)? > I do not seem to have editing writes that I can tell.. or just dont know where to look for them :) > > [...] > > Office Tools > > WSYWIG Editors > > What Sorta You Wanted I Got? :) > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Stephen J Smoogen. CSIRT/Linux System Administrator From sundaram at redhat.com Mon Dec 5 17:07:17 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 22:37:17 +0530 Subject: Core BrainStorm In-Reply-To: <80d7e4090512050827l12f3c22ft90fd607f62fb80d6@mail.gmail.com> References: <1133122591.21208.47.camel@cutter> <80d7e4090512040728k72435190hcd1ce2132a526be2@mail.gmail.com> <20051204165604.GA3689@jadzia.bu.edu> <80d7e4090512050827l12f3c22ft90fd607f62fb80d6@mail.gmail.com> Message-ID: <439473C5.2080805@redhat.com> Stephen J. Smoogen wrote: >On 12/4/05, Matthew Miller wrote: > > >>On Sun, Dec 04, 2005 at 08:28:29AM -0700, Stephen J. Smoogen wrote: >> >> >>>Ok the BIG question that I do not see on this or the CoreVsExtras is >>>Who Are the Architects? >>> >>> >>You rock -- excellent post. Can you put this in the wiki (as a brainstorm, >>at least)? >> >> >> > >I do not seem to have editing writes that I can tell.. or just dont >know where to look for them :) > http://fedoraproject.org/wiki/WikiEditing. Register yourself in FirstnameLastname format and ask anyone in the edit group to add you there. You can send me a offlist mail if you need me to do that. regards Rahul From jakub at redhat.com Thu Dec 8 09:51:35 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 8 Dec 2005 04:51:35 -0500 Subject: Fedora development switch to GCC 4.1.0-RH prerelease Message-ID: <20051208095135.GB31785@devserv.devel.redhat.com> Hi! Some time between today and tomorrow we plan to switch Fedora development primary compiler from GCC 4.0.2-RH to 4.1.0-RH prerelease. We hope GCC 4.1.0 will be officially released in time for the Fedora Core 5 release, but if we want to switch, we need to do it now so that the compiler and packages built with it are sufficiently tested. For (so far preliminary) list of changes see http://gcc.gnu.org/gcc-4.1/changes.html (though, safe builtins and -fstack-protector has been already provided in GCC 4.0.2-RH). GCC 4.1.0-RH rpms are based on snapshots from svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_1-branch This branch is a merge between the upstream svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch and svn://gcc.gnu.org/svn/gcc/branches/gomp-20050608-branch which adds (preliminary) OpenMP 2.5 support. From our experience with building rawhide packages with this compiler, we know about a few outstanding GCC bugs that affect them: http://gcc.gnu.org/PR25240 (_Pragma parsing bug, prevents glibc build) http://gcc.gnu.org/PR25221 (reload ICE when compiling GIMP on i?86) http://gcc.gnu.org/PR25023 (ICE with pushw in struct by value passing and -g on i586 kernel) (of course there are many more regressions: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3 but those weren't seen in rawhide packages (so far)). The C++ frontend is again more strict then in GCC 4.0.x and rejects more invalid code. Problems seen in multiple packages include: "extra qualification..." errors - http://gcc.gnu.org/PR16782 friend injection change - struct A { typedef int S; friend void foo (S); friend void foo (); }; struct B { typedef int T; T t; void foo () { ::foo (t); } }; used to be accepted but is not any longer as ill-formed code. To fix this, the function needs to be declared at namespace scope, not just in a friend declaration. methods defined in wrong namespaces - struct A { void foo (); }; namespace { void A::foo () {} }; This is ill-formed, the definition needs to be done in the namespace containing the class. extern int bar (const char *); template struct A { void bar (const T &) { } }; template struct B : public A { B () : x (0) { } void baz () { bar (this->x); } const T x; }; void foo () { B b; b.baz (); } This is ill-formed, as bar is not template dependent and so it is looked up and found in the global namespace. The fix is to make the call template dependent, e.g. by using this->bar (this->x); relying on some C++ STL headers to include - some of the headers no longer include (on purpose), if you see this, just add explicit #include . Also packages that use -Werror might need some changes, because some new warnings were added (especially strict aliasing warnings in C++) and with -Werror that means the package doesn't build any longer. Please report any internal compiler errors as well as other problems where GCC is on fault (and that aren't in the above list) to http://bugzilla.redhat.com/bugzilla/ as usually, ideally the /tmp/cc*.out preprocessed source GCC driver creates for ICEs, or by manually preprocessing the source, verifying the bug is still reproduceable and also mentioning exact compiler version, architecture and all compiler options needed to reproduce it. If you want to test OpenMP, use -fopenmp option. Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Dec 8 04:39:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Dec 2005 23:39:47 -0500 Subject: multilib fun - devel packages Message-ID: <20051208043947.GA22451@devserv.devel.redhat.com> One of the things we've been looking at is improving support for multilib/multiarch environments. The next big step is handling devel packages so they can be installed in a multilib fashion. However, many devel packages have conflicts in their header and similar files. Attached are lists of a) the 117 packages with conflicts b) the conflicts themselves. (This was tested on x86_64/i386; presumably, ppc/ppc64 would be similar.) We'd like to get these fixed for FC5. There are varying solutions that can be done, depending on the sorts of conflicts: 1) Old-style -config scripts for setting CFLAGS and LDFLAGS. Example: libst-config Can be a) ported to pkg-config b) genericized to have a single script for all arches. 2) Wordsize specific #defines and similar in a header file. a) If they're just informational, remove them: /* configured for i386-redhat-linux */ b) Abstract them out into separate files, or one common file. For example, a file that has on i386: #define LONG_SIZE 4 and on x86_64: #define LONG_SIZE 8 could be changed to: #ifdef __i386__ #include "bits/i386-defines.h" #endif #ifdef __x86_64__ #include "bits/x86_64-defines.h" #endif and the -defines.h files could be populated only on those arches. 3) Generated docs These are tricky; sometimes commands can be called to make sure that timestamps aren't inserted into the file, or architecture notes aren't added. Alternatively, generated docs can be packaged in separate subpackages. Bill -------------- next part -------------- apr-devel-1.2.2-2 apr-util-devel-1.2.2-2 aqbanking-devel-1.0.4beta-2 aqhbci-devel-1.0.2beta-2 arts-devel-1.5.0-0.1.rc2 aspell-devel-0.60.3-2 at-spi-devel-1.6.6-1 audiofile-devel-0.2.6-2 beecrypt-devel-4.1.2-9 cairo-java-devel-1.0.1-2 cdrecord-devel-2.01.01.0.a03-1 cups-devel-1.1.23-26 curl-devel-7.15.0-3 cyrus-sasl-devel-2.1.21-8 e2fsprogs-devel-1.38-2.1 eclipse-jdt-devel-3.1.1-1jpp_7fc eclipse-platform-devel-3.1.1-1jpp_7fc eclipse-rcp-devel-3.1.1-1jpp_7fc esound-devel-0.2.36-2 evolution-data-server-devel-1.5.2-1 freetype-devel-2.1.10-5 fribidi-devel-0.10.4-8 gail-devel-1.8.8-1 GConf-devel-1.0.9-17 gd-devel-2.0.33-5 gdk-pixbuf-devel-0.22.0-21 gettext-devel-0.14.5-2 ghostscript-devel-8.15.1-3 gimp-print-devel-4.2.7-13 gkrellm-devel-2.2.7-5 glib-devel-1.2.10-18 glib-java-devel-0.2.1-2 gmp-devel-4.1.4-6 gnome-libs-devel-1.4.1.2.90-46 gnome-vfs2-devel-2.13.1-1 gnutls-devel-1.2.9-1 gphoto2-devel-2.1.6-7 gsl-devel-1.7-1 gstreamer-devel-0.8.11-2 gtk+-devel-1.2.10-49 gtkspell-devel-2.0.11-1 guile-devel-1.6.7-4 gwenhywfar-devel-1.7.2-3 g-wrap-devel-1.3.4-9 httpd-devel-2.2.0-2 ImageMagick-c++-devel-6.2.5.4-1 ImageMagick-devel-6.2.5.4-1 imlib-devel-1.9.13-26 inn-devel-2.4.2-4 java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh kdelibs-devel-3.5.0-1 kdenetwork-devel-3.5.0-1 krb5-devel-1.4.3-1 libart_lgpl-devel-2.3.17-2 libbtctl-devel-0.5.0-1 libcroco-devel-0.6.0-6 libgcj-devel-4.0.2-6 libgconf-java-devel-2.12.1-1 libgcrypt-devel-1.2.2-1 libglade-devel-0.17-16 libglade-java-devel-2.12.1-2 libgnomecanvas-devel-2.12.0-1 libgnome-devel-2.13.2-1 libgnome-java-devel-2.12.1-2 libgnomeprint22-devel-2.12.1-3 libgnomeprintui22-devel-2.12.1-1 libgnomeui-devel-2.12.0-6 libgpg-error-devel-1.1-1 libgsf-devel-1.13.3-2 libgtk-java-devel-2.8.1-1 libicu-devel-3.4-5 libIDL-devel-0.8.6-2 libidn-devel-0.6.0-1 libpng-devel-1.2.8-2 libsilc-devel-0.9.12-12 libsoup-devel-2.2.7-1 libtiff-devel-3.7.4-3 libusb-devel-0.1.10a-1 libuser-devel-0.54.3-1 libvte-java-devel-0.11.11-6 libwmf-devel-0.2.8.4-2 libxml2-devel-2.6.22-1 libxml-devel-1.8.17-13 libxslt-devel-1.1.15-1 mikmod-devel-3.1.6-36 mod_perl-devel-2.0.2-3 mozilla-devel-1.7.12-2 mysqlclient10-devel-3.23.58-6 mysqlclient14-devel-4.1.14-1 mysql-devel-5.0.15-3 neon-devel-0.24.7-9 netpbm-devel-10.30-2 net-snmp-devel-5.2.2-1 nspr-devel-4.6-4 oaf-devel-0.6.10-12 openh323-devel-1.15.6-3 openjade-devel-1.3.2-16 ORBit2-devel-2.13.2-1 ORBit-devel-0.5.17-15 pciutils-devel-2.1.99.test8-10 pcre-devel-6.3-1 php-devel-5.1.1-4 postgresql-devel-8.1.0-4 pwlib-devel-1.8.7-2 pygtk2-devel-2.8.2-2 python-devel-2.4.2-2 qt-devel-3.3.5-10 sane-backends-devel-1.0.16-2 SDL-devel-1.2.9-2.1 setools-devel-2.2-2 sox-devel-12.17.7-3 syslinux-devel-3.10-2 tn5250-devel-0.17.3-1 tog-pegasus-devel-2.5-4 xdelta-devel-1.1.3-17 xfsprogs-devel-2.7.3-1 xmlsec1-devel-1.2.9-3 -------------- next part -------------- file /usr/bin/apr-1-config from install of apr-devel-1.2.2-2 conflicts with file from package apr-devel-1.2.2-2 file /usr/include/apr-1/apr.h from install of apr-devel-1.2.2-2 conflicts with file from package apr-devel-1.2.2-2 file /usr/bin/apu-1-config from install of apr-util-devel-1.2.2-2 conflicts with file from package apr-util-devel-1.2.2-2 file /usr/bin/aqbanking-config from install of aqbanking-devel-1.0.4beta-2 conflicts with file from package aqbanking-devel-1.0.4beta-2 file /usr/bin/aqhbci-config from install of aqhbci-devel-1.0.2beta-2 conflicts with file from package aqhbci-devel-1.0.2beta-2 file /usr/bin/artsc-config from install of arts-devel-1.5.0-0.1.rc2 conflicts with file from package arts-devel-1.5.0-0.1.rc2 file /usr/include/kde/arts/gsl/gslconfig.h from install of arts-devel-1.5.0-0.1.rc2 conflicts with file from package arts-devel-1.5.0-0.1.rc2 file /usr/bin/pspell-config from install of aspell-devel-0.60.3-2 conflicts with file from package aspell-devel-0.60.3-2 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-Accessible-Objects.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleAction-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleApplication-API.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleComponent-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleEditableText-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleHyperlink-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleHypertext-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleImage-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleRelations-and-RelationSets.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleSelection-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleTable-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleText-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-AccessibleValue-Interface.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-Event-Listener-Support.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-Registry-queries.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-SPI-main-loop-and-initialization.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/at-spi-cspi-State-and-StateSets.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/share/gtk-doc/html/at-spi-cspi/ch05.html from install of at-spi-devel-1.6.6-1 conflicts with file from package at-spi-devel-1.6.6-1 file /usr/bin/audiofile-config from install of audiofile-devel-0.2.6-2 conflicts with file from package audiofile-devel-0.2.6-2 file /usr/include/beecrypt/gnu.h from install of beecrypt-devel-4.1.2-9 conflicts with file from package beecrypt-devel-4.1.2-9 file /usr/share/java/cairo1.0-src-1.0.1.zip from install of cairo-java-devel-1.0.1-2 conflicts with file from package cairo-java-1.0.1-2 file /usr/share/java/cairo1.0-src-1.0.1.zip from install of cairo-java-devel-1.0.1-2 conflicts with file from package cairo-java-devel-1.0.1-2 file /usr/include/schily/xconfig.h from install of cdrecord-devel-2.01.01.0.a03-1 conflicts with file from package cdrecord-devel-2.01.01.0.a03-1 file /usr/bin/cups-config from install of cups-devel-1.1.23-26 conflicts with file from package cups-devel-1.1.23-26 file /usr/bin/curl-config from install of curl-devel-7.15.0-3 conflicts with file from package curl-devel-7.15.0-3 file /usr/include/sasl/md5global.h from install of cyrus-sasl-devel-2.1.21-8 conflicts with file from package cyrus-sasl-devel-2.1.21-8 file /usr/bin/compile_et from install of e2fsprogs-devel-1.38-2.1 conflicts with file from package e2fsprogs-devel-1.38-2.1 file /usr/bin/mk_cmds from install of e2fsprogs-devel-1.38-2.1 conflicts with file from package e2fsprogs-devel-1.38-2.1 file /usr/include/blkid/blkid_types.h from install of e2fsprogs-devel-1.38-2.1 conflicts with file from package e2fsprogs-devel-1.38-2.1 file /usr/include/ext2fs/ext2_types.h from install of e2fsprogs-devel-1.38-2.1 conflicts with file from package e2fsprogs-devel-1.38-2.1 file /usr/share/eclipse/plugins/org.eclipse.jdt.source_3.1.1/src/org.eclipse.jdt.core_3.1.1/src.zip from install of eclipse-jdt-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-jdt-devel-3.1.1-1jpp_7fc file /usr/share/eclipse/plugins/org.eclipse.platform.source_3.1.1/src/org.eclipse.compare_3.1.1/src.zip from install of eclipse-platform-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-platform-devel-3.1.1-1jpp_7fc file /usr/share/eclipse/plugins/org.eclipse.platform.source_3.1.1/src/org.eclipse.help.base_3.1.0/src.zip from install of eclipse-platform-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-platform-devel-3.1.1-1jpp_7fc file /usr/share/eclipse/plugins/org.eclipse.platform.source_3.1.1/src/org.eclipse.platform_3.1.1/launchersrc.zip from install of eclipse-platform-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-platform-devel-3.1.1-1jpp_7fc file /usr/share/eclipse/plugins/org.eclipse.platform.source_3.1.1/src/org.eclipse.tomcat_5.0.30/tomcatwrappersrc.zip from install of eclipse-platform-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-platform-devel-3.1.1-1jpp_7fc file /usr/share/eclipse/plugins/org.eclipse.platform.source_3.1.1/src/org.eclipse.update.ui_3.1.1/src.zip from install of eclipse-platform-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-platform-devel-3.1.1-1jpp_7fc file /usr/share/eclipse/plugins/org.eclipse.rcp.source_3.1.1/src/org.eclipse.core.runtime_3.1.1/src.zip from install of eclipse-rcp-devel-3.1.1-1jpp_7fc conflicts with file from package eclipse-rcp-devel-3.1.1-1jpp_7fc file /usr/bin/esd-config from install of esound-devel-0.2.36-2 conflicts with file from package esound-devel-0.2.36-2 file /usr/share/gtk-doc/html/libebook/EBook.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/EBookListener.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/EBookView.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/EBookViewListener.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/EContact.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/EVCard.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/ch01.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/libebook-EAddressWestern.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/libebook-ENameWestern.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/libebook-e-book-async.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/libebook-e-book-query.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libebook/libebook-e-book-types.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/ECal.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/ECalComponent.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/ch01.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-ECalListener.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-ECalView.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-ECalViewListener.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-e-cal-recur.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-e-cal-time-util.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-e-cal-types.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libecal/libecal-e-cal-util.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/ECalBackend.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/ECalBackendSExp.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/EDataCal.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/EDataCalView.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/ch01.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/libedata-cal-ECalBackendCache.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/libedata-cal-ECalBackendFactory.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/libedata-cal-ECalBackendSync.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/libedata-cal-EDataCalFactory.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedata-cal/libedata-cal-e-cal-backend-util.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/ch01.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EAccount.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EAccountList.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EComponentListener.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EFileCache.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EIterator.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EList.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-EListIterator.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-ESExp.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-ESource.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-ESourceGroup.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-ESourceList.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-categories.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-data-server-module.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-db3-utils.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-dbhash.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-iconv.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-memory.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-msgport.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-time-utils.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-trie.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-uid.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-url.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-util.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-e-xml-hash-utils.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/share/gtk-doc/html/libedataserver/libedataserver-md5-utils.html from install of evolution-data-server-devel-1.5.2-1 conflicts with file from package evolution-data-server-devel-1.5.2-1 file /usr/bin/freetype-config from install of freetype-devel-2.1.10-5 conflicts with file from package freetype-devel-2.1.10-5 file /usr/include/freetype2/freetype/config/ftconfig.h from install of freetype-devel-2.1.10-5 conflicts with file from package freetype-devel-2.1.10-5 file /usr/bin/fribidi-config from install of fribidi-devel-0.10.4-8 conflicts with file from package fribidi-devel-0.10.4-8 file /usr/share/gtk-doc/html/gail-libgail-util/gail-libgail-util-GailMisc.html from install of gail-devel-1.8.8-1 conflicts with file from package gail-devel-1.8.8-1 file /usr/share/gtk-doc/html/gail-libgail-util/gail-libgail-util-GailTextUtil.html from install of gail-devel-1.8.8-1 conflicts with file from package gail-devel-1.8.8-1 file /usr/bin/gconf-config-1 from install of GConf-devel-1.0.9-17 conflicts with file from package GConf-devel-1.0.9-17 file /usr/bin/gdlib-config from install of gd-devel-2.0.33-5 conflicts with file from package gd-devel-2.0.33-5 file /usr/bin/gdk-pixbuf-config from install of gdk-pixbuf-devel-0.22.0-21 conflicts with file from package gdk-pixbuf-devel-0.22.0-21 file /usr/share/gettext/libintl.jar from install of gettext-devel-0.14.5-2 conflicts with file from package gettext-devel-0.14.5-2 file /usr/bin/ijs-config from install of ghostscript-devel-8.15.1-3 conflicts with file from package ghostscript-devel-8.15.1-3 file /usr/bin/gimpprint-config from install of gimp-print-devel-4.2.7-13 conflicts with file from package gimp-print-devel-4.2.7-13 file /usr/include/gkrellm2/gkrellm.h from install of gkrellm-devel-2.2.7-5 conflicts with file from package gkrellm-devel-2.2.7-5 file /usr/include/gkrellm2/gkrellmd.h from install of gkrellm-devel-2.2.7-5 conflicts with file from package gkrellm-devel-2.2.7-5 file /usr/bin/glib-config from install of glib-devel-1.2.10-18 conflicts with file from package glib-devel-1.2.10-18 file /usr/share/java/glib0.2-src-0.2.1.zip from install of glib-java-devel-0.2.1-2 conflicts with file from package glib-java-devel-0.2.1-2 file /usr/include/gmp-mparam.h from install of gmp-devel-4.1.4-6 conflicts with file from package gmp-devel-4.1.4-6 file /usr/include/gmp.h from install of gmp-devel-4.1.4-6 conflicts with file from package gmp-devel-4.1.4-6 file /usr/bin/gnome-config from install of gnome-libs-devel-1.4.1.2.90-46 conflicts with file from package gnome-libs-devel-1.4.1.2.90-46 file /usr/bin/libart-config from install of gnome-libs-devel-1.4.1.2.90-46 conflicts with file from package gnome-libs-devel-1.4.1.2.90-46 file /usr/include/gnome-1.0/libart_lgpl/art_config.h from install of gnome-libs-devel-1.4.1.2.90-46 conflicts with file from package gnome-libs-devel-1.4.1.2.90-46 file /usr/share/gtk-doc/html/gnome-vfs-2.0/about.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-2.0.devhelp from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-application-registry.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-async-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-cancellation.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-context.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-directory-basic-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-directory-find-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-directory-list-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-dns-sd.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-drive.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-advanced-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-basic-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-info-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-info.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-rw-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-size.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-file-trunc-ops.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-inet-connection.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-init.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-method.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-mime-database-deprecated.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-mime-database.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-mime-monitor.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-mime.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-module-callback-module-api.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-module-callback.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-module-shared.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-module.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-monitor.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-parse-ls.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-resolve.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-result.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-socket-buffer.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-socket.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-ssl.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-standard-callbacks.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-transform.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-uri.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-utils.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-volume-monitor.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-volume.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-20-gnome-vfs-xfer.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-first-steps.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/gnome-vfs-writing-modules.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/share/gtk-doc/html/gnome-vfs-2.0/index.html from install of gnome-vfs2-devel-2.13.1-1 conflicts with file from package gnome-vfs2-devel-2.13.1-1 file /usr/bin/libgnutls-config from install of gnutls-devel-1.2.9-1 conflicts with file from package gnutls-devel-1.2.9-1 file /usr/bin/libgnutls-extra-config from install of gnutls-devel-1.2.9-1 conflicts with file from package gnutls-devel-1.2.9-1 file /usr/bin/gphoto2-config from install of gphoto2-devel-2.1.6-7 conflicts with file from package gphoto2-devel-2.1.6-7 file /usr/bin/gphoto2-port-config from install of gphoto2-devel-2.1.6-7 conflicts with file from package gphoto2-devel-2.1.6-7 file /usr/bin/gsl-config from install of gsl-devel-1.7-1 conflicts with file from package gsl-devel-1.7-1 file /usr/share/gtk-doc/html/gstreamer-0.8/GstBin.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstClock.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstElement.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstElementFactory.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstGhostPad.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstImplementsInterface.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstIndex.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstIndexFactory.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstObject.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstPad.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstPadTemplate.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstPipeline.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstPluginFeature.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstQueue.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstRealPad.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstRegistry.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstScheduler.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstSchedulerFactory.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstTagSetter.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstThread.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstTypeFindFactory.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/GstXML.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/api-index.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-Gst.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstAtomic.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstBuffer.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstCPU.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstCaps.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstCompat.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstData.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstElementDetails.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstEvent.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstFilter.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstFormat.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstGError.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstInfo.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstMacros.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstMemChunk.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstParse.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstPlugin.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstProbe.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstQuery.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstRegistryPool.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstStructure.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstSystemClock.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstTagList.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstTypeFind.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstTypes.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstUriHandler.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstUriType.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstUtils.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstValue.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-GstVersion.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-0.8/gstreamer-gstconfig.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/GstDParam.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/GstDParamLinInterp.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/GstDParamManager.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/GstDParamSmooth.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/GstUnitConvert.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/api-index.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/gstreamer-libs-GstControl.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/gstreamer-libs-gstadapter.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/gstreamer-libs-gstbytestream.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/gstreamer-libs-gstdataprotocol.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/share/gtk-doc/html/gstreamer-libs-0.8/gstreamer-libs-gstgetbits.html from install of gstreamer-devel-0.8.11-2 conflicts with file from package gstreamer-devel-0.8.11-2 file /usr/bin/gtk-config from install of gtk+-devel-1.2.10-49 conflicts with file from package gtk+-devel-1.2.10-49 file /usr/share/gtk-doc/html/gtkspell/gtkspell-gtkspell.html from install of gtkspell-devel-2.0.11-1 conflicts with file from package gtkspell-devel-2.0.11-1 file /usr/bin/guile-snarf from install of guile-devel-1.6.7-4 conflicts with file from package guile-devel-1.6.7-4 file /usr/include/libguile/scmconfig.h from install of guile-devel-1.6.7-4 conflicts with file from package guile-devel-1.6.7-4 file /usr/bin/gwenhywfar-config from install of gwenhywfar-devel-1.7.2-3 conflicts with file from package gwenhywfar-devel-1.7.2-3 file /usr/include/gwenhywfar/types.h from install of gwenhywfar-devel-1.7.2-3 conflicts with file from package gwenhywfar-devel-1.7.2-3 file /usr/bin/g-wrap-config from install of g-wrap-devel-1.3.4-9 conflicts with file from package g-wrap-devel-1.3.4-9 file /etc/httpd/build from install of httpd-devel-2.2.0-2 conflicts with file from package httpd-devel-2.2.0-2 file /usr/include/httpd/ap_config_layout.h from install of httpd-devel-2.2.0-2 conflicts with file from package httpd-devel-2.2.0-2 file /usr/sbin/apxs from install of httpd-devel-2.2.0-2 conflicts with file from package httpd-devel-2.2.0-2 file /usr/bin/Magick++-config from install of ImageMagick-c++-devel-6.2.5.4-1 conflicts with file from package ImageMagick-c++-devel-6.2.5.4-1 file /usr/bin/Magick-config from install of ImageMagick-devel-6.2.5.4-1 conflicts with file from package ImageMagick-devel-6.2.5.4-1 file /usr/include/magick/magick-config.h from install of ImageMagick-devel-6.2.5.4-1 conflicts with file from package ImageMagick-devel-6.2.5.4-1 file /usr/bin/imlib-config from install of imlib-devel-1.9.13-26 conflicts with file from package imlib-devel-1.9.13-26 file /usr/lib/news/lib/libinn.a from install of inn-devel-2.4.2-4 conflicts with file from package inn-devel-2.4.2-4 file /usr/lib/news/lib/libinnhist.a from install of inn-devel-2.4.2-4 conflicts with file from package inn-devel-2.4.2-4 file /usr/lib/news/lib/libstorage.a from install of inn-devel-2.4.2-4 conflicts with file from package inn-devel-2.4.2-4 file /usr/bin/aot-compile-rpm from install of java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh conflicts with file from package java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh file /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar from install of java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh conflicts with file from package java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp_55rh file /usr/include/kde/knotifywidgetbase.h from install of kdelibs-devel-3.5.0-1 conflicts with file from package kdelibs-devel-3.5.0-1 file /usr/include/kde/kopete/ui/fileconfirmbase.h from install of kdenetwork-devel-3.5.0-1 conflicts with file from package kdenetwork-devel-3.5.0-1 file /usr/include/kde/kopete/ui/kopeteawaydialogbase.h from install of kdenetwork-devel-3.5.0-1 conflicts with file from package kdenetwork-devel-3.5.0-1 file /usr/include/kde/kopete/ui/kopetepassworddialog.h from install of kdenetwork-devel-3.5.0-1 conflicts with file from package kdenetwork-devel-3.5.0-1 file /usr/include/kde/kopete/ui/kopetepasswordwidgetbase.h from install of kdenetwork-devel-3.5.0-1 conflicts with file from package kdenetwork-devel-3.5.0-1 file /usr/include/gssapi/gssapi.h from install of krb5-devel-1.4.3-1 conflicts with file from package krb5-devel-1.4.3-1 file /usr/include/kerberosIV/kadm_err.h from install of krb5-devel-1.4.3-1 conflicts with file from package krb5-devel-1.4.3-1 file /usr/include/kerberosIV/krb_err.h from install of krb5-devel-1.4.3-1 conflicts with file from package krb5-devel-1.4.3-1 file /usr/include/krb5.h from install of krb5-devel-1.4.3-1 conflicts with file from package krb5-devel-1.4.3-1 file /usr/include/profile.h from install of krb5-devel-1.4.3-1 conflicts with file from package krb5-devel-1.4.3-1 file /usr/kerberos/bin/krb5-config from install of krb5-devel-1.4.3-1 conflicts with file from package krb5-devel-1.4.3-1 file /usr/bin/libart2-config from install of libart_lgpl-devel-2.3.17-2 conflicts with file from package libart_lgpl-devel-2.3.17-2 file /usr/include/libart-2.0/libart_lgpl/art_config.h from install of libart_lgpl-devel-2.3.17-2 conflicts with file from package libart_lgpl-devel-2.3.17-2 file /usr/share/gtk-doc/html/libbtctl/BtctlController.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/share/gtk-doc/html/libbtctl/BtctlObex.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/share/gtk-doc/html/libbtctl/ch01.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/share/gtk-doc/html/libbtctl/ch02.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/share/gtk-doc/html/libbtctl/ch03.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/share/gtk-doc/html/libbtctl/libbtctl-btctl-discovery-source.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/share/gtk-doc/html/libbtctl/libbtctl-obex-server-source.html from install of libbtctl-devel-0.5.0-1 conflicts with file from package libbtctl-devel-0.5.0-1 file /usr/bin/croco-0.6-config from install of libcroco-devel-0.6.0-6 conflicts with file from package libcroco-devel-0.6.0-6 file /usr/include/c++/4.0.2/java/lang/Integer.h from install of libgcj-devel-4.0.2-6 conflicts with file from package libgcj-devel-4.0.2-6 file /usr/include/c++/4.0.2/javax/swing/Spring.h from install of libgcj-devel-4.0.2-6 conflicts with file from package libgcj-devel-4.0.2-6 file /usr/share/java/gconf2.12-src-2.12.1.zip from install of libgconf-java-devel-2.12.1-1 conflicts with file from package libgconf-java-devel-2.12.1-1 file /usr/bin/libgcrypt-config from install of libgcrypt-devel-1.2.2-1 conflicts with file from package libgcrypt-devel-1.2.2-1 file /usr/bin/libglade-config from install of libglade-devel-0.17-16 conflicts with file from package libglade-devel-0.17-16 file /usr/share/java/glade2.12-src-2.12.1.zip from install of libglade-java-devel-2.12.1-2 conflicts with file from package libglade-java-devel-2.12.1-2 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvas.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasBpath.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasClipgroup.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasEllipse.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasGroup.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasItem.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasLine.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasPixbuf.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasPolygon.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasRE.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasRect.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasRichText.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasShape.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasText.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/GnomeCanvasWidget.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/ch01.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/ch02.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/libgnomecanvas-gnome-canvas-path-def.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnomecanvas/libgnomecanvas-gnome-canvas-util.html from install of libgnomecanvas-devel-2.12.0-1 conflicts with file from package libgnomecanvas-devel-2.12.0-1 file /usr/share/gtk-doc/html/libgnome/ch01s02.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/ch01s03.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/ch01s04.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/ch01s05.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/index.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-config.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-exec.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-gconf.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-help.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-i18n.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-init.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-program.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-score.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-sound.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-triggers.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-url.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-gnome-util.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome-libgnometypebuiltins.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome.devhelp from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/gtk-doc/html/libgnome/libgnome.html from install of libgnome-devel-2.13.2-1 conflicts with file from package libgnome-devel-2.13.2-1 file /usr/share/java/gnome2.12-src-2.12.1.zip from install of libgnome-java-devel-2.12.1-2 conflicts with file from package libgnome-java-devel-2.12.1-2 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-Pango-Integration.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-compiling.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-font-face.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-font.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-glyphlist.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-pgl.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-print-config.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-print-job.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-print-paper.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-print-unit.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-print.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-gnome-rfont.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprint/libgnomeprint-resources.html from install of libgnomeprint22-devel-2.12.1-3 conflicts with file from package libgnomeprint22-devel-2.12.1-3 file /usr/share/gtk-doc/html/libgnomeprintui/ch02.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-font-dialog.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-print-copies.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-print-dialog.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-print-job-preview.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-print-paper-selector.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-print-preview.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeprintui/libgnomeprintui-gnome-printer-selector.html from install of libgnomeprintui22-devel-2.12.1-1 conflicts with file from package libgnomeprintui22-devel-2.12.1-1 file /usr/share/gtk-doc/html/libgnomeui/GnomeAbout.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeApp.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeAppBar.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeClient.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeColorPicker.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeDateEdit.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeDialog.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeDruid.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeDruidPage.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeDruidPageEdge.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeDruidPageStandard.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeEntry.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeFileEntry.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeFontPicker.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeHRef.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeIconEntry.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeIconList.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeIconSelection.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeMDI.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeMDIChild.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeMDIGenericChild.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeMessageBox.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomePixmap.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomePixmapEntry.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomePropertyBox.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/GnomeScores.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/ch01.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-GnomeIconLookup.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-GnomeIconTheme.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-GnomeThemeFile.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-GnomeThumbnail.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-app-helper.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-app-util.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-dialog-util.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-mdi-session.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-popup-menu.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-stock-icons.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-types.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-ui-init.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-uidefs.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-vfs-util.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnome-window.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/share/gtk-doc/html/libgnomeui/libgnomeui-gnometypebuiltins.html from install of libgnomeui-devel-2.12.0-6 conflicts with file from package libgnomeui-devel-2.12.0-6 file /usr/bin/gpg-error-config from install of libgpg-error-devel-1.1-1 conflicts with file from package libgpg-error-devel-1.1-1 file /usr/share/gtk-doc/html/gsf/GsfBlob.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/GsfClipData.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Bononbo.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Compression.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-GIOChannel.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-GnomeVFS.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Infile-reading-structed-files.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Input-from-unstructured-files.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-MS-OLE2.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Outfile-writing-structed-files.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Output-to-unstructured-files.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Reading-and-Writing-from-local-files-and-directories.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Structured-Blobs.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Text.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-XML-and-libxml.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-Zip.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-gsf-opendoc-utils.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-memory.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-metadata.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/gsf-utils.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/gtk-doc/html/gsf/ix01.html from install of libgsf-devel-1.13.3-2 conflicts with file from package libgsf-devel-1.13.3-2 file /usr/share/java/gtk2.8-src-2.8.1.zip from install of libgtk-java-devel-2.8.1-1 conflicts with file from package libgtk-java-devel-2.8.1-1 file /usr/bin/icu-config from install of libicu-devel-3.4-5 conflicts with file from package libicu-devel-3.4-5 file /usr/bin/libIDL-config-2 from install of libIDL-devel-0.8.6-2 conflicts with file from package libIDL-devel-0.8.6-2 file /usr/include/idn-int.h from install of libidn-devel-0.6.0-1 conflicts with file from package libidn-devel-0.6.0-1 file /usr/bin/libpng12-config from install of libpng-devel-1.2.8-2 conflicts with file from package libpng-devel-1.2.8-2 file /usr/include/silc/mpi.h from install of libsilc-devel-0.9.12-12 conflicts with file from package libsilc-devel-0.9.12-12 file /usr/include/silc/silcincludes.h from install of libsilc-devel-0.9.12-12 conflicts with file from package libsilc-devel-0.9.12-12 file /usr/share/gtk-doc/html/libsoup/SoupAddress.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupAuth.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupConnection.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupConnectionNTLM.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupMessage.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupServer.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupServerMessage.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupSession.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupSessionAsync.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupSessionSync.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupSoapMessage.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/SoupSocket.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/ch01.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/ix01.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/libsoup-soup-dns.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/libsoup-soup-ssl.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/libsoup-soup-status.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/share/gtk-doc/html/libsoup/libsoup-soup-uri.html from install of libsoup-devel-2.2.7-1 conflicts with file from package libsoup-devel-2.2.7-1 file /usr/include/tiffconf.h from install of libtiff-devel-3.7.4-3 conflicts with file from package libtiff-devel-3.7.4-3 file /usr/bin/libusb-config from install of libusb-devel-0.1.10a-1 conflicts with file from package libusb-devel-0.1.10a-1 file /usr/share/gtk-doc/html/libuser/ch01.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-config.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-entity.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-error.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-prompt.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-quota.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-user.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/gtk-doc/html/libuser/libuser-value.html from install of libuser-devel-0.54.3-1 conflicts with file from package libuser-devel-0.54.3-1 file /usr/share/java/vte0.11-src-0.11.11.zip from install of libvte-java-devel-0.11.11-6 conflicts with file from package libvte-java-devel-0.11.11-6 file /usr/bin/libwmf-config from install of libwmf-devel-0.2.8.4-2 conflicts with file from package libwmf-devel-0.2.8.4-2 file /usr/bin/xml2-config from install of libxml2-devel-2.6.22-1 conflicts with file from package libxml2-devel-2.6.22-1 file /usr/bin/xml-config from install of libxml-devel-1.8.17-13 conflicts with file from package libxml-devel-1.8.17-13 file /usr/bin/xslt-config from install of libxslt-devel-1.1.15-1 conflicts with file from package libxslt-devel-1.1.15-1 file /usr/bin/libmikmod-config from install of mikmod-devel-3.1.6-36 conflicts with file from package mikmod-devel-3.1.6-36 file /usr/include/httpd/modperl_xs_sv_convert.h from install of mod_perl-devel-2.0.2-3 conflicts with file from package mod_perl-devel-2.0.2-3 file /usr/include/httpd/modperl_xs_typedefs.h from install of mod_perl-devel-2.0.2-3 conflicts with file from package mod_perl-devel-2.0.2-3 file /usr/include/mozilla-1.7.12/js/jsautocfg.h from install of mozilla-devel-1.7.12-2 conflicts with file from package mozilla-devel-1.7.12-2 file /usr/include/mozilla-1.7.12/mozilla-config.h from install of mozilla-devel-1.7.12-2 conflicts with file from package mozilla-devel-1.7.12-2 file /usr/include/mysql3/mysql/my_config.h from install of mysqlclient10-devel-3.23.58-6 conflicts with file from package mysqlclient10-devel-3.23.58-6 file /usr/include/mysql4/mysql/my_config.h from install of mysqlclient14-devel-4.1.14-1 conflicts with file from package mysqlclient14-devel-4.1.14-1 file /usr/include/mysql/my_config.h from install of mysql-devel-5.0.15-3 conflicts with file from package mysql-devel-5.0.15-3 file /usr/bin/neon-config from install of neon-devel-0.24.7-9 conflicts with file from package neon-devel-0.24.7-9 file /usr/include/pm_config.h from install of netpbm-devel-10.30-2 conflicts with file from package netpbm-devel-10.30-2 file /usr/bin/net-snmp-config from install of net-snmp-devel-5.2.2-1 conflicts with file from package net-snmp-devel-5.2.2-1 file /usr/include/net-snmp/net-snmp-config.h from install of net-snmp-devel-5.2.2-1 conflicts with file from package net-snmp-devel-5.2.2-1 file /usr/share/man/man3/read_config.3.gz from install of net-snmp-devel-5.2.2-1 conflicts with file from package net-snmp-devel-5.2.2-1 file /usr/bin/nspr-config from install of nspr-devel-4.6-4 conflicts with file from package nspr-devel-4.6-4 file /usr/bin/oaf-config from install of oaf-devel-0.6.10-12 conflicts with file from package oaf-devel-0.6.10-12 file /usr/share/openh323/openh323u.mak from install of openh323-devel-1.15.6-3 conflicts with file from package openh323-devel-1.15.6-3 file /usr/include/OpenSP/config.h from install of openjade-devel-1.3.2-16 conflicts with file from package openjade-devel-1.3.2-16 file /usr/bin/orbit2-config from install of ORBit2-devel-2.13.2-1 conflicts with file from package ORBit2-devel-2.13.2-1 file /usr/include/orbit-2.0/orbit/orbit-config.h from install of ORBit2-devel-2.13.2-1 conflicts with file from package ORBit2-devel-2.13.2-1 file /usr/share/gtk-doc/html/ORBit2/ORBit2-orbit2-allocators.html from install of ORBit2-devel-2.13.2-1 conflicts with file from package ORBit2-devel-2.13.2-1 file /usr/share/gtk-doc/html/ORBit2/ORBit2-orbit2-small.html from install of ORBit2-devel-2.13.2-1 conflicts with file from package ORBit2-devel-2.13.2-1 file /usr/bin/libIDL-config from install of ORBit-devel-0.5.17-15 conflicts with file from package ORBit-devel-0.5.17-15 file /usr/bin/orbit-config from install of ORBit-devel-0.5.17-15 conflicts with file from package ORBit-devel-0.5.17-15 file /usr/include/pci/config.h from install of pciutils-devel-2.1.99.test8-10 conflicts with file from package pciutils-devel-2.1.99.test8-10 file /usr/bin/pcre-config from install of pcre-devel-6.3-1 conflicts with file from package pcre-devel-6.3-1 file /usr/bin/php-config from install of php-devel-5.1.1-4 conflicts with file from package php-devel-5.1.1-4 file /usr/bin/phpize from install of php-devel-5.1.1-4 conflicts with file from package php-devel-5.1.1-4 file /usr/include/php/main/build-defs.h from install of php-devel-5.1.1-4 conflicts with file from package php-devel-5.1.1-4 file /usr/include/php/main/php_config.h from install of php-devel-5.1.1-4 conflicts with file from package php-devel-5.1.1-4 file /usr/include/pg_config.h from install of postgresql-devel-8.1.0-4 conflicts with file from package postgresql-devel-8.1.0-4 file /usr/include/pgsql/server/pg_config.h from install of postgresql-devel-8.1.0-4 conflicts with file from package postgresql-devel-8.1.0-4 file /usr/include/ptbuildopts.h from install of pwlib-devel-1.8.7-2 conflicts with file from package pwlib-devel-1.8.7-2 file /usr/share/pwlib/make/ptbuildopts.mak from install of pwlib-devel-1.8.7-2 conflicts with file from package pwlib-devel-1.8.7-2 file /usr/share/pwlib/make/ptlib-config from install of pwlib-devel-1.8.7-2 conflicts with file from package pwlib-devel-1.8.7-2 file /usr/share/pygtk/2.0/codegen/__init__.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/__init__.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/argtypes.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/argtypes.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/codegen.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/codegen.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/definitions.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/definitions.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/defsparser.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/defsparser.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/docextract.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/docextract.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/docgen.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/docgen.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/h2def.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/h2def.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/mergedefs.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/mergedefs.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/mkskel.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/mkskel.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/override.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/override.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/reversewrapper.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/reversewrapper.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/scmexpr.pyc from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/share/pygtk/2.0/codegen/scmexpr.pyo from install of pygtk2-devel-2.8.2-2 conflicts with file from package pygtk2-devel-2.8.2-2 file /usr/include/python2.4/pyconfig.h from install of python-devel-2.4.2-2 conflicts with file from package python-devel-2.4.2-2 file /etc/profile.d/qt.csh from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /etc/profile.d/qt.sh from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/assistant from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/findtr from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/linguist from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/lrelease from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/lupdate from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/moc from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/qembed from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/qm2ts from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/qmake from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/qt20fix from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/qtrename140 from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/uic from install of qt-devel-3.3.5-10 conflicts with file from package qt-devel-3.3.5-10 file /usr/bin/sane-config from install of sane-backends-devel-1.0.16-2 conflicts with file from package sane-backends-devel-1.0.16-2 file /usr/bin/sdl-config from install of SDL-devel-1.2.9-2.1 conflicts with file from package SDL-devel-1.2.9-2.1 file /usr/include/setools/libsefs/sqlite/config.h from install of setools-devel-2.2-2 conflicts with file from package setools-devel-2.2-2 file /usr/bin/libst-config from install of sox-devel-12.17.7-3 conflicts with file from package sox-devel-12.17.7-3 file /usr/include/sox/ststdint.h from install of sox-devel-12.17.7-3 conflicts with file from package sox-devel-12.17.7-3 file /usr/lib/syslinux/com32/libcom32.a from install of syslinux-devel-3.10-2 conflicts with file from package syslinux-devel-3.10-2 file /usr/lib/syslinux/com32/libutil_com.a from install of syslinux-devel-3.10-2 conflicts with file from package syslinux-devel-3.10-2 file /usr/lib/syslinux/com32/libutil_lnx.a from install of syslinux-devel-3.10-2 conflicts with file from package syslinux-devel-3.10-2 file /usr/include/tn5250/config.h from install of tn5250-devel-0.17.3-1 conflicts with file from package tn5250-devel-0.17.3-1 file /usr/share/Pegasus/samples/mak/config.mak from install of tog-pegasus-devel-2.5-4 conflicts with file from package tog-pegasus-devel-2.5-4 file /usr/bin/xdelta-config from install of xdelta-devel-1.1.3-17 conflicts with file from package xdelta-devel-1.1.3-17 file /usr/include/xfs/platform_defs.h from install of xfsprogs-devel-2.7.3-1 conflicts with file from package xfsprogs-devel-2.7.3-1 file /usr/bin/xmlsec1-config from install of xmlsec1-devel-1.2.9-3 conflicts with file from package xmlsec1-devel-1.2.9-3 From dwmw2 at infradead.org Thu Dec 8 23:17:25 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Dec 2005 00:17:25 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051208043947.GA22451@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> Message-ID: <1134083845.19711.84.camel@localhost.localdomain> On Wed, 2005-12-07 at 23:39 -0500, Bill Nottingham wrote: > > 2) Wordsize specific #defines and similar in a header file. > > a) If they're just informational, remove them: > /* configured for i386-redhat-linux */ > b) Abstract them out into separate files, or one > common file. For example, a file that has on i386: > #define LONG_SIZE 4 > and on x86_64: > #define LONG_SIZE 8 > > could be changed to: > > #ifdef __i386__ > #include "bits/i386-defines.h" > #endif > #ifdef __x86_64__ > #include "bits/x86_64-defines.h" > #endif > > and the -defines.h files could be populated only on those arches. OK, so I'm picking on your specific example... but a point which probably needs making anyway... The specific case above _shouldn't_ be changed like that; it should be changed to sizeof(long) instead. If you can write portable code _without_ the gratuitous ifdefs that autoconf(spit) encourages you to abuse, then do so. -- dwmw2 From j.w.r.degoede at hhs.nl Thu Dec 8 23:30:05 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Dec 2005 00:30:05 +0100 Subject: multilib fun - devel packages In-Reply-To: <1134083845.19711.84.camel@localhost.localdomain> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134083845.19711.84.camel@localhost.localdomain> Message-ID: <4398C1FD.30503@hhs.nl> David Woodhouse wrote: > On Wed, 2005-12-07 at 23:39 -0500, Bill Nottingham wrote: >> 2) Wordsize specific #defines and similar in a header file. >> >> a) If they're just informational, remove them: >> /* configured for i386-redhat-linux */ >> b) Abstract them out into separate files, or one >> common file. For example, a file that has on i386: >> #define LONG_SIZE 4 >> and on x86_64: >> #define LONG_SIZE 8 >> >> could be changed to: >> >> #ifdef __i386__ >> #include "bits/i386-defines.h" >> #endif >> #ifdef __x86_64__ >> #include "bits/x86_64-defines.h" >> #endif >> >> and the -defines.h files could be populated only on those arches. > > OK, so I'm picking on your specific example... but a point which > probably needs making anyway... > > The specific case above _shouldn't_ be changed like that; it should be > changed to sizeof(long) instead. If you can write portable code > _without_ the gratuitous ifdefs that autoconf(spit) encourages you to > abuse, then do so. > Things are not always that easy, LONG_SIZE as currently defined may be used safely in preprocessor integer arithmetic, sizeof(long) == 0 as far as the preprocessor is concerned. Regards, Hans From orion at cora.nwra.com Thu Dec 8 23:23:55 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 08 Dec 2005 16:23:55 -0700 Subject: multilib fun - devel packages In-Reply-To: <20051208043947.GA22451@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> Message-ID: <4398C08B.7070907@cora.nwra.com> Bill Nottingham wrote: > One of the things we've been looking at is improving support for > multilib/multiarch environments. The next big step is handling > devel packages so they can be installed in a multilib fashion. > > However, many devel packages have conflicts in their header > and similar files. > Can a similar report be generated for Extras? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From dwmw2 at infradead.org Thu Dec 8 23:26:04 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Dec 2005 00:26:04 +0100 Subject: multilib fun - devel packages In-Reply-To: <4398C1FD.30503@hhs.nl> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134083845.19711.84.camel@localhost.localdomain> <4398C1FD.30503@hhs.nl> Message-ID: <1134084364.19711.85.camel@localhost.localdomain> On Fri, 2005-12-09 at 00:30 +0100, Hans de Goede wrote: > Things are not always that easy, LONG_SIZE as currently defined may be > used safely in preprocessor integer arithmetic, sizeof(long) == 0 as far > as the preprocessor is concerned. This is true, but still there's almost certainly going to be a more portable solution than one involving ifdefs on i386 or x86_64. -- dwmw2 From skvidal at phy.duke.edu Fri Dec 9 00:12:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 19:12:43 -0500 Subject: multilib fun - devel packages In-Reply-To: <4398C08B.7070907@cora.nwra.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <4398C08B.7070907@cora.nwra.com> Message-ID: <1134087163.28503.13.camel@cutter> On Thu, 2005-12-08 at 16:23 -0700, Orion Poplawski wrote: > Bill Nottingham wrote: > > One of the things we've been looking at is improving support for > > multilib/multiarch environments. The next big step is handling > > devel packages so they can be installed in a multilib fashion. > > > > However, many devel packages have conflicts in their header > > and similar files. > > > > Can a similar report be generated for Extras? > we don't ship any multilib pkgs in extras at all. and if it is possible hopefully we can keep it that way! :) -sv From tgl at redhat.com Fri Dec 9 02:12:56 2005 From: tgl at redhat.com (Tom Lane) Date: Thu, 08 Dec 2005 21:12:56 -0500 Subject: multilib fun - devel packages In-Reply-To: <1134084364.19711.85.camel@localhost.localdomain> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134083845.19711.84.camel@localhost.localdomain> <4398C1FD.30503@hhs.nl> <1134084364.19711.85.camel@localhost.localdomain> Message-ID: <5918.1134094376@sss.pgh.pa.us> David Woodhouse writes: > On Fri, 2005-12-09 at 00:30 +0100, Hans de Goede wrote: >> Things are not always that easy, LONG_SIZE as currently defined may be >> used safely in preprocessor integer arithmetic, sizeof(long) == 0 as far >> as the preprocessor is concerned. > This is true, but still there's almost certainly going to be a more > portable solution than one involving ifdefs on i386 or x86_64. It's unlikely that upstream developers are going to be interested in making wholesale changes to their configuration procedures just because Red Hat objects to having machine-dependent config files that are actually machine-dependent. They'll say, "Yup, that's what they are supposed to be." Personally I'll probably be following Bill's suggestion of #ifdef __i386__ #include "bits/i386-defines.h" #endif #ifdef __x86_64__ #include "bits/x86_64-defines.h" #endif But what's not very clear to me is where he imagines these additional files will go --- is the reference to bits/ supposed to imply some particular scheme, and if so what is it? Personally I'd rather not add a new subdirectory --- mainly because I don't see which package would own it --- and would rather have, say, my_config.h #including my_config_i386.h and so on from the same directory. regards, tom lane From rc040203 at freenet.de Fri Dec 9 04:11:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Dec 2005 05:11:50 +0100 Subject: multilib fun - devel packages In-Reply-To: <1134087163.28503.13.camel@cutter> References: <20051208043947.GA22451@devserv.devel.redhat.com> <4398C08B.7070907@cora.nwra.com> <1134087163.28503.13.camel@cutter> Message-ID: <1134101511.18030.113.camel@mccallum.corsepiu.local> On Thu, 2005-12-08 at 19:12 -0500, seth vidal wrote: > On Thu, 2005-12-08 at 16:23 -0700, Orion Poplawski wrote: > > Bill Nottingham wrote: > > > One of the things we've been looking at is improving support for > > > multilib/multiarch environments. The next big step is handling > > > devel packages so they can be installed in a multilib fashion. > > > > > > However, many devel packages have conflicts in their header > > > and similar files. > > > > > > > Can a similar report be generated for Extras? > > > > we don't ship any multilib pkgs in extras at all. ??? These issues affect Extras in the same way as they affect Core. Very oversimplified, Bill's remark boils down to: "Can xxx-devel-V-R.i386.rpm and xxx-devel-V-R.x86_64.rpm be installed simultaneously and in parallel without conflicts or functional defects?" Also, if thinking a bit further on this case, it's easy to identify more classes of breakages than Bill mentioned. Just to mention a few: * arch-depended package dependencies. * arch-depended runtime features. * rpm scriptlets. > and if it is possible hopefully we can keep it that way! :) Well, if FC and FE were shipping real multilib'ed packages (i.e. packages containing files for several archs of a basearch at once), this thread would not exist, because then, all packages which are not ready/designed for multilibs could not be shipped. Ralf From jorton at redhat.com Fri Dec 9 08:12:30 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 9 Dec 2005 08:12:30 +0000 Subject: multilib fun - devel packages In-Reply-To: <20051208043947.GA22451@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> Message-ID: <20051209081229.GA12061@redhat.com> On Wed, Dec 07, 2005 at 11:39:47PM -0500, Bill Nottingham wrote: > There are varying solutions that can be done, depending > on the sorts of conflicts: > > 1) Old-style -config scripts for setting CFLAGS and > LDFLAGS. Example: libst-config > > Can be a) ported to pkg-config b) genericized to have a > single script for all arches. At least for some of my packages it's not possible to simply remove the *-config scripts, they are an essential part of the build infrastructure. I don't see how (b) is possible. How do I tell a foo-config script whether it's doing an -m32 or an -m64 build? > 2) Wordsize specific #defines and similar in a header file. Not possible without massive deviation from upstream. joe From jakub at redhat.com Fri Dec 9 08:19:14 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 9 Dec 2005 03:19:14 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051209081229.GA12061@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> Message-ID: <20051209081914.GK31785@devserv.devel.redhat.com> On Fri, Dec 09, 2005 at 08:12:30AM +0000, Joe Orton wrote: > > 2) Wordsize specific #defines and similar in a header file. > > Not possible without massive deviation from upstream. Unless you do it cleanly and push the changes upstream? glibc does this in the upstream headers, so why couldn't other packages do that as well? If the only differences are wordsize related, you can e.g. portably #include and do: #if LONG_MAX == 2147483647L 32-bit stuff #else if LONG_MAX == 9223372036854775807L 64-bit stuff #else #error Unsupported long size #endif etc. Jakub From jorton at redhat.com Fri Dec 9 08:42:23 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 9 Dec 2005 08:42:23 +0000 Subject: multilib fun - devel packages In-Reply-To: <20051209081914.GK31785@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> <20051209081914.GK31785@devserv.devel.redhat.com> Message-ID: <20051209084223.GB12061@redhat.com> On Fri, Dec 09, 2005 at 03:19:14AM -0500, Jakub Jelinek wrote: > On Fri, Dec 09, 2005 at 08:12:30AM +0000, Joe Orton wrote: > > > 2) Wordsize specific #defines and similar in a header file. > > > > Not possible without massive deviation from upstream. > > Unless you do it cleanly and push the changes upstream? > glibc does this in the upstream headers, so why couldn't other > packages do that as well? > > If the only differences are wordsize related, you can e.g. > portably #include and do: The differences are generally because the entire header is autoconf-generated so really the whole thing would have to be renamed for each platform and an #if/#include stub put in its place. This is feasible but ugly and upstream would have little interest in maintaining such hacks (it's not as if I've ever heard any user cry out for this "problem" to be solved). But without a solution to the -config script issue there's little point in worrying about the headers. joe From jakub at redhat.com Fri Dec 9 08:48:14 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 9 Dec 2005 03:48:14 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051209084223.GB12061@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> <20051209081914.GK31785@devserv.devel.redhat.com> <20051209084223.GB12061@redhat.com> Message-ID: <20051209084814.GL31785@devserv.devel.redhat.com> On Fri, Dec 09, 2005 at 08:42:23AM +0000, Joe Orton wrote: > On Fri, Dec 09, 2005 at 03:19:14AM -0500, Jakub Jelinek wrote: > > On Fri, Dec 09, 2005 at 08:12:30AM +0000, Joe Orton wrote: > > > > 2) Wordsize specific #defines and similar in a header file. > > > > > > Not possible without massive deviation from upstream. > > > > Unless you do it cleanly and push the changes upstream? > > glibc does this in the upstream headers, so why couldn't other > > packages do that as well? > > > > If the only differences are wordsize related, you can e.g. > > portably #include and do: > > The differences are generally because the entire header is > autoconf-generated so really the whole thing would have to be renamed > for each platform and an #if/#include stub put in its place. This is > feasible but ugly and upstream would have little interest in maintaining > such hacks (it's not as if I've ever heard any user cry out for this > "problem" to be solved). It is really not hard to generate the file even in autoconf such that it works for both ABIs. Jakub From rc040203 at freenet.de Fri Dec 9 09:30:48 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Dec 2005 10:30:48 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051209084223.GB12061@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> <20051209081914.GK31785@devserv.devel.redhat.com> <20051209084223.GB12061@redhat.com> Message-ID: <1134120648.16298.46.camel@mccallum.corsepiu.local> On Fri, 2005-12-09 at 08:42 +0000, Joe Orton wrote: > On Fri, Dec 09, 2005 at 03:19:14AM -0500, Jakub Jelinek wrote: > > If the only differences are wordsize related, you can e.g. > > portably #include and do: Well, agreed, this is the by far the most common case as far as ix86/x86_64 are concerned, but I've seen such issues with packages trying to export all kind of system/compiler characteristics, comprising byte alignment, page size, inline asm-macros etc. > The differences are generally because the entire header is > autoconf-generated so really the whole thing would have to be renamed > for each platform and an #if/#include stub put in its place. This is > feasible but ugly and upstream would have little interest in maintaining > such hacks (it's not as if I've ever heard any user cry out for this > "problem" to be solved). Well, you might not have heard about it, probably because your primary target is non-multilib'ed - Users and developers on multilib'ed targets are used to complain about it and having to cope with it ;) [A well known example: lack of multilibs in GNAT (GCC Ada, libada).] Wrt. to autoconf, this topic (Exporting config-headers) comes up on the autoconf mailing list at a regular basis, ca. once per year. So it's not as uncommon as you might think. The answer template to this kind of questions on the autoconf list is: You are abusing the autotools. Auto-headers are not supposed to be exported. As Jakub already pointed out, solutions often are pretty simple, unless a package's API (We are talking about headers) is utterly mal-designed. Ralf From notting at redhat.com Fri Dec 9 18:21:08 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Dec 2005 13:21:08 -0500 Subject: multilib fun - devel packages In-Reply-To: <1134087163.28503.13.camel@cutter> References: <20051208043947.GA22451@devserv.devel.redhat.com> <4398C08B.7070907@cora.nwra.com> <1134087163.28503.13.camel@cutter> Message-ID: <20051209182108.GA15069@devserv.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > we don't ship any multilib pkgs in extras at all. > > and if it is possible hopefully we can keep it that way! :) I suspect that this will have to change. What happens if OOo goes to extras, hypothetically? Bill From skvidal at phy.duke.edu Fri Dec 9 18:24:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 13:24:55 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051209182108.GA15069@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <4398C08B.7070907@cora.nwra.com> <1134087163.28503.13.camel@cutter> <20051209182108.GA15069@devserv.devel.redhat.com> Message-ID: <1134152695.30757.43.camel@cutter> On Fri, 2005-12-09 at 13:21 -0500, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > we don't ship any multilib pkgs in extras at all. > > > > and if it is possible hopefully we can keep it that way! :) > > I suspect that this will have to change. What happens if OOo > goes to extras, hypothetically? > we block b/c it doesn't build on x86_64? :) -sv From notting at redhat.com Fri Dec 9 18:23:31 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Dec 2005 13:23:31 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051209081229.GA12061@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> Message-ID: <20051209182331.GB15069@devserv.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > On Wed, Dec 07, 2005 at 11:39:47PM -0500, Bill Nottingham wrote: > > There are varying solutions that can be done, depending > > on the sorts of conflicts: > > > > 1) Old-style -config scripts for setting CFLAGS and > > LDFLAGS. Example: libst-config > > > > Can be a) ported to pkg-config b) genericized to have a > > single script for all arches. > > At least for some of my packages it's not possible to simply remove the > *-config scripts, they are an essential part of the build > infrastructure. > > I don't see how (b) is possible. How do I tell a foo-config script > whether it's doing an -m32 or an -m64 build? You *can* use uname, although that requires that you use setarch when you're building. Checking $CFLAGS could also be used. Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Dec 9 18:55:57 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 9 Dec 2005 19:55:57 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051208043947.GA22451@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> Message-ID: <20051209195557.52bcf763@python2> Bill Nottingham wrote : > One of the things we've been looking at is improving support for > multilib/multiarch environments. The next big step is handling > devel packages so they can be installed in a multilib fashion. > > However, many devel packages have conflicts in their header > and similar files. Let me ask a silly question here : Why do we want to encourage people to build 32bit stuff on 64bit installs? As far as I'm concerned, we should already be trying to fix everything that made some 32bit packages get into 64bit installs (unfortunately, things like binary web browser plugins aren't helping). IMHO, there is too much workload and complexity created by any of the suggestions made. Just setarch and use mach or moch. Trying to get multiarch devel packages is probably going to be close to cross-compiling... ugly hacks, hard-to-manage-long Fedora specific patches upstream authors won't want to include, etc. Just my opinion, then again, I've never liked the whole multilib concept, and seeing it about to get worse gets me wondering some more. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1644_FC4 Load : 0.23 0.19 0.35 From nalin at redhat.com Fri Dec 9 19:05:24 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 9 Dec 2005 14:05:24 -0500 Subject: multilib fun - devel packages In-Reply-To: <1134087163.28503.13.camel@cutter> References: <20051208043947.GA22451@devserv.devel.redhat.com> <4398C08B.7070907@cora.nwra.com> <1134087163.28503.13.camel@cutter> Message-ID: <20051209190524.GB11457@redhat.com> On Thu, Dec 08, 2005 at 07:12:43PM -0500, seth vidal wrote: > we don't ship any multilib pkgs in extras at all. > > and if it is possible hopefully we can keep it that way! :) Sorry, you lose. :( Extras development contains modules for PAM (shared objects under %{_lib}/security), for both GTK and Qt (under %{_libdir}/gtk-2.0 and %{_libdir}/qt-*.*/plugins), and glibc (any shared object with a soname matching 'libnss_*.so.2'). The libraries which use these modules are provided for multilib systems, so any plugins which they can use should be also be provided for the sake of apps which use those libraries. Cheers, Nalin From skvidal at phy.duke.edu Fri Dec 9 19:09:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 14:09:07 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051209195557.52bcf763@python2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> Message-ID: <1134155348.30757.45.camel@cutter> > Let me ask a silly question here : Why do we want to encourage people to > build 32bit stuff on 64bit installs? As far as I'm concerned, we should > already be trying to fix everything that made some 32bit packages get into > 64bit installs (unfortunately, things like binary web browser plugins > aren't helping). > > IMHO, there is too much workload and complexity created by any of the > suggestions made. Just setarch and use mach or moch. Trying to get > multiarch devel packages is probably going to be close to > cross-compiling... ugly hacks, hard-to-manage-long Fedora specific patches > upstream authors won't want to include, etc. > > Just my opinion, then again, I've never liked the whole multilib concept, > and seeing it about to get worse gets me wondering some more. +10 I completely agree. Is there a defensibly good reason why we should be encouraging more multilib packages for fedora? -sv From dwmw2 at infradead.org Fri Dec 9 23:32:26 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 10 Dec 2005 00:32:26 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051209195557.52bcf763@python2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> Message-ID: <1134171146.19711.154.camel@localhost.localdomain> On Fri, 2005-12-09 at 19:55 +0100, Matthias Saou wrote: > Let me ask a silly question here : Why do we want to encourage people to > build 32bit stuff on 64bit installs? On PPC we use mostly 32-bit packages, because 64-bit is fairly pointless for most things. The choice of ppc32 vs. ppc64 isn't the same as the choice of ia32 vs. amd64, because in the ppc case the 32-bit option is still actually a sane architecture with a sane number of registers -- whereas on amd64 you gain more by using the extra registers than you lose to the natural inefficiency of 64-bit code. -- dwmw2 From notting at redhat.com Sat Dec 10 05:23:09 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 10 Dec 2005 00:23:09 -0500 Subject: Core BrainStorm In-Reply-To: <1133122591.21208.47.camel@cutter> References: <1133122591.21208.47.camel@cutter> Message-ID: <20051210052309.GD25071@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > So if you have any ideas discuss them here and post criteria to the > brainstorm page. OK, time for a brain dump. Stephen mentioned wondering who the Core architects were. Historically, it's been a loose confederation that involved mainly myself, Elliot Lee, and Jeremy Katz, with other people as necessary. New packages would be proposed, generally by those who would be maintaining them. They'd be asked to provide: - package name (example recently: libosp) - what it does (blah) - why it's needed (it was split off from openjade. Required by various things) - whether or not it needed to be in the comps file (and if so, where) A decision would then be made; sometimes it would be 'please put this in Extras instead'. If it was decided to be fine for Core, it would be added to some internal machinery, and the maintainer would check it into CVS and build it. A similar process would be followed for package removals. However, general reviews of the package universe looking for likely candidates for movement were only done when there was a space crunch, or as occasional projects when bored (such as looking for libraries no longer used by any apps.) That's the general mechanics of it, anyway. Now, as to criteria. I'm sure some of the interaction designers will tell me we're going about it the wrong way, but we've historically looked at the following usage cases: - Internet-attached server This means a server for the main internet protocols. This would include a web server, a database server, name server, DHCP server, etc. More esoteric things like gopher servers, IRC servers, or game servers wouldn't really fall into this category, though. - Knowledge worker desktop This would include the base desktop shell and applications that a typical knowledge worker would use - web browser, office suite, e-mail client, chat/IM client. - Technical workstation/desktop This is a superset of the knowledge worker desktop; it would include some basic development tools, and possibly things such as graphics editors. There are various usage cases we *haven't* focused on: - Game machine, with all the various open source games - Educational desktop for kids On top of these various usage cases, we have technical constraints that drive decisions: 1) Core must be self-hosting. 2) Extras must be self-hosting in conjunction with Core. 3) Subpackages cannot be split between Core and Extras, at least not without building them in each instance separately. Now, the question is, within Core, how do we apply these usage cases and criteria to packages to determine what is and isn't appropriate? Generally, we want to ship best-of-breed apps for any particular functionality. While we release that multiple implementations of various things exist and will need to be shipped (barring something very unforseen, we'll always have both Perl and Python), we want to limit the number of redundant apps - in nearly all cases, Extras is the perfect place for them. When determining what we'd consider best-of-breed, we have the following criteria (not all of these would apply to every package): - should be localized, or at least localizeable - should support internationalized input - should function properly in UTF-8 - should be in a modern graphical toolkit, such as GTK+ or QT - should not drag in an excess number of dependencies Historically, we've erred on the side of adding software; there has been a more-is-better approach, as the amount of things people expect a distribution to do increases. Now, how should this change in the future? What needs to happen, in my opinion, is that the idea of functionality being in packages in Extras shouldn't be seen as a bad thing, or as a barrier to entry. There are various ways to accomplish this: - brand the universe of Core + Extras as Fedora, and generally refer to that, as opposed to Fedora Core and Fedora Extras This could have ramifications on other projects, though - as how does this relate to things such as Fedora Directory Server, or other future Fedora Projects? - seamlessly allow Extras to be everywhere that Core is from an installation path - anaconda, yum, pup, system-config-packages, etc. This is done for yum and pup, but not yet for the others. - allow functionality grouping of packages for download and ISO creation, and potentially do this for Extras I've posted about this before - I think it simplifies the user experience if you have things like Fedora Office, Fedora Java - plus, it allows people to easily see what they would need to download for what they want. Alternatively, we could push DVD isos everywhere. But then we'd probably overflow those. (Fedora Blu-Ray!) Once we accomplish these things, we can then reexamine the package contents of Fedora Core as it stands now, and potentially rearrange things significantly. However, this does bring up issues: - Extras and Core have differing release models, generally. Core has a Release, plus Updates. Extras has a more rolling release model. It could be possible to move Extras to be released more like Core, complete with Updates and advisorys. However, I don't know if that's practical or wanted - it requires more discussion. - With the more rolling release model of Extras, how does that fit in with building CD images, or grouping of packages? Do we offer services that build Extras CDs on-the-fly? Do we have generated Extras isos at Core release time, and never afterwards? Do we allow third-parties to make their own Extras isos with scripts (or infrastructure) that we provide? (Cue the Trademark policy!) There are probably other issues I'm missing in this 20000 foot view. While we're here, we could think of new criteria that we'd use, and new polcies we could implement as part of this. Examples would be: - Compatibility libraries - All compatiblity libraries exist solely in Extras (unless they are required by Core packages - this should be minimized, of course.) Compatiblity libraries could exist in Extras for a period of time that is at the discretion of the maintainer, or we could have specific policy (one release? two releases?) This is something we could start implementing today. - Support for languages not deemed as being fully supported (whether by average translation percentage, or some other metric) would exist solely in Extras. Frankly, I think this is a bad idea, but I know that others disagree with me. I suspect we could come up with some significant reducutions in Core if we tried hard. Looking over a report of all the leaf nodes in the distribution would produce lists of smaller packages that could be removed, while reexaming the entirety of Core based on these criteria could remove various larger things. Examples of the former could include things like privoxy or dtach; examples of the latter could include larger things ranging from Jonas to KDE to Ruby. However, it's my opinion that a lot of implementation of the latter category should wait until we have install-time support for multiple repostiories, and potentially support for CD grouping of the same. Perhaps we should go down this road and start listing such things that we would move in the release notes, in preparation for FC6/FE6. Or should that just be F6: And You Thought Twister Was Bad! Comments? Flames? Not at all what you were looking for? Bill From notting at redhat.com Sat Dec 10 05:23:14 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 10 Dec 2005 00:23:14 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051209195557.52bcf763@python2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> Message-ID: <20051210052314.GE25071@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > IMHO, there is too much workload and complexity created by any of the > suggestions made. Just setarch and use mach or moch. Trying to get > multiarch devel packages is probably going to be close to > cross-compiling... ugly hacks, hard-to-manage-long Fedora specific patches > upstream authors won't want to include, etc. You're probably looking at this from the x86/x86_64 dichotomy, where we ship both ABIs as entirely separate distros - this makes it easy to build one or the other. Imagine a future where you'd only ship a 64-bit release, with support for 32-bit compatiblity. Where would you find all the packages to populate your mock tree for such a build? How would you handle this without co-existing devel packages? Now, imagine you're talking about arches such as ppc and ppc64, or sparc and sparc64. You're already at this stage, although in reverse - you have a mainly 32-bit OS, which has 64-bit compatiblity. HOw do you build those 64-bit packages without co-existing devel, if the whole tree isn't shipped? (You'll note that while there are ppc and ppc64 'trees' in rawhide, we don't actually ship a disparate distro for ppc64.) Bill From jkeating at j2solutions.net Sat Dec 10 08:20:58 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Dec 2005 00:20:58 -0800 Subject: Core BrainStorm In-Reply-To: <20051210052309.GD25071@nostromo.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <1134202858.3010.205.camel@yoda.loki.me> On Sat, 2005-12-10 at 00:23 -0500, Bill Nottingham wrote: > Comments? Flames? Not at all what you were looking for? Just from a namespace point of view: Core + Extras = Fedora Linux. Targetted core + extras = Fedora Target Linux. So if we cherry pick office applications from core and extras, we wind up with Fedora Office Linux. Flows, makes sense, says exactly what it is, and doesn't get in the way with other Fedora name space projects. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Sat Dec 10 08:32:08 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 10 Dec 2005 00:32:08 -0800 Subject: Core BrainStorm In-Reply-To: <20051210052309.GD25071@nostromo.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <1134203528.3010.211.camel@yoda.loki.me> On Sat, 2005-12-10 at 00:23 -0500, Bill Nottingham wrote: > Comments? Flames? Not at all what you were looking for? More thousand yard stare comments: I much like the idea of customized iso sets consisting of various core + extra packages. This however is a logistical nightmare from a QA point of view. How can we guess that a given random package set (made at a random point after release time) will actually be installable? Also this shouldn't stop us from distributing a few pre-made sets. As for the trademark stuff, Greg and I have cooked up some pretty good thoughts on this, and I'm just waiting for him to put it into usable text and post it to marketing list I do believe. I think we've covered the case where a vendor would toss their own packages into the mix when making their installer. I suppose a question to ask, once we get to the point where we're making specialized disks out of core+extras, and to get to that point we make extras look more like core, what is the benefit of moving packages into extras? Save iso space? We'll be doing that by rolling targetted isos instead of everything possible. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From fedora at leemhuis.info Sat Dec 10 12:22:52 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Dec 2005 13:22:52 +0100 Subject: multilib fun - devel packages In-Reply-To: <1134087163.28503.13.camel@cutter> References: <20051208043947.GA22451@devserv.devel.redhat.com> <4398C08B.7070907@cora.nwra.com> <1134087163.28503.13.camel@cutter> Message-ID: <1134217372.2573.10.camel@localhost.localdomain> Am Donnerstag, den 08.12.2005, 19:12 -0500 schrieb seth vidal: > On Thu, 2005-12-08 at 16:23 -0700, Orion Poplawski wrote: > > Bill Nottingham wrote: > > Can a similar report be generated for Extras? > we don't ship any multilib pkgs in extras at all. > > and if it is possible hopefully we can keep it that way! :) I'd like to propose one (or in fact: two) i386 package for the extras x86_64 tree: wine. It's under development/review in Bug 171526. This would require that we put lcms.i386 from extras in the x86_64 tree, too. All other i386 deps are in core afaics. wine.x86_64 itself should not be build, because that does not compile/work currently (afaik). It would be pretty pointless anyway because it could only run x64 binaries. Disclaimer: No, I'm not interested in wine. I have used WinOS/2 long enough to try to avoid similar things. But I got involved in this discussion somehow... CU thl -- Thorsten Leemhuis From gdk at redhat.com Sat Dec 10 16:43:23 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Sat, 10 Dec 2005 11:43:23 -0500 (EST) Subject: Core BrainStorm In-Reply-To: <20051210052309.GD25071@nostromo.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: Wow. Thoughtful note, Bill. Thanks. My own comments inline. On Sat, 10 Dec 2005, Bill Nottingham wrote: > What needs to happen, in my opinion, is that the idea of functionality > being in packages in Extras shouldn't be seen as a bad thing, or > as a barrier to entry. +1. > There are various ways to accomplish this: > > - brand the universe of Core + Extras as Fedora, and generally refer > to that, as opposed to Fedora Core and Fedora Extras > > This could have ramifications on other projects, though - as > how does this relate to things such as Fedora Directory Server, > or other future Fedora Projects? I think we'll need to figure out how to brand (Core+Extras) and build brand usage policies around that entity. Jesse Keating and I talked this week about precisely that. But I don't think that just calling it "Fedora" will work, for precisely the reason you point out. As frustrating as the name game is, the names "Fedora Core" and "Fedora Extras" have sorta-kinda-worked because they're basically descriptive. Apache is an instructive example. They've got "Apache," which is technically called "HTTP Server" now... but they've also got Apache Tomcat, and Apache Ant, and Apache Directory! And I suspect that we're in for exactly that kind of taxonomy ourselves down the road. > - seamlessly allow Extras to be everywhere that Core is from an > installation path - anaconda, yum, pup, system-config-packages, etc. > > This is done for yum and pup, but not yet for the others. But we're working on it, right? I mean, this *is* the future, right? > - allow functionality grouping of packages for download and ISO > creation, and potentially do this for Extras > > I've posted about this before - I think it simplifies the user > experience if you have things like Fedora Office, Fedora Java - > plus, it allows people to easily see what they would need to > download for what they want. +1. > Alternatively, we could push DVD isos everywhere. But then > we'd probably overflow those. (Fedora Blu-Ray!) I don't think it's an either-or. I think we can and should do both. > Once we accomplish these things, we can then reexamine the > package contents of Fedora Core as it stands now, and potentially > rearrange things significantly. > > However, this does bring up issues: > > - Extras and Core have differing release models, generally. Core > has a Release, plus Updates. Extras has a more rolling release > model. I'm not sure how true this actually is. It's only sorta rolling; we did end up rebuilding the Extras world right before FC4 came out, and I suspect we'll do the same for FC5. > It could be possible to move Extras to be released more like Core, > complete with Updates and advisorys. However, I don't know if > that's practical or wanted - it requires more discussion. It's as practical as we make it. It doesn't need to be a grand production; in Extras-land, it could be as simple as "putting an *advisory* text tag into a changelog means an 'advisory' email gets sent to the right list." If we start to split out current Core packages into Extras, then it'll be important to figure out *some* way to do this. It may be a matter of providing a dead-simple mechanism for the conscientious maintainers -- and then if, over time, it appears that the majority of Extras packagers can handle the security burden, we consider making it a mandate. But baby steps first, I think. > - With the more rolling release model of Extras, how does that fit > in with building CD images, or grouping of packages? Do we > offer services that build Extras CDs on-the-fly? Do we have > generated Extras isos at Core release time, and never afterwards? > Do we allow third-parties to make their own Extras isos with > scripts (or infrastructure) that we provide? (Cue the Trademark > policy!) My take: we figure out favorite collections and build ISOs for each of them. Making sure they all "work" in conjunction with Core could be tricky -- but we could perhaps ask prominent community folks to "release manage" their favorite collections. In the long term, we allow anyone to create their own collections as well, perhaps using the tools and rules that we end up developing to maintain the favorite collections. > There are probably other issues I'm missing in this 20000 foot view. Doubtless -- and if you don't see them, I'm not likely to. :) > While we're here, we could think of new criteria that we'd use, > and new polcies we could implement as part of this. Examples > would be: > > - Compatibility libraries - All compatiblity libraries exist > solely in Extras (unless they are required by Core > packages - this should be minimized, of course.) Compatiblity > libraries could exist in Extras for a period of time that is > at the discretion of the maintainer, or we could have specific > policy (one release? two releases?) > > This is something we could start implementing today. +1 > - Support for languages not deemed as being fully supported (whether > by average translation percentage, or some other metric) would > exist solely in Extras. > > Frankly, I think this is a bad idea, but I know that others > disagree with me. Why do you think it's a bad idea? > I suspect we could come up with some significant reducutions in > Core if we tried hard. Looking over a report of all the leaf nodes > in the distribution would produce lists of smaller packages that > could be removed... Any chance we could automatically generate for every Core release the RPM dependency graph that Adrian Likins used to build? That would be a *perfect* mechanism to respond to the "hey, let's just remove package X" arguments. > ...while reexaming the entirety of Core based on these criteria could > remove various larger things. Examples of the former could include > things like privoxy or dtach; examples of the latter could include > larger things ranging from Jonas to KDE to Ruby. Obviously, the "favorite collections" idea must be rock-solid before we can even consider the notion of "Kedora". > However, it's my opinion that a lot of implementation of the latter > category should wait until we have install-time support for multiple > repostiories, and potentially support for CD grouping of the same. > Perhaps we should go down this road and start listing such things > that we would move in the release notes, in preparation for FC6/FE6. +1. This is the right roadmap for F6, IMHO. > Comments? Flames? Not at all what you were looking for? One more thing: What about "Fedora Commons" instead of "Fedora Extras"? I realize that it then overloads the FC acronym, but "Extras" seems wrong to me now, especially since we're going to be relying so much upon Extras over time. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From fedora at leemhuis.info Sat Dec 10 18:23:12 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 10 Dec 2005 19:23:12 +0100 Subject: Core BrainStorm In-Reply-To: References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <1134238992.2805.19.camel@localhost.localdomain> Am Samstag, den 10.12.2005, 11:43 -0500 schrieb Greg DeKoenigsberg: > Wow. Thoughtful note, Bill. Yeah, thanks Bill. > On Sat, 10 Dec 2005, Bill Nottingham wrote: > > [...] > > > - brand the universe of Core + Extras as Fedora, and generally refer > > to that, as opposed to Fedora Core and Fedora Extras >[...] > I think we'll need to figure out how to brand (Core+Extras) and build > brand usage policies around that entity. Jesse Keating and I talked > this week about precisely that. But I don't think that just calling it > "Fedora" will work, for precisely the reason you point out. Quoting out of order here: >>...while reexaming the entirety of Core based on these criteria could > > remove various larger things. Examples of the former could include > > things like privoxy or dtach; examples of the latter could include > > larger things ranging from Jonas to KDE to Ruby. > > Obviously, the "favorite collections" idea must be rock-solid before we > can even consider the notion of "Kedora". Why not just Fedora Gnome and Fedora KDE? We avoid both the "KDE is a second class desktop for Fedora" problem and the name "Kedora" this way. And maybe Fedora Server for a version without GUI. Just "Fedora Linux" could also work, but I don't like that idea very much. > > - Support for languages not deemed as being fully supported (whether > > by average translation percentage, or some other metric) would > > exist solely in Extras. > > > > Frankly, I think this is a bad idea, but I know that others > > disagree with me. > > Why do you think it's a bad idea? I'm one of those who think moving some (most?) languages packages to extras is a good idea. But... > > However, it's my opinion that a lot of implementation of the latter > > category should wait until we have install-time support for multiple > > repostiories, and potentially support for CD grouping of the same. ...this must be done first. Just my 2 cent. CU thl -- Thorsten Leemhuis From sundaram at redhat.com Sat Dec 10 18:30:41 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 11 Dec 2005 00:00:41 +0530 Subject: Core BrainStorm In-Reply-To: <1134238992.2805.19.camel@localhost.localdomain> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <1134238992.2805.19.camel@localhost.localdomain> Message-ID: <439B1ED1.9000900@redhat.com> Hi >Why not just Fedora Gnome and Fedora KDE? We avoid both the "KDE is a >second class desktop for Fedora" problem and the name "Kedora" this >way. > > > Not entirely related but is switching more to the upstream defaults in the KDE packages in Fedora under consideration? . The advantage of BlueCurve was consistent theming between GNOME and KDE. Now that GNOME in Fedora using clearlooks the rationale behind sticking with BlueCurve for KDE is unclear to me. Not just the WM theme but also the icons. >And maybe Fedora Server for a version without GUI. Just "Fedora Linux" >could also work, but I don't like that idea very much. > > One of the ideas that could be explored is having Anaconda boot options like say auto which automatically installs Fedora using the default options. Similar choices for desktop, server etc. regards Rahul From jgarzik at redhat.com Sat Dec 10 21:41:48 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Sat, 10 Dec 2005 16:41:48 -0500 Subject: Core BrainStorm In-Reply-To: <20051210052309.GD25071@nostromo.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <20051210214148.GM7206@devserv.devel.redhat.com> On Sat, Dec 10, 2005 at 12:23:09AM -0500, Bill Nottingham wrote: [snip -- great note] > However, it's my opinion that a lot of implementation of the latter > category should wait until we have install-time support for multiple > repostiories, and potentially support for CD grouping of the same. To flog my own personal pet peeve: Install-time support for multiple repos is a big deal, for security reasons. Once the base system is installed, and the user reboots, they find out they have to download an additional 300MB+ of updates, before they have a secure system. Not only does the user install many packages twice (once at install, once during update) but there is a race window between 'unpatched' and 'patched' that can only be solved by installing updates at install time, rather than the not-updated packages. I would also like to see (a) trying several mirrors during install, to select the fastest ones. yum can select among a list of mirrors, why not the installer? (b) having yum use the fast mirrors picked during install, by default. yum picks random mirrors, which with my luck, often winds up being somewhere 3000+ miles away from me, over a tiny and overloaded link. (c) if it isn't already, the installer and yum should use HTTP/1.1 pipelining to avoid tons of DNS lookups and HTTP connections. This was a severe problem a year ago, when I had a slow DNS server. Need to re-test to see if its a problem now. Using >1 HTTP connections would also be nice. Regards, Jeff From jgarzik at redhat.com Sat Dec 10 21:44:35 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Sat, 10 Dec 2005 16:44:35 -0500 Subject: Core BrainStorm In-Reply-To: <1134238992.2805.19.camel@localhost.localdomain> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <1134238992.2805.19.camel@localhost.localdomain> Message-ID: <20051210214435.GN7206@devserv.devel.redhat.com> On Sat, Dec 10, 2005 at 07:23:12PM +0100, Thorsten Leemhuis wrote: > And maybe Fedora Server for a version without GUI. I've long wanted to see this... "Fedora Desktop" could be the desktop version with GNOME, with a KDE fan doing Fedora KDE Desktop. Jeff (a KDE user, in fact) From cra at WPI.EDU Sat Dec 10 23:07:25 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 10 Dec 2005 18:07:25 -0500 Subject: Core BrainStorm In-Reply-To: <20051210052309.GD25071@nostromo.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <20051210230725.GD5988@angus.ind.WPI.EDU> On Sat, Dec 10, 2005 at 12:23:09AM -0500, Bill Nottingham wrote: > - brand the universe of Core + Extras as Fedora, and generally refer > to that, as opposed to Fedora Core and Fedora Extras > - seamlessly allow Extras to be everywhere that Core is from an > installation path - anaconda, yum, pup, system-config-packages, etc. > - allow functionality grouping of packages for download and ISO > creation, and potentially do this for Extras I think it shoud be a goal to bring the Core and Extras processes and infrastructure closer and closer to each other until they can be absorbed into one entity. I like the name "Fedora Commons" that was mentioned elsewhere in this thread, and it has the advantage of using the same acronym, FC. > However, this does bring up issues: > - Extras and Core have differing release models, generally. Core > has a Release, plus Updates. Extras has a more rolling release > model. > - With the more rolling release model of Extras, how does that fit > in with building CD images, or grouping of packages? Do we A merged FC + FE could have timed Releases with CD images, followed by Updates until the next Release. > I suspect we could come up with some significant reducutions in > Core if we tried hard. Looking over a report of all the leaf nodes > in the distribution would produce lists of smaller packages that > could be removed, while reexaming the entirety of Core based on > these criteria could remove various larger things. Examples > of the former could include things like privoxy or dtach; examples > of the latter could include larger things ranging from Jonas > to KDE to Ruby. In a merged FC + FE world, the "Reductions in Core" issue would be generalized to creating functional package groups. Each group or perhaps sets of groups would be put onto CDs/DVDs, for as many CDs/DVDs as needed to hold the entire universe of packages. The base CD would be required to install the system, but the others could be chosen at will. For network installs, these distinctions are even less important. From Matt_Domsch at dell.com Sun Dec 11 00:01:19 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 10 Dec 2005 18:01:19 -0600 Subject: Core BrainStorm In-Reply-To: <20051210214148.GM7206@devserv.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <20051210214148.GM7206@devserv.devel.redhat.com> Message-ID: <20051211000119.GA13087@lists.us.dell.com> On Sat, Dec 10, 2005 at 04:41:48PM -0500, Jeff Garzik wrote: > (a) trying several mirrors during install, to select the fastest ones. > yum can select among a list of mirrors, why not the installer? > > (b) having yum use the fast mirrors picked during install, by default. > yum picks random mirrors, which with my luck, often winds up being > somewhere 3000+ miles away from me, over a tiny and overloaded link. http://people.redhat.com/lmacken/fastestmirror.py works great for me. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jspaleta at gmail.com Sun Dec 11 00:44:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Dec 2005 19:44:02 -0500 Subject: Core BrainStorm In-Reply-To: References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <604aa7910512101644k701a88e1k31d2c5c0b2b3e877@mail.gmail.com> On 12/10/05, Greg DeKoenigsberg wrote: > I'm not sure how true this actually is. It's only sorta rolling; we did > end up rebuilding the Extras world right before FC4 came out, and I > suspect we'll do the same for FC5. No Extras is very much "rolling" and this is going to lead to problems if we get to the point where this project supports or encourages Extras media for networkless install time use. If Fedora is in the future going to support media based install/updates that include Extras in the mix... then either Extras is going to have to have point releases that work with the Core isos. Do you know how difficult its going to be for Vendors to roll "install media" for Extras even if Fedora provides the scripts.. if the package set in the Extras tree is built against Core updates? These sort of media will not work with the official Core isos that are spun up for Core release. Or is the Core release team prepared to start releasing timestamped Core media that includes the Core update packages AND the associated level of bugreport activity that goes along with doing installable media respins? This request has come up in the past and has been shotdown. I don't see a change in that wind coming with regard to the issue of offering official respins. The easiest solution to the "install media" problem is to have a point release tree for Extras that works with the official isos for Core instead of the current rolling model. > It's as practical as we make it. It doesn't need to be a grand > production; in Extras-land, it could be as simple as "putting an > *advisory* text tag into a changelog means an 'advisory' email gets sent > to the right list." The problems are deeper than that. If you want Extras to be "release managed" then there needs to be much mroe structure to Extras. Extras as a collection is going to have to grow some simblance of 'freeze' points around which 'release managers' can start looking over the Extras tree and freeze out releases that work. As long as Extras is a contiual rolling mudball you will give anyone the time to actually do high level release engineering for "favorites." The Extras process must make the time. Point releases that track Core's point release and a development framework in which "freexes" happen to aid the "release managers" > My take: we figure out favorite collections and build ISOs for each of > them. Making sure they all "work" in conjunction with Core could be > tricky -- but we could perhaps ask prominent community folks to "release > manage" their favorite collections. Anyone who signs up to "release manage" collections inside Extras rolling framework is certifiably insane. Be prepared to see HIGH turnover here, these brave people will be fighting against the structure of Extras continually to produce something timely and worthwhile. Unless Extras moves to point release with some "freeze" points for the tree, making a call for these sort of volunteerism is unreasonable and unwise. Take a moment and ask the experts inside the fenceline how difficult it would be if there were timeframes and 'freezes' for the release trees that exist now. -jef From jorton at redhat.com Sun Dec 11 19:35:44 2005 From: jorton at redhat.com (Joe Orton) Date: Sun, 11 Dec 2005 19:35:44 +0000 Subject: Core BrainStorm In-Reply-To: <20051210214148.GM7206@devserv.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <20051210214148.GM7206@devserv.devel.redhat.com> Message-ID: <20051211193544.GC3456@redhat.com> On Sat, Dec 10, 2005 at 04:41:48PM -0500, Jeff Garzik wrote: > (c) if it isn't already, the installer and yum should use HTTP/1.1 pipelining > to avoid tons of DNS lookups and HTTP connections. This was a severe problem > a year ago, when I had a slow DNS server. Need to re-test to see if its a > problem now. Using >1 HTTP connections would also be nice. Pipelining does not avoid DNS lookups or making HTTP connections, it avoids latency. But it breaks with many proxies (particularly transparent proxies), so is generally not something you want to turn on by default, especially in something as critical as the installer. joe From laroche at redhat.com Mon Dec 12 10:42:20 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 12 Dec 2005 11:42:20 +0100 Subject: multilib fun - devel packages In-Reply-To: <1134171146.19711.154.camel@localhost.localdomain> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> Message-ID: <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> On Sat, Dec 10, 2005 at 12:32:26AM +0100, David Woodhouse wrote: > On Fri, 2005-12-09 at 19:55 +0100, Matthias Saou wrote: > > Let me ask a silly question here : Why do we want to encourage people to > > build 32bit stuff on 64bit installs? > > On PPC we use mostly 32-bit packages, because 64-bit is fairly pointless > for most things. The choice of ppc32 vs. ppc64 isn't the same as the > choice of ia32 vs. amd64, because in the ppc case the 32-bit option is > still actually a sane architecture with a sane number of registers -- > whereas on amd64 you gain more by using the extra registers than you > lose to the natural inefficiency of 64-bit code. Even on ppc we kind of move slowly over to use more and more 64bit apps, as multilib on power prefers 64bit applications over the 32bit ones. So it would actually make a lot of sense to talk about a ppc64 release where 32bit apps are only "added if needed". regards, Florian La Roche From laroche at redhat.com Mon Dec 12 10:45:36 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 12 Dec 2005 11:45:36 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051209081229.GA12061@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> Message-ID: <20051212104536.GB1326@dudweiler.stuttgart.redhat.com> > > 2) Wordsize specific #defines and similar in a header file. > > Not possible without massive deviation from upstream. This should be done together with upstream. A diff between the header files for different archs should show all problem areas. At least something we should start for the core libs first and then check further ones. Not really a hard problem, but will stay tricky if the changes do not get merged upstream as well. regards, Florian La Roche From jakub at redhat.com Mon Dec 12 10:46:46 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 12 Dec 2005 05:46:46 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> Message-ID: <20051212104646.GY31785@devserv.devel.redhat.com> On Mon, Dec 12, 2005 at 11:42:20AM +0100, Florian La Roche wrote: > On Sat, Dec 10, 2005 at 12:32:26AM +0100, David Woodhouse wrote: > > On Fri, 2005-12-09 at 19:55 +0100, Matthias Saou wrote: > > > Let me ask a silly question here : Why do we want to encourage people to > > > build 32bit stuff on 64bit installs? > > > > On PPC we use mostly 32-bit packages, because 64-bit is fairly pointless > > for most things. The choice of ppc32 vs. ppc64 isn't the same as the > > choice of ia32 vs. amd64, because in the ppc case the 32-bit option is > > still actually a sane architecture with a sane number of registers -- > > whereas on amd64 you gain more by using the extra registers than you > > lose to the natural inefficiency of 64-bit code. > > > Even on ppc we kind of move slowly over to use more and more 64bit apps, > as multilib on power prefers 64bit applications over the 32bit ones. But that's just rpm bug, it shouldn't always prefer 64bit rpms over 32bit ones, instead decide based on how it was configured. For x86_64, it should be obviously defined to prefer 64bit, I think on s390x similarly (there 64-bit code can do direct calls rather than go through the literal pool all the time etc.). On ppc and sparc it should on the other side prefer 32bit rpms over 64bit. Jakub From laroche at redhat.com Mon Dec 12 11:30:38 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 12 Dec 2005 12:30:38 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051212104646.GY31785@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> <20051212104646.GY31785@devserv.devel.redhat.com> Message-ID: <20051212113038.GC1326@dudweiler.stuttgart.redhat.com> On Mon, Dec 12, 2005 at 05:46:46AM -0500, Jakub Jelinek wrote: > On Mon, Dec 12, 2005 at 11:42:20AM +0100, Florian La Roche wrote: > > On Sat, Dec 10, 2005 at 12:32:26AM +0100, David Woodhouse wrote: > > > On Fri, 2005-12-09 at 19:55 +0100, Matthias Saou wrote: > > > > Let me ask a silly question here : Why do we want to encourage people to > > > > build 32bit stuff on 64bit installs? > > > > > > On PPC we use mostly 32-bit packages, because 64-bit is fairly pointless > > > for most things. The choice of ppc32 vs. ppc64 isn't the same as the > > > choice of ia32 vs. amd64, because in the ppc case the 32-bit option is > > > still actually a sane architecture with a sane number of registers -- > > > whereas on amd64 you gain more by using the extra registers than you > > > lose to the natural inefficiency of 64-bit code. > > > > > > Even on ppc we kind of move slowly over to use more and more 64bit apps, > > as multilib on power prefers 64bit applications over the 32bit ones. > > But that's just rpm bug, it shouldn't always prefer 64bit rpms over 32bit > ones, instead decide based on how it was configured. > For x86_64, it should be obviously defined to prefer 64bit, I think > on s390x similarly (there 64-bit code can do direct calls rather than > go through the literal pool all the time etc.). On ppc and sparc > it should on the other side prefer 32bit rpms over 64bit. This would depend on at least 32bit /sbin/ldconfig to also be able to work with 64bit ELF files. If that is fixed somehow within glibc*, then this change to rpm could be tried out. regards, Florian La Roche From jakub at redhat.com Mon Dec 12 11:39:10 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 12 Dec 2005 06:39:10 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051212113038.GC1326@dudweiler.stuttgart.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> <20051212104646.GY31785@devserv.devel.redhat.com> <20051212113038.GC1326@dudweiler.stuttgart.redhat.com> Message-ID: <20051212113910.GZ31785@devserv.devel.redhat.com> On Mon, Dec 12, 2005 at 12:30:38PM +0100, Florian La Roche wrote: > This would depend on at least 32bit /sbin/ldconfig to also be able to > work with 64bit ELF files. If that is fixed somehow within > glibc*, then this change to rpm could be tried out. And it doesn't? It is certainly supposed to handle it just fine. i?86 ldconfig should handle i?86, x86_64 and ia64 libraries, x86_64 should handle x86_64 and i?86, ia64 should handle ia64 and i?86, ppc{,64} should handle ppc and ppc64, s390{,x} ldconfig should handle s390{,x}, sparc{,64} should handle sparc{,64} and mips should handle the various mips ABIs. As far as glibc is concerned, the only requirement is that on x86_64 x86_64 headers are used and not i?86 ones, as only the former support both ABIs (and of course on ia64 too, but there -m32 isn't supported at all). Jakub From jorton at redhat.com Mon Dec 12 11:54:11 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 12 Dec 2005 11:54:11 +0000 Subject: multilib fun - devel packages In-Reply-To: <20051209182331.GB15069@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209081229.GA12061@redhat.com> <20051209182331.GB15069@devserv.devel.redhat.com> Message-ID: <20051212115411.GA26636@redhat.com> On Fri, Dec 09, 2005 at 01:23:31PM -0500, Bill Nottingham wrote: > Joe Orton (jorton at redhat.com) said: > > I don't see how (b) is possible. How do I tell a foo-config script > > whether it's doing an -m32 or an -m64 build? > > You *can* use uname, although that requires that you use setarch > when you're building. Checking $CFLAGS could also be used. So now my -config script becomes something like: case `uname -p` in ppc|i386|...) exec foo-config-32 "$@";; *) exec foo-config-64 "$@";; esac which isn't really something I could take to upstream either. (And given that it doesn't work without setarch *anyway*, well... I'd argue, why not just use chroots in the first place and avoid putting ten zillion ugly hacks into the distro?) joe From tburke at redhat.com Mon Dec 12 16:41:16 2005 From: tburke at redhat.com (Tim Burke) Date: Mon, 12 Dec 2005 11:41:16 -0500 Subject: Core BrainStorm In-Reply-To: References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <439DA82C.8090308@redhat.com> Greg DeKoenigsberg wrote: > > > >>- With the more rolling release model of Extras, how does that fit >> in with building CD images, or grouping of packages? Do we >> offer services that build Extras CDs on-the-fly? Do we have >> generated Extras isos at Core release time, and never afterwards? >> Do we allow third-parties to make their own Extras isos with >> scripts (or infrastructure) that we provide? (Cue the Trademark >> policy!) >> >> > >My take: we figure out favorite collections and build ISOs for each of >them. Making sure they all "work" in conjunction with Core could be >tricky -- but we could perhaps ask prominent community folks to "release >manage" their favorite collections. In the long term, we allow anyone to >create their own collections as well, perhaps using the tools and rules >that we end up developing to maintain the favorite collections. > > > This is a tough compromise between general usefulness and customization. One of the advantages of having so much in core is that for more naieve end users, more things will "just work" because the dependencies are present. This ease of use fosters increased adoption. If we go to the extreme where core is stripped down, and then commonly used stuff is off in extras which have been composed by an infinitely random set of custom isos, then for the naive user, there will likely be lots of frustration. This dependency trauma results from too fine-grained break up of Fedora into custom isos. Don't get me wrong, for the narrow audience that custom isos would be tailired to, thats great, and should be allowed. Whether it should be the main approach is what I question. I'm wondering if a compromise approach of having several functional sets as Bill suggested would be the preferred approach. For example, moving office/document processing apps onto a single iso. Following that approach there may be about 7 separate isos; but at least everyone has a common understanding of what those ISOs are. Whereas its harder to get a common understanding of what the "office edition", "hpc edition", "database server edition", etc, really means. From notting at redhat.com Mon Dec 12 18:37:24 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Dec 2005 13:37:24 -0500 Subject: Core BrainStorm In-Reply-To: References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> Message-ID: <20051212183724.GA17060@devserv.devel.redhat.com> Greg DeKoenigsberg (gdk at redhat.com) said: > > - seamlessly allow Extras to be everywhere that Core is from an > > installation path - anaconda, yum, pup, system-config-packages, etc. > > > > This is done for yum and pup, but not yet for the others. > > But we're working on it, right? I mean, this *is* the future, right? Yes. However, in the case of system-config-packages, this gets messy - if you're spinning various CD groups of Extras, how does it know about these CDs to know what you need? Do you duplicate any CD-related metadata in internet-connect repository data? Do you have it scan CDs for options of what to install? Something else? > > - Extras and Core have differing release models, generally. Core > > has a Release, plus Updates. Extras has a more rolling release > > model. > > I'm not sure how true this actually is. It's only sorta rolling; we did > end up rebuilding the Extras world right before FC4 came out, and I > suspect we'll do the same for FC5. Well, packages are much more likely to be added in Extras then in Core post release - someone will import something new for all the FC releases currently in play. Packages very very rarely get added to Core in updates. There's also Seth's favorite - multilib. :) > > - With the more rolling release model of Extras, how does that fit > > in with building CD images, or grouping of packages? Do we > > offer services that build Extras CDs on-the-fly? Do we have > > generated Extras isos at Core release time, and never afterwards? > > Do we allow third-parties to make their own Extras isos with > > scripts (or infrastructure) that we provide? (Cue the Trademark > > policy!) > > My take: we figure out favorite collections and build ISOs for each of > them. Making sure they all "work" in conjunction with Core could be > tricky -- but we could perhaps ask prominent community folks to "release > manage" their favorite collections. In the long term, we allow anyone to > create their own collections as well, perhaps using the tools and rules > that we end up developing to maintain the favorite collections. The problem I see is we need the trademark ducks in a row before we can do much of this, as it was a barrier to Extras CDs in the past. Perhaps I'm missing something important that changed this. > > - Support for languages not deemed as being fully supported (whether > > by average translation percentage, or some other metric) would > > exist solely in Extras. > > > > Frankly, I think this is a bad idea, but I know that others > > disagree with me. > > Why do you think it's a bad idea? If you don't have support for your language at install time, how do you read the screen to install it later? :) More seriously, I think this needs to at least block on anaconda/etc. installing from secondary repositories, as it's something that *would* be wanted at install time in most cases. > > I suspect we could come up with some significant reducutions in > > Core if we tried hard. Looking over a report of all the leaf nodes > > in the distribution would produce lists of smaller packages that > > could be removed... > > Any chance we could automatically generate for every Core release the RPM > dependency graph that Adrian Likins used to build? That would be a > *perfect* mechanism to respond to the "hey, let's just remove package X" > arguments. Lack of space for 50x50 page postscript documents? > > Comments? Flames? Not at all what you were looking for? > > One more thing: What about "Fedora Commons" instead of "Fedora Extras"? I > realize that it then overloads the FC acronym, but "Extras" seems wrong to > me now, especially since we're going to be relying so much upon Extras > over time. Contrib! *ducks* Would Commons get confused with a patent commons? Bill From notting at redhat.com Mon Dec 12 18:44:14 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Dec 2005 13:44:14 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051212104646.GY31785@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> <20051212104646.GY31785@devserv.devel.redhat.com> Message-ID: <20051212184414.GB17060@devserv.devel.redhat.com> Jakub Jelinek (jakub at redhat.com) said: > But that's just rpm bug, it shouldn't always prefer 64bit rpms over 32bit > ones, instead decide based on how it was configured. > For x86_64, it should be obviously defined to prefer 64bit, I think > on s390x similarly (there 64-bit code can do direct calls rather than > go through the literal pool all the time etc.). On ppc and sparc > it should on the other side prefer 32bit rpms over 64bit. This runs into problems on ppc64 installs when the ioctl/etc compatiblity layer is either a) missing b) broken. Bill From gdk at redhat.com Mon Dec 12 18:39:02 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 12 Dec 2005 13:39:02 -0500 (EST) Subject: Core BrainStorm In-Reply-To: <20051212183724.GA17060@devserv.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <20051212183724.GA17060@devserv.devel.redhat.com> Message-ID: On Mon, 12 Dec 2005, Bill Nottingham wrote: > > My take: we figure out favorite collections and build ISOs for each of > > them. Making sure they all "work" in conjunction with Core could be > > tricky -- but we could perhaps ask prominent community folks to "release > > manage" their favorite collections. In the long term, we allow anyone to > > create their own collections as well, perhaps using the tools and rules > > that we end up developing to maintain the favorite collections. > > The problem I see is we need the trademark ducks in a row before > we can do much of this, as it was a barrier to Extras CDs in the past. > Perhaps I'm missing something important that changed this. We just need to finalize a policy that details precisely how Core and Extras fit together. If we have a coherent universe, and we have standards that allow someone to mix and match from this universe to create their own distro, then we should have the ability to say "this distro is related to Fedora." Counsel agrees with this in theory; we just need to come up with the concrete proposals to Make it Real. > > One more thing: What about "Fedora Commons" instead of "Fedora Extras"? I > > realize that it then overloads the FC acronym, but "Extras" seems wrong to > > me now, especially since we're going to be relying so much upon Extras > > over time. > > Contrib! *ducks* > > Would Commons get confused with a patent commons? Hrm. I suppose it might. Personally, though, I think that the "commons" message is one of the strongest out there. Merits thought, though. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From jkeating at j2solutions.net Mon Dec 12 18:46:39 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Dec 2005 10:46:39 -0800 Subject: Core BrainStorm In-Reply-To: <20051212183724.GA17060@devserv.devel.redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <20051212183724.GA17060@devserv.devel.redhat.com> Message-ID: <1134413199.3010.292.camel@yoda.loki.me> On Mon, 2005-12-12 at 13:37 -0500, Bill Nottingham wrote: > The problem I see is we need the trademark ducks in a row before > we can do much of this, as it was a barrier to Extras CDs in the past. > Perhaps I'm missing something important that changed this. This is something GregDek and I are working on. This has to be nailed down as well before we start allowing OEM pre-installs of Fedora with any kind of modification. One of the aspects of this is can we legally call something Fedora if it includes bits from Core and Extras. [snip] > > > One more thing: What about "Fedora Commons" instead of "Fedora Extras"? I > > realize that it then overloads the FC acronym, but "Extras" seems wrong to > > me now, especially since we're going to be relying so much upon Extras > > over time. > > Contrib! *ducks* > > Would Commons get confused with a patent commons? > So nobody said anything about my suggestion, Fedora Linux which is a combo of Core and Extras components. Targetted rolls can insert the target name between, Fedora Office Linux, Fedora Server Linux, etc... Is there a reason we can't use the term Linux in the name? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From notting at redhat.com Mon Dec 12 18:45:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Dec 2005 13:45:47 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051212184414.GB17060@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> <20051212104646.GY31785@devserv.devel.redhat.com> <20051212184414.GB17060@devserv.devel.redhat.com> Message-ID: <20051212184547.GC17060@devserv.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Jakub Jelinek (jakub at redhat.com) said: > > But that's just rpm bug, it shouldn't always prefer 64bit rpms over 32bit > > ones, instead decide based on how it was configured. > > For x86_64, it should be obviously defined to prefer 64bit, I think > > on s390x similarly (there 64-bit code can do direct calls rather than > > go through the literal pool all the time etc.). On ppc and sparc > > it should on the other side prefer 32bit rpms over 64bit. > > This runs into problems on ppc64 installs when the ioctl/etc > compatiblity layer is either a) missing b) broken. Also, just changing the %prefer64 setting requires changing more than that, as there are ordering implications in upper-level tools that need conditionalized if this changes. Bill From sundaram at redhat.com Mon Dec 12 18:48:17 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 13 Dec 2005 00:18:17 +0530 Subject: Core BrainStorm In-Reply-To: <1134413199.3010.292.camel@yoda.loki.me> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <20051212183724.GA17060@devserv.devel.redhat.com> <1134413199.3010.292.camel@yoda.loki.me> Message-ID: <439DC5F1.7020909@redhat.com> Hi > >So nobody said anything about my suggestion, Fedora Linux which is a >combo of Core and Extras components. Targetted rolls can insert the >target name between, Fedora Office Linux, Fedora Server Linux, etc... >Is there a reason we can't use the term Linux in the name? > > > Maybe? http://www.linuxmark.org/. Fedora, Fedora Office, Fedora Server etc sound better to me anyway. regards Rahul From jkeating at j2solutions.net Mon Dec 12 19:02:06 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Dec 2005 11:02:06 -0800 Subject: Core BrainStorm In-Reply-To: <439DC5F1.7020909@redhat.com> References: <1133122591.21208.47.camel@cutter> <20051210052309.GD25071@nostromo.devel.redhat.com> <20051212183724.GA17060@devserv.devel.redhat.com> <1134413199.3010.292.camel@yoda.loki.me> <439DC5F1.7020909@redhat.com> Message-ID: <1134414126.3010.296.camel@yoda.loki.me> On Tue, 2005-12-13 at 00:18 +0530, Rahul Sundaram wrote: > Maybe? http://www.linuxmark.org/. Fedora, Fedora Office, Fedora Server > etc sound better to me anyway. I think that they are far too ambiguous of terms. Is Fedora Directory Server a spin of Fedora Core+Extras that is suited for being a Directory Server, or is it the project around the software bits of directory server? Is Fedora Documentation a spin suited for authors and publishers, or is it documentation for Fedora? See what I mean? There is major namespace squashing IMHO if we don't use some term that signifies a spin vs a project title. Provided the commonality of all the different $FOO Linux distributions that use the term Linux, I would find it hard to believe that it would be a legal issue preventing the term Linux from being used in this context. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From sopwith at redhat.com Mon Dec 12 19:01:33 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 12 Dec 2005 14:01:33 -0500 (EST) Subject: CVS Message-ID: You should be able to commit to Extras CVS again - sorry for the problems. Best, -- Elliot Unanswered questions in The Matrix: What happens if you take both the red pill AND the blue pill? From dwmw2 at infradead.org Tue Dec 13 08:17:36 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 13 Dec 2005 09:17:36 +0100 Subject: multilib fun - devel packages In-Reply-To: <20051212184414.GB17060@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051209195557.52bcf763@python2> <1134171146.19711.154.camel@localhost.localdomain> <20051212104220.GA1326@dudweiler.stuttgart.redhat.com> <20051212104646.GY31785@devserv.devel.redhat.com> <20051212184414.GB17060@devserv.devel.redhat.com> Message-ID: <1134461856.2607.0.camel@localhost.localdomain> On Mon, 2005-12-12 at 13:44 -0500, Bill Nottingham wrote: > This runs into problems on ppc64 installs when the ioctl/etc > compatiblity layer is either a) missing b) broken. This is thankfully a relatively rare occurrence. -- dwmw2 From veillard at redhat.com Tue Dec 13 13:33:55 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 13 Dec 2005 08:33:55 -0500 Subject: multilib fun - devel packages In-Reply-To: <20051208043947.GA22451@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> Message-ID: <20051213133355.GN4116@redhat.com> On Wed, Dec 07, 2005 at 11:39:47PM -0500, Bill Nottingham wrote: > Attached are lists of a) the 117 packages with conflicts > b) the conflicts themselves. (This was tested on x86_64/i386; [...] > 1) Old-style -config scripts for setting CFLAGS and > LDFLAGS. Example: libst-config > > Can be a) ported to pkg-config b) genericized to have a > single script for all arches. xml2-config, xslt-config, xmlsec1-config are shown as conflicting, though there is no good reason for it. Independantly of the arch their content should basically be the same. The only difference is due to libdir=/usr/lib64 vs. libdir=/usr/lib as generated by configure. Fixing this is possible but I would rather not make this fedora specific. > libxml2-devel-2.6.22-1 > libxslt-devel-1.1.15-1 > xmlsec1-devel-1.2.9-3 > libxml-devel-1.8.17-13 Why on earth do I still hear about libxml (v1) in the context of Fedora ? Repeat after me, this package is dead, unmaintained, and nothing should rely on it anymore, shipping a -devel for it is just insane, I though the decision it was dropped for good had been taken ages ago, or did I missed something ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From ville.skytta at iki.fi Tue Dec 13 17:14:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 13 Dec 2005 19:14:36 +0200 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051213133355.GN4116@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> Message-ID: <1134494076.17887.22.camel@bobcat.mine.nu> On Tue, 2005-12-13 at 08:33 -0500, Daniel Veillard wrote: > On Wed, Dec 07, 2005 at 11:39:47PM -0500, Bill Nottingham wrote: > > libxml-devel-1.8.17-13 > > Why on earth do I still hear about libxml (v1) in the context of Fedora ? > Repeat after me, this package is dead, unmaintained, and nothing should > rely on it anymore, shipping a -devel for it is just insane, I though the > decision it was dropped for good had been taken ages ago, or did I missed > something ? At least the following still shipped rawhide packages have a build dependency on libxml-devel: gal, GConf, gnome-print, gnucash, gtkhtml, Guppi, libglade, oaf. From veillard at redhat.com Tue Dec 13 18:07:34 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 13 Dec 2005 13:07:34 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134494076.17887.22.camel@bobcat.mine.nu> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> Message-ID: <20051213180734.GP4116@redhat.com> On Tue, Dec 13, 2005 at 07:14:36PM +0200, Ville Skytt? wrote: > On Tue, 2005-12-13 at 08:33 -0500, Daniel Veillard wrote: > > On Wed, Dec 07, 2005 at 11:39:47PM -0500, Bill Nottingham wrote: > > > > libxml-devel-1.8.17-13 > > > > Why on earth do I still hear about libxml (v1) in the context of Fedora ? > > Repeat after me, this package is dead, unmaintained, and nothing should > > rely on it anymore, shipping a -devel for it is just insane, I though the > > decision it was dropped for good had been taken ages ago, or did I missed > > something ? > > At least the following still shipped rawhide packages have a build > dependency on libxml-devel: gal, GConf, gnome-print, gnucash, gtkhtml, > Guppi, libglade, oaf. that's the old GNOME-1 APIs, I really hope no core apps still use this Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From shahms at shahms.com Tue Dec 13 18:24:35 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 13 Dec 2005 10:24:35 -0800 Subject: libxml v1 dependencies In-Reply-To: <20051213180734.GP4116@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> Message-ID: <439F11E3.9040702@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: > On Tue, Dec 13, 2005 at 07:14:36PM +0200, Ville Skytt? wrote: > >>On Tue, 2005-12-13 at 08:33 -0500, Daniel Veillard wrote: >> >>>On Wed, Dec 07, 2005 at 11:39:47PM -0500, Bill Nottingham wrote: >> >>>>libxml-devel-1.8.17-13 >>> >>>Why on earth do I still hear about libxml (v1) in the context of Fedora ? >>>Repeat after me, this package is dead, unmaintained, and nothing should >>>rely on it anymore, shipping a -devel for it is just insane, I though the >>>decision it was dropped for good had been taken ages ago, or did I missed >>>something ? >> >>At least the following still shipped rawhide packages have a build >>dependency on libxml-devel: gal, GConf, gnome-print, gnucash, gtkhtml, >>Guppi, libglade, oaf. > > > that's the old GNOME-1 APIs, I really hope no core apps still use this > > Daniel I'm pretty sure the only core app that uses the GNOME 1 libraries is gnucash. Unfortunately, it's still the best personal finance program for GNOME and the GNOME 2 port is going glacially slow. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDnxHj/qs2NkWy11sRAre3AJ9nPCPEkIYh4vRzsDubAyq3GyGJswCeMrqI weq9T3fY6ubdmOZLS78Mva0= =bWA+ -----END PGP SIGNATURE----- From jspaleta at gmail.com Tue Dec 13 18:28:41 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Dec 2005 13:28:41 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051213180734.GP4116@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> Message-ID: <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> On 12/13/05, Daniel Veillard wrote: > that's the old GNOME-1 APIs, I really hope no core apps still use this gnucash -jef"is praying the gnucash people make at least a gtk2 based pre-release release before fc5 lands"spaleta From veillard at redhat.com Tue Dec 13 18:31:10 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 13 Dec 2005 13:31:10 -0500 Subject: libxml v1 dependencies In-Reply-To: <439F11E3.9040702@shahms.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <439F11E3.9040702@shahms.com> Message-ID: <20051213183110.GR4116@redhat.com> On Tue, Dec 13, 2005 at 10:24:35AM -0800, Shahms King wrote: > > that's the old GNOME-1 APIs, I really hope no core apps still use this > > I'm pretty sure the only core app that uses the GNOME 1 libraries is > gnucash. Unfortunately, it's still the best personal finance program > for GNOME and the GNOME 2 port is going glacially slow. If glacially slow means it's basically frozen, dumping it from FC and giving another actively maintained package a chance to grow its user base and hence its level of features and polish sounds like the right thing to do from a Fedora perspective (and from my slighly biased point of view). Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alexl at redhat.com Thu Dec 15 08:51:23 2005 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 15 Dec 2005 09:51:23 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> Message-ID: <1134636683.28842.39.camel@greebo> On Tue, 2005-12-13 at 13:28 -0500, Jeff Spaleta wrote: > On 12/13/05, Daniel Veillard wrote: > > that's the old GNOME-1 APIs, I really hope no core apps still use this > > gnucash Maybe we can push gnucash to extras, since this will allow us to also move the GNOME 1 stuff to extras. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted overambitious master criminal who dotes on his loving old ma. She's a plucky French-Canadian journalist on her way to prison for a murder she didn't commit. They fight crime! From bugs.michael at gmx.net Thu Dec 15 12:28:45 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 15 Dec 2005 13:28:45 +0100 Subject: Fwd: at-poke Message-ID: <20051215132845.47ef2214.bugs.michael@gmx.net> No reply yet. [...] Begin forwarded message: Date: Wed, 16 Nov 2005 18:02:06 +0100 From: Michael Schwendt To: Subject: at-poke Been playing with automated repoclosure mails and found that your "at-poke" package in Fedora Extras is not listed in CVS owners/owners.list yet. Hence no bugzilla component and no way to find out who this package belongs to. This mail was sent manually: --- at-poke.spec.~1.2.~ 2005-07-29 18:15:24.000000000 +0200 +++ at-poke.spec 2005-11-16 18:00:21.000000000 +0100 @@ -42,6 +42,7 @@ %defattr(-,root,root,-) %doc %{_bindir}/at-poke +%dir %{_datadir]/at-poke %{_datadir}/at-poke/at-poke.glade2 repoclosure report: source rpm: at-poke-0.2.2-2.src.rpm package: at-poke - 0.2.2-2.i386 from fedora-extras-development-i386 unresolved deps: libpixman.so.1 libcairo.so.1 source rpm: at-poke-0.2.2-2.src.rpm package: at-poke - 0.2.2-2.x86_64 from fedora-extras-development-x86_64 unresolved deps: libpixman.so.1()(64bit) libcairo.so.1()(64bit) source rpm: at-poke-0.2.2-2.src.rpm package: at-poke - 0.2.2-2.ppc from fedora-extras-development-ppc unresolved deps: libpixman.so.1 libcairo.so.1 -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.14-1.1637_FC4 loadavg: 1.02 1.13 1.21 -------------- next part -------------- A non-text attachment was scrubbed... Name: 00000000.mimetmp Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From jspaleta at gmail.com Thu Dec 15 13:20:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 08:20:19 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134636683.28842.39.camel@greebo> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> Message-ID: <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> On 12/15/05, Alexander Larsson wrote: > Maybe we can push gnucash to extras, since this will allow us to also > move the GNOME 1 stuff to extras. Would you replace that functional niche with another program or just drop that functionality from Core? -jef"I'll let you drop gnucash if we drop emacs* as well"spaleta From fedora at camperquake.de Thu Dec 15 13:22:34 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 15 Dec 2005 14:22:34 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> Message-ID: <20051215132234.GC12468@ryoko.camperquake.de> On Thu, Dec 15, 2005 at 08:20:19AM -0500, Jeff Spaleta wrote: > Would you replace that functional niche with another program or just > drop that functionality from Core? Drop it. There must be an obscure Java library somewhere that we do not ship in Core yet to take it's place. Just kidding. Mostly. From alan at redhat.com Thu Dec 15 13:33:00 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Dec 2005 08:33:00 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> Message-ID: <20051215133300.GA15979@devserv.devel.redhat.com> On Thu, Dec 15, 2005 at 08:20:19AM -0500, Jeff Spaleta wrote: > -jef"I'll let you drop gnucash if we drop emacs* as well"spaleta Excellent plan From bdpepple at ameritech.net Thu Dec 15 14:04:35 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 15 Dec 2005 09:04:35 -0500 Subject: libxml v1 dependencies In-Reply-To: <1134636683.28842.39.camel@greebo> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> Message-ID: <1134655475.17989.1.camel@shuttle.273piedmont.com> On Thu, 2005-12-15 at 09:51 +0100, Alexander Larsson wrote: > Maybe we can push gnucash to extras, since this will allow us to also > move the GNOME 1 stuff to extras. > +1. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Dec 15 14:18:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 09:18:15 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051215132234.GC12468@ryoko.camperquake.de> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> Message-ID: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> On 12/15/05, Ralf Ertzinger wrote: > On Thu, Dec 15, 2005 at 08:20:19AM -0500, Jeff Spaleta wrote: > > > Would you replace that functional niche with another program or just > > drop that functionality from Core? > > Drop it. There must be an obscure Java library somewhere that we do > not ship in Core yet to take it's place. > > > Just kidding. Mostly. I'm still interested in hearing about candidate applications that fill a role similar to gnucash that could be promoted to Core. Dropping the aging gnucash codebase and its dependancies certaintly has its merit. I'd be much happier with moving gnucash to Extras if there was something else in the personal finances/book-keeping area taking its place inside Core. If we only had a better idea of when the gtk2 port of gnucash was expected to release something..anything..even pre-releases. -jef From qspencer at ieee.org Thu Dec 15 15:01:25 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Thu, 15 Dec 2005 09:01:25 -0600 Subject: libxml v1 dependencies In-Reply-To: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> Message-ID: <43A18545.7020300@ieee.org> Jeff Spaleta wrote: >On 12/15/05, Ralf Ertzinger wrote: > > >>On Thu, Dec 15, 2005 at 08:20:19AM -0500, Jeff Spaleta wrote: >> >> >> >>>Would you replace that functional niche with another program or just >>>drop that functionality from Core? >>> >>> >>Drop it. There must be an obscure Java library somewhere that we do >>not ship in Core yet to take it's place. >> >> >>Just kidding. Mostly. >> >> > >I'm still interested in hearing about candidate applications that fill >a role similar to gnucash that could be promoted to Core. Dropping >the aging gnucash codebase and its dependancies certaintly has its >merit. I'd be much happier with moving gnucash to Extras if there was >something else in the personal finances/book-keeping area taking its >place inside Core. If we only had a better idea of when the gtk2 port >of gnucash was expected to release something..anything..even >pre-releases. > > Take a look at kmymoney2, which is currently in extras. -Quentin From orion at cora.nwra.com Thu Dec 15 16:21:01 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 15 Dec 2005 09:21:01 -0700 Subject: libxml v1 dependencies In-Reply-To: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> Message-ID: <43A197ED.9090907@cora.nwra.com> Jeff Spaleta wrote: > If we only had a better idea of when the gtk2 port > of gnucash was expected to release something..anything..even > pre-releases. FWIW - on Oct 20 as posted at www.gnucash.org, they thought gnome2 pre-release packages would be available in December. Looking at CVS you see things like: ChangeLog 1.1919 6 weeks hampton Collapse the gnome2 branch back into HEAD. but 6 weeks is fairly old. Has anyone built a CVS snapshot? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From nphilipp at redhat.com Thu Dec 15 16:28:45 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 15 Dec 2005 17:28:45 +0100 Subject: Fwd: at-poke In-Reply-To: <20051215132845.47ef2214.bugs.michael@gmx.net> References: <20051215132845.47ef2214.bugs.michael@gmx.net> Message-ID: <1134664125.22563.1.camel@wombat.tiptoe.de> On Thu, 2005-12-15 at 13:28 +0100, Michael Schwendt wrote: > +%dir %{_datadir]/at-poke s/]/}/ Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From gauret at free.fr Thu Dec 15 17:50:11 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 15 Dec 2005 18:50:11 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> Message-ID: <200512151850.11481.gauret@free.fr> > I'm still interested in hearing about candidate applications that fill > a role similar to gnucash that could be promoted to Core. There is "Grisbi" in extras. It's GTK2, actively maintained, but currently has less features than gnucash. It does have enough for personal finances, though. Worth a try. I use it, it's pretty good. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. From notting at redhat.com Fri Dec 16 00:53:05 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Dec 2005 19:53:05 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> Message-ID: <20051216005305.GB28216@devserv.devel.redhat.com> > I'm still interested in hearing about candidate applications that fill > a role similar to gnucash that could be promoted to Core. Dropping > the aging gnucash codebase and its dependancies certaintly has its > merit. I'd be much happier with moving gnucash to Extras if there was > something else in the personal finances/book-keeping area taking its > place inside Core. If we only had a better idea of when the gtk2 port > of gnucash was expected to release something..anything..even > pre-releases. The proverbial 'soon'. Realistically, this conversation appears to be 'let's drop it because it uses GNOME 1'. I'd argue that, especially since the work is in progress, that that's not the reason it should be dropped. If you're willing to drop all personal finance stuff from Core, that seems like a more consistent idea. Bill From sundaram at redhat.com Fri Dec 16 00:55:04 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 16 Dec 2005 06:25:04 +0530 Subject: libxml v1 dependencies In-Reply-To: <20051216005305.GB28216@devserv.devel.redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <20051216005305.GB28216@devserv.devel.redhat.com> Message-ID: <43A21068.4090107@redhat.com> Hi >. If >you're willing to drop all personal finance stuff from Core, that >seems like a more consistent idea. > > What other packages besides GNUCash caters exclusively to financial stuff in Core? regards Rahul From notting at redhat.com Fri Dec 16 01:01:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Dec 2005 20:01:00 -0500 Subject: libxml v1 dependencies In-Reply-To: <43A21068.4090107@redhat.com> References: <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <20051216005305.GB28216@devserv.devel.redhat.com> <43A21068.4090107@redhat.com> Message-ID: <20051216010100.GD28216@devserv.devel.redhat.com> Rahul Sundaram (sundaram at redhat.com) said: > Hi > > >. If > >you're willing to drop all personal finance stuff from Core, that > >seems like a more consistent idea. > > > > > What other packages besides GNUCash caters exclusively to financial > stuff in Core? None. Unless you're really stretching the usage case for bc. Bill From jkeating at j2solutions.net Fri Dec 16 01:02:16 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 17:02:16 -0800 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> Message-ID: <1134694936.3005.101.camel@yoda.loki.me> On Thu, 2005-12-15 at 09:18 -0500, Jeff Spaleta wrote: > I'm still interested in hearing about candidate applications that fill > a role similar to gnucash that could be promoted to Core. Dropping > the aging gnucash codebase and its dependancies certaintly has its > merit. I'd be much happier with moving gnucash to Extras if there was > something else in the personal finances/book-keeping area taking its > place inside Core. If we only had a better idea of when the gtk2 port > of gnucash was expected to release something..anything..even > pre-releases. Is there a reason why there has to be a financial software in core? I see pushing this to extras as a win win situation. Core wins by being smaller, and the deps just for gnucash can go as well, plus the community that uses this software can maintain it, and track the port in extras. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 16 01:24:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 20:24:55 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134694936.3005.101.camel@yoda.loki.me> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> Message-ID: <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> On 12/15/05, Jesse Keating wrote: > Is there a reason why there has to be a financial software in core? I > see pushing this to extras as a win win situation. Core wins by being > smaller, and the deps just for gnucash can go as well, plus the > community that uses this software can maintain it, and track the port in > extras. whats the target group for Core again? knowledge worker doesn't encompass finance tracking of any sort? I think thats probably a very very narrow definition of "knowledge" "worker" and the resulting combination of the two words. And if you want to apply that narrow a definition.. i have a very very long list of application level functionality I could suggest be shown the door as well to suppliment Seth's list of duplicate functionality. -jef"I'll let you remove finance software from the target if we also remove graphics software too.. I'm all for compromise"spaleta From jkeating at j2solutions.net Fri Dec 16 01:32:45 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 17:32:45 -0800 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> Message-ID: <1134696765.3005.120.camel@yoda.loki.me> On Thu, 2005-12-15 at 20:24 -0500, Jeff Spaleta wrote: > > whats the target group for Core again? knowledge worker doesn't > encompass finance tracking of any sort? I think thats probably a very > very narrow definition of "knowledge" "worker" and the resulting > combination of the two words. And if you want to apply that narrow a > definition.. i have a very very long list of application level > functionality I could suggest be shown the door as well to suppliment > Seth's list of duplicate functionality. > > -jef"I'll let you remove finance software from the target if we also > remove graphics software too.. I'm all for compromise"spaleta > I'm not suggesting we move it as a target issue, I'm suggesting we move it as a legacy software w/ no good replacement. I can't help that there is no good replacement at this time. It could be a temporary move to Extras until such time the gtk2 version is ready for use. Then we can explore adding it back in as a target reason. But by then, we may be to the stage of Fedora Linux being pushed as a disk set made up of core +extras. Then the 'target' isn't really the deciding factor as to if it is in Core or Extras. For the mean time, as a complexity issue, I see no problem with pushing it into extras. We really need to combat the Extras is Second Class stigma going forward. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From sundaram at redhat.com Fri Dec 16 01:54:15 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 16 Dec 2005 07:24:15 +0530 Subject: libxml v1 dependencies In-Reply-To: <1134696765.3005.120.camel@yoda.loki.me> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> Message-ID: <43A21E47.9070303@redhat.com> Hi > We really need to combat the >Extras is Second Class stigma going forward. > > > Stigma arises from the lack of Extras ISO images primarily. Even if Anaconda doesnt get installation time support for this repository, if the packages are available in ISO images and users can click and install them using system-config-packages the problem would be mostly resolved. regards Rahul From notting at redhat.com Fri Dec 16 01:56:58 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Dec 2005 20:56:58 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134696765.3005.120.camel@yoda.loki.me> References: <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> Message-ID: <20051216015658.GA20270@devserv.devel.redhat.com> Jesse Keating (jkeating at j2solutions.net) said: > I'm not suggesting we move it as a target issue, I'm suggesting we move > it as a legacy software w/ no good replacement. I can't help that there > is no good replacement at this time. It could be a temporary move to > Extras until such time the gtk2 version is ready for use. I don't buy this logic - if the functionality is that important, it should stay; if the functionality isn't, it should go. Bill From jspaleta at gmail.com Fri Dec 16 02:27:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 21:27:06 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134696765.3005.120.camel@yoda.loki.me> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> Message-ID: <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> On 12/15/05, Jesse Keating wrote: > I'm not suggesting we move it as a target issue, I'm suggesting we move > it as a legacy software w/ no good replacement. Are we sure there's isn't a good replacement? I think thats an open question. grisbi in Extras might be a reasonable replacement. > But by then, we may be to > the stage of Fedora Linux being pushed as a disk set made up of core > +extras. Here's me.. holding my breath. There are much larger issues with moving to a single cd Core than whether or not a single financial application is in Core. Until there is a clear signal that the definition of Core has changed direction I'm not going to be working under the single CD goal assumption. Someone is going to have the balls to move KDE and some of that java crap over to Extras if you have a chance in hell of going to one CD. I'll pay more attention to this argument as a serious statement of policy direction once I see KDE move over. And I think the self-hosting restriction on whatever that 1 -cd "Core" is going to be too tight a constraint and ultimately kill the goal of a single cd that is in anyway usable to a mere mortal by itself. I think the 1 cd goal will require a competely different restructuring, and the brickwall between Core and Extras buildsystem is going to be a big problem that is going to get in the way of that re-structuring. Quite frankly i think everyone will have dvd burner drives by the time Core is ready to make the infrstructure and policy jump to a single cd.... which would be satisifyingly ironic. > We really need to combat the > Extras is Second Class stigma going forward. You don't do that by pulling all functionality out of Core just to get down to a single cd. Core has to be designed with some usage pattern in mind, If Core usage case is going to be condensed to "web browsing" fine, lets state that and pick the applications based on that. and we live with the size of the distro that results. As it stands I'm working under the assumption of "knowledge worker" as a design goal for Core and I think that includes financial software more strongly than say a bittorrent client or the gimp or emacs* -jef"and by balls I mean moist warm Schwetty balls"spaleta From jkeating at j2solutions.net Fri Dec 16 02:47:04 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 18:47:04 -0800 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> Message-ID: <1134701224.3005.137.camel@yoda.loki.me> On Thu, 2005-12-15 at 21:27 -0500, Jeff Spaleta wrote: > Here's me.. holding my breath. There are much larger issues with > moving to a single cd Core than whether or not a single financial > application is in Core. > Until there is a clear signal that the definition of Core has changed > direction I'm not going to be working under the single CD goal > assumption. Someone is going to have the balls to move KDE and some > of that java crap over to Extras if you have a chance in hell of going > to one CD. I'll pay more attention to this argument as a serious > statement of policy direction once I see KDE move over. > > And I think the self-hosting restriction on whatever that 1 -cd "Core" > is going to be too tight a constraint and ultimately kill the goal of > a single cd that is in anyway usable to a mere mortal by itself. I > think the 1 cd goal will require a competely different restructuring, > and the brickwall between Core and Extras buildsystem is going to be a > big problem that is going to get in the way of that re-structuring. > Quite frankly i think everyone will have dvd burner drives by the time > Core is ready to make the infrstructure and policy jump to a single > cd.... which would be satisifyingly ironic. You've mistaken what I said. I'm not talking about a single CD core, I'm talking about targetted ISO sets created by bits of Core and bits of Extras, rolled into one ISO or one ISO set. Targetted for specific user sets. Fedora Office Linux, Fedora Gaming Linux, Fedora Server Linux, etc.. Yes these are vague targets, but less vague that Fedora itself. Once this happens, then it shouldn't / doesn't matter to the user if the package is in Core or Extras, as long as it is on the CD set they choose they can install it. > > We really need to combat the > > Extras is Second Class stigma going forward. > > You don't do that by pulling all functionality out of Core just to get > down to a single cd. Core has to be designed with some usage pattern > in mind, If Core usage case is going to be condensed to "web > browsing" fine, lets state that and pick the applications based on > that. and we live with the size of the distro that results. As it > stands I'm working under the assumption of "knowledge worker" as a > design goal for Core and I think that includes financial software more > strongly than say a bittorrent client or the gimp or emacs* I'm not trying to get to a single CD. However I would like to see the gtk1 reqs moved into Extras for now. Mostly because it is only supporting one app right now, gnucash. If there is a non-gtk1 replacement, thats great, lets swap it in and swap gnucash out, until gnucash is gtk2 ready, ready. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 16 03:01:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 22:01:15 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134701224.3005.137.camel@yoda.loki.me> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> Message-ID: <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> On 12/15/05, Jesse Keating wrote: > You've mistaken what I said. I'm not talking about a single CD core, > I'm talking about targetted ISO sets created by bits of Core and bits of > Extras, rolled into one ISO or one ISO set. Targetted for specific user > sets. Fedora Office Linux, Fedora Gaming Linux, Fedora Server Linux, > etc.. Yes these are vague targets, but less vague that Fedora itself. > Once this happens, then it shouldn't / doesn't matter to the user if the > package is in Core or Extras, as long as it is on the CD set they choose > they can install it. That concept has the same infrastructure problems with regard to mixed buildsystems and self hosting requirement. On top of that mixing Core+Extras into a single release target while Extras is still a rolling tree with no established freeze points or releases is going to be a huge pain in the ass. If rawhide didn't freeze for Core releases the Core release time would take up russian rulette as a lunchtime bonding activity. Something very drastic is going to have to be done with Extras's release model to give any potential community release engineers for alternative collections a fighting chance at getting anything out the door. Anyone volunteering to do that kind of release work with the way things stand is crazy and shouldn't be trusted with cvs access. -jef From jkeating at j2solutions.net Fri Dec 16 03:11:08 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 19:11:08 -0800 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> Message-ID: <1134702668.3005.141.camel@yoda.loki.me> On Thu, 2005-12-15 at 22:01 -0500, Jeff Spaleta wrote: > That concept has the same infrastructure problems with regard to mixed > buildsystems and self hosting requirement. On top of that mixing > Core+Extras into a single release target while Extras is still a > rolling tree with no established freeze points or releases is going to > be a huge pain in the ass. If rawhide didn't freeze for Core releases > the Core release time would take up russian rulette as a lunchtime > bonding activity. Something very drastic is going to have to be done > with Extras's release model to give any potential community release > engineers for alternative collections a fighting chance at getting > anything out the door. Anyone volunteering to do that kind of release > work with the way things stand is crazy and shouldn't be trusted with > cvs access. Yes, I know there is a lot of work to do to make this happen. Doesn't mean that the work shouldn't be done. I honestly don't think we can continue in the direction we are now, constantly growing Core, constantly fighting what goes in/out, etc.. Things have to get better. Certain restrictions on RHEL have been removed wrt including software that is maintained in Extras, so now there is nothing saying that whats in RHEL MUST be in Core. This changes the way we think about Core quite a bit, and opens the door for more creative ways of dealing with Core vs Extras. Things have to change. The question is do we do it now or later? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 16 03:24:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 22:24:20 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134702668.3005.141.camel@yoda.loki.me> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> <1134702668.3005.141.camel@yoda.loki.me> Message-ID: <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> On 12/15/05, Jesse Keating wrote: > Things have to change. The question is do we do it now or later? Sure do "it" now... the problem is "it" isnt pulling crap out of Core. "it" is changing the Extras policy and development model to make maintaining Core+Extras release targets attractive and manageable for volunteers to do. Pulling functionality from Core now, before the inftrastructure and policy that allows Core+Extras release targets to be made is putting the cart before the horse. If you start pulling functionality out of Core now, to encourage people to maintain Core+Extras release targets all you are going to do is frustrate your potential volunteer release maintainers because they will be fighting against the infrastructure. You want Core+Extras release targets to be a successful experiment then I suggest you lock yourself in a room with the other Core release team members for a day and write down exactly what is needed to make sure a release target is managable as paid professionals, then ask what support would be needed if they were volunteering spare time to maintain a release target. At a minimum "freeze" points in the tree(s) from which a release is built from has to be there. Extras NEEDS "freeze" points or you are asking volunteers to do the impossible. Define what Core is suppose to be Define what Extras is suppose to be Define what the Core+Extras relationshiop is suppose to be Build policies and infrastructure to support that relationship. THEN start moving things around in the framework of that relatonship. -jef From jkeating at j2solutions.net Fri Dec 16 03:34:43 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 19:34:43 -0800 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> <1134702668.3005.141.camel@yoda.loki.me> <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> Message-ID: <1134704083.3005.146.camel@yoda.loki.me> On Thu, 2005-12-15 at 22:24 -0500, Jeff Spaleta wrote: > Define what Core is suppose to be > Define what Extras is suppose to be > Define what the Core+Extras relationshiop is suppose to be > Build policies and infrastructure to support that relationship. > THEN start moving things around in the framework of that relatonship. Unfortunately we can't take our ball and go home until we figure things out. Stuff still has to happen, we still need to get an FC5 out the door. What I'm merely saying is that changes we make now for whatever reason may become obsolete or indifferent very soon. A lot of your list is a good one, and it should be done. Maybe not in the same order, but maybe. The time between FC5 and FC6 is a great time to investigate this. Maybe we'll make a few steps toward our goal, and maybe FC6 to FC7 will be the major change period. I don't know, the 8ball is hazy. I'm just further feeding the seeds of thought planted by Bill. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From blizzard at redhat.com Fri Dec 16 04:55:21 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 15 Dec 2005 23:55:21 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> Message-ID: <1134708921.2661.14.camel@mobile2> On Thu, 2005-12-15 at 20:24 -0500, Jeff Spaleta wrote: > On 12/15/05, Jesse Keating wrote: > > Is there a reason why there has to be a financial software in core? I > > see pushing this to extras as a win win situation. Core wins by being > > smaller, and the deps just for gnucash can go as well, plus the > > community that uses this software can maintain it, and track the port in > > extras. > > whats the target group for Core again? knowledge worker doesn't > encompass finance tracking of any sort? I think thats probably a very "Technology Enthusiasts." People like you and me. Community members. That's why we still include 15 web browsers in core and 50 editors. (Too much hyperbole?) This is an interesting question, actually. If we want to get to a one-cd install we're going to have to make some hard choices. Not that I would mind making those choices, but we would have to shrink down the scope of what we deliver right now. There's also the question of if we're server focused or desktop focused. Right now it's some strange combination of both. But for a one-cd install we're going to have to make a choice between the two. --Chris From blizzard at redhat.com Fri Dec 16 04:57:06 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 15 Dec 2005 23:57:06 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051216015658.GA20270@devserv.devel.redhat.com> References: <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <20051216015658.GA20270@devserv.devel.redhat.com> Message-ID: <1134709026.2661.16.camel@mobile2> I think your setting yourself up for only one possible answer here. I wouldn't say it's about the functionality. It's a question of priorities. In this case, is keeping the functionality worth the cost of carrying most of the Gtk 1.2 + Old Ass Gnome stack? I think that's how we need to frame the question. --Chris On Thu, 2005-12-15 at 20:56 -0500, Bill Nottingham wrote: > Jesse Keating (jkeating at j2solutions.net) said: > > I'm not suggesting we move it as a target issue, I'm suggesting we move > > it as a legacy software w/ no good replacement. I can't help that there > > is no good replacement at this time. It could be a temporary move to > > Extras until such time the gtk2 version is ready for use. > > I don't buy this logic - if the functionality is that important, it should > stay; if the functionality isn't, it should go. > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From blizzard at redhat.com Fri Dec 16 05:00:44 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 16 Dec 2005 00:00:44 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> Message-ID: <1134709244.2661.20.camel@mobile2> On Thu, 2005-12-15 at 21:27 -0500, Jeff Spaleta wrote: > Until there is a clear signal that the definition of Core has changed > direction I'm not going to be working under the single CD goal > assumption. Someone is going to have the balls to move KDE and some > of that java crap over to Extras if you have a chance in hell of going > to one CD. I'll pay more attention to this argument as a serious > statement of policy direction once I see KDE move over. I'll fall on my sword and say that I think that moving KDE out to extras is a good idea - but probably not for the reason you expect. Since it's clear that Red Hat is not going to be supporting KDE (we're just not going to put up the resources) let's stop holding it hostage and invite the KDE community who cares about it to develop and support it as part of Extras. We can give them a lot of freedom to make it look nice and work the way that they think it should. (Kedora?) --Chris From skvidal at linux.duke.edu Fri Dec 16 05:08:44 2005 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 16 Dec 2005 00:08:44 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134709244.2661.20.camel@mobile2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> Message-ID: <1134709725.29750.0.camel@cutter> > I'll fall on my sword and say that I think that moving KDE out to extras > is a good idea - but probably not for the reason you expect. Since it's > clear that Red Hat is not going to be supporting KDE (we're just not > going to put up the resources) let's stop holding it hostage and invite > the KDE community who cares about it to develop and support it as part > of Extras. We can give them a lot of freedom to make it look nice and > work the way that they think it should. (Kedora?) > As an example of this working - XFCE looks damn nice in extras, imo. -sv From caillon at redhat.com Fri Dec 16 06:18:02 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 16 Dec 2005 01:18:02 -0500 Subject: mozilla-nss is dead, long live nss Message-ID: <43A25C1A.3030001@redhat.com> Just a note that mozilla-nss is no longer in the tree. Packages should depend on nss instead, and nss-devel for building. I've rebuilt evolution and xmlsec1 already to support this. Note that there is now a version jump. NSS is currently at v3.11 (and NSPR is at 4.6), so packages which checked for mozilla-nss >= 1.x should also update their version checks (nss 1.x would not be usable). Bug reports go in bugzilla. From rc040203 at freenet.de Fri Dec 16 06:47:32 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Dec 2005 07:47:32 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> <1134702668.3005.141.camel@yoda.loki.me> <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> Message-ID: <1134715652.30243.281.camel@mccallum.corsepiu.local> On Thu, 2005-12-15 at 22:24 -0500, Jeff Spaleta wrote: > On 12/15/05, Jesse Keating wrote: > > Things have to change. The question is do we do it now or later? > Extras NEEDS "freeze" points Why? What, in your opinion, qualifies "FC+updates" as "non-rolling" and FE as "rolling"? Except that some FE packages occasionally break on shared libraries, I don't see a basic difference between both of them. > or you are asking volunteers > to do the impossible. Being one of these volunteers, I have to tell you that for non-RH'ers, the actual current problems in maintaining FE packages isn't Extras' packages "rolling" or "Core vs. Extras", but are completely different (In priority-sorted order): 1. Rawhide volatility/instability/rolling 2. FE's buildsystem stability/reliability/usability 3. FE's package submission/maintenance infrastructure 4. Cooperation/coordination between RH and FE. 5. Absence of leadership/guidance. ... > Define what Core is suppose to be > Define what Extras is suppose to be > Define what the Core+Extras relationshiop is suppose to be > Build policies and infrastructure to support that relationship. > THEN start moving things around in the framework of that relatonship. Well, whether you like it or not, from a volunteer's point of view, this topic actually is quite trivial: "Core is the God-sent foundation", you build your house (your contributed packages to Extra) on top. Anything concerning Core is out of your control, it is God-sent. Similar considerations apply to "ordinary users": Once you have accepted the fact FE exists (Which apparently is a problem for some), it doesn't really matter if a package is in Core or Extras. The only thing that matters is "the package you are looking for is present and works sufficiently well". Also, the "how many CDs problems" isn't an actual problem to many users. All you typically need is a possibility to boot a minimial installation/upgrade (Which normally means one CD or network install bootloader), anything else is being pulled from the net afterwards. This applies to Core as well as to Extras (without having looked into the details, I would estimate at least 50% of all packages from the original FC4 release meanwhile have been updated). Ralf From alexl at redhat.com Fri Dec 16 08:38:55 2005 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Dec 2005 09:38:55 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134709026.2661.16.camel@mobile2> References: <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <20051216015658.GA20270@devserv.devel.redhat.com> <1134709026.2661.16.camel@mobile2> Message-ID: <1134722336.28842.168.camel@greebo> On Thu, 2005-12-15 at 23:57 -0500, Christopher Blizzard wrote: > I think your setting yourself up for only one possible answer here. I > wouldn't say it's about the functionality. It's a question of > priorities. In this case, is keeping the functionality worth the cost > of carrying most of the Gtk 1.2 + Old Ass Gnome stack? I think that's > how we need to frame the question. Of course, we do basically nothing with Gtk 1.2 and gnome 1.x, so the cost is basically just the size of the packages on the CDs. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a notorious playboy librarian She's a cynical junkie cab driver living on borrowed time. They fight crime! From veillard at redhat.com Fri Dec 16 08:47:27 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 16 Dec 2005 03:47:27 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134722336.28842.168.camel@greebo> References: <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <20051216015658.GA20270@devserv.devel.redhat.com> <1134709026.2661.16.camel@mobile2> <1134722336.28842.168.camel@greebo> Message-ID: <20051216084727.GX23448@redhat.com> On Fri, Dec 16, 2005 at 09:38:55AM +0100, Alexander Larsson wrote: > On Thu, 2005-12-15 at 23:57 -0500, Christopher Blizzard wrote: > > I think your setting yourself up for only one possible answer here. I > > wouldn't say it's about the functionality. It's a question of > > priorities. In this case, is keeping the functionality worth the cost > > of carrying most of the Gtk 1.2 + Old Ass Gnome stack? I think that's > > how we need to frame the question. > > Of course, we do basically nothing with Gtk 1.2 and gnome 1.x, so the > cost is basically just the size of the packages on the CDs. Well I would feel way better if we weren't shipping devel packages for what I know as broken, deprecated for nearly 4 years code base. Ship the library if you really want it, but please drop the -devel from the CDs, I really really don't want to take the risk of people accidentally using it. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pmatilai at laiskiainen.org Fri Dec 16 10:48:02 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 16 Dec 2005 02:48:02 -0800 (PST) Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134709244.2661.20.camel@mobile2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> Message-ID: On Fri, 16 Dec 2005, Christopher Blizzard wrote: > On Thu, 2005-12-15 at 21:27 -0500, Jeff Spaleta wrote: >> Until there is a clear signal that the definition of Core has changed >> direction I'm not going to be working under the single CD goal >> assumption. Someone is going to have the balls to move KDE and some >> of that java crap over to Extras if you have a chance in hell of going >> to one CD. I'll pay more attention to this argument as a serious >> statement of policy direction once I see KDE move over. > > I'll fall on my sword and say that I think that moving KDE out to extras > is a good idea - but probably not for the reason you expect. Since it's > clear that Red Hat is not going to be supporting KDE (we're just not > going to put up the resources) let's stop holding it hostage and invite > the KDE community who cares about it to develop and support it as part > of Extras. We can give them a lot of freedom to make it look nice and > work the way that they think it should. (Kedora?) +100 Letting KDE enthusiastics package it the way they think it should be done in Extras instead of having them whining about "RH shipping broken KDE" is probably going to gain more friends than you lose by dropping it out of Core. - Panu - From fedora at leemhuis.info Fri Dec 16 11:21:14 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 16 Dec 2005 12:21:14 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> Message-ID: <1134732074.2805.20.camel@thl.ct.heise.de> Am Freitag, den 16.12.2005, 02:48 -0800 schrieb Panu Matilainen: > On Fri, 16 Dec 2005, Christopher Blizzard wrote: > > On Thu, 2005-12-15 at 21:27 -0500, Jeff Spaleta wrote: > >> Until there is a clear signal that the definition of Core has changed > >> direction I'm not going to be working under the single CD goal > >> assumption. Someone is going to have the balls to move KDE and some > >> of that java crap over to Extras if you have a chance in hell of going > >> to one CD. I'll pay more attention to this argument as a serious > >> statement of policy direction once I see KDE move over. > > > > I'll fall on my sword and say that I think that moving KDE out to extras > > is a good idea - but probably not for the reason you expect. Since it's > > clear that Red Hat is not going to be supporting KDE (we're just not > > going to put up the resources) let's stop holding it hostage and invite > > the KDE community who cares about it to develop and support it as part > > of Extras. We can give them a lot of freedom to make it look nice and > > work the way that they think it should. (Kedora?) I liked the "Fedora KDE Desktop" that someone suggest on this list some days ago a lot more ;-) > +100 > > Letting KDE enthusiastics package it the way they think it should be done > in Extras instead of having them whining about "RH shipping broken KDE" > is probably going to gain more friends Up to here I fully agree. But I disagree with this... > than you lose by dropping it out of > Core. ...if we do it *now*. There will be a lot of bad press about Fedora then. I'd like to avoid that. And avoiding that is quite easy afaics if we just wait another 6 or 12 month until anaconda can access fedora-extras via internet or from extras-iso-files that were burned on CD. Installing KDE should then be as smooth as it is now and nobody can complain that KDE is in "Fedora Extras -- the second class citizen" (they still will, but that's life). CU thl From blizzard at redhat.com Fri Dec 16 14:49:54 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 16 Dec 2005 09:49:54 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134715652.30243.281.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> <1134702668.3005.141.camel@yoda.loki.me> <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> <1134715652.30243.281.camel@mccallum.corsepiu.local> Message-ID: <1134744594.7524.3.camel@mobile2> On Fri, 2005-12-16 at 07:47 +0100, Ralf Corsepius wrote: > Also, the "how many CDs problems" isn't an actual problem to many users. > All you typically need is a possibility to boot a minimial > installation/upgrade (Which normally means one CD or network install > bootloader), anything else is being pulled from the net afterwards. > This applies to Core as well as to Extras (without having looked into > the details, I would estimate at least 50% of all packages from the > original FC4 release meanwhile have been updated). The one-CD install (note that I say install here, not "core must fit on one CD") is more of a distribution and marketing problem - that is, we want to be able to get people started on a single CD and show them that it works. --Chris From blizzard at redhat.com Fri Dec 16 14:59:02 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 16 Dec 2005 09:59:02 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> Message-ID: <1134745142.7524.7.camel@mobile2> On Fri, 2005-12-16 at 02:48 -0800, Panu Matilainen wrote: > On Fri, 16 Dec 2005, Christopher Blizzard wrote: > > +100 > > Letting KDE enthusiastics package it the way they think it should be done > in Extras instead of having them whining about "RH shipping broken KDE" > is probably going to gain more friends than you lose by dropping it out of > Core. It's just something that needs to be handled pretty carefully. Don't want to see the story "Red Hat drops support for KDE" (we haven't really supported it for a long time anyway) but more "enables community around KDE" because that's the real goal. Also don't want to see the confusion of Fedora/Red Hat here. It's likely that we will include KDE for a long time in our Red Hat releases even though it comes from Extras. --Chris From blizzard at redhat.com Fri Dec 16 15:00:44 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 16 Dec 2005 10:00:44 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134732074.2805.20.camel@thl.ct.heise.de> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> <1134732074.2805.20.camel@thl.ct.heise.de> Message-ID: <1134745244.7524.10.camel@mobile2> On Fri, 2005-12-16 at 12:21 +0100, Thorsten Leemhuis wrote: > > than you lose by dropping it out of > > Core. > > ...if we do it *now*. There will be a lot of bad press about Fedora > then. I'd like to avoid that. And avoiding that is quite easy afaics if > we just wait another 6 or 12 month until anaconda can access > fedora-extras via internet or from extras-iso-files that were burned on > CD. > > Installing KDE should then be as smooth as it is now and nobody can > complain that KDE is in "Fedora Extras -- the second class > citizen" (they still will, but that's life). \ I don't think it's an FC5 target. Waaay too late for that. (Strange, I've never through of Extras as second class.) --Chris From laroche at redhat.com Fri Dec 16 15:17:30 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 16 Dec 2005 16:17:30 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134744594.7524.3.camel@mobile2> References: <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> <1134702668.3005.141.camel@yoda.loki.me> <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> <1134715652.30243.281.camel@mccallum.corsepiu.local> <1134744594.7524.3.camel@mobile2> Message-ID: <20051216151730.GA17304@dudweiler.stuttgart.redhat.com> > The one-CD install (note that I say install here, not "core must fit on > one CD") is more of a distribution and marketing problem - that is, we > want to be able to get people started on a single CD and show them that > it works. Plus also a working LiveCD where people can quickly look around and try things out. But this item is also unclear if it will be ready for FC5. regards, Florian La Roche From dennis at ausil.us Fri Dec 16 15:34:34 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 16 Dec 2005 09:34:34 -0600 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134745142.7524.7.camel@mobile2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134745142.7524.7.camel@mobile2> Message-ID: <200512160934.35139.dennis@ausil.us> On Friday 16 December 2005 08:59, Christopher Blizzard wrote: > On Fri, 2005-12-16 at 02:48 -0800, Panu Matilainen wrote: > > On Fri, 16 Dec 2005, Christopher Blizzard wrote: > > > > +100 > > > > Letting KDE enthusiastics package it the way they think it should be done > > in Extras instead of having them whining about "RH shipping broken KDE" > > is probably going to gain more friends than you lose by dropping it out > > of Core. > > It's just something that needs to be handled pretty carefully. Don't > want to see the story "Red Hat drops support for KDE" (we haven't really > supported it for a long time anyway) but more "enables community around > KDE" because that's the real goal. Also don't want to see the confusion > of Fedora/Red Hat here. It's likely that we will include KDE for a long > time in our Red Hat releases even though it comes from Extras. As a long time KDE/Red Hat/Fedora user i would love to have the opportunity to look after and improve upon some of the kde stuff i use day in day out. im pretty sure that Rex Dieter would also like to help. Along these line i really think core should be core things needed on every machine and the build chain. i.e. kernel, iptables, glibc, gcc, ntp, binutils, etc everything else should then be moved to extras where it can benefit from greater community support. I know that to do this would require alot of work and effort to setup and co-ordinate, but i think the community as a whole will benefit greatly from this. It would probably invole having to set new guidelines for extras package updates during a release lifecycle. Dennis From fedora at leemhuis.info Fri Dec 16 16:44:21 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 16 Dec 2005 17:44:21 +0100 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134745244.7524.10.camel@mobile2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> <1134732074.2805.20.camel@thl.ct.heise.de> <1134745244.7524.10.camel@mobile2> Message-ID: <1134751461.3322.9.camel@localhost.localdomain> Am Freitag, den 16.12.2005, 10:00 -0500 schrieb Christopher Blizzard: > On Fri, 2005-12-16 at 12:21 +0100, Thorsten Leemhuis wrote: > > > than you lose by dropping it out of > > > Core. > > > > ...if we do it *now*. There will be a lot of bad press about Fedora > > then. I'd like to avoid that. And avoiding that is quite easy afaics if > > we just wait another 6 or 12 month until anaconda can access > > fedora-extras via internet or from extras-iso-files that were burned on > > CD. > > > > Installing KDE should then be as smooth as it is now and nobody can > > complain that KDE is in "Fedora Extras -- the second class > > citizen" (they still will, but that's life). \ > > I don't think it's an FC5 target. Waaay too late for that. Sorry, maybe I was not clear enough on that (but where is I say FC5?). I said "avoid that ... wait another 6 or 12 month" -- so I meant FC6 or FC7 ;-) > (Strange, I've never through of Extras as second class.) No, it is not. But Google says: Results 1 - 23 of about 80 for "Fedora Extras" "second class citizen". -- Thorsten Leemhuis From jamatos at fc.up.pt Fri Dec 16 16:58:04 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 16 Dec 2005 16:58:04 +0000 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134751461.3322.9.camel@localhost.localdomain> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134745244.7524.10.camel@mobile2> <1134751461.3322.9.camel@localhost.localdomain> Message-ID: <200512161658.04673.jamatos@fc.up.pt> On Friday 16 December 2005 16:44, Thorsten Leemhuis wrote: > Am Freitag, den 16.12.2005, 10:00 -0500 schrieb Christopher Blizzard: > > On Fri, 2005-12-16 at 12:21 +0100, Thorsten Leemhuis wrote: > > > > than you lose by dropping it out of > > > > Core. > > > > > > ...if we do it *now*. There will be a lot of bad press about Fedora > > > then. I'd like to avoid that. And avoiding that is quite easy afaics if > > > we just wait another 6 or 12 month until anaconda can access > > > fedora-extras via internet or from extras-iso-files that were burned on > > > CD. > > > > > > Installing KDE should then be as smooth as it is now and nobody can > > > complain that KDE is in "Fedora Extras -- the second class > > > citizen" (they still will, but that's life). \ > > > > I don't think it's an FC5 target. Waaay too late for that. > > Sorry, maybe I was not clear enough on that (but where is I say FC5?). I > said "avoid that ... wait another 6 or 12 month" -- so I meant FC6 or > FC7 ;-) > > > (Strange, I've never through of Extras as second class.) > > No, it is not. But Google says: > Results 1 - 23 of about 80 for "Fedora Extras" "second class citizen". I get 78, OK, two less to worry about. ;-) (I know, I know about differences in google searches) The funny part is that some of those intend to rebut that, so they should probably use other words. ;-) -- Jos? Ab?lio From jspaleta at gmail.com Fri Dec 16 21:52:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Dec 2005 16:52:24 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134715652.30243.281.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134701224.3005.137.camel@yoda.loki.me> <604aa7910512151901w58cf5a74h9fd07837bfe14f4a@mail.gmail.com> <1134702668.3005.141.camel@yoda.loki.me> <604aa7910512151924r5875580ax7790e240dd0fd9a6@mail.gmail.com> <1134715652.30243.281.camel@mccallum.corsepiu.local> Message-ID: <604aa7910512161352x3bcdb3acqda4b538d931327bf@mail.gmail.com> On 12/16/05, Ralf Corsepius wrote: > > Extras NEEDS "freeze" points > Why? > > What, in your opinion, qualifies "FC+updates" as "non-rolling" and > FE as "rolling"? Except that some FE packages occasionally break on > shared libraries, I don't see a basic difference between both of them. The basic difference is that rawhide freezes for short periods of time which allows the release team to spin up release candidate trees and fix whatever needs to be fixed before the final release goes out..without the additional burden of having the rawhide tree shift around while they are doing this. If Fedora project leadership is going to encourage the concept of altnerative release targets.. items that ship on installable media... that span Core+Extras.... Extras is going to need to have similar freeze points so the release maintainers for these alternative collections will have some time to do exactly what the Core release people do before the final release..spin up release candidate trees and have specific packaging issues addressed. The volatility of rawhide and extras-development are exactly why the freeze points are needed before a final release of target. -jef From jspaleta at gmail.com Fri Dec 16 22:55:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Dec 2005 17:55:24 -0500 Subject: mozilla-nss is dead, long live nss In-Reply-To: <43A25C1A.3030001@redhat.com> References: <43A25C1A.3030001@redhat.com> Message-ID: <604aa7910512161455x2e82c3b8vd959f6d5b39f8a1@mail.gmail.com> On 12/16/05, Christopher Aillon wrote: > Bug reports go in bugzilla. Just an FYI, repoquery --repoid=extras-development --whatrequires mozilla-nss repoquery --repoid=extras-development --whatrequires mozilla-nss-devel returns nothing as of today repoquery --repoid=development --whatrequires mozilla-nss returns mozilla-37:1.7.12-2.i386 mozilla-nss-devel-37:1.7.12-2.i386 xmlsec1-nss-0:1.2.9-3.i386 openoffice.org-core-1:2.0.1-145.2.2.i386 I don't know if I can use repoquery to check the buildrequires on srpms -jef From caillon at redhat.com Sat Dec 17 02:40:45 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 16 Dec 2005 21:40:45 -0500 Subject: mozilla-nss is dead, long live nss In-Reply-To: <604aa7910512161455x2e82c3b8vd959f6d5b39f8a1@mail.gmail.com> References: <43A25C1A.3030001@redhat.com> <604aa7910512161455x2e82c3b8vd959f6d5b39f8a1@mail.gmail.com> Message-ID: <43A37AAD.6060701@redhat.com> On 12/16/2005 05:55 PM, Jeff Spaleta wrote: > Just an FYI, > repoquery --repoid=extras-development --whatrequires mozilla-nss > repoquery --repoid=extras-development --whatrequires mozilla-nss-devel > returns nothing as of today > > repoquery --repoid=development --whatrequires mozilla-nss > returns > mozilla-37:1.7.12-2.i386 > mozilla-nss-devel-37:1.7.12-2.i386 > xmlsec1-nss-0:1.2.9-3.i386 > openoffice.org-core-1:2.0.1-145.2.2.i386 > > I don't know if I can use repoquery to check the buildrequires on srpms You're using an out-of-date mirror. I fixed all except oo.o last night and they did make it into rawhide judging by the rawhide update mail (and by my own execution of repoquery on the development tree) From stickster at gmail.com Sat Dec 17 04:12:07 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Dec 2005 23:12:07 -0500 Subject: libxml v1 dependencies In-Reply-To: <20051216010100.GD28216@devserv.devel.redhat.com> References: <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <20051216005305.GB28216@devserv.devel.redhat.com> <43A21068.4090107@redhat.com> <20051216010100.GD28216@devserv.devel.redhat.com> Message-ID: <1134792727.4013.10.camel@localhost.localdomain> On Thu, 2005-12-15 at 20:01 -0500, Bill Nottingham wrote: > Rahul Sundaram (sundaram at redhat.com) said: > > What other packages besides GNUCash caters exclusively to financial > > stuff in Core? > > None. Unless you're really stretching the usage case for bc. Did someone say "bc"? 1. read YEARS RATE CAP && \ echo "scale=10; $CAP*(1+$RATE/12)^(12*$YEARS)" | bc 2. ... 3. Profit! Sorry. :-) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Sat Dec 17 07:12:24 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 17 Dec 2005 02:12:24 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051216084727.GX23448@redhat.com> References: <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <20051216015658.GA20270@devserv.devel.redhat.com> <1134709026.2661.16.camel@mobile2> <1134722336.28842.168.camel@greebo> <20051216084727.GX23448@redhat.com> Message-ID: <20051217071224.GE24500@devserv.devel.redhat.com> Daniel Veillard (veillard at redhat.com) said: > Well I would feel way better if we weren't shipping devel packages for > what I know as broken, deprecated for nearly 4 years code base. Ship the > library if you really want it, but please drop the -devel from the CDs, > I really really don't want to take the risk of people accidentally using > it. I know how much you care about this one issue, but I think changing the mechanics of how Core is distributed for one library is going overboard. (there's no such thing as not-on-CD core packages.) Realistically, there's plenty of stuff we ship that sane third-party developers shouldn't be building against. We should have some sort of defined developer platform (i.e., this is what you *should* use.) That would help more than playing with what is packaged where. Bill From notting at redhat.com Sat Dec 17 07:16:36 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 17 Dec 2005 02:16:36 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134751461.3322.9.camel@localhost.localdomain> References: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> <1134732074.2805.20.camel@thl.ct.heise.de> <1134745244.7524.10.camel@mobile2> <1134751461.3322.9.camel@localhost.localdomain> Message-ID: <20051217071636.GF24500@devserv.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > > (Strange, I've never through of Extras as second class.) > > No, it is not. But Google says: > Results 1 - 23 of about 80 for "Fedora Extras" "second class citizen". Heh. Results 1 - 10 of about 115 for "bill nottingham" devil. (0.38 seconds) Uh-oh, does that mean I'm more of a problem than Extras as a second class citizen? (Yes, I know. But I'm not sure 80 google hits amounts to much.) Bill From ville.skytta at iki.fi Sat Dec 17 10:07:12 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 17 Dec 2005 12:07:12 +0200 Subject: mozilla-nss is dead, long live nss In-Reply-To: <604aa7910512161455x2e82c3b8vd959f6d5b39f8a1@mail.gmail.com> References: <43A25C1A.3030001@redhat.com> <604aa7910512161455x2e82c3b8vd959f6d5b39f8a1@mail.gmail.com> Message-ID: <1134814032.13582.83.camel@bobcat.mine.nu> On Fri, 2005-12-16 at 17:55 -0500, Jeff Spaleta wrote: > I don't know if I can use repoquery to check the buildrequires on srpms https://www.redhat.com/archives/fedora-extras-list/2005-December/msg00287.html From jspaleta at gmail.com Sat Dec 17 15:32:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 17 Dec 2005 10:32:03 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051217071224.GE24500@devserv.devel.redhat.com> References: <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <20051216015658.GA20270@devserv.devel.redhat.com> <1134709026.2661.16.camel@mobile2> <1134722336.28842.168.camel@greebo> <20051216084727.GX23448@redhat.com> <20051217071224.GE24500@devserv.devel.redhat.com> Message-ID: <604aa7910512170732i1d0a270bu3fa2b28a995d06ac@mail.gmail.com> On 12/17/05, Bill Nottingham wrote: > Realistically, there's plenty of stuff we ship that sane third-party > developers shouldn't be building against. We should have some sort > of defined developer platform (i.e., this is what you *should* use.) > That would help more than playing with what is packaged where. +1 for defined developer platform. Though I have no idea how you go about defining that. -jef From bnocera at redhat.com Mon Dec 19 11:34:07 2005 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 19 Dec 2005 11:34:07 +0000 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <20051217071636.GF24500@devserv.devel.redhat.com> References: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <604aa7910512151827v66d012c8n38abd38bb55b2fff@mail.gmail.com> <1134709244.2661.20.camel@mobile2> <1134732074.2805.20.camel@thl.ct.heise.de> <1134745244.7524.10.camel@mobile2> <1134751461.3322.9.camel@localhost.localdomain> <20051217071636.GF24500@devserv.devel.redhat.com> Message-ID: <1134992047.12592.3.camel@bnocera.surrey.redhat.com> On Sat, 2005-12-17 at 02:16 -0500, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: > > > (Strange, I've never through of Extras as second class.) > > > > No, it is not. But Google says: > > Results 1 - 23 of about 80 for "Fedora Extras" "second class citizen". > > Heh. > > Results 1 - 10 of about 115 for "bill nottingham" devil. (0.38 seconds) > > Uh-oh, does that mean I'm more of a problem than Extras as a second > class citizen? > > (Yes, I know. But I'm not sure 80 google hits amounts to much.) What should I say: Results 1 - 10 of about 201 for "bastien nocera" devil. (0.61 seconds) That seems to be because I contributed to sound-juicer whose maintainer also makes Devil's Pie though :) -- Bastien Nocera From jkeating at redhat.com Mon Dec 19 17:14:42 2005 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Dec 2005 09:14:42 -0800 Subject: Fedora Core 5 Test 2 slipping until January 16 Message-ID: <1135012482.28062.26.camel@yoda.loki.me> Dashing through the builds In a one cup holder desk O're the build errors we go Swearing all the way! Phones on dev's desks ring Making Managers frown What fun it is to cuss and swear re-baseing on GCC! Oh, software sucks, Software sucks, Software really sucks! Oh what fun it is to slip our release for a month! Software sucks, Software sucks, Software really sucks! Oh, what fun it is to slip our release for a month! We rebuilt java* once It wasn't very nice we rebuilt everything else to our user's delight! Broken deps still there Making testing fun We really thing we need to test for another month! Oh, software sucks, Software sucks, Software really sucks! Oh what fun it is to slip our release for a month! Oh What Fun It Is To Slip Our Release For A Monnnnnnnnnnnnnnnnth!!! Ok, it won't be a full month, but due to the recent upgrade of gcc and the subsequent full rebuild of everything that does (and doesn't, whoops!) get built with gcc, including java stuff with gcj, and the need to further test package selection windows in Anaconda, system-config-packages for upgrades, and the development tree in general once we settle down the rebuilds, we have decided to delay test2. Here is a new schedule that we will be working toward: * Test2 freeze date to 9 January * Test2 release, 16 January * Test3 freeze, 6 February * Test3 release, 13 February * Final absolute freeze, 6 March * Release, 15 March We are going to try very hard to have a stable(ish) tree suitable for testing over the holidays, so that Test2 will be better for the slip and keep us in line with getting Test3 and eventually the final release out in the best shape possible. Thank you all for your hard work in helping us develop the best distribution we can! -- Jesse Keating Release Engineer: Fedora From arjan at fenrus.demon.nl Mon Dec 19 17:17:38 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 19 Dec 2005 18:17:38 +0100 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012482.28062.26.camel@yoda.loki.me> References: <1135012482.28062.26.camel@yoda.loki.me> Message-ID: <1135012659.2947.13.camel@laptopd505.fenrus.org> On Mon, 2005-12-19 at 09:14 -0800, Jesse Keating wrote: > Ok, it won't be a full month, but due to the recent upgrade of gcc and does this mean that the handoff of FC3 to fedora legacy is also delayed a month ? From wtogami at redhat.com Mon Dec 19 17:21:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Dec 2005 12:21:53 -0500 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012659.2947.13.camel@laptopd505.fenrus.org> References: <1135012482.28062.26.camel@yoda.loki.me> <1135012659.2947.13.camel@laptopd505.fenrus.org> Message-ID: <43A6EC31.3000603@redhat.com> Arjan van de Ven wrote: > On Mon, 2005-12-19 at 09:14 -0800, Jesse Keating wrote: > >> Ok, it won't be a full month, but due to the recent upgrade of gcc and > > > does this mean that the handoff of FC3 to fedora legacy is also delayed > a month ? Whenever test2 is released, FC3 maintainership will be handed to Legacy. Warren Togami wtogami at redhat.com From jkeating at redhat.com Mon Dec 19 17:23:23 2005 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Dec 2005 09:23:23 -0800 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012659.2947.13.camel@laptopd505.fenrus.org> References: <1135012482.28062.26.camel@yoda.loki.me> <1135012659.2947.13.camel@laptopd505.fenrus.org> Message-ID: <1135013003.28062.32.camel@yoda.loki.me> On Mon, 2005-12-19 at 18:17 +0100, Arjan van de Ven wrote: > > does this mean that the handoff of FC3 to fedora legacy is also delayed > a month ? Yes, I do believe that is correct. -- Jesse Keating Release Engineer: Fedora From notting at redhat.com Mon Dec 19 19:03:06 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Dec 2005 14:03:06 -0500 Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <604aa7910512170732i1d0a270bu3fa2b28a995d06ac@mail.gmail.com> References: <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134696765.3005.120.camel@yoda.loki.me> <20051216015658.GA20270@devserv.devel.redhat.com> <1134709026.2661.16.camel@mobile2> <1134722336.28842.168.camel@greebo> <20051216084727.GX23448@redhat.com> <20051217071224.GE24500@devserv.devel.redhat.com> <604aa7910512170732i1d0a270bu3fa2b28a995d06ac@mail.gmail.com> Message-ID: <20051219190306.GB10337@devserv.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On 12/17/05, Bill Nottingham wrote: > > Realistically, there's plenty of stuff we ship that sane third-party > > developers shouldn't be building against. We should have some sort > > of defined developer platform (i.e., this is what you *should* use.) > > That would help more than playing with what is packaged where. > > +1 for defined developer platform. Though I have no idea how you go > about defining that. Linker warnings! /usr/bin/ld: Warning: "No. No, not good. No, no." /usr/bin/ld: Warning: "Never use this." Bill From gdk at redhat.com Mon Dec 19 18:59:13 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 19 Dec 2005 13:59:13 -0500 (EST) Subject: libxml v1 dependencies (was: Re: multilib fun - devel packages) In-Reply-To: <1134708921.2661.14.camel@mobile2> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> Message-ID: On Thu, 15 Dec 2005, Christopher Blizzard wrote: > This is an interesting question, actually. If we want to get to a > one-cd install we're going to have to make some hard choices. Not that > I would mind making those choices, but we would have to shrink down the > scope of what we deliver right now. If what Jeremy says is correct, we will be making these choices fairly soon in order to make Fedora Core's disk 1 installable all by its lonesome -- which means we'll end up in a situation in which we've got "Fedora Core Disk 1," which will become known as "Fedora Core Core". And then we'll have "Fedora Core Disk 2," which will become known as "Fedora Core-almost-Extras Disk 1". > There's also the question of if we're server focused or desktop focused. > Right now it's some strange combination of both. But for a one-cd > install we're going to have to make a choice between the two. Good question. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From sundaram at redhat.com Tue Dec 20 03:36:34 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 09:06:34 +0530 Subject: libxml v1 dependencies In-Reply-To: References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> Message-ID: <43A77C42.5000704@redhat.com> Hi >>There's also the question of if we're server focused or desktop focused. >>Right now it's some strange combination of both. But for a one-cd >>install we're going to have to make a choice between the two. >> >> > >Good question. > >--g > > Desktop just makes better sense for a single CD target IMO. Server users generally are more advanced and would want to install more packages while a significant portion of desktop users might be willing to settle for the default desktop Lapps in a single CD. There is still a question of providing specific targets such as GNOME, KDE and XFCE among others. This can be resolved by building one and enable the community to build the rest. regards Rahul From tgl at redhat.com Tue Dec 20 04:37:39 2005 From: tgl at redhat.com (Tom Lane) Date: Mon, 19 Dec 2005 23:37:39 -0500 Subject: libxml v1 dependencies In-Reply-To: <43A77C42.5000704@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> Message-ID: <24898.1135053459@sss.pgh.pa.us> Rahul Sundaram writes: > Desktop just makes better sense for a single CD target IMO. Server users > generally are more advanced and would want to install more packages > while a significant portion of desktop users might be willing to settle > for the default desktop Lapps in a single CD. Really? Can you fit a reasonable desktop environment on one CD these days? (How many meg is OpenOffice at the moment?) Server is actually much more likely to fit on one CD, not least because server admins tend to favor "don't install what we don't need" for security reasons --- while desktop users seldom worry about that. I don't disagree with your premise, only with the assumption that it's actually possible to do anything very useful with one CD for desktop. regards, tom lane From sundaram at redhat.com Tue Dec 20 04:49:52 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 10:19:52 +0530 Subject: libxml v1 dependencies In-Reply-To: <24898.1135053459@sss.pgh.pa.us> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <24898.1135053459@sss.pgh.pa.us> Message-ID: <43A78D70.4050009@redhat.com> Tom Lane wrote: >Rahul Sundaram writes: > > >>Desktop just makes better sense for a single CD target IMO. Server users >>generally are more advanced and would want to install more packages >>while a significant portion of desktop users might be willing to settle >>for the default desktop Lapps in a single CD. >> >> > >Really? Can you fit a reasonable desktop environment on one CD these >days? (How many meg is OpenOffice at the moment?) > > People have done it before. There are more than a few Live CD's and single CD distributions which are based on Fedora ( http://fedoraproject.org/wiki/DerivedDistributions/ ) and yes they can still be useful. The magic sauce is pick a default desktop environment, office suite, browser, music player etc and carefully prune out extra dependencies by splitting out packages where necessary to strictly keep up with a typical user desktop. We might have to make some hard choices in this process but its certainly doable. regards Rahul From notting at redhat.com Tue Dec 20 04:56:01 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Dec 2005 23:56:01 -0500 Subject: some packages that can be removed from Core Message-ID: <20051220045601.GB15410@devserv.devel.redhat.com> These are libraries not required by anything. Note that I'm treating perl modules as libraries in this case. liboldX libxkbui libXvMC libnl libXxf86dga perl-Archive-Tar perl-Convert-ASN1 perl-Crypt-SSLeay perl-DateManip perl-Devel-Syndump perl-File-MMagic perl-Frontier-RPC perl-Inline perl-IO-String perl-IO-Zlib perl-LDAP perl-LDAP perl-libxml-perl perl-NKF perl-Parse-RecDescent perl-PDL perl-RPM-Specfile perl-TermReadKey perl-TimeDate perl-XML-Dumper perl-XML-Grove perl-XML-LibXML perl-XML-LibXML-Common perl-XML-NamespaceSupport perl-XML-SAX perl-XML-Twig libxkbui is required only by fontforge, in Extras. libXxf86dga is required by various things in Extras. perl-File-MMagic and perl-NKF are required by namazu, in Extras. perl-DateManip is required by cvsplot, in Extras. The rest of them aren't required by *anything*, AFACIT, aside from perl module interdependencies among the group. Bill From bdpepple at ameritech.net Tue Dec 20 04:59:55 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 19 Dec 2005 23:59:55 -0500 Subject: libxml v1 dependencies In-Reply-To: <24898.1135053459@sss.pgh.pa.us> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <24898.1135053459@sss.pgh.pa.us> Message-ID: <1135054795.14207.1.camel@shuttle.273piedmont.com> On Mon, 2005-12-19 at 23:37 -0500, Tom Lane wrote: > I don't disagree with your premise, only with the assumption that it's > actually possible to do anything very useful with one CD for desktop. > Ubuntu doesn't seem to have a problem having only one CD for the desktop, why should Fedora? /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at redhat.com Tue Dec 20 05:02:32 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 10:32:32 +0530 Subject: libxml v1 dependencies In-Reply-To: <1135054795.14207.1.camel@shuttle.273piedmont.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <24898.1135053459@sss.pgh.pa.us> <1135054795.14207.1.camel@shuttle.273piedmont.com> Message-ID: <43A79068.3090509@redhat.com> Brian Pepple wrote: >On Mon, 2005-12-19 at 23:37 -0500, Tom Lane wrote: > > >>I don't disagree with your premise, only with the assumption that it's >>actually possible to do anything very useful with one CD for desktop. >> >> >> > >Ubuntu doesn't seem to have a problem having only one CD for the >desktop, why should Fedora? > > If we decide that the targets are similar we can make similar decisions, however distro X does it why not distro Y is generally not a good rationale by itself. regards Rahul From jgarzik at redhat.com Tue Dec 20 05:59:23 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Tue, 20 Dec 2005 00:59:23 -0500 Subject: some packages that can be removed from Core In-Reply-To: <20051220045601.GB15410@devserv.devel.redhat.com> References: <20051220045601.GB15410@devserv.devel.redhat.com> Message-ID: <20051220055923.GA4467@devserv.devel.redhat.com> On Mon, Dec 19, 2005 at 11:56:01PM -0500, Bill Nottingham wrote: > perl-Archive-Tar > perl-Crypt-SSLeay Highly popular, like openssl-devel. > perl-DateManip > perl-IO-String > perl-IO-Zlib I'm really surprised these are unused. > perl-XML-Dumper > perl-XML-Grove > perl-XML-LibXML > perl-XML-LibXML-Common > perl-XML-NamespaceSupport > perl-XML-SAX > perl-XML-Twig It's a bit nice to have the Perl version of libxml. Other than that, I totally agree. Jeff From notting at redhat.com Tue Dec 20 06:00:43 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Dec 2005 01:00:43 -0500 Subject: some packages that can be removed from Core In-Reply-To: <20051220055923.GA4467@devserv.devel.redhat.com> References: <20051220045601.GB15410@devserv.devel.redhat.com> <20051220055923.GA4467@devserv.devel.redhat.com> Message-ID: <20051220060043.GA8180@devserv.devel.redhat.com> Jeff Garzik (jgarzik at redhat.com) said: > On Mon, Dec 19, 2005 at 11:56:01PM -0500, Bill Nottingham wrote: > > perl-Archive-Tar > > perl-Crypt-SSLeay > > Highly popular, like openssl-devel. > > > > perl-DateManip > > perl-IO-String > > perl-IO-Zlib > > I'm really surprised these are unused. > > > > perl-XML-Dumper > > perl-XML-Grove > > perl-XML-LibXML > > perl-XML-LibXML-Common > > perl-XML-NamespaceSupport > > perl-XML-SAX > > perl-XML-Twig > > It's a bit nice to have the Perl version of libxml. Other than that, I > totally agree. Yes, but... none of these are being used by anything in Core - hence, I don't see why they couldn't be in Extras. Bill From rc040203 at freenet.de Tue Dec 20 06:12:17 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Dec 2005 07:12:17 +0100 Subject: libxml v1 dependencies In-Reply-To: <43A77C42.5000704@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> Message-ID: <1135059137.12394.134.camel@mccallum.corsepiu.local> On Tue, 2005-12-20 at 09:06 +0530, Rahul Sundaram wrote: > Hi > > >>There's also the question of if we're server focused or desktop focused. > >>Right now it's some strange combination of both. But for a one-cd > >>install we're going to have to make a choice between the two. > >> > >> > > > >Good question. > > > >--g > > > > > Desktop just makes better sense for a single CD target IMO. Server users > generally are more advanced and would want to install more packages > while a significant portion of desktop users might be willing to settle > for the default desktop Lapps in a single CD. IMO, distinguishing between desktop and server installs and basing decisions on "whether to include a package or not onto this CD" on this, doesn't make much sense due to the "rolling nature" of _both_ FC and FE. I'd prefer if a "1CD-Fedora" was to contain only those packages a user needs to be able to bring up his system to the point, where he can configure it and download additional packages from the net. I.e. I'd prefer a 1CD-Fedora not to be much more than an extended "installer/bootstrap CD". "Office", etc. then would not be much more than "predefined sets of packages, a user would chose to install. Be it from CD, the net or whatever media. > There is still a question > of providing specific targets such as GNOME, KDE and XFCE among others. Given what I wrote above, if one of these is part of "packages required to bootstrap", so be it on the 1CD, if not, so be it not ... > This can be resolved by building one and enable the community to build > the rest. I feel you seem to be mixing up "1CD-distro" with "FC vs. FE" and "RH-maintained vs. community-maintained", here. In my understanding there actually is no real connection between these topics at all. Ralf From sundaram at redhat.com Tue Dec 20 06:22:07 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 11:52:07 +0530 Subject: libxml v1 dependencies In-Reply-To: <1135059137.12394.134.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> Message-ID: <43A7A30F.3080507@redhat.com> Hi >I'd prefer if a "1CD-Fedora" was to contain only those packages a user >needs to be able to bring up his system to the point, where he can >configure it and download additional packages from the net. > >I.e. I'd prefer a 1CD-Fedora not to be much more than an extended >"installer/bootstrap CD". > > This does not work for many regions in the world where net access is limited or extremely costly. Such as a CD is also not useful target in itself for redistribution. You cant get into do anything useful for anybody without downloading stuff from the net first. For that there is already a boot.iso image which provides a network installation option. >I feel you seem to be mixing up "1CD-distro" with "FC vs. FE" and >"RH-maintained vs. community-maintained", here. In my understanding >there actually is no real connection between these topics at all. > > I meant for example that one of the targets such as Fedora GNOME could by build by the Fedora Core team while leaving rest of the other potential variations like Fedora KDE or Fedora XFCE build by the rest of the community using infrastructure or tools provided within the Fedora Project. regards Rahul From mharris at mharris.ca Tue Dec 20 07:18:51 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 20 Dec 2005 02:18:51 -0500 Subject: some packages that can be removed from Core In-Reply-To: <20051220045601.GB15410@devserv.devel.redhat.com> References: <20051220045601.GB15410@devserv.devel.redhat.com> Message-ID: <43A7B05B.3080502@mharris.ca> Bill Nottingham wrote: > These are libraries not required by anything. Note that I'm treating > perl modules as libraries in this case. > > liboldX In all honesty, I don't think anything out there uses this library in Linux, and probably nothing ever has. I've never seen or heard of anything using it anyway. Ancient legacy, and can probably just be dropped entirely from the OS. > libxkbui > libXvMC > libXxf86dga [SNIP] > libxkbui is required only by fontforge, in Extras. libXxf86dga > is required by various things in Extras. These are core X Window System libraries, and are expected to be there. Various 3rd party software uses and relies upon these libraries. They can't IMHO be removed from Core. Also, the maintenance of the X Window System as a whole, while modularized, is not done one package as a time. There is a fair bit of automation being done to update libraries, drivers, and keep everything in synchronization, and rolling with upstream changes. Splitting things into 2 different piles, which are maintained separately, with 2 different build systems, etc. would be a major maintenance nightmare. Nothing is really to be gained by pushing these small libraries into Fedora Extras IMHO, except complicating maintenance of X. Having said that, there are a number of packages that are part of the full X Window System release which are not currently part of Fedora Core, and unlike the libraries, are prime candidates for possible inclusion in Fedora Extras. A number of the old legacy X applications, some of which we haven't shipped for many releases now, can potentially be maintained in Extras if there are volunteers who are interested in maintaining them. There are a few other things which are lesser used software previously part of X11R6-contrib a number of years back, which interested volunteers may want to maintain in extras. I'll post a list of them all sometime after Christmas, and see if anyone is interested in any of the bits and pieces. I believe many users will be happy to see some of these lesser used tools made available via Extras now, which is made easily possible thanks to modularization of X. HTH -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From rc040203 at freenet.de Tue Dec 20 07:29:16 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Dec 2005 08:29:16 +0100 Subject: libxml v1 dependencies In-Reply-To: <43A7A30F.3080507@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> <43A7A30F.3080507@redhat.com> Message-ID: <1135063756.12394.154.camel@mccallum.corsepiu.local> On Tue, 2005-12-20 at 11:52 +0530, Rahul Sundaram wrote: > Hi > > >I'd prefer if a "1CD-Fedora" was to contain only those packages a user > >needs to be able to bring up his system to the point, where he can > >configure it and download additional packages from the net. > > > >I.e. I'd prefer a 1CD-Fedora not to be much more than an extended > >"installer/bootstrap CD". > > > > > This does not work for many regions in the world where net access is > limited or extremely costly. I am living in such a region - Here, bandwidth is the limiting factor. Also, IMO it is a fact that Fedora already is not reasonably usable without low cost net access ;) > Such as a CD is also not useful target in > itself for redistribution. Why not? You would ship such a CD and would ship additional CDs containing snapshots of subsets of the yum repositories. A "Fedora Office CD", e.g. would contain a repository snapshot of openoffice, firefox etc. and all of their infrastructure. To be able to apply this what would be required is yum being able to handle CDs, or users to copy the repo-on-CD to a reachable filesystem. > You cant get into do anything useful for > anybody without downloading stuff from the net first. For that there is > already a boot.iso image which provides a network installation option. Well, boot.iso is not what I am talking about. I am talking about a CD that installs a system up to the point where all system-config* tools can be launched, /etc/sysconf/* can be configured, other /etc/* files can be edited, a web browser be launched and a graphical frontend to yum can be run. I.e. in the end, a user would end with a running X11 under a "sysadmin user" and "be clicking together" his "custom setup". > >I feel you seem to be mixing up "1CD-distro" with "FC vs. FE" and > >"RH-maintained vs. community-maintained", here. In my understanding > >there actually is no real connection between these topics at all. > > > > > I meant for example that one of the targets such as Fedora GNOME could > by build by the Fedora Core team while leaving rest of the other > potential variations like Fedora KDE or Fedora XFCE build by the rest of > the community using infrastructure or tools provided within the Fedora > Project. IMO, there is no reason to put GNOME in a privileged position. Those parts of it which are requirement of a "minimal install" are inevitable but anything else is waste of disc space. The same applies to GCC, python, Perl, ... simply any package. Ralf From sundaram at redhat.com Tue Dec 20 07:53:28 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 13:23:28 +0530 Subject: libxml v1 dependencies In-Reply-To: <1135063756.12394.154.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> <43A7A30F.3080507@redhat.com> <1135063756.12394.154.camel@mccallum.corsepiu.local> Message-ID: <43A7B878.7000602@redhat.com> Hi >Why not? You would ship such a CD and would ship additional CDs >containing snapshots of subsets of the yum repositories. > >A "Fedora Office CD", e.g. would contain a repository snapshot of >openoffice, firefox etc. and all of their infrastructure. > > That would drive up the cost for redistribution. Fedora Projects ships CDs/DVDs to many places all over the world. >IMO, there is no reason to put GNOME in a privileged position. >Those parts of it which are requirement of a "minimal install" are >inevitable but anything else is waste of disc space. The same applies to >GCC, python, Perl, ... simply any package. > > Its not about GNOME as such but providing a targeted version of Fedora for desktop users from a single CD. Single CD obviously limits the choice of a DE. We can pick GNOME, KDE or XFCE and provide the infrastructure for others to create their own subsets from Core and Extras repository. Somebody might choose a Games, Educational or even a Perl edition. regards Rahul From jpo at di.uminho.pt Tue Dec 20 09:15:13 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Tue, 20 Dec 2005 09:15:13 +0000 Subject: some packages that can be removed from Core In-Reply-To: <20051220045601.GB15410@devserv.devel.redhat.com> References: <20051220045601.GB15410@devserv.devel.redhat.com> Message-ID: <43A7CBA1.2070206@di.uminho.pt> Bill Nottingham wrote: > These are libraries not required by anything. Note that I'm treating > perl modules as libraries in this case. > > perl-Convert-ASN1 > perl-LDAP > perl-XML-SAX > > The rest of them aren't required by *anything*, AFACIT, aside > from perl module interdependencies among the group. perl-LDAP (plus perl-Convert-ASN1 and perl-XML-SAX) should be required by the samba package. Unfortunately the smbldap-tools, included in the samba tarball for several months now, are being packaged as docs. SMBLDAP tools http://samba.idealx.org/index.en.html jpo PS - There are other perl modules being filtered out from core RPMS. PS2 - perl-Tk and perl-IO-Socket-SSL should be core modules: i) perl-Tk is needed by tetex and should be *required* by net-snmp (this package is being crippled as the utility tkmib is simply removed) ii) SSL support for several perl modules (perl-LDAP, ...) -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Tue Dec 20 09:29:14 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Dec 2005 10:29:14 +0100 Subject: libxml v1 dependencies In-Reply-To: <43A7B878.7000602@redhat.com> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> <43A7A30F.3080507@redhat.com> <1135063756.12394.154.camel@mccallum.corsepiu.local> <43A7B878.7000602@redhat.com> Message-ID: <1135070954.12394.191.camel@mccallum.corsepiu.local> On Tue, 2005-12-20 at 13:23 +0530, Rahul Sundaram wrote: > Hi > > >Why not? You would ship such a CD and would ship additional CDs > >containing snapshots of subsets of the yum repositories. > > > >A "Fedora Office CD", e.g. would contain a repository snapshot of > >openoffice, firefox etc. and all of their infrastructure. > > > > > That would drive up the cost for redistribution. Fedora Projects ships > CDs/DVDs to many places all over the world. I don't understand this. You'd have different Fedora Distributions and different Fedora Distributors. Each one would be able to ship the collection of packages from the FC + FE he wants to ship. Users would be able to mix these distros (As all packages would originate from FC or FE). Vendors/VARs would be able to compile their collection of packages etc. The burdon/load of compiling CDs would be shifted away from RH, except if RH also wants to be one of these "vendors" To me sound like great progress over the current situation, the average user is facing with a fresh install of Fedora 4: * Download 4 ISOs/2.5GB of FC4 CDs (Many will also download the SRPM-ISOs) * Install from CD1 (In many cases the user will notice too late that he might not need some of the CDs). * Upon first run of yum, download at least half of the packages from updates anew, because they are outdated. * Start fiddling with yum's configuration to pull-in the packages you actually want. I.e. users using CDs actually waste bandwidth! Now try to install Fedora on several machines. Sophisticated users will find ways to reuse the packages they downloaded from updates and extras, beforehand (e.g. by setting up local yum repos or by sharing yum caches). Less sophisticated users will download everything anew. - I am sorry, but I can't find this method to be compelling ;) > >IMO, there is no reason to put GNOME in a privileged position. > >Those parts of it which are requirement of a "minimal install" are > >inevitable but anything else is waste of disc space. The same applies to > >GCC, python, Perl, ... simply any package. > > > > > Its not about GNOME as such but providing a targeted version of Fedora > for desktop users from a single CD. As it seems to me, I can't make it to you - I am questioning this kind of partitioning a distribution as a whole, because whatever you or RH considers "nominal desktop" is irrelevant to users. With the scheme outlined above, what you seem to have in mind would by "RH Fedora Desktop CD", i.e. RH would ship a _second_ CD in addition to CD1, containing those packages RH considers to be "their preferred" desktop. Ralf From sundaram at redhat.com Tue Dec 20 09:42:59 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 15:12:59 +0530 Subject: libxml v1 dependencies In-Reply-To: <1135070954.12394.191.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> <43A7A30F.3080507@redhat.com> <1135063756.12394.154.camel@mccallum.corsepiu.local> <43A7B878.7000602@redhat.com> <1135070954.12394.191.camel@mccallum.corsepiu.local> Message-ID: <43A7D223.3020405@redhat.com> Hi >I don't understand this. > >You'd have different Fedora Distributions and different Fedora >Distributors. Each one would be able to ship the collection of packages >from the FC + FE he wants to ship. > > Different vendors can already distribute Fedora. http://fedoraproject.org/wiki/Distribution > The burdon/load of compiling CDs would be >shifted away from RH, except if RH also wants to be one of these >"vendors" > > Think LUGs or conferences. RH does ship Fedora for free on these occasions and additional CD's would cost more to redistribute. >As it seems to me, I can't make it to you - I am questioning this kind >of partitioning a distribution as a whole, because whatever you or RH >considers "nominal desktop" is irrelevant to users. > > > My personal preference might be irrelevant but whatever engineering resources being alloted to the project directly determines the level of development and integration work. Setting aside that point , community like I said can create their own targets based on Fedora repositories. There would can be any of Fedora GNOME or KDE or editions. The difference is that the user can download one of those *single* CD's based on their choice and get most of what they want. regards Rahul From veillard at redhat.com Tue Dec 20 11:13:08 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 20 Dec 2005 06:13:08 -0500 Subject: some packages that can be removed from Core In-Reply-To: <20051220045601.GB15410@devserv.devel.redhat.com> References: <20051220045601.GB15410@devserv.devel.redhat.com> Message-ID: <20051220111308.GB5740@redhat.com> On Mon, Dec 19, 2005 at 11:56:01PM -0500, Bill Nottingham wrote: > perl-libxml-perl [...] > perl-XML-LibXML > perl-XML-LibXML-Common Hum, I wonder the level of code duplication there..., I know perl-XML-LibXML is a maintained libxml2 binding, I assume perl-XML-LibXML-Common is just a split (maybe for perl-XML-LibXSLT), but perl-libxml-perl I never heard of... Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rc040203 at freenet.de Tue Dec 20 12:18:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Dec 2005 13:18:22 +0100 Subject: some packages that can be removed from Core In-Reply-To: <20051220111308.GB5740@redhat.com> References: <20051220045601.GB15410@devserv.devel.redhat.com> <20051220111308.GB5740@redhat.com> Message-ID: <1135081102.12394.213.camel@mccallum.corsepiu.local> On Tue, 2005-12-20 at 06:13 -0500, Daniel Veillard wrote: > On Mon, Dec 19, 2005 at 11:56:01PM -0500, Bill Nottingham wrote: > > perl-libxml-perl > [...] > > perl-XML-LibXML > > perl-XML-LibXML-Common > > Hum, I wonder the level of code duplication there..., I know perl-XML-LibXML > is a maintained libxml2 binding, I assume perl-XML-LibXML-Common is just a > split (maybe for perl-XML-LibXSLT) perl-XML-LibXML-Common is a base package of perl-XML-LibXML, being shared between several perl modules of the perl-XML-LibXML family, from the same author as perl-XML-LibXML (Christian Glahn). For detail, see http://search.cpan.org/~phish Whether it is actively maintained, is arguable. It's latest changes date back to 04/04, but this doesn't mean much, because these packages "just work". Several other perl modules from Bill's list also are base-packages/dependencies of perl-XML-LibXML, eg. perl-XML-SAX and perl-XML-NamespaceSupport. I.e. lurking in Bill's list is a proposal to remove a tree of perl-modules forming a popular libxml2 perl-interface ;) Ralf From veillard at redhat.com Tue Dec 20 14:02:32 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 20 Dec 2005 09:02:32 -0500 Subject: some packages that can be removed from Core In-Reply-To: <1135081102.12394.213.camel@mccallum.corsepiu.local> References: <20051220045601.GB15410@devserv.devel.redhat.com> <20051220111308.GB5740@redhat.com> <1135081102.12394.213.camel@mccallum.corsepiu.local> Message-ID: <20051220140232.GC5740@redhat.com> On Tue, Dec 20, 2005 at 01:18:22PM +0100, Ralf Corsepius wrote: > On Tue, 2005-12-20 at 06:13 -0500, Daniel Veillard wrote: > > On Mon, Dec 19, 2005 at 11:56:01PM -0500, Bill Nottingham wrote: > > > perl-libxml-perl > > [...] > > > perl-XML-LibXML > > > perl-XML-LibXML-Common > > > > Hum, I wonder the level of code duplication there..., I know perl-XML-LibXML > > is a maintained libxml2 binding, I assume perl-XML-LibXML-Common is just a > > split (maybe for perl-XML-LibXSLT) > > perl-XML-LibXML-Common is a base package of perl-XML-LibXML, being > shared between several perl modules of the perl-XML-LibXML family, from > the same author as perl-XML-LibXML (Christian Glahn). > For detail, see http://search.cpan.org/~phish > > Whether it is actively maintained, is arguable. It's latest changes date > back to 04/04, but this doesn't mean much, because these packages "just > work". I have heard that he made progresses but they were not yet pushed, nothing conclusive but seems he is still the active maintainer. > Several other perl modules from Bill's list also are > base-packages/dependencies of perl-XML-LibXML, eg. perl-XML-SAX and > perl-XML-NamespaceSupport. > > I.e. lurking in Bill's list is a proposal to remove a tree of > perl-modules forming a popular libxml2 perl-interface ;) I honnestly can't juge how popular they are :-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jkeating at redhat.com Tue Dec 20 23:43:08 2005 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Dec 2005 15:43:08 -0800 Subject: Plan for the Holidays Message-ID: <1135122188.10390.3.camel@yoda.loki.me> With the holidays upcoming, I plan to get the devel tree as broken-dep free as possible. This includes the foo-kernel packages. I'll be trying to keep those in sync with the new kernels that are pushed into rawhide. A lot of folks will have time off over the next couple weeks and if they choose to test stuff I'd like it to be as easy as possible. That said, I think it would be good for developers to post what specifically they think should be tested during this time. What components do we need some extra eyes on as we approach test2 freeze? Off the top of my head, we need the java stack tested, and that is a pretty big thing. Also the functionality of your favorite apps is a good thing to target, given that everything has been rebuilt with the new gcc. So Developers? What would you like the masses to test? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Dec 21 00:14:07 2005 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Dec 2005 16:14:07 -0800 Subject: Plan for the Holidays In-Reply-To: <43A89B9E.7060203@reub.net> References: <1135122188.10390.3.camel@yoda.loki.me> <43A89B9E.7060203@reub.net> Message-ID: <1135124047.10390.12.camel@yoda.loki.me> On Wed, 2005-12-21 at 11:02 +1100, Reuben Farrelly wrote: > A whole lot of stuff in -extras development hasn't been rebuilt for months and > months either - some as far back as March/April (look at perl-* modules in > extras for an example). No doubt there are various dependency issues there too. > > Can this be looked at as well? I'm sure packages in extras would also benefit > from a rebuild with newer gcc and therefore wider testing over the break. > > Extras really does look like a second rate citizen if everything in rawhide is > rebuilt for a new gc(c|j)/openssl but packages in extras are left untouched for > months... Extras is maintained by the individual package maintainers. It is up to them to keep their packages updated. This is usually the way it works inside Red Hat as well, however when we release a new GCC so close to the freeze date, I step in to autobump the packages when possible. There isn't really somebody to do this for all of Extras, nor would extras maintainers be all that welcome for it as a whole. Extras tracking rawhide is pretty tough as things change so rapidly. However during the holidays would be a good time for extras maintainers to rebase their packages off the current rawhide. Also during the freeze and just after a test release would be another good time for Extras maintainers to rebuild their packages. Extras is only as second rate as the maintainers (community) makes it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From blizzard at redhat.com Wed Dec 21 03:05:10 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 20 Dec 2005 22:05:10 -0500 Subject: libxml v1 dependencies In-Reply-To: <1135059137.12394.134.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> Message-ID: <1135134310.3805.23.camel@mobile2> I'm pretty sure we can get a single-CD that shows off a decent GNOME desktop, including a web browser, email client, network connections and a few other items. It's not enough that they are able to bootstrap themselves onto the network. I suspect that some basic functionality would also be nice. Can we do firefox + evo + OOo? I suspect so. --Chris On Tue, 2005-12-20 at 07:12 +0100, Ralf Corsepius wrote: > On Tue, 2005-12-20 at 09:06 +0530, Rahul Sundaram wrote: > > Hi > > > > >>There's also the question of if we're server focused or desktop focused. > > >>Right now it's some strange combination of both. But for a one-cd > > >>install we're going to have to make a choice between the two. > > >> > > >> > > > > > >Good question. > > > > > >--g > > > > > > > > Desktop just makes better sense for a single CD target IMO. Server users > > generally are more advanced and would want to install more packages > > while a significant portion of desktop users might be willing to settle > > for the default desktop Lapps in a single CD. > IMO, distinguishing between desktop and server installs and basing > decisions on "whether to include a package or not onto this CD" on this, > doesn't make much sense due to the "rolling nature" of _both_ FC and FE. > > I'd prefer if a "1CD-Fedora" was to contain only those packages a user > needs to be able to bring up his system to the point, where he can > configure it and download additional packages from the net. > > I.e. I'd prefer a 1CD-Fedora not to be much more than an extended > "installer/bootstrap CD". > > "Office", etc. then would not be much more than "predefined sets of > packages, a user would chose to install. Be it from CD, the net or > whatever media. > > > There is still a question > > of providing specific targets such as GNOME, KDE and XFCE among others. > Given what I wrote above, if one of these is part of "packages required > to bootstrap", so be it on the 1CD, if not, so be it not ... > > > This can be resolved by building one and enable the community to build > > the rest. > I feel you seem to be mixing up "1CD-distro" with "FC vs. FE" and > "RH-maintained vs. community-maintained", here. In my understanding > there actually is no real connection between these topics at all. > > > Ralf > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From blizzard at redhat.com Wed Dec 21 03:10:16 2005 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 20 Dec 2005 22:10:16 -0500 Subject: libxml v1 dependencies In-Reply-To: <1135063756.12394.154.camel@mccallum.corsepiu.local> References: <20051208043947.GA22451@devserv.devel.redhat.com> <20051213133355.GN4116@redhat.com> <1134494076.17887.22.camel@bobcat.mine.nu> <20051213180734.GP4116@redhat.com> <604aa7910512131028i5f8f0c5s9e20a8f9d8f4fab3@mail.gmail.com> <1134636683.28842.39.camel@greebo> <604aa7910512150520s2cf1f894rca0ab5ac3b3d62d7@mail.gmail.com> <20051215132234.GC12468@ryoko.camperquake.de> <604aa7910512150618v27218cfbheb698b1830b688f3@mail.gmail.com> <1134694936.3005.101.camel@yoda.loki.me> <604aa7910512151724i35e7e1b8sb2d706a1414a0354@mail.gmail.com> <1134708921.2661.14.camel@mobile2> <43A77C42.5000704@redhat.com> <1135059137.12394.134.camel@mccallum.corsepiu.local> <43A7A30F.3080507@redhat.com> <1135063756.12394.154.camel@mccallum.corsepiu.local> Message-ID: <1135134616.3805.28.camel@mobile2> On Tue, 2005-12-20 at 08:29 +0100, Ralf Corsepius wrote: > IMO, there is no reason to put GNOME in a privileged position. > Those parts of it which are requirement of a "minimal install" are > inevitable but anything else is waste of disc space. The same applies to > GCC, python, Perl, ... simply any package. GNOME is "first among equals" to be sure - it's what we have the most expertise with, it's what we support and the GNOME project has a design goal that's consistent with Red Hat's own. There's a natural alignment. So if the Red Hat folks decide that we want to do a single CD install, it will probably use GNOME as the desktop and its apps as the defaults. That's not to say that we wouldn't enable others to create something KDE-based or xfce based. Quite the opposite, we would encourage it. We just wouldn't spend a huge amount of time on it ourselves. --Chris From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Dec 21 09:09:40 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 21 Dec 2005 10:09:40 +0100 Subject: Need help to fix xmms x86_64 build Message-ID: <20051221100940.6a578dc0@python2> Hi, I'm seeing a problem I really don't know how to solve when rebuilding xmms for x86_64. When using mach or plain rpmbuild, things seem to work fine, but when using mock (I've reproduced it locally) or the Extras builsystem, many plugins fail to build/link properly, and end up only as .a archives instead of .so. Typical nasty build output looks like this : /bin/sh ./libtool --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=nocona -Wall -Wpointer-arith -o libxmms.la -rpath /usr/lib64 -export-dynamic -version-info 4:1:3 configfile.lo xmmsctrl.lo dirbrowser.lo util.lo formatter.lo titlestring.lo xentry.lo xconvert.lo -L/usr/lib64 -L/usr/lib64 -lgtk -lgdk -rdynamic -lgmodule -lgthread -lglib -lpthread -ldl -lXi -lXext -lX11 -lm rm -fr .libs/libxmms.la .libs/libxmms.* .libs/libxmms.* *** Warning: linker path does not have real file for library -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpthread and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib64/libpthread.so *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. You can see a complete build.log here : http://buildsys.fedoraproject.org/logs/fedora-development-extras/2040-xmms-1.2.10-18.1.fc5/x86_64/ A wild guess would be that this could be caused by mock only considering x86_64 packages and not any ix86 ones. In this case it's definitely an xmms build bug, and might be possible to fix with a standard "autogen.sh" set of commands (ah, libtool...), but all my attempts to gets things back into shape have failed (all the m4 files in there are pretty old...). Anyway, all this makes me really think XMMS should die once and for all. But again, it lacks a serious replacement since BMP is now discontinued (and the very latest version still has a few bugs), and the "audacious" project that wants to take over (again!) is... well... not really completely ready (yet?), and I know for having built and tested it yesterday. *sigh* Any help on this issue would be really welcome. Note that the previous release (-16 vs. this -18) built fine on x86_64, so it's either because of some fairly recent FC4 update(s) or some mock/buildsys changes. Please add anything you find to this bugzilla entry : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175493 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1653_FC4 Load : 0.55 0.41 0.36 From j.w.r.degoede at hhs.nl Wed Dec 21 13:22:00 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 Dec 2005 14:22:00 +0100 Subject: Need help to fix xmms x86_64 build In-Reply-To: <20051221100940.6a578dc0@python2> References: <20051221100940.6a578dc0@python2> Message-ID: <43A956F8.30001@hhs.nl> Matthias Saou wrote: > Hi, > > I'm seeing a problem I really don't know how to solve when rebuilding xmms > for x86_64. When using mach or plain rpmbuild, things seem to work fine, > but when using mock (I've reproduced it locally) or the Extras builsystem, > many plugins fail to build/link properly, and end up only as .a archives > instead of .so. Typical nasty build output looks like this : > Hi, I've a x86_64 myself and although I would like to see xmms replaced by something which actually is maintained upstream I too currently don't see an alternative which "just works (TM)" so I'll take a look at it. I probably won't have time untill this weekend though. Regards, Hans From jkeating at redhat.com Wed Dec 21 19:38:29 2005 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Dec 2005 11:38:29 -0800 Subject: Another round of java rebuilds Message-ID: <1135193909.10390.46.camel@yoda.loki.me> A gcc bug was found that is triggered by some of the java packages. This has been fixed so I am starting another round of java rebuilds. It remains to be seen if all java packages will rebuild cleanly this time around. I do believe jonas and jacorb were the only ones left after last time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Dec 28 11:59:35 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 28 Dec 2005 12:59:35 +0100 Subject: Need help to fix xmms x86_64 build In-Reply-To: <43A956F8.30001@hhs.nl> References: <20051221100940.6a578dc0@python2> <43A956F8.30001@hhs.nl> Message-ID: <20051228125935.69682642@python2> Hans de Goede wrote : > > I'm seeing a problem I really don't know how to solve when rebuilding xmms > > for x86_64. When using mach or plain rpmbuild, things seem to work fine, > > but when using mock (I've reproduced it locally) or the Extras builsystem, > > many plugins fail to build/link properly, and end up only as .a archives > > instead of .so. Typical nasty build output looks like this : > > > > > I've a x86_64 myself and although I would like to see xmms replaced by > something which actually is maintained upstream I too currently don't > see an alternative which "just works (TM)" so I'll take a look at it. I > probably won't have time untill this weekend though. Well, if the s/-lpthread// is working and seems to be the only solution, please go ahead and update/rebuild the package for FC4 and FC5 if you can (I'd appreciate!), changing the proper X build requirements for FC5 too, as I'm on holidays with a mobile phone Internet access for the next week and a half... :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1653_FC4 Load : 0.10 0.20 0.17