From bojan at rexursive.com Mon May 1 01:31:09 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 1 May 2006 01:31:09 +0000 (UTC) Subject: Mozilla 1.7.13 for FC5 updates References: <1145993426.14509.55.camel@coyote.rexursive.com> Message-ID: Rex Dieter math.unl.edu> writes: > Put it in bugzilla.redhat.com then. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190238 -- Bojan From sonar_guy at c-ccom.com Mon May 1 03:09:46 2006 From: sonar_guy at c-ccom.com (Scott Glaser) Date: Sun, 30 Apr 2006 23:09:46 -0400 Subject: Beware of bash 3.1 Message-ID: <1146452986.2641.7.camel@compaqlaptop> This was said by Chris Adams : >> Step 9, which looks like this: >> >>cat < /etc/profile.d/java.sh >> export JAVA_HOME=/opt/jre1.5.0_06 >> export PATH=$JAVA_HOME/bin:$PATH >> EOF >> >> Results in this: >> >> # cat /etc/profile.d/java.sh >> export JAVA_HOME=/opt/jre1.5.0_06 >> export PATH=/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin >> So... bash 3.1 has definitely changed the way variable expansion is >> done, namely it expands things it didn't used to expand. Bug or feature? >> Either way, beware. >Nope, nope, and nope. base 3.1 hasn't changed that, it isn't a bug, nor >a "feature". It is the standard documented behavior and I believe the >behavior all the way back to the beginning of the Bourne shell. >The only bug is in poor (and apparently untested) instructions. >-- >Chris Adams >Systems and Network Administrator - HiWAAY Internet Services >I don't speak for anybody but myself - that's enough trouble. Chris, This was tested numerous times and the results listed above could not be replicated following the directions posted in the how-to. What occured that caused the issue was the command was executed as a user then the file was sourced via SUDO. Following the original procedure step by step did you will not get the issue shown above. This procedure was thoroughly tested and proofed before being made available for public consumption. Scott Glaser -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Mon May 1 07:25:13 2006 From: buildsys at redhat.com (Build System) Date: Mon, 1 May 2006 03:25:13 -0400 Subject: rawhide report: 20060501 changes Message-ID: <200605010725.k417PDbL027780@porkchop.devel.redhat.com> Updated Packages: audit-1.2.1-2 ------------- * Tue Apr 25 2006 David Woodhouse 1.2.1-2 - Require kernel-headers, not glibc-kernheaders - Fix redefinition of audit_rule_data with new kernel headers - Remove abuse of __KERNEL__ in lookup_table.c cairo-1.1.2-2 ------------- * Fri Apr 28 2006 Carl Worth - 1.1.2-2 - Add suggested patch for XRenderAddGlyphs crash of bug #4705 https://bugs.freedesktop.org/show_bug.cgi?id=4705 cairo-java-1.0.3-0 ------------------ * Fri Apr 28 2006 Stepan Kasal - 1.0.3-0 - New version. fetchmail-6.3.4-1 ----------------- * Mon May 01 2006 Miloslav Trmac - 6.3.4-1 - Update to fetchmail-6.3.4 glib-java-0.2.4-1 ----------------- * Fri Apr 28 2006 Stepan Kasal - 0.2.4-1 - New version. glibc-kernheaders-3.0-22 ------------------------ * Sat Apr 29 2006 David Woodhouse 3.0-22 - Add linux/pci.h * Fri Apr 28 2006 David Woodhouse 3.0-21 - Remove the libaudit workaround hack * Fri Apr 28 2006 David Woodhouse 3.0-20 - Remove syscall macros from asm-*/unistd.h - Clean up asm-generic/signal.h - Update kernel-headers Provides: kdebase-6:3.5.2-5 ----------------- * Fri Apr 28 2006 Than Ngo 6:3.5.2-5 - fix #189702, kwin crashes when switching windows with Alt-Tab * Tue Apr 25 2006 Than Ngo 6:3.5.2-4 - fix #189790, kcheckpass cannot authenticate users using a LDAP directory * Thu Apr 13 2006 Than Ngo 6:3.5.2-3 - fix startkde to look in /usr and /etc/kde for env/ and shutdown/ kernel-2.6.16-1.2181_FC6 ------------------------ * Sun Apr 30 2006 Dave Jones - 2.6.17rc3-git3 * Fri Apr 28 2006 Dave Jones - 2.6.17rc3-git2 * Fri Apr 28 2006 David Woodhouse - Disable Xen on the basis that it doesn't build - Check for Xen tarball being unclean, abort early even on i386. libuser-0.54.6-1 ---------------- * Mon May 01 2006 Miloslav Trmac - 0.54.6-1 - Fix bugs in handling of invalid lines in the files and shadow modules - Fix pattern matching in lu_*_enumerate_full in the files and shadow modules - Add more error reporting, return non-zero exit status on error from utils - Use the skeleton directory specified in libuser.conf by Python admin.createHome and admin.addUser, add parameter skeleton= to admin.addUser (#189984) libxml2-2.6.24-1 ---------------- * Fri Apr 28 2006 Daniel Veillard - upstream release 2.6.24 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems mc-1:4.6.1a-14 -------------- * Fri Apr 28 2006 Jindrich Novy 4.6.1a-14 - don't reread panel contents while in panelized mode (#188438) rpm-4.4.2-21 ------------ * Fri Apr 28 2006 Jeremy Katz - 4.4.2-21 - run ldconfig in -libs subpackage %post, not main package - add patch to generate shared lib deps by following symlinks so that -devel packages sanely depend on main libs system-config-printer-0.7.6-1 ----------------------------- * Fri Apr 28 2006 Tim Waugh - Make it actually run. * Fri Apr 21 2006 Tim Waugh - Build requires CUPS 1.2. vim-1:7.0.f001-1 ---------------- * Fri Apr 28 2006 Karsten Hopp 7.0.f001-1 - vim-7.0f3 BETA xen-3.0.2-3 ----------- * Thu Apr 27 2006 Daniel Veillard - 3.0.2-3 - xen.h now requires xen-compat.h, install it too Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From kms at passback.co.uk Mon May 1 08:02:31 2006 From: kms at passback.co.uk (Keith Sharp) Date: Mon, 01 May 2006 09:02:31 +0100 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <4454CBE7.5010602@gnome.org> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> <4454CBE7.5010602@gnome.org> Message-ID: <1146470551.4541.13.camel@animal.passback.co.uk> On Sun, 2006-04-30 at 10:38 -0400, Marco Pesenti Gritti wrote: > Nicolas Mailhot wrote: > > > > Don't get your hopes too high, having a sane shareable mozilla HTML > > rendering component has been a goal since before firefox existed. > > > > One has to wonder after all this time if the moz code is not too badly > > designed for it to ever happen. > > > > There are good news about this, it's finally happening. XULRunner 1.8 > works pretty well (I actually made some experimental rpms). Yelp, > epiphany and the other gtkmozembed applications should run just fine > with it. > > I think running firefox on the top of xulrunner requires 1.9 though > (which will be released 2007 Q1). So is the plan for FC6 to build the gtkmozembed applications against xulrunner (and add xulrunner to core) and keep Firefox and Mozilla as they currently are? Thanks, Keith. From sonar_guy at c-ccom.com Mon May 1 11:28:33 2006 From: sonar_guy at c-ccom.com (Scott Glaser) Date: Mon, 01 May 2006 07:28:33 -0400 Subject: FC5 ISO Re-Spins Message-ID: <1146482913.2609.10.camel@compaqlaptop> All This may sound like a silly question but I will ask anyway: If I were to do re-spins of the FC5 ISOs would they need to be done on the particular arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)? Thanks in advance. Scott Glaser -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Mon May 1 13:02:22 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 01 May 2006 14:02:22 +0100 Subject: FC5 ISO Re-Spins In-Reply-To: <1146482913.2609.10.camel@compaqlaptop> References: <1146482913.2609.10.camel@compaqlaptop> Message-ID: <1146488542.2885.91.camel@hades.cambridge.redhat.com> On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote: > This may sound like a silly question but I will ask anyway: If I were to > do re-spins of the FC5 ISOs would they need to be done on the particular > arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)? And PPC respun on PPC hardware. Yes, I think that's probably the case although I wouldn't swear to it. I think you'll get away with doing i386 on x86_64 though. -- dwmw2 From ajackson at redhat.com Mon May 1 12:42:25 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 01 May 2006 08:42:25 -0400 Subject: Confused about /usr/bin/nm, linker, and stripped libs In-Reply-To: <1146346115.3125.16.camel@laptopd505.fenrus.org> References: <44537BC6.1080201@research.att.com> <1146346115.3125.16.camel@laptopd505.fenrus.org> Message-ID: <44560231.2050705@redhat.com> Arjan van de Ven wrote: > On Sat, 2006-04-29 at 10:44 -0400, John Ellson wrote: >> These days rpm installs most libs stripped of their symbols, which is >> fine as it makes them smaller and presumably load faster. >> >> But how does the linker resolve symbols against stripped libs? And if >> the linker can do it, why can't /usr/bin/nm ? > > > just pass -D to nm... or use eu-readelf ;) Remind me why we don't make the useful behaviour for nm the default. - ajax From l.timochouk at gmail.com Mon May 1 14:20:41 2006 From: l.timochouk at gmail.com (Leonid Timochouk) Date: Mon, 1 May 2006 15:20:41 +0100 Subject: Fwd: Loss of prism54 functionality in 2181 In-Reply-To: <4cfaa6780605010716r2e501d95j38a7f7d8fc96feeb@mail.gmail.com> References: <4cfaa6780605010716r2e501d95j38a7f7d8fc96feeb@mail.gmail.com> Message-ID: <4cfaa6780605010720w19c7b606waa79e79da3afcd3@mail.gmail.com> Dear Colleagues, In kernel-2.6.16-1.2181_FC6 on x86_64, the prism54 driver no longer recognises the PCI card: 05:00.0 0280: 1260:3890 (rev 01) Network controller: Intersil Corporation ISL3890 [Prism GT/Prism Duette] (rev 01) Subsystem: 10b8:2802 Flags: bus master, fast Back2Back, medium devsel, latency 80, IRQ 22 Memory at b0000000 (32-bit, non-prefetchable) [size=8K] Capabilities: [dc] Power Management version 1 It was working fine in 2.6.16-2096. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Mon May 1 14:37:22 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 01 May 2006 10:37:22 -0400 Subject: FC5 ISO Re-Spins In-Reply-To: <1146482913.2609.10.camel@compaqlaptop> References: <1146482913.2609.10.camel@compaqlaptop> Message-ID: <1146494242.810.2.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote: > > This may sound like a silly question but I will ask anyway: If I were to > do re-spins of the FC5 ISOs would they need to be done on the particular > arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)? I don't think this is the case. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Mon May 1 15:33:16 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 01 May 2006 17:33:16 +0200 Subject: FESCo Election Message-ID: <1146497596.2830.40.camel@localhost.localdomain> Hi All! Just FYI, FESCo (the Fedora Extras Steering Committee) currently plans a election of the members for the next FESCo. The current plan is that all members of the cvsextras group in the accounts systems (e.g. all Fedora Extras packagers) can vote their new "leaders". For details see https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00026.html For further discussion please use fedora-extras-list. tia CU thl -- Thorsten Leemhuis From cjb at mrao.cam.ac.uk Mon May 1 15:55:18 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Mon, 01 May 2006 11:55:18 -0400 Subject: rawhide report: 20060501 changes References: <200605010725.k417PDbL027780@porkchop.devel.redhat.com> Message-ID: <871wvdd9jt.fsf@mrao.cam.ac.uk> >> On Mon, 1 May 2006 03:25:13, Build System said: > kernel-2.6.16-1.2181_FC6 > ------------------------ > * Sun Apr 30 2006 Dave Jones > - 2.6.17rc3-git3 > > * Fri Apr 28 2006 Dave Jones > - 2.6.17rc3-git2 > > * Fri Apr 28 2006 David Woodhouse > - Disable Xen on the basis that it doesn't build > - Check for Xen tarball being unclean, abort early even on i386. 2181 doesn't boot here; it gets to init after finding my lvm groups and mounting /, but then drops me to a shell after: Checking filesystems e2fsck: Cannot continue, aborting. 2171 continues to boot/fsck successfully. -- Chris Ball From rhally at mindspring.com Mon May 1 16:06:23 2006 From: rhally at mindspring.com (Richard Hally) Date: Mon, 01 May 2006 12:06:23 -0400 Subject: rawhide report: 20060501 changes In-Reply-To: <871wvdd9jt.fsf@mrao.cam.ac.uk> References: <200605010725.k417PDbL027780@porkchop.devel.redhat.com> <871wvdd9jt.fsf@mrao.cam.ac.uk> Message-ID: <445631FF.2050809@mindspring.com> Chris Ball wrote: >>> On Mon, 1 May 2006 03:25:13, Build System said: > > > kernel-2.6.16-1.2181_FC6 > > ------------------------ > > * Sun Apr 30 2006 Dave Jones > > - 2.6.17rc3-git3 > > > > * Fri Apr 28 2006 Dave Jones > > - 2.6.17rc3-git2 > > > > * Fri Apr 28 2006 David Woodhouse > > - Disable Xen on the basis that it doesn't build > > - Check for Xen tarball being unclean, abort early even on i386. > > 2181 doesn't boot here; it gets to init after finding my lvm groups and > mounting /, but then drops me to a shell after: > > Checking filesystems > e2fsck: Cannot continue, aborting. > > 2171 continues to boot/fsck successfully. > Same thing happened to me but I thought it was because I had to power off to get to reboot with the new kernel. By taking taking "rhgb" and "quiet" off the kernel line in the grub.conf, I was able to answer the "do you want to continue" with a "y" and continue the boot. HTH rh From docs-list at fedoralinks.org Mon May 1 16:28:58 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Mon, 01 May 2006 11:28:58 -0500 Subject: FC5 ISO Re-Spins In-Reply-To: <1146482913.2609.10.camel@compaqlaptop> References: <1146482913.2609.10.camel@compaqlaptop> Message-ID: <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote: > All > > This may sound like a silly question but I will ask anyway: If I were to > do re-spins of the FC5 ISOs would they need to be done on the particular > arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)? > > Thanks in advance. > > Scott Glaser > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Lets see, Keating says no, Woodhouse says yes. x86_64 spin on i386 failed...Could be user error or some other issue, I say we are batting .500. -- -- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Mon May 1 16:39:44 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 01 May 2006 17:39:44 +0100 Subject: rawhide report: 20060501 changes In-Reply-To: <200605010725.k417PDbL027780@porkchop.devel.redhat.com> References: <200605010725.k417PDbL027780@porkchop.devel.redhat.com> Message-ID: <1146501585.2885.116.camel@hades.cambridge.redhat.com> On Mon, 2006-05-01 at 03:25 -0400, Build System wrote: > > libxml2-2.6.24-1 > ---------------- > * Fri Apr 28 2006 Daniel Veillard > - upstream release 2.6.24 see http://xmlsoft.org/news.html > > * Thu Jan 02 2003 Daniel Veillard > - integrated drv_libxml2 xml.sax driver from Stphane Bidoul That's not his name, surely? You seem to have used some legacy character set in the changelog instead of UTF-8. Our tools probably ought to catch that and refuse to build. -- dwmw2 From jkeating at j2solutions.net Mon May 1 17:03:23 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 01 May 2006 13:03:23 -0400 Subject: FC5 ISO Re-Spins In-Reply-To: <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> Message-ID: <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-01 at 11:28 -0500, Robert 'Bob' Jensen wrote: > x86_64 spin on i386 failed...Could be user error or some other issue, I > say we are batting .500. > Can you show me how it failed on i386? What were your steps, where did it go boom? Tracebacks or whatnot from the boom? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From docs-list at fedoralinks.org Mon May 1 17:16:38 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Mon, 01 May 2006 12:16:38 -0500 Subject: FC5 ISO Re-Spins In-Reply-To: <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146503798.29359.17.camel@cbcclt02.cbcchome.cbccgroup.com> On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote: > > Can you show me how it failed on i386? What were your steps, where did > it go boom? Tracebacks or whatnot from the boom? > Jesse, Thanks for the response, I will clean up my x86_64 tree here and give it a run. It failed when running pkgorder, would get through the 5 kernels and fail... Come to think of it, three of those kernels were on in x86_64 at release time, there were also some other "cluster bits" not in the original release. Let me check that out. I will post back, I bet all that needs to be added to the comps.xml. -- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief -------------- 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 alan at clueserver.org Mon May 1 17:44:58 2006 From: alan at clueserver.org (alan) Date: Mon, 1 May 2006 10:44:58 -0700 (PDT) Subject: FC5 ISO Re-Spins In-Reply-To: <1146494242.810.2.camel@dhcp83-49.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146494242.810.2.camel@dhcp83-49.boston.redhat.com> Message-ID: On Mon, 1 May 2006, Jesse Keating wrote: > On Mon, 2006-05-01 at 07:28 -0400, Scott Glaser wrote: >> >> This may sound like a silly question but I will ask anyway: If I were to >> do re-spins of the FC5 ISOs would they need to be done on the particular >> arch (i.e. would x86_64 have to be re-spun on x86_64 hardware)? > > I don't think this is the case. You should be able to do this with mock. Not certain if every package is buildable as a cross-compile though. Worth a test... -- "Waiter! This lambchop tastes like an old sock!" - Sheri Lewis From zaitcev at redhat.com Mon May 1 18:16:38 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 1 May 2006 11:16:38 -0700 Subject: [BUG] yelp depends on mozilla? In-Reply-To: References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> Message-ID: <20060501111638.7f360f96.zaitcev@redhat.com> On Sun, 30 Apr 2006 15:20:17 +0100, Leon wrote: > However there is no need for yelp to depend on mozilla. It could > depend on firefox, right? Firefox is not an application suite like Mozilla. It's just a big binary blob. You cannot use the Firefox's rendering engine in your application. -- Pete From mschick at redhat.com Mon May 1 18:45:12 2006 From: mschick at redhat.com (Matthew Schick) Date: Mon, 01 May 2006 14:45:12 -0400 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <20060501111638.7f360f96.zaitcev@redhat.com> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> <20060501111638.7f360f96.zaitcev@redhat.com> Message-ID: <1146509112.2562.13.camel@localhost.localdomain> On Mon, 2006-05-01 at 11:16 -0700, Pete Zaitcev wrote: > On Sun, 30 Apr 2006 15:20:17 +0100, Leon wrote: > > > However there is no need for yelp to depend on mozilla. It could > > depend on firefox, right? > > Firefox is not an application suite like Mozilla. It's just a big > binary blob. You cannot use the Firefox's rendering engine in your > application. Actually you can... '--with-mozilla=firefox' will do just that for yelp... Matt -------------- 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 sdl.web at gmail.com Mon May 1 18:49:28 2006 From: sdl.web at gmail.com (Leon) Date: Mon, 01 May 2006 19:49:28 +0100 Subject: [BUG] yelp depends on mozilla? References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> <20060501111638.7f360f96.zaitcev@redhat.com> Message-ID: Pete Zaitcev writes: > On Sun, 30 Apr 2006 15:20:17 +0100, Leon wrote: > >> However there is no need for yelp to depend on mozilla. It could >> depend on firefox, right? > > Firefox is not an application suite like Mozilla. It's just a big > binary blob. You cannot use the Firefox's rendering engine in your > application. > > -- Pete Thank you, Pete. Although I remember (not sure) Ubuntu has only firefox installed by default. But yelp is still usable. -- Leon From docs-list at fedoralinks.org Mon May 1 19:38:26 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Mon, 01 May 2006 14:38:26 -0500 Subject: FC5 ISO Re-Spins In-Reply-To: <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote: > > Can you show me how it failed on i386? What were your steps, where did > it go boom? Tracebacks or whatnot from the boom? Here is the output at the point of failure [bob-local at spinmaster x86_64]$ pwd /var/www/mirror/fedora/linux/5/x86_64 [bob-local at spinmaster x86_64]$ pkgorder /var/www/mirror/fedora/linux/5/x86_64/iso-build_bob-local x86_64 Fedora | tee /var/www/mirror/fedora/linux/5/x86_64/iso-build_pkgfile_bob-local kernel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xen0-2.6.16-1.2096_FC5.x86_64.rpm kernel-xenU-devel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xen0-devel-2.6.16-1.2096_FC5.x86_64.rpm kernel-xenU-2.6.16-1.2096_FC5.x86_64.rpm Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 159, in ? addGroups(ds, ["Core", "Base", "Text-based Internet"]) File "/usr/lib/anaconda-runtime/pkgorder", line 97, in addGroups ds.resolveDeps() File "/usr/lib/anaconda/yuminstall.py", line 303, in resolveDeps unresolved = self.tsCheck(unresolved) File "/usr/lib/anaconda/yuminstall.py", line 329, in tsCheck dep = self._provideToPkg(req) File "/usr/lib/anaconda/yuminstall.py", line 280, in _provideToPkg best = self.bestPackagesFromList(satisfiers)[0] IndexError: list index out of range Again this is building x86_64 on i386, the instructions used worked for i386 on i386. Instructions are based on http://fedoranews.org/contributors/gene_czarcinski/update_distro/ modified and updated for FC5. Should we be using Mock for this as alan pointed out above? -- -- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief -------------- 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 katzj at redhat.com Mon May 1 19:49:58 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 15:49:58 -0400 Subject: FC5 ISO Re-Spins In-Reply-To: <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> Message-ID: <1146512998.11225.56.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 14:38 -0500, Robert 'Bob' Jensen wrote: > On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote: > > Can you show me how it failed on i386? What were your steps, where did > > it go boom? Tracebacks or whatnot from the boom? > > Here is the output at the point of failure [snip] > Again this is building x86_64 on i386, the instructions used worked for > i386 on i386. Instructions are based on > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > modified and updated for FC5. > > Should we be using Mock for this as alan pointed out above? Using mock isn't the important part, but you'll need to make sure that things think that you're running on 32-bit as otherwise, arch scoring will want x86_64 pieces. You might be able to get away with just running the commands under setarch, but setarch + a chroot is safer[1] Jeremy [1] And also how we compose the actual trees From katzj at redhat.com Mon May 1 19:55:32 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 15:55:32 -0400 Subject: FC5 ISO Re-Spins In-Reply-To: <1146512998.11225.56.camel@orodruin.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> Message-ID: <1146513332.11225.58.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote: > On Mon, 2006-05-01 at 14:38 -0500, Robert 'Bob' Jensen wrote: > > On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote: > > > Can you show me how it failed on i386? What were your steps, where did > > > it go boom? Tracebacks or whatnot from the boom? > > > > Here is the output at the point of failure > [snip] > > Again this is building x86_64 on i386, the instructions used worked for > > i386 on i386. Instructions are based on > > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > > modified and updated for FC5. > > > > Should we be using Mock for this as alan pointed out above? > > Using mock isn't the important part, but you'll need to make sure that > things think that you're running on 32-bit as otherwise, arch scoring > will want x86_64 pieces. You might be able to get away with just > running the commands under setarch, but setarch + a chroot is safer[1] ... and as Jesse points out, I read your message backwards. There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to work with the current set of tools Jeremy From docs-list at fedoralinks.org Mon May 1 20:10:23 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Mon, 01 May 2006 15:10:23 -0500 Subject: FC5 ISO Re-Spins In-Reply-To: <1146513332.11225.58.camel@orodruin.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> Message-ID: <1146514223.29359.29.camel@cbcclt02.cbcchome.cbccgroup.com> On Mon, 2006-05-01 at 15:55 -0400, Jeremy Katz wrote: > On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote: > > and as Jesse points out, I read your message backwards. > > There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to > work with the current set of tools > > Jeremy > I assume then the same is true for PPC. Thank you all for your input. -- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief Keating 0 Woodhouse 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Mon May 1 20:24:54 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 01 May 2006 21:24:54 +0100 Subject: FC5 ISO Re-Spins In-Reply-To: <1146514223.29359.29.camel@cbcclt02.cbcchome.cbccgroup.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> <1146514223.29359.29.camel@cbcclt02.cbcchome.cbccgroup.com> Message-ID: <1146515095.1921.49.camel@shinybook.infradead.org> On Mon, 2006-05-01 at 15:10 -0500, Robert 'Bob' Jensen wrote: > I assume then the same is true for PPC. It's different for PPC. The PPC32 architecture isn't as crap as i386 -- it actually has a sane number of registers. Therefore you don't really gain much by using 64-bit userspace on a PPC64 machine; on PPC64 we still use mostly PPC32 userspace. So the PPC distro contains PPC64 as a secondary architecture in the same way that the x86_64 distro contains i386 packages. And you _can_ do the buildinstall of that (including ppc64 packages) on a ppc32 host. There _is_ a 'pure ppc64' distro in rawhide, but we don't ship that -- just as we don't ship ia64, s390, etc. -- dwmw2 From jkeating at j2solutions.net Mon May 1 20:35:22 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 01 May 2006 16:35:22 -0400 Subject: FC5 ISO Re-Spins In-Reply-To: <1146515095.1921.49.camel@shinybook.infradead.org> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> <1146514223.29359.29.camel@cbcclt02.cbcchome.cbccgroup.com> <1146515095.1921.49.camel@shinybook.infradead.org> Message-ID: <1146515722.810.99.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-01 at 21:24 +0100, David Woodhouse wrote: > So the PPC distro contains PPC64 as a secondary architecture in the same > way that the x86_64 distro contains i386 packages. And you _can_ do the > buildinstall of that (including ppc64 packages) on a ppc32 host. I think it was more of 'I have to use ppc to compose ppc, I can't do it on i386' question (; -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From docs-list at fedoralinks.org Mon May 1 20:33:53 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Mon, 01 May 2006 15:33:53 -0500 Subject: FC5 ISO Re-Spins In-Reply-To: <1146515095.1921.49.camel@shinybook.infradead.org> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> <1146514223.29359.29.camel@cbcclt02.cbcchome.cbccgroup.com> <1146515095.1921.49.camel@shinybook.infradead.org> Message-ID: <1146515633.29359.32.camel@cbcclt02.cbcchome.cbccgroup.com> On Mon, 2006-05-01 at 21:24 +0100, David Woodhouse wrote: > It's different for PPC. > > The PPC32 architecture isn't as crap as i386 -- it actually has a sane > number of registers. Therefore you don't really gain much by using > 64-bit userspace on a PPC64 machine; on PPC64 we still use mostly PPC32 > userspace. > > So the PPC distro contains PPC64 as a secondary architecture in the same > way that the x86_64 distro contains i386 packages. And you _can_ do the > buildinstall of that (including ppc64 packages) on a ppc32 host. > > There _is_ a 'pure ppc64' distro in rawhide, but we don't ship that -- > just as we don't ship ia64, s390, etc. > > -- > dwmw2 > I was asking about spinning the ISOs for PPC(32) on a PPC(32) -- -- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Mon May 1 20:38:53 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 01 May 2006 21:38:53 +0100 Subject: FC5 ISO Re-Spins In-Reply-To: <1146515722.810.99.camel@dhcp83-49.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> <1146514223.29359.29.camel@cbcclt02.cbcchome.cbccgroup.com> <1146515095.1921.49.camel@shinybook.infradead.org> <1146515722.810.99.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146515934.1921.51.camel@shinybook.infradead.org> On Mon, 2006-05-01 at 16:35 -0400, Jesse Keating wrote: > I think it was more of 'I have to use ppc to compose ppc, I can't do it > on i386' question (; P'raps. Although qemu might help with that. -- dwmw2 From katzj at redhat.com Mon May 1 21:32:00 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 01 May 2006 17:32:00 -0400 Subject: rawhide report: 20060501 changes In-Reply-To: <871wvdd9jt.fsf@mrao.cam.ac.uk> References: <200605010725.k417PDbL027780@porkchop.devel.redhat.com> <871wvdd9jt.fsf@mrao.cam.ac.uk> Message-ID: <1146519120.11225.77.camel@orodruin.boston.redhat.com> On Mon, 2006-05-01 at 11:55 -0400, Chris Ball wrote: > >> On Mon, 1 May 2006 03:25:13, Build System said: > > > kernel-2.6.16-1.2181_FC6 > > ------------------------ > > * Sun Apr 30 2006 Dave Jones > > - 2.6.17rc3-git3 > > > > * Fri Apr 28 2006 Dave Jones > > - 2.6.17rc3-git2 > > > > * Fri Apr 28 2006 David Woodhouse > > - Disable Xen on the basis that it doesn't build > > - Check for Xen tarball being unclean, abort early even on i386. > > 2181 doesn't boot here; it gets to init after finding my lvm groups and > mounting /, but then drops me to a shell after: Actually a bug in mkinitrd, not the kernel. Will be fixed in 5.0.37 (building now-ish) Jeremy From nutello at sweetness.com Mon May 1 22:26:47 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 2 May 2006 00:26:47 +0200 Subject: FC5 ISO Re-Spins In-Reply-To: <1146513332.11225.58.camel@orodruin.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> Message-ID: <20060501222647.GZ445@plain.rackshack.net> On Mon, May 01, 2006 at 03:55:32PM -0400, Jeremy Katz wrote: > There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to > work with the current set of tools Is RHPL at fault here? I thought that was the case with FC4 and previous versions, but I seem to remember that things were supposed to change with FC5. Hold on, I thought you still couldn't do i386 on x86_64, either: is that new in FC5, then? Is this documented anywhere? -- Rudi From docs-list at fedoralinks.org Tue May 2 04:00:54 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Mon, 01 May 2006 23:00:54 -0500 Subject: FC5 ISO Re-Spins In-Reply-To: <1146513332.11225.58.camel@orodruin.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> Message-ID: <1146542454.29359.40.camel@cbcclt02.cbcchome.cbccgroup.com> On Mon, 2006-05-01 at 15:55 -0400, Jeremy Katz wrote: > On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote: > > > > Using mock isn't the important part, but you'll need to make sure that > > things think that you're running on 32-bit as otherwise, arch scoring > > will want x86_64 pieces. You might be able to get away with just > > running the commands under setarch, but setarch + a chroot is safer[1] > > ... > > and as Jesse points out, I read your message backwards. > > There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to > work with the current set of tools > > Jeremy The results are in, my x86_64 updated ISO did build correctly on my x86_64 machine and installed correctly on two so far. Thank you for your time everyone. -- Robert 'Bob' Jensen http://fedoraproject.org/wiki/BobJensen Fedora Documentation Projects Release Notes Editor-in-Chief -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue May 2 04:51:22 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 01 May 2006 23:51:22 -0500 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <20060501111638.7f360f96.zaitcev@redhat.com> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> <20060501111638.7f360f96.zaitcev@redhat.com> Message-ID: <1146545483.26250.8.camel@localhost.localdomain> On Mon, 2006-05-01 at 11:16 -0700, Pete Zaitcev wrote: > On Sun, 30 Apr 2006 15:20:17 +0100, Leon wrote: > > However there is no need for yelp to depend on mozilla. It could > > depend on firefox, right? > > Firefox is not an application suite like Mozilla. It's just a big > binary blob. You cannot use the Firefox's rendering engine in your > application. Actually, Galeon and most other things these days can compile against firefox, but Fedora seems to lack a firefox-devel making such at thing impossible. Firefox's build system was a nightmare last I checked. I attempted to figure out how to get a firefox-devel package built a year or two back... and gave up. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Tue May 2 11:14:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 2 May 2006 13:14:54 +0200 Subject: FC5 ISO Re-Spins In-Reply-To: <1146513332.11225.58.camel@orodruin.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <1146512998.11225.56.camel@orodruin.boston.redhat.com> <1146513332.11225.58.camel@orodruin.boston.redhat.com> Message-ID: <20060502111454.GA5950@neu.nirvana> On Mon, May 01, 2006 at 03:55:32PM -0400, Jeremy Katz wrote: > On Mon, 2006-05-01 at 15:49 -0400, Jeremy Katz wrote: > > On Mon, 2006-05-01 at 14:38 -0500, Robert 'Bob' Jensen wrote: > > > On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote: > > > > Can you show me how it failed on i386? What were your steps, where did > > > > it go boom? Tracebacks or whatnot from the boom? > > > > > > Here is the output at the point of failure > > [snip] > > > Again this is building x86_64 on i386, the instructions used worked for > > > i386 on i386. Instructions are based on > > > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > > > modified and updated for FC5. > > > > > > Should we be using Mock for this as alan pointed out above? > > > > Using mock isn't the important part, but you'll need to make sure that > > things think that you're running on 32-bit as otherwise, arch scoring > > will want x86_64 pieces. You might be able to get away with just > > running the commands under setarch, but setarch + a chroot is safer[1] > > ... > > and as Jesse points out, I read your message backwards. > > There are ways to do i386 on x86_64, but x86_64 on i386 isn't going to > work with the current set of tools I think there may be some confusion in this thread. Some posters define "respin the isos" with "replace the packages with ones from updates and rerun anaconda bits on them", and others define it as "rebuild from src.rpms". For the latter you need arch comaptibility, e.g. i386 can be built on x86_64 (provided you setup sane chroots, use setarch etc.). But the former might not need any special arch considerations. E.g. createrepo, pkgroder and the like only look at rpm headers and hopefully shouldn't care about the actual contents and rpm colors. Is that true? E.g. can I build x86_64 and ppc isos on i386 (provided the packages are already available, e.g. no rebuilds). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From d.lesca at solinos.it Tue May 2 11:50:47 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 02 May 2006 13:50:47 +0200 Subject: fc5: install: boot option: VGA driver i810 Message-ID: <1146570647.3422.518.camel@lesca.home.solinos.it> How to force to anaconda installer the Display driver ? Witch option I must type at the linux: prompt? This help when I install FC5 on a system whit a VGA Intel i810 driven. This driver (i810) not work on many system (or on my system?) Many thanks -- Dario Lesca From david at lovesunix.net Tue May 2 12:55:51 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 02 May 2006 14:55:51 +0200 Subject: [BUG] yelp depends on mozilla? In-Reply-To: <1146545483.26250.8.camel@localhost.localdomain> References: <445467B2.30903@thecodergeek.com> <1146393229.4541.10.camel@animal.passback.co.uk> <1146395413.10326.16.camel@rousalka.dyndns.org> <20060501111638.7f360f96.zaitcev@redhat.com> <1146545483.26250.8.camel@localhost.localdomain> Message-ID: <1146574551.2814.20.camel@localhost.localdomain> man, 01 05 2006 kl. 23:51 -0500, skrev Callum Lerwick: > On Mon, 2006-05-01 at 11:16 -0700, Pete Zaitcev wrote: > > On Sun, 30 Apr 2006 15:20:17 +0100, Leon wrote: > > > However there is no need for yelp to depend on mozilla. It could > > > depend on firefox, right? > > > > Firefox is not an application suite like Mozilla. It's just a big > > binary blob. You cannot use the Firefox's rendering engine in your > > application. > > Actually, Galeon and most other things these days can compile against > firefox, but Fedora seems to lack a firefox-devel making such at thing > impossible. > > Firefox's build system was a nightmare last I checked. I attempted to > figure out how to get a firefox-devel package built a year or two > back... and gave up. Isn't this really what we need XULRunner for? - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jkeating at redhat.com Tue May 2 15:13:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 May 2006 11:13:53 -0400 Subject: development push b0rked last night Message-ID: <1146582833.10316.21.camel@dhcp83-49.boston.redhat.com> I'm working on it to hopefully get a development tree out sometime today. Isn't development fun?! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at lovesunix.net Tue May 2 15:47:13 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 02 May 2006 17:47:13 +0200 Subject: development push b0rked last night In-Reply-To: <1146582833.10316.21.camel@dhcp83-49.boston.redhat.com> References: <1146582833.10316.21.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146584833.2814.29.camel@localhost.localdomain> tir, 02 05 2006 kl. 11:13 -0400, skrev Jesse Keating: > I'm working on it to hopefully get a development tree out sometime > today. Isn't development fun?! You're not allowed fun comrade.. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From philipp_subx at redfish-solutions.com Tue May 2 18:54:18 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Tue, 02 May 2006 12:54:18 -0600 Subject: FC5 kickstart buggered? Message-ID: <4457AADA.5020808@redfish-solutions.com> I was trying to come up with a ks.cfg that I could use to image laptops out here, but after entering a basic configuration with system-config-kickstart and trying to click on Preview, I get: Traceback (most recent call last): File "/usr/share/system-config-kickstart/kickstartGui.py", line 293, in on_activate_preview_options if self.getAllData() != None: File "/usr/share/system-config-kickstart/kickstartGui.py", line 237, in getAllData if self.basic_class.formToKsdata(doInstall) is None: File "/usr/share/system-config-kickstart/basic.py", line 202, in formToKsdata self.ksdata.rootpw["password"] = pure UnboundLocalError: local variable 'pure' referenced before assignment looking at the source, I see: if self.encrypt_root_pw_checkbutton.get_active() == True: pure = self.root_passwd_entry.get_text() salt = "$1$" saltLen = 8 if not pure.startswith(salt): for i in range(saltLen): salt = salt + random.choice (string.letters + string.digits + './') self.passwd = crypt.crypt (pure, salt) temp = unicode (self.passwd, 'iso-8859-1') self.ksdata.rootpw["isCrypted"] = True self.ksdata.rootpw["password"] = temp else: self.ksdata.rootpw["isCrypted"] = True self.ksdata.rootpw["password"] = pure else: self.passwd = self.root_passwd_entry.get_text() self.ksdata.rootpw["password"] = pure and indeed "pure" hasn't been set down this path. Does it just need to be moved outside the "if"? And is this a known issue? Anyone work on kickstart upstream that could file a bug if one hasn't been already? -Philip From philipp_subx at redfish-solutions.com Tue May 2 20:22:47 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Tue, 02 May 2006 14:22:47 -0600 Subject: FC5 kickstart buggered? In-Reply-To: <4457AADA.5020808@redfish-solutions.com> References: <4457AADA.5020808@redfish-solutions.com> Message-ID: <4457BF97.6060305@redfish-solutions.com> Philip Prindeville wrote: > [snip] It seems that moving the assignment of "pure" up a line was the fix. I'll file a defect and post the fix. BTW: Is there a good document on how to explode the FC5 DVD .iso file, add or subtract some files and RPM's, maybe add a ks.cfg file to it, and then put it all back together again? Seems that this would be a handy tool... Thanks, -Philip From buildsys at redhat.com Tue May 2 23:43:11 2006 From: buildsys at redhat.com (Build System) Date: Tue, 2 May 2006 19:43:11 -0400 Subject: rawhide report: 20060502 changes Message-ID: <200605022343.k42NhBXe021259@porkchop.devel.redhat.com> Removed package caching-nameserver Updated Packages: anaconda-11.1.0.6-1 ------------------- * Mon May 01 2006 Jeremy Katz - 11.1.0.6-1 - fix build * Mon May 01 2006 Jeremy Katz - 11.1.0.5-1 - Fix loopback mounted url installs (dcantrel, #189097, #183999) - Different message during upgrade post scripts (clumens, #189312) - Remove obsolete startx stub (clumens) - Default UTC box to checked if we don't find a windows partition (clumens) - Fix manual IP config (clumens) - Don't change timezone in rootpath mode (Jane Dogalt, #185930) - Don't symlink things that don't exist - Don't change network config in rootpath mode (#185930) - Warn on lack of space on upgrade (clumens, #189022) - Emit --useexisting and --noformat in anaconda-ks.cfg (clumens, #189123) - Handle NFS mount options (Dave Lehman, #168384) - Do firewall and auth config in rootpath mode - Make bootloader code handle live cd case apr-1.2.7-3 ----------- * Tue May 02 2006 Joe Orton 1.2.7-3 - fix installbuilddir in apr-1-config * Tue May 02 2006 Joe Orton 1.2.7-2 - update to 1.2.7 - use pkg-config in apr-1-config to make it libdir-agnostic apr-util-1.2.7-2 ---------------- * Tue May 02 2006 Joe Orton 1.2.7-2 - update to 1.2.7 - use pkg-config in apu-1-config to make it libdir-agnostic autofs-1:4.1.4-20 ----------------- * Tue May 02 2006 Ian Kent - 1:4.1.4-20 - add patch to use "cifs" instead of smbfs and escape speces in share names (bz #163999, #187732). avahi-0.6.9-9.FC6 ----------------- * Tue May 02 2006 Jason Vas Dias - 0.6.9-9.FC6 - fix avahi-sharp issues for banshee - patches from caillon at redhat.com * Thu Apr 20 2006 Jason Vas Dias - 0.6.9-9.FC6 - fix bug 189427: correct avahi-resolve --help typo beagle-0.2.6-2 -------------- * Tue May 02 2006 Alexander Larsson - 0.2.6-2 - Update to 0.2.6 bison-2.1-3 ----------- * Mon May 01 2006 Roland McGrath - 2.1-3 - Fix K&R parser definition when it has no arguments (#190376). booty-0.74-1 ------------ * Mon May 01 2006 Jeremy Katz - 0.74=1 - add support for creating an isolinux.cfg for live CD - remove no-longer used edd code - use rhpl instead of butil copies of code - build as noarch now devhelp-0.11-3.1.fc5 -------------------- * Wed Apr 26 2006 Christopher Aillon - 0.11-3.1.fc5 - Rebuild fribidi-0.10.7-2 ---------------- * Tue May 02 2006 Caolan McNamara 0.10.7-2 - base fribidi-config on pkg-config output - allow fribidi_config.h to be the same on 32 and 64 bit gcc-4.1.0-12 ------------ * Mon May 01 2006 Jakub Jelinek 4.1.0-12 - update from gcc-4_1-branch (-r113242:113416) - PRs c++/26534, c++/26912, c++/27094, c++/27278, c++/27279, fortran/26017, libgfortran/20257, libgfortran/27304, libgfortran/27360, libstdc++/26513, middle-end/26565, middle-end/26869, rtl-optimization/26685, target/26826 - merge gomp changes from trunk (-r113255:113256, -r113420:113421) - PRs libgomp/25865, c/27358 - assorted gomp fixes (PRs middle-end/27325, middle-end/27310, middle-end/27328, middle-end/27337, c++/26943) - fix builtin memset (Alan Modra, PR middle-end/27260, PR middle-end/27095) ghostscript-8.15.2-3 -------------------- * Tue May 02 2006 Tim Waugh 8.15.2-3 - Remove adobe-cmaps and acro5-cmaps, since latest CMaps are already included (bug #190463). glibc-kernheaders-3.0-24 ------------------------ * Tue May 02 2006 David Woodhouse 3.0-24 - ... but not quite that much. Put __attribute_const__ back for now. * Tue May 02 2006 David Woodhouse 3.0-23 - Clean up linux/compiler.h gnome-screensaver-2.14.1-3 -------------------------- * Tue May 02 2006 Ray Strode 2.14.1-3 - apply patch from upstream CVS to allow scrolls to unlock the screen (bug 189335) icu-3.4-7 --------- * Tue May 02 2006 Caolan McNamara - 3.4-7 - add a pkgconfig.pc, make icu-config use it k3b-0:0.12.15-1 --------------- * Tue May 02 2006 Harald Hoyer 0:0.12.15-1 - version 0.12.15 * Fri Feb 10 2006 Jesse Keating - 0:0.12.10-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 0:0.12.10-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes kernel-2.6.16-1.2182_FC6 ------------------------ * Mon May 01 2006 Dave Jones - 2.6.17rc3-git4 lftp-3.4.6-1.FC6 ---------------- * Fri Apr 28 2006 Jason Vas Dias - 3.4.6-1 - Upgrade to upstream version 3.4.6 libglade-java-2.12.3-0 ---------------------- * Sat Apr 29 2006 Stepan Kasal - 2.12.3-0 - New version. - Try to build on s390x again. libgnome-java-2.12.2-0 ---------------------- * Tue May 02 2006 Stepan Kasal - 2.12.2-0 - New upstream version. - Fix the (Build)Requires according to the configure.ac. - Try to build on s390x again. libgtk-java-2.8.4-0 ------------------- * Fri Apr 28 2006 Stepan Kasal - 2.8.4-0 - New version, which integrates both patches. - Remove the patches. - Fix typo in %post. - Try to build on s390x again. * Wed Mar 15 2006 Phil Muldoon - 2.8.3.020060301.rh1-2 - Added libgtk-java-glib-timer-gc.patch to fix double free on Timer GC * Tue Mar 14 2006 Adam Jocksch - 2.8.3.0.20060301.rh1-1 - Added GdkCairoFix.patch to address bug in GdkCairo class. libselinux-1.30.3-2 ------------------- * Tue May 02 2006 Dan Walsh 1.30.3-2 - Add selinuxswig fixes - Stop using PAGE_SIZE and start using sysconf(_SC_PAGE_SIZE) libsepol-1.12.6-1 ----------------- * Mon May 01 2006 Dan Walsh 1.12.6-1 - Upgrade to latest from NSA * Fixed cond_normalize to traverse the entire cond list at link time. libwmf-0.2.8.4-6 ---------------- * Tue May 02 2006 Caolan McNamara 0.2.8.4-6 - add a .pc and base libwmf-devel on pkg-config output * Tue Feb 28 2006 Caolan McNamara 0.2.8.4-5 - rh#143096# extra deps according to libwmf-config libxslt-1.1.16-1 ---------------- * Mon May 01 2006 Daniel Veillard - upstream release 1.1.16 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems man-1.6c-3 ---------- * Mon May 01 2006 Ivana Varekova - 1.6c-3 - fix man displaying problem (bug 190287) - thanks JW * Mon Feb 27 2006 Ivana Varekova - 1.6c-2 - fix the encoding of the Bulgarian translation * Fri Feb 10 2006 Jesse Keating - 1.6c-1.2 - bump again for double-long bug on ppc(64) mkinitrd-5.0.37-1 ----------------- * Mon May 01 2006 Jeremy Katz - 5.0.37-1 - munge rootopts on all non-nfs cases mozilla-37:1.7.13-1.1.fc5 ------------------------- * Wed Apr 26 2006 Christopher Aillon - 37:1.7.13-1.1.fc5 - Update to 1.7.13 mysql-5.0.21-1 -------------- * Mon May 01 2006 Tom Lane 5.0.21-1 - Update to MySQL 5.0.21 * Mon Mar 27 2006 Tom Lane 5.0.18-4 - Modify multilib header hack to not break non-RH arches, per bug #181335 - Remove logrotate script, per bug #180639. - Add a new mysql-test RPM to carry the regression test files; hack up test scripts as needed to make them run in /usr/share/mysql-test. * Fri Feb 10 2006 Jesse Keating - 5.0.18-2.1 - bump again for double-long bug on ppc(64) nfs-utils-1.0.8.rc2-5.FC5 ------------------------- * Mon Mar 20 2006 Steve Dickson 1.0.8.rc2-5.FC5 - Fixed typo in nfs initscript (bz 158866) nss_ldap-250-3 -------------- * Tue May 02 2006 Nalin Dahyabhai - 250-3 - update to pam_ldap 182 * Mon May 01 2006 Nalin Dahyabhai - 250-2 - update to pam_ldap 181 - fix syntax error in pam_ldap.c (upstream #269) selinux-policy-2.2.36-2 ----------------------- * Mon May 01 2006 Dan Walsh 2.2.36-2 - Fix libjvm spec * Tue Apr 25 2006 Dan Walsh 2.2.36-1 - Update to upstream smartmontools-1:5.33-8 ---------------------- * Tue May 02 2006 Tomas Mraz - 1:5.33-8 - regenerate smartd.conf on every startup if the config file is autogenerated (#190065) system-config-securitylevel-1.6.19-1 ------------------------------------ * Tue May 02 2006 Chris Lumens 1.6.19-1 - Add a patch to support writing out a default IPv6 firewall (Brad Smith, #140305). * Tue May 02 2006 Chris Lumens 1.6.18-2 - Require glade (#190440). * Wed Apr 19 2006 Dan Walsh 1.6.18-1 - Update booleand/tunable descriptions tzdata-2006f-1 -------------- * Tue May 02 2006 Petr Machata - 2006f-1 - Upstream 2006f - America/Guatemala observes DST between Apr/30 and Oct/1 - Historical changes for Nicaragua - Update of America/Indiana/Vincennes in zone table vim-1:7.0.g001-1 ---------------- * Tue May 02 2006 Karsten Hopp 7.0.g001-1 - vim-7.0g BETA Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 epiphany - 2.14.1-2.i386 requires mozilla = 37:1.7.12 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_match.pl) mysql-test - 5.0.21-1.i386 requires perl(lib::mtr_gprof.pl) Broken deps for ia64 ---------------------------------------------------------- epiphany - 2.14.1-2.ia64 requires mozilla = 37:1.7.12 mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_gprof.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.ia64 requires perl(lib::mtr_match.pl) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- epiphany - 2.14.1-2.ppc requires mozilla = 37:1.7.12 gcc - 4.1.0-12.ppc requires libgomp.so.1()(64bit) gcc-c++ - 4.1.0-12.ppc requires libstdc++.so.6()(64bit) gcc-gfortran - 4.1.0-12.ppc requires libgfortran.so.1()(64bit) gcc-objc - 4.1.0-12.ppc requires libobjc.so.1()(64bit) libmudflap-devel - 4.1.0-12.ppc requires libmudflap.so.0()(64bit) libmudflap-devel - 4.1.0-12.ppc requires libmudflapth.so.0()(64bit) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_match.pl) mysql-test - 5.0.21-1.ppc requires perl(lib::mtr_gprof.pl) Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi epiphany - 2.14.1-2.ppc64 requires mozilla = 37:1.7.12 gcc - 4.1.0-12.ppc64 requires libgomp.so.1 gcc-c++ - 4.1.0-12.ppc64 requires libstdc++.so.6 gcc-gfortran - 4.1.0-12.ppc64 requires libgfortran.so.1 gcc-objc - 4.1.0-12.ppc64 requires libobjc.so.1 geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libmudflap-devel - 4.1.0-12.ppc64 requires libmudflapth.so.0 libmudflap-devel - 4.1.0-12.ppc64 requires libmudflap.so.0 mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_gprof.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.ppc64 requires perl(lib::mtr_match.pl) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 epiphany - 2.14.1-2.s390 requires mozilla = 37:1.7.12 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_match.pl) mysql-test - 5.0.21-1.s390 requires perl(lib::mtr_gprof.pl) rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 epiphany - 2.14.1-2.s390x requires mozilla = 37:1.7.12 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_gprof.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.s390x requires perl(lib::mtr_match.pl) rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 epiphany - 2.14.1-2.x86_64 requires mozilla = 37:1.7.12 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_timer.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_gcov.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_report.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_io.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_misc.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_stress.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_gprof.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_process.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_diff.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_cases.pl) mysql-test - 5.0.21-1.x86_64 requires perl(lib::mtr_match.pl) From ellson at research.att.com Wed May 3 01:34:42 2006 From: ellson at research.att.com (John Ellson) Date: Tue, 02 May 2006 21:34:42 -0400 Subject: rawhide report: 20060502 changes In-Reply-To: <200605022343.k42NhBXe021259@porkchop.devel.redhat.com> References: <200605022343.k42NhBXe021259@porkchop.devel.redhat.com> Message-ID: <445808B2.7090500@research.att.com> Additional broken deps on X86_64 - not listed in announcement: error: Failed dependencies: libgomp.so.1 is needed by gcc-4.1.0-12.x86_64 libstdc++.so.6 is needed by gcc-c++-4.1.0-12.x86_64 libgfortran.so.1 is needed by gcc-gfortran-4.1.0-12.x86_64 libobjc.so.1 is needed by gcc-objc-4.1.0-12.x86_64 From dimi at lattica.com Wed May 3 03:20:11 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 02 May 2006 23:20:11 -0400 Subject: rawhide report: 20060502 changes In-Reply-To: <200605022343.k42NhBXe021259@porkchop.devel.redhat.com> References: <200605022343.k42NhBXe021259@porkchop.devel.redhat.com> Message-ID: <1146626411.15988.0.camel@dimi> On Tue, 2006-05-02 at 19:43 -0400, Build System wrote: > Removed package caching-nameserver So what's the story here? -- Dimi Paun Lattica, Inc. From jkeating at j2solutions.net Wed May 3 03:26:04 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 02 May 2006 23:26:04 -0400 Subject: rawhide report: 20060502 changes In-Reply-To: <1146626411.15988.0.camel@dimi> References: <200605022343.k42NhBXe021259@porkchop.devel.redhat.com> <1146626411.15988.0.camel@dimi> Message-ID: <1146626764.2488.0.camel@ender> On Tue, 2006-05-02 at 23:20 -0400, Dimi Paun wrote: > So what's the story here? Obsoleted by bind-config which provides the config files for doing a caching name server. This happened a while ago, shortly after FC5 released, we just didn't whack the old package. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Wed May 3 07:17:14 2006 From: buildsys at redhat.com (Build System) Date: Wed, 3 May 2006 03:17:14 -0400 Subject: rawhide report: 20060503 changes Message-ID: <200605030717.k437HE9s019184@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.16-1.2185_FC6 ------------------------ * Tue May 02 2006 Dave Jones - 2.6.17rc3-git6 * Tue May 02 2006 Juan Quintela - rebase on linux-2.6 & linux-2.6-xen as of May,1st. - new HV from xen-unstable as of 20060428. - fixed the binaries included on xen tarball :p libgpg-error-1.3-1 ------------------ * Tue May 02 2006 Nalin Dahyabhai - 1.3-1 - update to version 1.3 mysql-5.0.21-2 -------------- * Tue May 02 2006 Tom Lane 5.0.21-2 - Fix bogus perl Requires for mysql-test * Mon May 01 2006 Tom Lane 5.0.21-1 - Update to MySQL 5.0.21 * Mon Mar 27 2006 Tom Lane 5.0.18-4 - Modify multilib header hack to not break non-RH arches, per bug #181335 - Remove logrotate script, per bug #180639. - Add a new mysql-test RPM to carry the regression test files; hack up test scripts as needed to make them run in /usr/share/mysql-test. tog-pegasus-2:2.5.1-4.FC6 ------------------------- * Tue May 02 2006 Jason Vas Dias - 2:2.5.1-4 - fix bug 190432: %exclude /usr/lib/debug from RPM - fix upstream OpenPegasus '2.5.2_APPROVED' bugs, applying upstream patches: o 4955 : Bogus Description property for OperatingSystem provider o 4956 : reserveCapacity method may cause size overflow on invalid input o 4968 : CMPI provider up-calls cause failure with out-of-process o 4978 : snmpDeliverTrap_netsnmp::_createSession function is not thread safe o 4983 : Memory leak in OOP indication generation o 4984 : Forked process hangs in system call o 4986 : Adding automated test for snmpIndication Handler ( http://cvs.opengroup.org/bugzilla/show_bug.cgi?id=? ) - apply upstream update to 'pegasus-2.5.1-warnings.patch' xorg-x11-server-1.0.99.902-1 ---------------------------- * Mon May 01 2006 Adam Jackson 1.0.99.902-1 - Update to 7.1RC2 plus fix for CVE 2006-1526. Disable the fastpathing patch for fdo bug #4320 since that should be covered in the generic Render code now. * Mon Apr 24 2006 Adam Jackson 1.0.99.901-6 - Backport a Render crash fix from HEAD. * Thu Apr 13 2006 Kristian H??gsberg 1.0.99.901-5 - Update spiffiffity patch to only suppress move damage events for manually redirected windows. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 epiphany - 2.14.1-2.i386 requires mozilla = 37:1.7.12 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- epiphany - 2.14.1-2.ia64 requires mozilla = 37:1.7.12 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- epiphany - 2.14.1-2.ppc requires mozilla = 37:1.7.12 gcc - 4.1.0-12.ppc requires libgomp.so.1()(64bit) gcc-c++ - 4.1.0-12.ppc requires libstdc++.so.6()(64bit) gcc-gfortran - 4.1.0-12.ppc requires libgfortran.so.1()(64bit) gcc-objc - 4.1.0-12.ppc requires libobjc.so.1()(64bit) libmudflap-devel - 4.1.0-12.ppc requires libmudflap.so.0()(64bit) libmudflap-devel - 4.1.0-12.ppc requires libmudflapth.so.0()(64bit) Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi epiphany - 2.14.1-2.ppc64 requires mozilla = 37:1.7.12 gcc - 4.1.0-12.ppc64 requires libgomp.so.1 gcc-c++ - 4.1.0-12.ppc64 requires libstdc++.so.6 gcc-gfortran - 4.1.0-12.ppc64 requires libgfortran.so.1 gcc-objc - 4.1.0-12.ppc64 requires libobjc.so.1 geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libmudflap-devel - 4.1.0-12.ppc64 requires libmudflapth.so.0 libmudflap-devel - 4.1.0-12.ppc64 requires libmudflap.so.0 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 epiphany - 2.14.1-2.s390 requires mozilla = 37:1.7.12 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 epiphany - 2.14.1-2.s390x requires mozilla = 37:1.7.12 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 epiphany - 2.14.1-2.x86_64 requires mozilla = 37:1.7.12 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From Axel.Thimm at ATrpms.net Wed May 3 08:20:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 3 May 2006 10:20:35 +0200 Subject: xorg-x11- packaging prefix Message-ID: <20060503082035.GB27035@neu.nirvana> Hi, Should packages with source from outside of the xorg-x11 tree carry this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like often used "for " or is it a cendor prefix, e.g. "by "? How would a 3rd party driver package be best named? xorg-x11-drv- or <3rd-party-vendor>-drv-? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From emeric.maschino at jouy.inra.fr Wed May 3 09:42:37 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Wed, 03 May 2006 11:42:37 +0200 Subject: Filesystem check Message-ID: <1146649357.29023.71.camel@localhost.localdomain> Hi, Has something changed in the manner the filesystems are checked at boot time? Indeed, at startup, once the logical volumes are configured and activated, my filesystem is checked but the check fails with the following message: e2fsck: Cannot continue, aborting. I'm then asked to enter the root password in order to manually check the filesystem. At this stage, the filesystem is already mounted, so I pressed Ctrl-D to continue and my system was rebooted. The strange thing is that, if I boot using a rescue CD in order to run e2fsck on unmounted filesystems, everything is clean. Yesterday, I had the bad idea to finally enter the root password and manually run fsck as requested. Of course, this ended up with a totally corrupted filesystem. Fortunately, my data are on a separate disk. I've then performed a network install of Fedora Core Rawhide during this night (most recent packages dated May 2nd). Everything ran fine, but at boot time, e2fsck is still failing and ask for a manual intervention! Rebooting the system (Windows inside (R)) has no effect. Any hint ? This is on an Itanium workstation (ia64) and I don't know if this problem also appears on other architectures. Many thanks, ?meric From rob at choralone.org Wed May 3 10:47:53 2006 From: rob at choralone.org (Rob Andrews) Date: Wed, 3 May 2006 11:47:53 +0100 Subject: Filesystem check In-Reply-To: <1146649357.29023.71.camel@localhost.localdomain> References: <1146649357.29023.71.camel@localhost.localdomain> Message-ID: <20060503104752.GA28319@testure.choralone.org> On 03-May-2006 10:42.37 (BST), Emeric Maschino wrote: > Indeed, at startup, once the logical volumes are configured and > activated, my filesystem is checked but the check fails with the > following message: > e2fsck: Cannot continue, aborting. [snip] > Yesterday, I had the bad idea to finally enter the root password and > manually run fsck as requested. Of course, this ended up with a totally > corrupted filesystem. [snip] > Any hint ? This is on an Itanium workstation (ia64) and I don't know if > this problem also appears on other architectures. Yeah, I'm seeing this too on an x86_64 machine, so I guess it's not architecture specific. I also have LVM, and an earlier kernel package works Just Fine(tm). I think the version is 2.6.16-1.2157_FC6, but ICBW (I'm relying on memory here). As a future note, I suspect you received filesystem corruption because the filesystem you ran e2fsck upon was mounted at the time. It might help to check /proc/mounts to see if the root filesystem is mounted read/write before running e2fsck by hand, or just perform "mount / -r -o remount" in a blanket fashion before running e2fsck on the root filesystem. -- rob :: pgp 0xb35ff721 :: rob at choralone.org From paul at all-the-johnsons.co.uk Wed May 3 10:51:56 2006 From: paul at all-the-johnsons.co.uk (PFJ) Date: Wed, 03 May 2006 11:51:56 +0100 Subject: Filesystem check In-Reply-To: <20060503104752.GA28319@testure.choralone.org> References: <1146649357.29023.71.camel@localhost.localdomain> <20060503104752.GA28319@testure.choralone.org> Message-ID: <1146653516.23682.13.camel@mrwibble.mrwobble> On Wed, 2006-05-03 at 11:47 +0100, Rob Andrews wrote: > On 03-May-2006 10:42.37 (BST), Emeric Maschino wrote: > > Indeed, at startup, once the logical volumes are configured and > > activated, my filesystem is checked but the check fails with the > > following message: > > e2fsck: Cannot continue, aborting. > [snip] > > Yesterday, I had the bad idea to finally enter the root password and > > manually run fsck as requested. Of course, this ended up with a totally > > corrupted filesystem. > [snip] > > Any hint ? This is on an Itanium workstation (ia64) and I don't know if > > this problem also appears on other architectures. > > Yeah, I'm seeing this too on an x86_64 machine, so I guess it's not > architecture specific. I also have LVM, and an earlier kernel package > works Just Fine(tm). I think the version is 2.6.16-1.2157_FC6, but ICBW > (I'm relying on memory here). This appeared a few days back. If you remove the rhgb quiet from the boot line, you should find it will boot happily - apparently, it's a mkinitrd problem. It's fixed in the current rawhide release though. The problem can be seen on any kernel past 2157 upto 2181 TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From dragoran at feuerpokemon.de Wed May 3 10:58:21 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 03 May 2006 12:58:21 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <20060503082035.GB27035@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> Message-ID: <44588CCD.8090502@feuerpokemon.de> Axel Thimm wrote: > Hi, > > Should packages with source from outside of the xorg-x11 tree carry > this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > often used "for " or is it a cendor prefix, e.g. "by > "? > > How would a 3rd party driver package be best named? > xorg-x11-drv- or <3rd-party-vendor>-drv-? > I would say use xorg-x11-drv- the second one only confuses users. From emeric.maschino at jouy.inra.fr Wed May 3 11:04:01 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Wed, 03 May 2006 13:04:01 +0200 Subject: Filesystem check In-Reply-To: <20060503104752.GA28319@testure.choralone.org> References: <1146649357.29023.71.camel@localhost.localdomain> <20060503104752.GA28319@testure.choralone.org> Message-ID: <1146654241.29023.95.camel@localhost.localdomain> Le mercredi 03 mai 2006 ? 11:47 +0100, Rob Andrews a ?crit : > On 03-May-2006 10:42.37 (BST), Emeric Maschino wrote: > > Indeed, at startup, once the logical volumes are configured and > > activated, my filesystem is checked but the check fails with the > > following message: > > e2fsck: Cannot continue, aborting. > [snip] > > Yesterday, I had the bad idea to finally enter the root password and > > manually run fsck as requested. Of course, this ended up with a totally > > corrupted filesystem. > [snip] > > Any hint ? This is on an Itanium workstation (ia64) and I don't know if > > this problem also appears on other architectures. > > Yeah, I'm seeing this too on an x86_64 machine, so I guess it's not > architecture specific. I also have LVM, and an earlier kernel package > works Just Fine(tm). I think the version is 2.6.16-1.2157_FC6, but ICBW > (I'm relying on memory here). You're right, the latest working kernel appears to be 2157 (see Paul's message in this thread). As an alternative, he also suggests to remove the quiet rhgb option from the boot parameters. I'll try it tonight. Thanks for your help, ?meric From emeric.maschino at jouy.inra.fr Wed May 3 11:05:05 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Wed, 03 May 2006 13:05:05 +0200 Subject: Filesystem check In-Reply-To: <1146653516.23682.13.camel@mrwibble.mrwobble> References: <1146649357.29023.71.camel@localhost.localdomain> <20060503104752.GA28319@testure.choralone.org> <1146653516.23682.13.camel@mrwibble.mrwobble> Message-ID: <1146654305.29023.98.camel@localhost.localdomain> > > > Indeed, at startup, once the logical volumes are configured and > > > activated, my filesystem is checked but the check fails with the > > > following message: > > > e2fsck: Cannot continue, aborting. > > [snip] > > > Yesterday, I had the bad idea to finally enter the root password and > > > manually run fsck as requested. Of course, this ended up with a totally > > > corrupted filesystem. > > [snip] > > > Any hint ? This is on an Itanium workstation (ia64) and I don't know if > > > this problem also appears on other architectures. > > > > Yeah, I'm seeing this too on an x86_64 machine, so I guess it's not > > architecture specific. I also have LVM, and an earlier kernel package > > works Just Fine(tm). I think the version is 2.6.16-1.2157_FC6, but ICBW > > (I'm relying on memory here). > > This appeared a few days back. If you remove the rhgb quiet from the > boot line, you should find it will boot happily - apparently, it's a > mkinitrd problem. It's fixed in the current rawhide release though. > > The problem can be seen on any kernel past 2157 upto 2181 OK, I'll try to remove the quiet option tonight and post the result. Many thanks for your help, ?meric From arjan at fenrus.demon.nl Wed May 3 11:54:17 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 03 May 2006 13:54:17 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <44588CCD.8090502@feuerpokemon.de> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> Message-ID: <1146657258.3122.7.camel@laptopd505.fenrus.org> On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > Axel Thimm wrote: > > Hi, > > > > Should packages with source from outside of the xorg-x11 tree carry > > this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > often used "for " or is it a cendor prefix, e.g. "by > > "? > > > > How would a 3rd party driver package be best named? > > xorg-x11-drv- or <3rd-party-vendor>-drv-? > > > > I would say use > > xorg-x11-drv- > > the second one only confuses users. but xorg-x11 is the name of the upstream vendor, and probably trademarked or close to that. So I would suggest to not do that; even if it's not a legal trademark, it makes sure that users realize where it comes from (and thus where to report bugs ;) > From Axel.Thimm at ATrpms.net Wed May 3 12:10:24 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 3 May 2006 14:10:24 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <1146657258.3122.7.camel@laptopd505.fenrus.org> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> Message-ID: <20060503121024.GI27035@neu.nirvana> On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > > Axel Thimm wrote: > > > Should packages with source from outside of the xorg-x11 tree carry > > > this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > > often used "for " or is it a cendor prefix, e.g. "by > > > "? > > > > > > How would a 3rd party driver package be best named? > > > xorg-x11-drv- or <3rd-party-vendor>-drv-? > > > > > > > I would say use > > > > xorg-x11-drv- > > > > the second one only confuses users. > > but xorg-x11 is the name of the upstream vendor, and probably > trademarked or close to that. So I would suggest to not do that; even if > it's not a legal trademark, it makes sure that users realize where it > comes from (and thus where to report bugs ;) Which brings us back to the question, does the prefix really imply "by " or "for ". Usually in packaging practice "-foo" means foo built for , e.g. the miriads of perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all other module- or plugin-type packages. I don't mind either way, I just want to hear a clear statement from the X11 packaging folks. Personally I tend to hear the sound of the vendor in it, but I see many folks suggesting to use it as a domain prefix. That's why I'm bringing it up. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed May 3 14:13:44 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 03 May 2006 09:13:44 -0500 Subject: xorg-x11- packaging prefix In-Reply-To: <20060503121024.GI27035@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> Message-ID: <4458BA98.8050101@math.unl.edu> Axel Thimm wrote: > Which brings us back to the question, does the prefix really imply "by > " or "for ". Usually in packaging practice > "-foo" means foo built for , e.g. the miriads of > perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > other module- or plugin-type packages. Depending on the context, prefix can imply either by *or* for. In this case, As you already noted, it's already common convention to use -foo to package something for foo, so IMO, stick with xorg-x11-drv-foo -- Rex From notting at redhat.com Wed May 3 14:28:35 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 3 May 2006 10:28:35 -0400 Subject: Filesystem check In-Reply-To: <1146649357.29023.71.camel@localhost.localdomain> References: <1146649357.29023.71.camel@localhost.localdomain> Message-ID: <20060503142835.GC29978@devserv.devel.redhat.com> Emeric Maschino (emeric.maschino at jouy.inra.fr) said: > Hi, > > Has something changed in the manner the filesystems are checked at boot > time? > > Indeed, at startup, once the logical volumes are configured and > activated, my filesystem is checked but the check fails with the > following message: > > e2fsck: Cannot continue, aborting. Grab the new mkinitrd, rebuild your initrd. Sorry about that. :) Bill From krh at redhat.com Wed May 3 15:05:03 2006 From: krh at redhat.com (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=) Date: Wed, 03 May 2006 11:05:03 -0400 Subject: xorg-x11- packaging prefix In-Reply-To: <20060503121024.GI27035@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> Message-ID: <4458C69F.7010308@redhat.com> Axel Thimm wrote: > On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: >> On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: >>> Axel Thimm wrote: >>>> Should packages with source from outside of the xorg-x11 tree carry >>>> this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like >>>> often used "for " or is it a cendor prefix, e.g. "by >>>> "? >>>> >>>> How would a 3rd party driver package be best named? >>>> xorg-x11-drv- or <3rd-party-vendor>-drv-? >>>> >>> I would say use >>> >>> xorg-x11-drv- >>> >>> the second one only confuses users. >> but xorg-x11 is the name of the upstream vendor, and probably >> trademarked or close to that. So I would suggest to not do that; even if >> it's not a legal trademark, it makes sure that users realize where it >> comes from (and thus where to report bugs ;) > > Which brings us back to the question, does the prefix really imply "by > " or "for ". Usually in packaging practice > "-foo" means foo built for , e.g. the miriads of > perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > other module- or plugin-type packages. > > I don't mind either way, I just want to hear a clear statement from > the X11 packaging folks. Personally I tend to hear the sound of the > vendor in it, but I see many folks suggesting to use it as a domain > prefix. That's why I'm bringing it up. It's used in a 'by' sense, notice that we have other out of tree drivers in the distribution already: synaptics and linuxwacom. cheers, Kristian From benjy.grogan at gmail.com Wed May 3 17:33:01 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Wed, 3 May 2006 13:33:01 -0400 Subject: AIGLX packages for FC5 (and rawhide) In-Reply-To: <444696F0.9080801@redhat.com> References: <444696F0.9080801@redhat.com> Message-ID: Hello: I had AIGLX working on FC5 using the aiglx.repo for rstrode's directory. I'm now having problems using this new aiglx.repo. I dropped it into my /etc/yum.repos.d today and now my XServer is kaputt. I get the following messages after a failure to load at GDM. Module Loader Present ... (EE) module ABI minor version (5) is newer than the server's version (4) (EE) Failed to load module "bitmap" (module requirement mismatch, 0) Fatal Server error: Unable to load required base modules, Exiting... Does anyone have any idea what happened? I've got the [updates-testing] repo also activated. I would like to get AIGLX working again. I don't think the experimental screen magnifier was available on the old AIGLX I had running. Benjy On 4/19/06, Kristian H?gsberg wrote: > Hi, > > I've set up a yum repository with AIGLX packages for FC5. It's on > download.fedora.redhat.com: > > http://download.fedora.redhat.com/pub/fedora/projects/aiglx > > and there's a aiglx.repo file there that can be dropped into > /etc/yum.repos.d. With that, > > $ yum --enablerepo=aiglx update > > should pull down the AIGLX package set. The packages are just the > rawhide RPMs rebuilt for FC5, so they're a little rough around the > edges. That said, if the metacity compositor isn't enabled (see below), > things should be pretty stable. > > Here's an overview of the features and tweakable settings in the current > versions of the repository packages. Since rawhide has the same > packages the instructions below can also be used with a recent rawhide > system: > > - metacity with compositing manager functionality. Turn it on using > gconf-editor by enabling /apps/metacity/general/compositing_manager or > alternatively, use > > $ gconftool-2 -s /apps/metacity/general/compositing_manager --type bool > true > > - the metacity build in the repo has wobbly windows as an optional > feature. Set the environment variable USE_WOBBLY to 1 and restart > metacity. For example: > > $ USE_WOBBLY=1 metacity --replace & > > - metacity also has an experimental screen magnifier built in. Like > the wobbly windows this is enabled by setting an environment variable - > USE_MAGNIFIER: > > $ USE_MAGNIFIER=1 metacity --replace & > > - real translucency in gnome-terminal. Enable this by clicking the > "Transparent background" radio box in the "Effects" tab of the termnal > profile editor dialog. gnome-terminal may have to be restarted for this > to take effect - pkill gnome-terminal should do the trick. > > There are a number of known bugs with these packages, so go easy on > bugzilla :). Specifically, > > - The damage events doesn't always kick in, so sometimes window > contents doesn't update properly. A workaround for this is to switch > desktop back and forth. > > - The drop shadows look weird on shaped/argb windows, for example > xeyes, the notify bubbles and well, even the rounded metacity corners. > The shadow code is due for an overhaul later, so we're not going to > patch over this issue in the short term. > > - Perfomance for in-window updates isn't always great. We're > currently doing too much work when updating textures from pixmaps. It's > still possible to optimize this further with the current setup, and > longer term the memory architecture in the X server and DRI stack will > see some changes that will allow us to optimize this further. > > Have fun, > Kristian > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nicolas.mailhot at laposte.net Wed May 3 17:33:31 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 03 May 2006 19:33:31 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <20060503121024.GI27035@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> Message-ID: <1146677614.28311.6.camel@rousalka.dyndns.org> Le mercredi 03 mai 2006 ? 14:10 +0200, Axel Thimm a ?crit : > Which brings us back to the question, does the prefix really imply "by > " or "for ". Usually in packaging practice > "-foo" means foo built for , e.g. the miriads of > perl-XXX packages, now python-XXX, too, java-XXX, There are no miriads of java-XXX precisely because "java" is not a code provider. You *do* have miriads of jakarta-XXX packages because jakarta represents the org which produces the code in question (likewise you have classpathx-XXX packages) I believe the perl-XXXX are close to being a cpan-XXXX synonym. IMHO the prefix means "code closely associated to project foo", either because foo is the upstream project or it's a well-known extension of foo which can easily be found from foo website. But in the end it's a packager preference. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed May 3 17:35:42 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 03 May 2006 19:35:42 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <4458C69F.7010308@redhat.com> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> Message-ID: <1146677745.28311.9.camel@rousalka.dyndns.org> Le mercredi 03 mai 2006 ? 11:05 -0400, Kristian H?gsberg a ?crit : > It's used in a 'by' sense, notice that we have other out of tree drivers > in the distribution already: synaptics and linuxwacom. It's a "for" when there is only one candidate. When there are several competing implementations of the same thing (for example : closed and open radeon drivers) the by must take precedence over the for IMHO. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bojan at rexursive.com Thu May 4 00:12:12 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 04 May 2006 10:12:12 +1000 Subject: Kernel kernel-2.6.16-1.2107_FC5 Message-ID: <20060504101212.7p1taeehr34cwsg4@www.rexursive.com> Just upgraded to this kernel on two boxes today, one is i386 the other x86_64. On i386, I'm having all sorts of problems with dovecot and httpd. Reverting back to 2096, everything returns to normal. Disabling SELinux doesn't help and relevant logs contain nothing useful. Complete mistery to me... On x86_64, the whole IP stack appears broken. I can't even ping 127.0.0.1! Is anyone seeing similar things? -- Bojan From bojan at rexursive.com Thu May 4 00:33:19 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 4 May 2006 00:33:19 +0000 (UTC) Subject: Kernel kernel-2.6.16-1.2107_FC5 References: <20060504101212.7p1taeehr34cwsg4@www.rexursive.com> Message-ID: Bojan Smojver rexursive.com> writes: > Is anyone seeing similar things? OUCH! All over the place: http://tinyurl.com/o7uqj -- Bojan From Axel.Thimm at ATrpms.net Thu May 4 00:39:42 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 May 2006 02:39:42 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <4458C69F.7010308@redhat.com> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> Message-ID: <20060504003942.GA14427@neu.nirvana> On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian H?gsberg wrote: > Axel Thimm wrote: > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > >>>Axel Thimm wrote: > >>>>Should packages with source from outside of the xorg-x11 tree carry > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > >>>>often used "for " or is it a cendor prefix, e.g. "by > >>>>"? > >>>> > >>>>How would a 3rd party driver package be best named? > >>>>xorg-x11-drv- or <3rd-party-vendor>-drv-? > >>>> > >>>I would say use > >>> > >>>xorg-x11-drv- > >>> > >>>the second one only confuses users. > >>but xorg-x11 is the name of the upstream vendor, and probably > >>trademarked or close to that. So I would suggest to not do that; even if > >>it's not a legal trademark, it makes sure that users realize where it > >>comes from (and thus where to report bugs ;) > > > >Which brings us back to the question, does the prefix really imply "by > >" or "for ". Usually in packaging practice > >"-foo" means foo built for , e.g. the miriads of > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > >other module- or plugin-type packages. > > > >I don't mind either way, I just want to hear a clear statement from > >the X11 packaging folks. Personally I tend to hear the sound of the > >vendor in it, but I see many folks suggesting to use it as a domain > >prefix. That's why I'm bringing it up. > > It's used in a 'by' sense, notice that we have other out of tree drivers > in the distribution already: synaptics and linuxwacom. OK, thanks, that was what I was looking for. So oot drivers have free nomenclature (e.g. following the project's name), and when (if) they enter xorg-x11 they become canonicalized to xorg-x11-drv-foo. Maybe I should toss it to fedoraproject.org's wiki somehwere. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu May 4 00:52:54 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 May 2006 02:52:54 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <20060504003942.GA14427@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> Message-ID: <20060504005254.GB14427@neu.nirvana> On Thu, May 04, 2006 at 02:39:42AM +0200, Axel Thimm wrote: > On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian H?gsberg wrote: > > Axel Thimm wrote: > > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > > >>>Axel Thimm wrote: > > >>>>Should packages with source from outside of the xorg-x11 tree carry > > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > >>>>often used "for " or is it a cendor prefix, e.g. "by > > >>>>"? > > >>>> > > >>>>How would a 3rd party driver package be best named? > > >>>>xorg-x11-drv- or <3rd-party-vendor>-drv-? > > >>>> > > >>>I would say use > > >>> > > >>>xorg-x11-drv- > > >>> > > >>>the second one only confuses users. > > >>but xorg-x11 is the name of the upstream vendor, and probably > > >>trademarked or close to that. So I would suggest to not do that; even if > > >>it's not a legal trademark, it makes sure that users realize where it > > >>comes from (and thus where to report bugs ;) > > > > > >Which brings us back to the question, does the prefix really imply "by > > >" or "for ". Usually in packaging practice > > >"-foo" means foo built for , e.g. the miriads of > > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > > >other module- or plugin-type packages. > > > > > >I don't mind either way, I just want to hear a clear statement from > > >the X11 packaging folks. Personally I tend to hear the sound of the > > >vendor in it, but I see many folks suggesting to use it as a domain > > >prefix. That's why I'm bringing it up. > > > > It's used in a 'by' sense, notice that we have other out of tree drivers > > in the distribution already: synaptics and linuxwacom. > > OK, thanks, that was what I was looking for. So oot drivers have free > nomenclature (e.g. following the project's name), and when (if) they > enter xorg-x11 they become canonicalized to xorg-x11-drv-foo. > > Maybe I should toss it to fedoraproject.org's wiki somehwere. I've added an entry to http://fedoraproject.org/wiki/Packaging/NamingGuidelines "Addon Packages (x11 drivers)" -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From benjy.grogan at gmail.com Thu May 4 04:29:45 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 4 May 2006 00:29:45 -0400 Subject: AIGLX breaks XServer with new Repo Message-ID: Hello, I had AIGLX working on FC5 using the old aiglx.repo that pointed to Ray Strode's repo. I recently dropped in the new aiglx.repo that Kristian Hogsberg posted a few weeks ago and the result was that my XServer won't start anymore. I seem to have a module requirement mismatch for the X.org module "bitmap". I don't know what that is, so maybe someone here can help me. Here are the rpms from /var/log/yum.log that broke my system and following is my /var/log/Xorg.0.log that shows the problem. May 03 12:56:46 Updated: xorg-x11-server-Xorg.i386 1.0.99.901-3 May 03 12:57:05 Updated: libXcomposite.i386 0.3-4 May 03 12:57:06 Updated: libdrm.i386 2.0.1-2 May 03 12:57:10 Updated: mesa-libGL.i386 6.5-5 May 03 12:57:11 Updated: mesa-libGLU.i386 6.5-5 May 03 12:57:12 Updated: mesa-libGL-devel.i386 6.5-5 May 03 12:57:25 Updated: metacity.i386 2.15.0-6 May 03 12:57:28 Updated: libdrm-devel.i386 2.0.1-2 May 03 12:57:29 Updated: glx-utils.i386 6.5-5 May 03 12:57:30 Updated: xorg-x11-drv-ati.i386 6.6.0-2 May 03 12:57:31 Updated: xorg-x11-drv-i810.i386 1.6.0-2 May 03 12:57:31 Updated: libXcomposite-devel.i386 0.3-4 May 03 12:57:37 Updated: gtk2-engines.i386 2.7.4-5 May 03 12:57:40 Updated: xorg-x11-proto-devel.i386 7.0-11 May 03 12:57:49 Updated: gnome-terminal.i386 2.14.1-7 /var/log/Xorg.0.log: X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.15-1.1948_FC5 i686Red Hat, Inc. Current Operating System: Linux localhost.localdomain 2.6.16-1.2107_FC5smp #1 SMP Tue May 2 19:18:41 EDT 2006 i686 Build Date: 22 February 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu May 4 00:01:19 2006 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "single head configuration" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) FontPath set to "unix/:7100" (==) RgbPath set to "/usr/share/X11/rgb" (==) ModulePath set to "/usr/lib/xair/modules" (**) Extension "Composite" is enabled (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.8 X.Org XInput driver : 0.5 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/lib/xair/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 7.0.0, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (EE) module ABI minor version (5) is newer than the server's version (4) (II) UnloadModule: "bitmap" (II) Unloading /usr/lib/xair/modules/fonts/libbitmap.so (EE) Failed to load module "bitmap" (module requirement mismatch, 0) (II) LoadModule: "pcidata" (II) Loading /usr/lib/xair/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 7.0.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.8 Fatal server error: Unable to load required base modules, Exiting... (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor From fedora at leemhuis.info Thu May 4 04:50:21 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 04 May 2006 06:50:21 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <20060504005254.GB14427@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> Message-ID: <1146718221.4263.10.camel@thl.ct.heise.de> Am Donnerstag, den 04.05.2006, 02:52 +0200 schrieb Axel Thimm: > On Thu, May 04, 2006 at 02:39:42AM +0200, Axel Thimm wrote: > > On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian H?gsberg wrote: > > > Axel Thimm wrote: > > > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > > > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > > > >>>Axel Thimm wrote: > > > >>>>Should packages with source from outside of the xorg-x11 tree carry > > > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > > >>>>often used "for " or is it a cendor prefix, e.g. "by > > > >>>>"? > > > >>>> > > > >>>>How would a 3rd party driver package be best named? > > > >>>>xorg-x11-drv- or <3rd-party-vendor>-drv-? > > > >>>> > > > >>>I would say use > > > >>> > > > >>>xorg-x11-drv- > > > >>> > > > >>>the second one only confuses users. > > > >>but xorg-x11 is the name of the upstream vendor, and probably > > > >>trademarked or close to that. So I would suggest to not do that; even if > > > >>it's not a legal trademark, it makes sure that users realize where it > > > >>comes from (and thus where to report bugs ;) > > > > > > > >Which brings us back to the question, does the prefix really imply "by > > > >" or "for ". Usually in packaging practice > > > >"-foo" means foo built for , e.g. the miriads of > > > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > > > >other module- or plugin-type packages. > > > >I don't mind either way, I just want to hear a clear statement from > > > >the X11 packaging folks. Personally I tend to hear the sound of the > > > >vendor in it, but I see many folks suggesting to use it as a domain > > > >prefix. That's why I'm bringing it up. > > > It's used in a 'by' sense, notice that we have other out of tree drivers > > > in the distribution already: synaptics and linuxwacom. > > OK, thanks, that was what I was looking for. So oot drivers have free > > nomenclature (e.g. following the project's name), and when (if) they > > enter xorg-x11 they become canonicalized to xorg-x11-drv-foo. > > Maybe I should toss it to fedoraproject.org's wiki somehwere. > I've added an entry to > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > "Addon Packages (x11 drivers)" No offense, but I removed it again. Changes to these kind of documents are best (read "best" -- not "have to be") discussed with FESCo, on fedora-packaging and/or with spot, the original author and maintainer of this document and the Packaging Guidelines in general. BTW: Shortly before FC5 was released there was a irc-discussion regarding the package naming of the proprietary nvidia and fglrx drivers. It was on #fedora-extras (spot was involved in that discussion, too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg drivers". And that's what livna did for FC5 then. We should probably discuss this during the next FESCo-Meeting with spot. CU thl From peter.bieshaar at gmail.com Thu May 4 06:45:15 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Thu, 4 May 2006 08:45:15 +0200 Subject: layout of FC5 (and previous) CD's Message-ID: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> First I am wondering the strategy the rpm's are put on the different CDs. On a previous test I had to do something with openldap, which is on CD5, with a dependency on libtools, which is on CD2. Now I'm doing a mysql installation which was found fast at CD2, but still some dependent rpm's are on other CDs. I once worked with a guy who constructed a dependency tree on a Solaris jumpstart. For example when an Oracle had to be on a system the DBD.Oracleand the DBI should also be on the system (this is just meant as an example). In other words what I'm suggesting, under the Fedoro/RPMS directory, is differentiating rpm-trees based on functionality and dependencies: (base|extras)/(development|web|office|etc..). Darkside is a major extention of the comps.xml file and loads of initial work. Brightside however is maintainablity and more friendly post-installation when a FC# is installed. I'm wondering if: - this is a good idea - this is something to do with future Fedora distributions Peter Bieshaar -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at all-the-johnsons.co.uk Thu May 4 07:12:47 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 04 May 2006 08:12:47 +0100 Subject: AIGLX breaks XServer with new Repo In-Reply-To: References: Message-ID: <1146726767.31421.31.camel@T7.Linux> Hi, On Thu, 2006-05-04 at 00:29 -0400, Benjy Grogan wrote: > I recently dropped in the new aiglx.repo that > Kristian Hogsberg posted a few weeks ago and the result was that my > XServer won't start anymore. I'm still using the Ray's old repo - what are the details for the new one? TTFN Paul -- Computer sind Klimaanlagen sehr ?hnlich: beide funktionieren, es sei denn man ?ffnet die Fenster -------------- 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 benjy.grogan at gmail.com Thu May 4 07:18:31 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 4 May 2006 03:18:31 -0400 Subject: AIGLX breaks XServer with new Repo In-Reply-To: <1146726767.31421.31.camel@T7.Linux> References: <1146726767.31421.31.camel@T7.Linux> Message-ID: On 5/4/06, Paul wrote: > Hi, > > On Thu, 2006-05-04 at 00:29 -0400, Benjy Grogan wrote: > > I recently dropped in the new aiglx.repo that > > Kristian Hogsberg posted a few weeks ago and the result was that my > > XServer won't start anymore. > > I'm still using the Ray's old repo - what are the details for the new > one? In Kristian H?gsberg's words: Benjy > > TTFN > > Paul > -- > Computer sind Klimaanlagen sehr ?hnlich: beide funktionieren, es sei > denn man ?ffnet die Fenster > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBEWalv3tjMTq6WnnQRAvPAAJ90BLNxN9Kpyeh5htFCb8g9AqNslwCZAcLt > YdPD7KaTjyC53bKo+L9IS+0= > =yaI/ > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From arjan at fenrus.demon.nl Thu May 4 07:35:05 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 04 May 2006 09:35:05 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> Message-ID: <1146728106.3101.19.camel@laptopd505.fenrus.org> On Thu, 2006-05-04 at 08:45 +0200, Peter Bieshaar wrote: > First I am wondering the strategy the rpm's are put on the different > CDs. I suspect it's primarily about "don't have dependencies on packages on a future CD", so that during installation you never need to go back to an older CD. Beyond that I suspect there is a goal built in to have a basic install only use one or two cds... From peter.bieshaar at gmail.com Thu May 4 08:12:53 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Thu, 4 May 2006 10:12:53 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <1146728106.3101.19.camel@laptopd505.fenrus.org> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> Message-ID: <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> I didn't mean previous FC CDs. But keeping rpm's more structured on CD's. So keep the dependent rpm's at least on the same CD. Just did a mysql server installation, needed 2 CDs. What I "felt" in your words (and saw in previous discussions) is that future FC releases RPMs will have less or no dependencies. That is another solution of-course, but IMHO harder to maintain in later future. The later: only 2CDs, would be great. But is it known what FC users are using? 2006/5/4, Arjan van de Ven : > > On Thu, 2006-05-04 at 08:45 +0200, Peter Bieshaar wrote: > > First I am wondering the strategy the rpm's are put on the different > > CDs. > > I suspect it's primarily about "don't have dependencies on packages on a > future CD", so that during installation you never need to go back to an > older CD. > > Beyond that I suspect there is a goal built in to have a basic install > only use one or two cds... > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Peter Bieshaar NL(0)6 29577255 use this or: peter at bieshaar.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjan at fenrus.demon.nl Thu May 4 08:19:58 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 04 May 2006 10:19:58 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> Message-ID: <1146730799.3101.27.camel@laptopd505.fenrus.org> On Thu, 2006-05-04 at 10:12 +0200, Peter Bieshaar wrote: > I didn't mean previous FC CDs. But keeping rpm's more structured on > CD's. So keep the dependent rpm's at least on the same CD. Just did > a mysql server installation, needed 2 CDs. how do you do that with.. say a dependency on glibc? From tmus at tmus.dk Thu May 4 08:25:03 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 04 May 2006 10:25:03 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> Message-ID: Peter Bieshaar wrote: > I didn't mean previous FC CDs. But keeping rpm's more structured on > CD's. So keep the dependent rpm's at least on the same CD. Just did > a mysql server installation, needed 2 CDs. > The thing is that although this is inconvenient for you in this case, chances are that other packages are depending on some of the same libs and it may be hard to fit everything that have interdependencies on a single disc, as long as FC is as large as it is atm. /Thomas From Axel.Thimm at ATrpms.net Thu May 4 08:34:45 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 4 May 2006 10:34:45 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <1146718221.4263.10.camel@thl.ct.heise.de> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> <1146718221.4263.10.camel@thl.ct.heise.de> Message-ID: <20060504083445.GC22088@neu.nirvana> On Thu, May 04, 2006 at 06:50:21AM +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 04.05.2006, 02:52 +0200 schrieb Axel Thimm: > > On Thu, May 04, 2006 at 02:39:42AM +0200, Axel Thimm wrote: > > > On Wed, May 03, 2006 at 11:05:03AM -0400, Kristian H?gsberg wrote: > > > > Axel Thimm wrote: > > > > >On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: > > > > >>On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: > > > > >>>Axel Thimm wrote: > > > > >>>>Should packages with source from outside of the xorg-x11 tree carry > > > > >>>>this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > > > > >>>>often used "for " or is it a cendor prefix, e.g. "by > > > > >>>>"? > > > > >>>> > > > > >>>>How would a 3rd party driver package be best named? > > > > >>>>xorg-x11-drv- or <3rd-party-vendor>-drv-? > > > > >>>> > > > > >>>I would say use > > > > >>> > > > > >>>xorg-x11-drv- > > > > >>> > > > > >>>the second one only confuses users. > > > > >>but xorg-x11 is the name of the upstream vendor, and probably > > > > >>trademarked or close to that. So I would suggest to not do that; even if > > > > >>it's not a legal trademark, it makes sure that users realize where it > > > > >>comes from (and thus where to report bugs ;) > > > > > > > > > >Which brings us back to the question, does the prefix really imply "by > > > > >" or "for ". Usually in packaging practice > > > > >"-foo" means foo built for , e.g. the miriads of > > > > >perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > > > > >other module- or plugin-type packages. > > > > >I don't mind either way, I just want to hear a clear statement from > > > > >the X11 packaging folks. Personally I tend to hear the sound of the > > > > >vendor in it, but I see many folks suggesting to use it as a domain > > > > >prefix. That's why I'm bringing it up. > > > > It's used in a 'by' sense, notice that we have other out of tree drivers > > > > in the distribution already: synaptics and linuxwacom. > > > OK, thanks, that was what I was looking for. So oot drivers have free > > > nomenclature (e.g. following the project's name), and when (if) they > > > enter xorg-x11 they become canonicalized to xorg-x11-drv-foo. > > > Maybe I should toss it to fedoraproject.org's wiki somehwere. > > I've added an entry to > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines > > > > "Addon Packages (x11 drivers)" > > No offense, but I removed it again. Changes to these kind of documents > are best (read "best" -- not "have to be") discussed with FESCo, on > fedora-packaging and/or with spot, the original author and maintainer of > this document and the Packaging Guidelines in general. No problem, discuss it in FESCo and then add it again. :) I've added fedora-packaging and spot in the Cc. > BTW: Shortly before FC5 was released there was a irc-discussion > regarding the package naming of the proprietary nvidia and fglrx > drivers. It was on #fedora-extras (spot was involved in that discussion, > too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg > drivers". And that's what livna did for FC5 then. > > We should probably discuss this during the next FESCo-Meeting with spot. We know that Fedora Extras and Fedora Core don't yet have identical packaging rules, but they are converging. Wrt new packaging rules one should discuss it with both sides, e.g. ask the x11 maintainers at FC who introduced that prefix what the purpose of the prefix is like done in this thread. Creating new divergent views isn't helpful, I'd say either convince FC's x11 folks to change their mind or follow along. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From emeric.maschino at jouy.inra.fr Thu May 4 08:49:34 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Thu, 04 May 2006 10:49:34 +0200 Subject: Filesystem check In-Reply-To: <1146649357.29023.71.camel@localhost.localdomain> References: <1146649357.29023.71.camel@localhost.localdomain> Message-ID: <1146732574.32373.9.camel@localhost.localdomain> > Has something changed in the manner the filesystems are checked at boot > time? > > Indeed, at startup, once the logical volumes are configured and > activated, my filesystem is checked but the check fails with the > following message: > > e2fsck: Cannot continue, aborting. > > I'm then asked to enter the root password in order to manually check the > filesystem. At this stage, the filesystem is already mounted, so I > pressed Ctrl-D to continue and my system was rebooted. > > The strange thing is that, if I boot using a rescue CD in order to run > e2fsck on unmounted filesystems, everything is clean. > > Yesterday, I had the bad idea to finally enter the root password and > manually run fsck as requested. Of course, this ended up with a totally > corrupted filesystem. Fortunately, my data are on a separate disk. I've > then performed a network install of Fedora Core Rawhide during this > night (most recent packages dated May 2nd). Everything ran fine, but at > boot time, e2fsck is still failing and ask for a manual intervention! > Rebooting the system (Windows inside (R)) has no effect. > > Any hint ? This is on an Itanium workstation (ia64) and I don't know if > this problem also appears on other architectures. Removing the rhgb quiet boot options as suggested by Paul allowed me to log in (but you need to cancel the filesystem check when asked for the root password). As stated by Bill Nottingham, updating to the latest mkinitrd and rebuilding the initrd image definitely solved the problem (the rhgb quiet boot options can be passed again to the kernel). Many thanks to all, ?meric From peter.bieshaar at gmail.com Thu May 4 08:50:03 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Thu, 4 May 2006 10:50:03 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> Message-ID: <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> I agree this is inconvenient for me ;) That's why I tried to suggest a solution for my inconvenience. All I suggested is to have dependent packages on the same disk, which I think could be done. 2006/5/4, Thomas M Steenholdt : > > Peter Bieshaar wrote: > > I didn't mean previous FC CDs. But keeping rpm's more structured on > > CD's. So keep the dependent rpm's at least on the same CD. Just did > > a mysql server installation, needed 2 CDs. > > > > The thing is that although this is inconvenient for you in this case, > chances are that other packages are depending on some of the same libs > and it may be hard to fit everything that have interdependencies on a > single disc, as long as FC is as large as it is atm. > > /Thomas > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Peter Bieshaar NL(0)6 29577255 use this or: peter at bieshaar.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From emeric.maschino at jouy.inra.fr Thu May 4 09:03:27 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Thu, 04 May 2006 11:03:27 +0200 Subject: Cannot log in to a GNOME desktop Message-ID: <1146733408.32373.22.camel@localhost.localdomain> Hi, What can prevent a user to log in a GNOME session? When entering my username and password at the GDM log in screen, I immediately get a dialog box telling me that the X session lasts less than 10 sec and that some help can be provided by the ~/.xsession_error. Well, this file doesn't even exist. I've tried the "Last session" and "Default GNOME session" options in the GDM log in screen without a success. Same problem for root. This is on an Itanium workstation (ia64) with a fresh install of Fedora Core Rawhide on May 2nd, updated with the latest packages. I don't know if this problem also appears on other architectures. Roughly a month ago (before my filesystem problem), I didn't have this problem. But a lot of things have changed since... Cheers, ?meric From peter.bieshaar at gmail.com Thu May 4 09:05:16 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Thu, 4 May 2006 11:05:16 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <1146730799.3101.27.camel@laptopd505.fenrus.org> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <1146730799.3101.27.camel@laptopd505.fenrus.org> Message-ID: <529f9df20605040205m52fffe08p4372168be60fcff5@mail.gmail.com> glibc is used by init, so quite essential and very base. The glibc dependency therefore is not part of my suggestion and initial idea. It's more a discussion openldap depends on libtools, mysql-server depends on perl-DBD which depends on mysql, whereas perl-DBI (as far as I saw) is not dependent but nice to have when perl is used to enter a mysql database. So in the first example TRY to keep these 2 rpms on same CD and the later keep these 3 RPMs with a relationship on another CD. Maybe the word dependancy should be s/.../(relationship|relation to)/ 2006/5/4, Arjan van de Ven : > > On Thu, 2006-05-04 at 10:12 +0200, Peter Bieshaar wrote: > > I didn't mean previous FC CDs. But keeping rpm's more structured on > > CD's. So keep the dependent rpm's at least on the same CD. Just did > > a mysql server installation, needed 2 CDs. > > how do you do that with.. say a dependency on glibc? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Peter Bieshaar NL(0)6 29577255 use this or: peter at bieshaar.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.thery at bull.net Thu May 4 09:20:46 2006 From: benjamin.thery at bull.net (Benjamin Thery) Date: Thu, 04 May 2006 11:20:46 +0200 Subject: Old Flex version in FC5? Message-ID: <4459C76E.30705@bull.net> Hello, I use Fedora Core 5 to test Mobile IPv6 on Linux. In a recent version of the mobility daemon source code a change made to a lex file make the build failson FC5. This changes introduced some flex options to reduce warnings output during compilation. To my surprise these options are not supported by the current flex version shipped with FC5. I found it strange because FC5 is very recent. Then, googling a bit, I discovered that flex state seems a bit confusing: - Fedora ships 2.5.4a (released in 1997) - Gentoo has 2.5.33 - Debian has two different packages flex-old (2.5.4a) and flex (2.5.33) My question is: why does Fedora ships flex 2.5.4a and not a more recent one? What are the mysteries behind flex versioning? Thanks, Benjamin From jos at xos.nl Thu May 4 10:36:20 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 04 May 2006 12:36:20 +0200 Subject: Proposal for adding kernel <-> xen dependency Message-ID: <200605041036.k44AaK507467@xos037.xos.nl> Hi, Today I saw that installing "xen" does not automatically pull in kernel-xen0. Shouldn't that ideally be the case? Furthermore, not any combination of kernel-xen0 and xen is valid, AFAIK, so just "Requires: kernel-xen0" would not be good enough. Proposal: Use a pseudo-package "xen-kernel" for enforcing the dependency: - Add a "Provides: xen-kernel = 3.0.1" (or whatever the included Xen version is) to the kernel-xen0 package. - Add a "Requires: xen-kernel = 3.0.1" (or whatever the required kernel part is, maybe >= is ok too) to the xen package. Does that sounds sensible? Comments? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From arjan at fenrus.demon.nl Thu May 4 11:00:56 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 04 May 2006 13:00:56 +0200 Subject: Proposal for adding kernel <-> xen dependency In-Reply-To: <200605041036.k44AaK507467@xos037.xos.nl> References: <200605041036.k44AaK507467@xos037.xos.nl> Message-ID: <1146740457.3101.31.camel@laptopd505.fenrus.org> On Thu, 2006-05-04 at 12:36 +0200, Jos Vos wrote: > Hi, > > Today I saw that installing "xen" does not automatically pull in > kernel-xen0. Shouldn't that ideally be the case? why would a userspace optional thing force a xen kernel? From mailinglists at erwinrol.com Thu May 4 11:24:21 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 04 May 2006 13:24:21 +0200 Subject: libusb scanner Message-ID: <1146741861.2630.12.camel@xpc.home.erwinrol.com> I have a (old) HP6300C USB scanner, that used to work with a usbscanner (or was that hpscanner?) kernel module. That kernel module is gone, now xsane and kooka only can use it via libusb. The problem is this only seems to work when i am root. Is there a way to let normal users use the scanner? - Erwin From jos at xos.nl Thu May 4 11:25:13 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 4 May 2006 13:25:13 +0200 Subject: Proposal for adding kernel <-> xen dependency In-Reply-To: <1146740457.3101.31.camel@laptopd505.fenrus.org>; from arjan@fenrus.demon.nl on Thu, May 04, 2006 at 01:00:56PM +0200 References: <200605041036.k44AaK507467@xos037.xos.nl> <1146740457.3101.31.camel@laptopd505.fenrus.org> Message-ID: <20060504132513.A7640@xos037.xos.nl> On Thu, May 04, 2006 at 01:00:56PM +0200, Arjan van de Ven wrote: > why would a userspace optional thing force a xen kernel? Because the userspace thing needs that kernel to be used? B.t.w., if you don't want to force the pull, you can still add version dependencies like: kernel-xen0: Provides: xen-kernel = 3.0.1 xen: Conflicts: xen-kernel != 3.0.1 -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From arjan at fenrus.demon.nl Thu May 4 11:33:34 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 04 May 2006 13:33:34 +0200 Subject: Proposal for adding kernel <-> xen dependency In-Reply-To: <20060504132513.A7640@xos037.xos.nl> References: <200605041036.k44AaK507467@xos037.xos.nl> <1146740457.3101.31.camel@laptopd505.fenrus.org> <20060504132513.A7640@xos037.xos.nl> Message-ID: <1146742414.3101.33.camel@laptopd505.fenrus.org> On Thu, 2006-05-04 at 13:25 +0200, Jos Vos wrote: > On Thu, May 04, 2006 at 01:00:56PM +0200, Arjan van de Ven wrote: > > > why would a userspace optional thing force a xen kernel? > > Because the userspace thing needs that kernel to be used? similar to reiserfstools needs a reiserfs to do something? (and a dependency on a kernel to be installed doesn't mean that kernel is running, which is another issue ;) From jakub at redhat.com Thu May 4 11:52:46 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 4 May 2006 07:52:46 -0400 Subject: Proposal for adding kernel <-> xen dependency In-Reply-To: <1146742414.3101.33.camel@laptopd505.fenrus.org> References: <200605041036.k44AaK507467@xos037.xos.nl> <1146740457.3101.31.camel@laptopd505.fenrus.org> <20060504132513.A7640@xos037.xos.nl> <1146742414.3101.33.camel@laptopd505.fenrus.org> Message-ID: <20060504115245.GE14147@devserv.devel.redhat.com> On Thu, May 04, 2006 at 01:33:34PM +0200, Arjan van de Ven wrote: > On Thu, 2006-05-04 at 13:25 +0200, Jos Vos wrote: > > On Thu, May 04, 2006 at 01:00:56PM +0200, Arjan van de Ven wrote: > > > > > why would a userspace optional thing force a xen kernel? > > > > Because the userspace thing needs that kernel to be used? > > similar to reiserfstools needs a reiserfs to do something? > > (and a dependency on a kernel to be installed doesn't mean that kernel > is running, which is another issue ;) And conflict with all kernel that provide different Xen NVR will mean that whenever you have two kernels installed and they have different versions, even if you are running the one with the matching Xen interface, xen can't be installed at all. Jakub From jos at xos.nl Thu May 4 12:09:13 2006 From: jos at xos.nl (Jos Vos) Date: Thu, 4 May 2006 14:09:13 +0200 Subject: Proposal for adding kernel <-> xen dependency In-Reply-To: <20060504115245.GE14147@devserv.devel.redhat.com>; from jakub@redhat.com on Thu, May 04, 2006 at 07:52:46AM -0400 References: <200605041036.k44AaK507467@xos037.xos.nl> <1146740457.3101.31.camel@laptopd505.fenrus.org> <20060504132513.A7640@xos037.xos.nl> <1146742414.3101.33.camel@laptopd505.fenrus.org> <20060504115245.GE14147@devserv.devel.redhat.com> Message-ID: <20060504140913.A7756@xos037.xos.nl> On Thu, May 04, 2006 at 07:52:46AM -0400, Jakub Jelinek wrote: > And conflict with all kernel that provide different Xen NVR > will mean that whenever you have two kernels installed and they have > different versions, even if you are running the one with the matching > Xen interface, xen can't be installed at all. Yes, using conflicts was a bad idea. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rdieter at math.unl.edu Thu May 4 12:33:14 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 04 May 2006 07:33:14 -0500 Subject: Old Flex version in FC5? In-Reply-To: <4459C76E.30705@bull.net> References: <4459C76E.30705@bull.net> Message-ID: <4459F48A.6070901@math.unl.edu> Benjamin Thery wrote: > My question is: why does Fedora ships flex 2.5.4a and not a more recent > one? Probably at least 1 of: * If it aint broke, don't fix it * No one has asked File an update request against Fedora Core/flex at http://bugzilla.redhat.com/ -- Rex From rc040203 at freenet.de Thu May 4 12:40:22 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 May 2006 14:40:22 +0200 Subject: Old Flex version in FC5? In-Reply-To: <4459F48A.6070901@math.unl.edu> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> Message-ID: <1146746422.5294.100.camel@mccallum.corsepiu.local> On Thu, 2006-05-04 at 07:33 -0500, Rex Dieter wrote: > Benjamin Thery wrote: > > > My question is: why does Fedora ships flex 2.5.4a and not a more recent > > one? > > Probably at least 1 of: > * If it aint broke, don't fix it > * No one has asked * Many flex versions > 2.5.4a had been too broken to be usable * Many flex versions > 2.5.4a had been too incompatible to flex-2.5.x * Many major packages have not been prepared for flex > 2.5.x > File an update request against Fedora Core/flex at > http://bugzilla.redhat.com/ Ralf From cjb at mrao.cam.ac.uk Thu May 4 14:09:17 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Thu, 04 May 2006 10:09:17 -0400 Subject: Proposal for adding kernel <-> xen dependency References: <200605041036.k44AaK507467@xos037.xos.nl> Message-ID: <87lkth51bm.fsf@mrao.cam.ac.uk> >> On Thu, 04 May 2006 12:36:20 +0200, Jos Vos said: > Hi, Today I saw that installing "xen" does not automatically pull > in kernel-xen0. Shouldn't that ideally be the case? Orthogonal to the dependency issue, we don't have kernel-xen0 packages in Rawhide; the GIT tree Xen rebases to (-stable) and the GIT tree the Rawhide kernel rebases to (-git) are two moving targets that aren't going to apply against each other cleanly. So, we're left without a Xen kernel until we get close enough to a release for someone to care enough to make the patch apply by hand. This seems to be one of those annoying problems that can't be solved even when you have an obscenely powerful SCM available. :) We could try to have someone volunteer to manually get the Xen patch applying against davej's tree each day, but even that sounds implausible due to the tight deadlines we're already pushing with the build system. I haven't seen any list discussion about this, so maybe this is a good time for some -- does anyone have plans for getting Xen kernels into Rawhide? Thanks, -- Chris Ball From arjan at fenrus.demon.nl Thu May 4 14:30:04 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 04 May 2006 16:30:04 +0200 Subject: Proposal for adding kernel <-> xen dependency In-Reply-To: <87lkth51bm.fsf@mrao.cam.ac.uk> References: <200605041036.k44AaK507467@xos037.xos.nl> <87lkth51bm.fsf@mrao.cam.ac.uk> Message-ID: <1146753004.3101.44.camel@laptopd505.fenrus.org> On Thu, 2006-05-04 at 10:09 -0400, Chris Ball wrote: > >> On Thu, 04 May 2006 12:36:20 +0200, Jos Vos said: > > > Hi, Today I saw that installing "xen" does not automatically pull > > in kernel-xen0. Shouldn't that ideally be the case? > > Orthogonal to the dependency issue, we don't have kernel-xen0 packages > in Rawhide; the GIT tree Xen rebases to (-stable) and the GIT tree the > Rawhide kernel rebases to (-git) are two moving targets that aren't > going to apply against each other cleanly. So, we're left without a > Xen kernel until we get close enough to a release for someone to care > enough to make the patch apply by hand. > I haven't seen any list discussion about this, so maybe this is a > good time for some -- does anyone have plans for getting Xen kernels > into Rawhide? until the Xen people get their act together (eg base on -git and not on ancient -stable kernels, and like actually tries to make any effort to work with upstream) it will be an endless chase without a winner. From rdieter at math.unl.edu Thu May 4 14:30:31 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 04 May 2006 09:30:31 -0500 Subject: Old Flex version in FC5? In-Reply-To: <1146746422.5294.100.camel@mccallum.corsepiu.local> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> Message-ID: <445A1007.4010106@math.unl.edu> Ralf Corsepius wrote: > On Thu, 2006-05-04 at 07:33 -0500, Rex Dieter wrote: > >>Benjamin Thery wrote: >> >> >>>My question is: why does Fedora ships flex 2.5.4a and not a more recent >>>one? >> >>Probably at least 1 of: >>* If it aint broke, don't fix it >>* No one has asked > > * Many flex versions > 2.5.4a had been too broken to be usable > * Many flex versions > 2.5.4a had been too incompatible to flex-2.5.x > * Many major packages have not been prepared for flex > 2.5.x Probably explains why Benjamin noticed other distros with 2 flex packages (one old, one new). Perhaps someone could review possibilities of dually-installed flex pkgs, and submit the "new" one to Extras. (: -- Rex From benjamin.thery at bull.net Thu May 4 14:39:44 2006 From: benjamin.thery at bull.net (Benjamin Thery) Date: Thu, 04 May 2006 16:39:44 +0200 Subject: Old Flex version in FC5? In-Reply-To: <445A1007.4010106@math.unl.edu> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <445A1007.4010106@math.unl.edu> Message-ID: <445A1230.1090709@bull.net> Rex Dieter wrote: > Ralf Corsepius wrote: >> On Thu, 2006-05-04 at 07:33 -0500, Rex Dieter wrote: >> >>> Benjamin Thery wrote: >>> >>>> My question is: why does Fedora ships flex 2.5.4a and not a more >>>> recent one? >>> >>> Probably at least 1 of: >>> * If it aint broke, don't fix it >>> * No one has asked >> >> * Many flex versions > 2.5.4a had been too broken to be usable >> * Many flex versions > 2.5.4a had been too incompatible to flex-2.5.x >> * Many major packages have not been prepared for flex > 2.5.x > > Probably explains why Benjamin noticed other distros with 2 flex > packages (one old, one new). > Perhaps someone could review possibilities > of dually-installed flex pkgs, and submit the "new" one to Extras. (: This sounds like a good compromise. One of the first thing I did when I discovered Debian has two packages was: heading to Extras to see if there was also an "updated-experimental" flex package there :) I've opened a bugzilla to track this update request: 190673. Thanks for your answers. Benjamin -- B e n j a m i n T h e r y - BULL/DT/Open Software R&D http://www.bull.com From fedora at camperquake.de Thu May 4 14:40:22 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 4 May 2006 16:40:22 +0200 Subject: Old Flex version in FC5? In-Reply-To: <1146746422.5294.100.camel@mccallum.corsepiu.local> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> Message-ID: <20060504164022.40dff0e1@duras.int.addix.net> Hi. On Thu, 04 May 2006 14:40:22 +0200, Ralf Corsepius wrote: > * Many flex versions > 2.5.4a had been too broken to be usable > * Many flex versions > 2.5.4a had been too incompatible to flex-2.5.x > * Many major packages have not been prepared for flex > 2.5.x It can't be that bad if Debian stable uses 2.5.31. From rc040203 at freenet.de Thu May 4 15:05:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 May 2006 17:05:15 +0200 Subject: Old Flex version in FC5? In-Reply-To: <20060504164022.40dff0e1@duras.int.addix.net> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <20060504164022.40dff0e1@duras.int.addix.net> Message-ID: <1146755115.5294.124.camel@mccallum.corsepiu.local> On Thu, 2006-05-04 at 16:40 +0200, Ralf Ertzinger wrote: > Hi. > > On Thu, 04 May 2006 14:40:22 +0200, Ralf Corsepius wrote: > > > * Many flex versions > 2.5.4a had been too broken to be usable > > * Many flex versions > 2.5.4a had been too incompatible to flex-2.5.x > > * Many major packages have not been prepared for flex > 2.5.x > > It can't be that bad if Debian stable uses 2.5.31. > Well, it's worse than that ... I guess you are aware which major packages I am referring to and what all might break because of a flex upgrade? Ralf From fedora at camperquake.de Thu May 4 15:07:12 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 4 May 2006 17:07:12 +0200 Subject: Old Flex version in FC5? In-Reply-To: <1146755115.5294.124.camel@mccallum.corsepiu.local> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <20060504164022.40dff0e1@duras.int.addix.net> <1146755115.5294.124.camel@mccallum.corsepiu.local> Message-ID: <20060504170712.28e31e2e@duras.int.addix.net> Hi. On Thu, 04 May 2006 17:05:15 +0200, Ralf Corsepius wrote: > Well, it's worse than that ... I guess you are aware which major > packages I am referring to and what all might break because of a flex > upgrade? I am not. From ellson at research.att.com Thu May 4 15:08:02 2006 From: ellson at research.att.com (John Ellson) Date: Thu, 04 May 2006 11:08:02 -0400 Subject: Old Flex version in FC5? In-Reply-To: <20060504164022.40dff0e1@duras.int.addix.net> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <20060504164022.40dff0e1@duras.int.addix.net> Message-ID: <445A18D2.9040102@research.att.com> Ralf Ertzinger wrote: > Hi. > > On Thu, 04 May 2006 14:40:22 +0200, Ralf Corsepius wrote: > > >>* Many flex versions > 2.5.4a had been too broken to be usable >>* Many flex versions > 2.5.4a had been too incompatible to flex-2.5.x >>* Many major packages have not been prepared for flex > 2.5.x > > > It can't be that bad if Debian stable uses 2.5.31. > flex-2.5..31 on Debian definitely broke graphviz builds. I just tried flex-2.5.33 from Sourceforge on an x86_64 Rawhide box and that particular problem seems to be fixed, but I would have to test all platform builds to be more confident. Problems with flex and bison can be particularly obscure and result in strange breakages in stable code. Just this week I ran into a problem in bison that only showed up when bison products generated on FC5 were compiled on Windows. (Fixed promptly by Roland McGrath. Thanks again.). These tools need extra care when updating. John From rc040203 at freenet.de Thu May 4 15:09:17 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 04 May 2006 17:09:17 +0200 Subject: Old Flex version in FC5? In-Reply-To: <20060504170712.28e31e2e@duras.int.addix.net> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <20060504164022.40dff0e1@duras.int.addix.net> <1146755115.5294.124.camel@mccallum.corsepiu.local> <20060504170712.28e31e2e@duras.int.addix.net> Message-ID: <1146755357.5294.126.camel@mccallum.corsepiu.local> On Thu, 2006-05-04 at 17:07 +0200, Ralf Ertzinger wrote: > Hi. > > On Thu, 04 May 2006 17:05:15 +0200, Ralf Corsepius wrote: > > > Well, it's worse than that ... I guess you are aware which major > > packages I am referring to and what all might break because of a flex > > upgrade? > > I am not. The very core of the distro: Binutils, gdb, GCC. Ralf From lamont at gurulabs.com Thu May 4 15:26:44 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 4 May 2006 09:26:44 -0600 Subject: Filesystem check In-Reply-To: <1146732574.32373.9.camel@localhost.localdomain> References: <1146649357.29023.71.camel@localhost.localdomain> <1146732574.32373.9.camel@localhost.localdomain> Message-ID: <200605040926.45105.lamont@gurulabs.com> On Thursday 04 May 2006 02:49am, Emeric Maschino wrote: > > Has something changed in the manner the filesystems are checked at boot > > time? > > > > Indeed, at startup, once the logical volumes are configured and > > activated, my filesystem is checked but the check fails with the > > following message: > > > > e2fsck: Cannot continue, aborting. > > > > I'm then asked to enter the root password in order to manually check the > > filesystem. At this stage, the filesystem is already mounted, so I > > pressed Ctrl-D to continue and my system was rebooted. > > > > The strange thing is that, if I boot using a rescue CD in order to run > > e2fsck on unmounted filesystems, everything is clean. > > > > Yesterday, I had the bad idea to finally enter the root password and > > manually run fsck as requested. Of course, this ended up with a totally > > corrupted filesystem. Fortunately, my data are on a separate disk. I've > > then performed a network install of Fedora Core Rawhide during this > > night (most recent packages dated May 2nd). Everything ran fine, but at > > boot time, e2fsck is still failing and ask for a manual intervention! > > Rebooting the system (Windows inside (R)) has no effect. > > > > Any hint ? This is on an Itanium workstation (ia64) and I don't know if > > this problem also appears on other architectures. > > Removing the rhgb quiet boot options as suggested by Paul allowed me to > log in (but you need to cancel the filesystem check when asked for the > root password). As stated by Bill Nottingham, updating to the latest > mkinitrd and rebuilding the initrd image definitely solved the problem > (the rhgb quiet boot options can be passed again to the kernel). rhgb and quiet are two separate options. They do not have anything to do with each other. IIRC, quite is understood by the kernel and causes it to not spew lots-o-text about it's initialization. You see the audit message and then the next text ("Welcome to Fedora Core" or however it's phrased) comes from /etc/rc.sysinit . The rhgb option is not understood by the kernel and is, therefore, passwd on to init, which is patched to understand that the rhgb option should be passed on (in some way) to rc.sysinit which then launches the X server and the rhgb display program. Are those details all correct? Anyway, since quiet and rhgb are separate items, I wonder which one actually had the effect on your booting. Or was it from interactions coming from both? Not that it's a big deal, since mkinitrd is now fixed. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Thu May 4 15:33:25 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 04 May 2006 11:33:25 -0400 Subject: Filesystem check In-Reply-To: <200605040926.45105.lamont@gurulabs.com> References: <1146649357.29023.71.camel@localhost.localdomain> <1146732574.32373.9.camel@localhost.localdomain> <200605040926.45105.lamont@gurulabs.com> Message-ID: <1146756806.14914.12.camel@orodruin.boston.redhat.com> On Thu, 2006-05-04 at 09:26 -0600, Lamont R. Peterson wrote: > Anyway, since quiet and rhgb are separate items, I wonder which one actually > had the effect on your booting. Or was it from interactions coming from > both? Not that it's a big deal, since mkinitrd is now fixed. It's an interaction of rhgb dealing with how the output from the boot process actually gets redirected to the embedded terminal. And you really don't want to know how that works ;-) Jeremy From emeric.maschino at jouy.inra.fr Thu May 4 15:43:42 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Thu, 04 May 2006 17:43:42 +0200 Subject: Filesystem check In-Reply-To: <200605040926.45105.lamont@gurulabs.com> References: <1146649357.29023.71.camel@localhost.localdomain> <1146732574.32373.9.camel@localhost.localdomain> <200605040926.45105.lamont@gurulabs.com> Message-ID: <1146757423.32373.74.camel@localhost.localdomain> > Anyway, since quiet and rhgb are separate items, I wonder which one actually > had the effect on your booting. Or was it from interactions coming from > both? Not that it's a big deal, since mkinitrd is now fixed. IIRC, the quiet option is disabled in actual Rawhide kernel. So I imagine that the faulty one was rhgb. ?meric From brunson at brunson.com Thu May 4 16:08:19 2006 From: brunson at brunson.com (Eric Brunson) Date: Thu, 04 May 2006 10:08:19 -0600 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> Message-ID: <445A26F3.8020509@brunson.com> Refusing to top quote... Peter Bieshaar wrote: > I agree this is inconvenient for me ;) That's why I tried to suggest a > solution for my inconvenience. All I suggested is to have dependent > packages on the same disk, which I think could be done. > > 2006/5/4, Thomas M Steenholdt >: > > Peter Bieshaar wrote: > > I didn't mean previous FC CDs. But keeping rpm's more structured on > > CD's. So keep the dependent rpm's at least on the same CD. Just did > > a mysql server installation, needed 2 CDs. > > > > The thing is that although this is inconvenient for you in this case, > chances are that other packages are depending on some of the same libs > and it may be hard to fit everything that have interdependencies on a > single disc, as long as FC is as large as it is atm. > > /Thomas > I'm going to toss in a vote of support for Peter's side. I tried to do as close to a minimal install as I could by de-selecting every thing I could in ananconda and ended up needing all 5 CDs. FC-4 was nice for building servers because I could boot and install a minimal system from CD 1 and then yum update and install up-to-date packages that I needed from the repos. Trying that with FC-5 was extremely frustrating, watching the (in my opinion) totally un-necessary dependencies required from CDs 3, 4 and 5, for example bluez-libs sticks in my mind as something I just had to roll my eyes at as I wondered what on earth it was going to load off CD 5. Would the simpler request simply be to ask for the "Minimal Install" back? Thanks, e. From zaitcev at redhat.com Thu May 4 16:31:27 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 4 May 2006 09:31:27 -0700 Subject: libusb scanner In-Reply-To: <1146741861.2630.12.camel@xpc.home.erwinrol.com> References: <1146741861.2630.12.camel@xpc.home.erwinrol.com> Message-ID: <20060504093127.5792252a.zaitcev@redhat.com> On Thu, 04 May 2006 13:24:21 +0200, Erwin Rol wrote: > I have a (old) HP6300C USB scanner, that used to work with a usbscanner > (or was that hpscanner?) kernel module. That kernel module is gone, now > xsane and kooka only can use it via libusb. The problem is this only > seems to work when i am root. Is there a way to let normal users use the > scanner? As far as I am aware, the only way to do it is to edit /etc/rc.d/rc.sysinit and have usbfs mounted with devuid=someone. I'd say, the drive to purge modules from kernel was rather misguided as far as permissions are concerned, and we're going to hear from Palm Pilot users yet. -- Pete From jkeating at j2solutions.net Thu May 4 16:45:15 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 04 May 2006 12:45:15 -0400 Subject: layout of FC5 (and previous) CD's In-Reply-To: <445A26F3.8020509@brunson.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> <445A26F3.8020509@brunson.com> Message-ID: <1146761115.29889.5.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-04 at 10:08 -0600, Eric Brunson wrote: > I tried to do as close to a minimal install as I could by de-selecting > every thing I could in ananconda and ended up needing all 5 CDs. FC-4 > was nice for building servers because I could boot and install a minimal > system from CD 1 and then yum update and install up-to-date packages > that I needed from the repos. Trying that with FC-5 was extremely > frustrating, watching the (in my opinion) totally un-necessary > dependencies required from CDs 3, 4 and 5, for example bluez-libs sticks > in my mind as something I just had to roll my eyes at as I wondered what > on earth it was going to load off CD 5. I call BS on this. Even a default install, one including Office stuff from that first selection page never asks for anything beyond 2 cds. And if I remember correctly, the asking for CD 2 was a bug we failed to fix, it doesn't actually grab any packages from said CD. If you deselected everything, theres no way it should have asked you for more CDs, you've ended up selecting something. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Thu May 4 16:45:45 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 04 May 2006 17:45:45 +0100 Subject: libusb scanner In-Reply-To: <20060504093127.5792252a.zaitcev@redhat.com> References: <1146741861.2630.12.camel@xpc.home.erwinrol.com> <20060504093127.5792252a.zaitcev@redhat.com> Message-ID: <1146761145.20773.101.camel@pmac.infradead.org> On Thu, 2006-05-04 at 09:31 -0700, Pete Zaitcev wrote: > As far as I am aware, the only way to do it is to edit /etc/rc.d/rc.sysinit > and have usbfs mounted with devuid=someone. I'd say, the drive to purge > modules from kernel was rather misguided as far as permissions are > concerned, and we're going to hear from Palm Pilot users yet. This used to work fine in FC4 -- the permissions were correctly granted to the console user. In FC5, xsane just seems to be totally screwed anyway. -- dwmw2 From notting at redhat.com Thu May 4 17:05:32 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 May 2006 13:05:32 -0400 Subject: libusb scanner In-Reply-To: <1146741861.2630.12.camel@xpc.home.erwinrol.com> References: <1146741861.2630.12.camel@xpc.home.erwinrol.com> Message-ID: <20060504170532.GA17007@devserv.devel.redhat.com> Erwin Rol (mailinglists at erwinrol.com) said: > I have a (old) HP6300C USB scanner, that used to work with a usbscanner > (or was that hpscanner?) kernel module. That kernel module is gone, now > xsane and kooka only can use it via libusb. The problem is this only > seems to work when i am root. Is there a way to let normal users use the > scanner? This should be fixed in FC5 - I tested it with a USB scanner shortly before release. What *should* happen is that the udev rules in /etc/udev/rules.d/60-libsane.rules get run, making a scanner- symlink to /dev/bus/usb/XXX. This device is then chown'ed via pam_console, later by udev. Bill From nicolas.mailhot at laposte.net Thu May 4 17:36:52 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 04 May 2006 19:36:52 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> Message-ID: <1146764214.2528.4.camel@rousalka.dyndns.org> Le jeudi 04 mai 2006 ? 10:50 +0200, Peter Bieshaar a ?crit : > I agree this is inconvenient for me ;) That's why I tried to suggest a > solution for my inconvenience. All I suggested is to have dependent > packages on the same disk, which I think could be done. Technical package inter dependencies are quite complex, and social dependencies (people use foo with bar even if they are technically distinct) are worse. I think if you actually try to do what you suggest you'll hit a wall pretty soon. Or buy a dvd reader. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Thu May 4 19:20:39 2006 From: buildsys at redhat.com (Build System) Date: Thu, 4 May 2006 15:20:39 -0400 Subject: rawhide report: 20060504 changes Message-ID: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> Updated Packages: alsa-utils-1.0.11-6.rc2 ----------------------- * Wed May 03 2006 Martin Stransky 1.0.11-6.rc2 - removed HW specific switch - it should be set by driver booty-0.75-1 ------------ * Wed May 03 2006 Chris Lumens 0.75-1 - Remove rogue reference to butil. busybox-1:1.1.1-2 ----------------- * Thu May 04 2006 Ivana Varekova - 1:1.1.1-2 - add -Z option to id command, rename ps command -Z option (#190534) * Wed May 03 2006 Ivana Varekova - 1:1.1.1-1 - update to 1.1.1 - fix CVE-2006-1058 - BusyBox passwd command fails to generate password with salt (#187386) - add -minimal-toc option - add RPM_OPT_FLAGS - remove asm/page.h used sysconf command to get PAGE_SIZE - add overfl patch to aviod Buffer warning cairo-1.1.4-2 ------------- * Wed May 03 2006 Carl Worth - 1.1.4-2 - Revert upstream commit that introduced a dependency on a newer poppler version for the PDF tests. * Wed May 03 2006 Carl Worth - 1.1.4-1 - Update to new upstream 1.1.4 - Drop both embedded-bitmaps and XRenderAddGlyphs patches as both now have upstream versions * Fri Apr 28 2006 Carl Worth - 1.1.2-2 - Add suggested patch for XRenderAddGlyphs crash of bug #4705 https://bugs.freedesktop.org/show_bug.cgi?id=4705 dovecot-1.0-0.beta7.1 --------------------- * Thu May 04 2006 Petr Rockai - 1.0-0.beta7.1 - upgrade to latest upstream beta release * Fri Mar 17 2006 Petr Rockai - 1.0-0.beta2.8 - fix sqlite detection in upstream configure checks, second part of #182240 epiphany-2.14.1-3 ----------------- * Thu May 04 2006 Dan Williams - 2.14.1-3 - Rebuild for a mozilla update evolution-2.6.1-3 ----------------- * Wed May 03 2006 Matthew Barnes - 2.6.1-3 - rebuilt * Mon Apr 10 2006 Matthias Clasen - 2.6.1-2 - Update to 2.6.1 * Thu Mar 30 2006 Caolan McNamara - 2.6.0-2 - rebuild against reverted pilot-link - disable evolution-2.5.4-fix-conduits.patch for reversion to pilot-link 0.11.8 gcc-4.1.0-13 ------------ * Wed May 03 2006 Jakub Jelinek 4.1.0-13 - update from gcc-4_1-branch (-r113416:113489) - PRs c/25309, target/27374, target/27387, tree-optimization/27364 - merge gomp changes from trunk (-r113267:113271, -r113411:113412, -r113452:113456, -r113482:113483, -r113493:113494) - PR fortran/27395 - additional gomp fixes (PRs c++/27359, middle-end/27388) - package SYSCALLS.c.X for protize (#190047) - fix gcj -fprofile-arcs -ftest-coverage (Alexandre Oliva, #177450) - reenable profiledbootstrap - in 64-bit builds remove 32-bit /usr/lib/lib* libraries from the buildroots (and similarly on 32-bit builds remove 64-bit /usr/lib64/lib*) before AutoReq generation (#190541) glib2-2.11.0-1 -------------- * Tue May 02 2006 Matthias Clasen - 2.11.0-1 - Update to 2.11.0 glibc-2.4.90-4 -------------- * Mon May 01 2006 Jakub Jelinek 2.4.90-4 - update from CVS - SETENT_BATCH_READ /etc/default/nss option for speeding up some usages of NIS+ (#188246) - move debug state change notification (#179208) - fix ldd script if one of the dynamic linkers is not installed (#190259) httpd-2.2.2-2 ------------- * Wed May 03 2006 Joe Orton 2.2.2-2 - update to 2.2.2 icu-3.4-8 --------- * Wed May 03 2006 Caolan McNamara - 3.4-8 - add Harshula's icu-3.4-sinhala1.patch for some Sinhala support kdebase-6:3.5.2-6 ----------------- * Thu May 04 2006 Than Ngo 6:3.5.2-6 - add missing kcheckpass kdemultimedia-6:3.5.2-2 ----------------------- * Tue May 02 2006 Than Ngo 6:3.5.2-2 - add buildrequires on libtheora-devel #190321 - add buildrequires on libXxf86dga-devel #128599 kdepim-6:3.5.2-2 ---------------- * Wed May 03 2006 Than Ngo 6:3.5.2-2 - fix #190491, korganizer crashes whenever New Event selected - fix crash from proko2 - possibly fix crash while selecting mail in mail header view - fix #122571, kmail doesn't remember "fallback character encoding" setting - fix #126571, kmail crashes when pressing "Send again..." in drafts folder - fix syntax error in /usr/bin/kmail_clamav.sh kernel-2.6.16-1.2187_FC6 ------------------------ * Wed May 03 2006 Dave Jones - 2.6.17rc3-git8 * Wed May 03 2006 Juan Quintela - rebase xen-unstable HV 9920" less-394-4 ---------- * Fri May 05 2006 Ivana Varekova - 394-4 - fix problem with unassigned variable DECOMPRESSOR (#190619) libpng-2:1.2.10-1 ----------------- * Thu May 04 2006 Matthias Clasen - 2:1.2.10-1 - Update to 1.2.10 - Drop static libraries libstdc++so7-4.2.0-0.5.20060428 ------------------------------- * Fri Apr 28 2006 Benjamin Kosnik 4.2.0-0.5.20060428 - update sources and add libstdc++-v3-so7-version.patch - libstdc++/24660 - mt_allocator fixes from David Boreham and Scott Bridges php-5.1.3-3 ----------- * Wed May 03 2006 Joe Orton 5.1.3-3 - update to 5.1.3 rpm-4.4.2-22 ------------ * Wed May 03 2006 Jeremy Katz - 4.4.2-22 - put in simple workaround for per-file deps with autoreq off (#190488) while pnasrat works on a real fix sane-backends-1.0.17-9 ---------------------- * Tue Apr 25 2006 Nils Philippsen 1.0.17-9 - add support for Canon Lide 60 scanner (#189726) setools-2.4-1 ------------- * Wed May 03 2006 Dan Walsh 2.4-1 - Update from upstream * Mon Apr 10 2006 Dan Walsh 2.3-3 - Fix help - Add icons squid-7:2.5.STABLE13-4 ---------------------- * Wed May 03 2006 Martin Stransky - 7:2.5.STABLE13-4 - added extra group check (#190544) system-config-printer-0.7.7-1 ----------------------------- * Thu May 04 2006 Tim Waugh 0.7.7-1 - Updated to system-config-printer-0.7.7. - Updated to pycups-1.9.9. - Desktop file. - Requires PyXML. udev-091-2 ---------- * Wed May 03 2006 Harald Hoyer - 091-2 - added subpackages libvolume_id and libvolume_id-devel * Wed May 03 2006 Harald Hoyer - 091-1 - version 091 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From nalin at redhat.com Thu May 4 19:26:01 2006 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 4 May 2006 15:26:01 -0400 Subject: AIGLX breaks XServer with new Repo In-Reply-To: References: Message-ID: <20060504192601.GA8365@redhat.com> On Thu, May 04, 2006 at 12:29:45AM -0400, Benjy Grogan wrote: > I had AIGLX working on FC5 using the old aiglx.repo that pointed to > Ray Strode's repo. I recently dropped in the new aiglx.repo that > Kristian Hogsberg posted a few weeks ago and the result was that my > XServer won't start anymore. [snip] > (EE) module ABI minor version (5) is newer than the server's version (4) [snip] Are you still using Xair (from the old xorg-x11-server-Xair package in Ray's repository, which is out of date) as your server? Someone correct me if I'm wrong, but AFAIK the accelerated-indirect code was merged into the main xorg-x11 packages in time for the FC5 release, and the xorg-x11-server-Xair package was removed from the repository, but it wasn't obsoleted by anything because, well, this is Raw Hide. If you've got the package installed, and are still using the server binaries that it contains, that would explain the version mismatch, and undoing the configuration changes which call Xair instead of Xorg should fix it up. HTH, Nalin From jkeating at redhat.com Thu May 4 19:38:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 May 2006 15:38:41 -0400 Subject: rawhide report: 20060504 changes In-Reply-To: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> Message-ID: <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-04 at 15:20 -0400, Build System wrote: > > rpm-4.4.2-22 > ------------ > * Wed May 03 2006 Jeremy Katz - 4.4.2-22 > - put in simple workaround for per-file deps with autoreq off (#190488) > while pnasrat works on a real fix So you're going to want to update rpm first, then proceed with the rest of the update, or else you're going to get bit on the glibc update with: rpmte.c:589: rpmteColorDS: Assertion 'ix < Count' failed. Welcome to rawhide (: -- 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 Thu May 4 19:45:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 May 2006 15:45:43 -0400 Subject: rawhide report: 20060504 changes In-Reply-To: <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> Message-ID: <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-04 at 15:38 -0400, Jesse Keating wrote: > > > > rpm-4.4.2-22 > > ------------ > > * Wed May 03 2006 Jeremy Katz - 4.4.2-22 > > - put in simple workaround for per-file deps with autoreq off (#190488) > > while pnasrat works on a real fix > > So you're going to want to update rpm first, then proceed with the rest > of the update, or else you're going to get bit on the glibc update with: > > rpmte.c:589: rpmteColorDS: Assertion 'ix < Count' failed. > > > Welcome to rawhide (: > Um, that should be rpm and rpm-libs. -- 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 peter.bieshaar at gmail.com Thu May 4 20:17:09 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Thu, 4 May 2006 22:17:09 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <1146764214.2528.4.camel@rousalka.dyndns.org> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> <1146764214.2528.4.camel@rousalka.dyndns.org> Message-ID: <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> OK I think the discussion is running out of hand and not what I meant in the first place. As far as I understand within the discussions, there was no or little common sense in placing the rpm's on the CDs. Please forgive me if I'm wrong, all FC guys did a tremendous job. Can anyone JUST tell me how a "rpm -i some.rpm" knows that package someother.rpm is needed. I have tried before with --requires but that didn't do the trick. I might come up with a little script which tells the hierarchie on relationships, which can be used to differentiate the packages on the CDs in a more structured way, which might be of help for future FC distributions. These of course should only be handled for extras. 2006/5/4, Nicolas Mailhot : > > Le jeudi 04 mai 2006 ? 10:50 +0200, Peter Bieshaar a ?crit : > > I agree this is inconvenient for me ;) That's why I tried to suggest a > > solution for my inconvenience. All I suggested is to have dependent > > packages on the same disk, which I think could be done. > > Technical package inter dependencies are quite complex, and social > dependencies (people use foo with bar even if they are technically > distinct) are worse. > > I think if you actually try to do what you suggest you'll hit a wall > pretty soon. Or buy a dvd reader. > > -- > Nicolas Mailhot > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iEYEABECAAYFAkRaO7QACgkQI2bVKDsp8g3M2QCgveE+LUAl9xwZQL90lTiMQ2HW > 52cAoKbXpxRtJG9ZizMtpPYpuXAxcZXG > =zkHj > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Peter Bieshaar NL(0)6 29577255 use this or: peter at bieshaar.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Thu May 4 20:26:52 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 04 May 2006 16:26:52 -0400 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> <1146764214.2528.4.camel@rousalka.dyndns.org> <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> Message-ID: <1146774412.29889.27.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-04 at 22:17 +0200, Peter Bieshaar wrote: > > As far as I understand within the discussions, there was no or little > common sense in placing the rpm's on the CDs. Please forgive me if I'm > wrong, all FC guys did a tremendous job. The rpms are split in such a way that you'll never have to go back to another CD for a dep. When you're installing, once you're done w/ CD1, you're DONE with CD1. No other package to be installed should call for CD 1 again. Ditto CD2, and so forth. Also some logic is put in so that hopefully a basic or default install should only require the first and possibly the second CD. > Can anyone JUST tell me how a "rpm -i some.rpm" knows that package > someother.rpm is needed. I have tried before with --requires but that > didn't do the trick. I might come up with a little script which tells > the hierarchie on relationships, which can be used to differentiate > the packages on the CDs in a more structured way, which might be of > help for future FC distributions. These of course should only be > handled for extras. It is requires. Each package has a list of things that it requires. Those requires in turn may need some other packages, so on and so forth. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gianluca.cecchi at gmail.com Thu May 4 20:29:19 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 4 May 2006 22:29:19 +0200 Subject: [OT] change default compiler version to build an rpm In-Reply-To: <561c252c0605041314t3560ebe7n25177ff6de94221d@mail.gmail.com> References: <561c252c0605041314t3560ebe7n25177ff6de94221d@mail.gmail.com> Message-ID: <561c252c0605041329x485d34beua1d75823552f0113@mail.gmail.com> On my FC5 system I have problems running rpmbuild for a program with default gcc that is 4.1.0. I have the compat-gcc-32 package installed on my system. Getting the source tgz file, setting CC with export CC=gcc32 and then running configure and make it works and I can compile the program, but I am not able to replicate this in spec file for rpmbuild. So I'm trying to change compiler settings from gcc to gcc32. I added for dependency into the spec file the line BuildRequires: compat-gcc-32 but I'm not able to have the gcc32 compiler set up. I tried something like %define %{__cc} gcc32 before the prep and build phases, but in %configure step in build phase I see that the detected compiler is gcc and not gcc32. Any hints and pointers? Already sent to rpm-list too. Thanks in advance, Gianluca From Lam at Lam.pl Thu May 4 20:30:19 2006 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 04 May 2006 22:30:19 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> <1146764214.2528.4.camel@rousalka.dyndns.org> <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> Message-ID: <1146774619.3428.47.camel@pensja.lam.pl> Dnia 04-05-2006, czw o godzinie 22:17 +0200, Peter Bieshaar napisa?(a): > Can anyone JUST tell me how a "rpm -i some.rpm" knows that package > someother.rpm is needed. I have tried before with --requires but that > didn't do the trick. For me, rpm -q --requires does the trick, combined with rpm -q --provides on the other side. There are such scripts, including "pkgorder". Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From davej at redhat.com Thu May 4 20:49:00 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 4 May 2006 16:49:00 -0400 Subject: [OT] change default compiler version to build an rpm In-Reply-To: <561c252c0605041329x485d34beua1d75823552f0113@mail.gmail.com> References: <561c252c0605041314t3560ebe7n25177ff6de94221d@mail.gmail.com> <561c252c0605041329x485d34beua1d75823552f0113@mail.gmail.com> Message-ID: <20060504204900.GK18962@redhat.com> On Thu, May 04, 2006 at 10:29:19PM +0200, Gianluca Cecchi wrote: > On my FC5 system I have problems running rpmbuild for a program with > default gcc that is 4.1.0. So why not fix the program so it builds with 4.1.0 ? Running away from the problem to older gcc's means it'll miss out on advantages such as FORTIFY_SOURCE. Dave -- http://www.codemonkey.org.uk From mpeters at mac.com Thu May 4 21:25:18 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 04 May 2006 14:25:18 -0700 Subject: Old Flex version in FC5? In-Reply-To: <445A1007.4010106@math.unl.edu> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <445A1007.4010106@math.unl.edu> Message-ID: <1146777918.5627.38.camel@atlantis.mpeters.local> On Thu, 2006-05-04 at 09:30 -0500, Rex Dieter wrote: > > Probably explains why Benjamin noticed other distros with 2 flex > packages (one old, one new). Perhaps someone could review possibilities > of dually-installed flex pkgs, and submit the "new" one to Extras. (: Does Debian install them parallel installable? I remember this being discussed before in an Extras review - where someone was submitting a package that needed the new flex. If I remember, the problem was that the new flex would have to be installed in such a way that it was never used by mistake, and no one had submitted a package yet. The package ended up being patched to not need the new flex, and nothing more came of it. How many software packages out there do not build on Fedora Core for lack of the new flex? From mpeters at mac.com Thu May 4 21:28:30 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 04 May 2006 14:28:30 -0700 Subject: [OT] change default compiler version to build an rpm In-Reply-To: <561c252c0605041329x485d34beua1d75823552f0113@mail.gmail.com> References: <561c252c0605041314t3560ebe7n25177ff6de94221d@mail.gmail.com> <561c252c0605041329x485d34beua1d75823552f0113@mail.gmail.com> Message-ID: <1146778110.5627.41.camel@atlantis.mpeters.local> On Thu, 2006-05-04 at 22:29 +0200, Gianluca Cecchi wrote: > On my FC5 system I have problems running rpmbuild for a program with > default gcc that is 4.1.0. > I have the compat-gcc-32 package installed on my system. > Getting the source tgz file, setting CC with > export CC=gcc32 > and then running configure and make it works and I can compile the > program, but I am not able to replicate this in spec file for > rpmbuild. > > So I'm trying to change compiler settings from gcc to gcc32. > I added for dependency into the spec file the line > BuildRequires: compat-gcc-32 > > but I'm not able to have the gcc32 compiler set up. > I tried something like > %define %{__cc} gcc32 > before the prep and build phases, but in > %configure step in build phase > I see that the detected compiler is gcc and not gcc32. > Any hints and pointers? Already sent to rpm-list too. > Thanks in advance, > Gianluca > in %build section: try export CC=%{_bindir}/gcc32 or make CC=%{_bindir}/gcc32 -=- If I remember correctly, you may also have to change the %optflags macro because FC4/FC5 use some flags that not compatible with gcc32 From gianluca.cecchi at gmail.com Thu May 4 21:43:35 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 4 May 2006 23:43:35 +0200 Subject: [OT] change default compiler version to build an rpm Message-ID: <561c252c0605041443g18df2277qed26cea9165e50c3@mail.gmail.com> On Thu, 4 May 2006 16:49:00 -0400 Dave Jones wrote: >So why not fix the program so it builds with 4.1.0 ? >Running away from the problem to older gcc's means it'll miss out >on advantages such as FORTIFY_SOURCE. Indeed, and infact I sent an e-mail to the author of the program. The problem is pertinent to the "invalid lvalue in assignment" that I saw in various other programs that were then patched to be able to compile from gcc 3 to 4. But my question could also be seen in general as how to override pre-defined macros, not only for the __cc one. Or is this in general a no-no thing to do? Thanks, Gianluca From gianluca.cecchi at gmail.com Thu May 4 21:57:08 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 4 May 2006 23:57:08 +0200 Subject: [OT] change default compiler version to build an rpm Message-ID: <561c252c0605041457u4e09bbd4pf50a4964391da529@mail.gmail.com> On Thu, 04 May 2006 14:28:30 -0700 Michael A. Peters wrote: >in %build section: >try export CC=%{_bindir}/gcc32 >or >make CC=%{_bindir}/gcc32 either setting in %build %configure CC=%{_bindir}/gcc32 %{__make} CC=%{_bindir}/gcc32 or export CC=%{_bindir}/gcc32 I get this during configure: checking for i686-redhat-linux-gnu-gcc... /usr/bin/gcc32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. In config.log I have: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable -shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --enable-la nguages=c,c++,f77 --disable-libgcj --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5) configure:2076: $? = 0 configure:2078: /usr/bin/gcc32 -V &5 gcc32: argument to `-V' is missing configure:2081: $? = 1 configure:2104: checking for C compiler default output file name configure:2107: /usr/bin/gcc32 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protect or --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables conftest.c >&5 cc1: invalid option `tune=generic' cc1: unrecognized option `-fstack-protector' cc1: invalid parameter `ssp-buffer-size' configure:2110: $? = 1 Do I have also to change CFLAGS...? From david at lovesunix.net Thu May 4 22:22:41 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 05 May 2006 00:22:41 +0200 Subject: [OT] change default compiler version to build an rpm In-Reply-To: <561c252c0605041457u4e09bbd4pf50a4964391da529@mail.gmail.com> References: <561c252c0605041457u4e09bbd4pf50a4964391da529@mail.gmail.com> Message-ID: <1146781361.2646.12.camel@localhost.localdomain> tor, 04 05 2006 kl. 23:57 +0200, skrev Gianluca Cecchi: > On Thu, 04 May 2006 14:28:30 -0700 Michael A. Peters wrote: > >in %build section: > >try export CC=%{_bindir}/gcc32 > >or > >make CC=%{_bindir}/gcc32 > > either setting in %build > %configure CC=%{_bindir}/gcc32 > %{__make} CC=%{_bindir}/gcc32 > > or > export CC=%{_bindir}/gcc32 > > I get this during configure: > > checking for i686-redhat-linux-gnu-gcc... /usr/bin/gcc32 > checking for C compiler default output file name... configure: error: > C compiler cannot create executables > See `config.log' for more details. > > In config.log I have: > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable > -shared --enable-threads=posix --disable-checking --with-system-zlib > --enable-__cxa_atexit --enable-la > nguages=c,c++,f77 --disable-libgcj --host=i386-redhat-linux > Thread model: posix > gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5) > configure:2076: $? = 0 > configure:2078: /usr/bin/gcc32 -V &5 > gcc32: argument to `-V' is missing > configure:2081: $? = 1 > configure:2104: checking for C compiler default output file name > configure:2107: /usr/bin/gcc32 -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protect > or --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic > -fasynchronous-unwind-tables conftest.c > >&5 > cc1: invalid option `tune=generic' > cc1: unrecognized option `-fstack-protector' > cc1: invalid parameter `ssp-buffer-size' > configure:2110: $? = 1 > > Do I have also to change CFLAGS...? Of course, these are not supported in gcc 3.2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From mpeters at mac.com Thu May 4 22:33:30 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 04 May 2006 15:33:30 -0700 Subject: [OT] change default compiler version to build an rpm In-Reply-To: <561c252c0605041457u4e09bbd4pf50a4964391da529@mail.gmail.com> References: <561c252c0605041457u4e09bbd4pf50a4964391da529@mail.gmail.com> Message-ID: <1146782011.5627.47.camel@atlantis.mpeters.local> On Thu, 2006-05-04 at 23:57 +0200, Gianluca Cecchi wrote: > On Thu, 04 May 2006 14:28:30 -0700 Michael A. Peters wrote: > >in %build section: > >try export CC=%{_bindir}/gcc32 > >or > >make CC=%{_bindir}/gcc32 > > either setting in %build > %configure CC=%{_bindir}/gcc32 > %{__make} CC=%{_bindir}/gcc32 > > or > export CC=%{_bindir}/gcc32 > > I get this during configure: > > checking for i686-redhat-linux-gnu-gcc... /usr/bin/gcc32 > checking for C compiler default output file name... configure: error: > C compiler cannot create executables > See `config.log' for more details. > > In config.log I have: > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable > -shared --enable-threads=posix --disable-checking --with-system-zlib > --enable-__cxa_atexit --enable-la > nguages=c,c++,f77 --disable-libgcj --host=i386-redhat-linux > Thread model: posix > gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5) > configure:2076: $? = 0 > configure:2078: /usr/bin/gcc32 -V &5 > gcc32: argument to `-V' is missing > configure:2081: $? = 1 > configure:2104: checking for C compiler default output file name > configure:2107: /usr/bin/gcc32 -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protect > or --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic > -fasynchronous-unwind-tables conftest.c > >&5 > cc1: invalid option `tune=generic' > cc1: unrecognized option `-fstack-protector' > cc1: invalid parameter `ssp-buffer-size' > configure:2110: $? = 1 > > Do I have also to change CFLAGS...? > Yes - rpm sets CFLAGS to %optflags So you can define the optflags macro in the spec file to flags that work with gcc32. From emeric.maschino at jouy.inra.fr Fri May 5 01:06:43 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Fri, 05 May 2006 03:06:43 +0200 Subject: Cannot log in to a GNOME desktop In-Reply-To: <1146733408.32373.22.camel@localhost.localdomain> References: <1146733408.32373.22.camel@localhost.localdomain> Message-ID: <1146791203.26527.5.camel@localhost.localdomain> > What can prevent a user to log in a GNOME session? When entering my > username and password at the GDM log in screen, I immediately get a > dialog box telling me that the X session lasts less than 10 sec and that > some help can be provided by the ~/.xsession_error. Well, this file > doesn't even exist. I've tried the "Last session" and "Default GNOME > session" options in the GDM log in screen without a success. Same > problem for root. This is on an Itanium workstation (ia64) with a fresh > install of Fedora Core Rawhide on May 2nd, updated with the latest > packages. I don't know if this problem also appears on other > architectures. Roughly a month ago (before my filesystem problem), I > didn't have this problem. But a lot of things have changed since... I've performed regression tests and finally isolate the faulty package: it's gnome-session-2.14.1-2. Reverting to FC5 original gnome- session-2.14.0-1 solves the problem. I don't know if other versions where built in the meantime, so I can't precisely determine whether the log in problem only appears with the latest gnome-session version or not. Does this issue only affect ia64 systems or other architectures too? Should I file a bug report? ?meric From benjy.grogan at gmail.com Fri May 5 06:06:51 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 5 May 2006 02:06:51 -0400 Subject: AIGLX breaks XServer with new Repo In-Reply-To: <20060504192601.GA8365@redhat.com> References: <20060504192601.GA8365@redhat.com> Message-ID: On 5/4/06, Nalin Dahyabhai wrote: > On Thu, May 04, 2006 at 12:29:45AM -0400, Benjy Grogan wrote: > > I had AIGLX working on FC5 using the old aiglx.repo that pointed to > > Ray Strode's repo. I recently dropped in the new aiglx.repo that > > Kristian Hogsberg posted a few weeks ago and the result was that my > > XServer won't start anymore. > [snip] > > (EE) module ABI minor version (5) is newer than the server's version (4) > [snip] > > Are you still using Xair (from the old xorg-x11-server-Xair package in > Ray's repository, which is out of date) as your server? Yes, Xair was always at the top of the list in System Monitor in terms of processor time. So, if that Xair should no longer be there, how do I remove it and properly replace it with the right Xorg? > Someone correct me if I'm wrong, but AFAIK the accelerated-indirect code > was merged into the main xorg-x11 packages in time for the FC5 release, > and the xorg-x11-server-Xair package was removed from the repository, > but it wasn't obsoleted by anything because, well, this is Raw Hide. > > If you've got the package installed, and are still using the server > binaries that it contains, that would explain the version mismatch, and > undoing the configuration changes which call Xair instead of Xorg should > fix it up. What exactly are the configuration changes that are calling Xair instead of Xorg? Benjy > > HTH, > > Nalin > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nicolas.mailhot at laposte.net Fri May 5 06:10:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 05 May 2006 08:10:30 +0200 Subject: layout of FC5 (and previous) CD's In-Reply-To: <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> References: <529f9df20605032345k31950041ya7eec2a97cdf613a@mail.gmail.com> <1146728106.3101.19.camel@laptopd505.fenrus.org> <529f9df20605040112v13e3d2eej91a96a16ea12841a@mail.gmail.com> <529f9df20605040150r21049e94u2c41cc33fc8c9f2e@mail.gmail.com> <1146764214.2528.4.camel@rousalka.dyndns.org> <529f9df20605041317u1f9980b8t704b24b46298913a@mail.gmail.com> Message-ID: <1146809432.2528.13.camel@rousalka.dyndns.org> Le jeudi 04 mai 2006 ? 22:17 +0200, Peter Bieshaar a ?crit : > As far as I understand within the discussions, there was no or little > common sense in placing the rpm's on the CDs. Please forgive me if I'm > wrong, all FC guys did a tremendous job. The CD layout is never random, be it in FC5 or nay other release. > Can anyone JUST tell me how a "rpm -i some.rpm" knows that package > someother.rpm is needed. I have tried before with --requires but that > didn't do the trick. I might come up with a little script which tells > the hierarchie on relationships, which can be used to differentiate > the packages on the CDs in a more structured way, which might be of > help for future FC distributions. You might try http://article.gmane.org/gmane.linux.redhat.fedora.java/561 Which produced for a *small* subset of Fedora a few years ago: http://gnu.wildebeest.org/diary/index.php?p=97 (the page may be dead, it's in google cache right now at least) As you'll see in the example, rpm deps are *not* a simple tree graph, you have cycles, critical nodes used by many other packages, etc. And that's not taking into account relations like for example people interested in the gimp will probably need inkscape too (moreover these relations depend on the user viewpoint, to take your example some people will want a pure mysql server, others don't care about the actual db backend but need perl perl db bindings, etc) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From arjan at fenrus.demon.nl Fri May 5 07:05:33 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 05 May 2006 09:05:33 +0200 Subject: [OT] change default compiler version to build an rpm In-Reply-To: <561c252c0605041443g18df2277qed26cea9165e50c3@mail.gmail.com> References: <561c252c0605041443g18df2277qed26cea9165e50c3@mail.gmail.com> Message-ID: <1146812733.2891.11.camel@laptopd505.fenrus.org> On Thu, 2006-05-04 at 23:43 +0200, Gianluca Cecchi wrote: > On Thu, 4 May 2006 16:49:00 -0400 Dave Jones wrote: > >So why not fix the program so it builds with 4.1.0 ? > >Running away from the problem to older gcc's means it'll miss out > >on advantages such as FORTIFY_SOURCE. > > Indeed, and infact I sent an e-mail to the author of the program. > The problem is pertinent to the "invalid lvalue in assignment" that I > saw in various other programs that were then patched to be able to > compile from gcc 3 to 4. > But my question could also be seen in general as how to override > pre-defined macros, not only for the __cc one. Or is this in general a > no-no thing to do? for example to override _sourcedir you can do rpmbuild --define "_sourcedir `pwd`" so I assume that works for most others too From buildsys at redhat.com Fri May 5 07:31:11 2006 From: buildsys at redhat.com (Build System) Date: Fri, 5 May 2006 03:31:11 -0400 Subject: rawhide report: 20060505 changes Message-ID: <200605050731.k457VBSf019005@porkchop.devel.redhat.com> Updated Packages: MAKEDEV-3.22-1 -------------- * Thu May 04 2006 Nalin Dahyabhai 3.22-1 - update to 1 March devices-2.6+.txt: - add ttyEQ* anaconda-11.1.0.8-1 ------------------- * Thu May 04 2006 Jeremy Katz - 11.1.0.8-1 - and fix the build * Thu May 04 2006 Paul Nasrat - 11.1.0.7-1 - class Anaconda (pnasrat, clumens) - User/service kickstart handlers (clumens) - Don't include kernel fs headers (katzj) kernel-2.6.16-1.2188_FC6 ------------------------ * Thu May 04 2006 Jeremy Katz - improved ahci suspend patch from Forrest Zhao libtiff-3.8.2-2 --------------- * Wed Apr 26 2006 Matthias Clasen - 3.8.2-2 - Drop tiffgt to get rid of the libGL dependency (#190768) pykickstart-0.27-1 ------------------ * Thu May 04 2006 Chris Lumens 0.27-1 - Output formatting fixes. - Added commands for managing users and services. rpm-4.4.2-23 ------------ * Thu May 04 2006 Jeremy Katz - 4.4.2-23 - make rpm-libs requires on base package stronger selinux-policy-2.2.37-1 ----------------------- * Wed May 03 2006 Dan Walsh 2.2.37-1 - Update to upstream Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From gbiczo at freestart.hu Fri May 5 08:05:29 2006 From: gbiczo at freestart.hu (gbiczo at freestart.hu) Date: Fri, 5 May 2006 10:05:29 +0200 (CEST) Subject: Help! fc2->fc5 Message-ID: <31940999.1146816329493.JavaMail.www-data@www2> Hi all, I tried to upgrade my FC 2 system to FC5. For some reason, the installation/upgrade process stopped, I retryed several times, but haden't success. The installation is thus broken. I decided to upgrade the packages manually. Now two questions emerged. 1. Graphical package installation (pirut?) doesn't work, seems it cannot find repository data. How can it be told to "look into" the installation cds? Is pirut the tool I need to use? (manual installation/upgrade is a bit difficult: deps). 2. Tried to compile a kernel module for my lt winmodem. insmod won't load the module, exits with interesting error messages. Has anybody tried such a blasphemy under FC5? Kernel is 2.6.16-1.2080 (Yes, because of nvidia...) aha! and a minor question: Release notes mentions, that fc5 doesn't support serial mice. Now my broken installation uses perfectly my old mouse (serial, of course), which is very good. Is there an "official" possibility to use serial mice? Thanks in advance Giovanni ____________________________________________________________________ Nagyobb szabads?gra v?gysz? T?rj ki a n?gy fal k?z?l! Start ADSL el?fizet?sedhez az EuroWeb mostant?l havi 100 perc ingyenes WiFi hozz?f?r?st biztos?t sz?modra. R?szletek: www.freestart.hu From sdl.web at gmail.com Fri May 5 08:14:18 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 09:14:18 +0100 Subject: Help! fc2->fc5 References: <31940999.1146816329493.JavaMail.www-data@www2> Message-ID: gbiczo at freestart.hu writes: > Hi all, > > I tried to upgrade my FC 2 system to FC5. For some reason, the > installation/upgrade process stopped, I retryed several times, but > haden't success. The installation is thus broken. I decided to > upgrade the packages manually. Now two questions emerged. > > 1. Graphical package installation (pirut?) doesn't work, seems it > cannot find repository data. How can it be told to "look into" the > installation cds? Is pirut the tool I need to use? (manual > installation/upgrade is a bit difficult: deps). > > 2. Tried to compile a kernel module for my lt winmodem. insmod won't > load the module, exits with interesting error messages. Has anybody > tried such a blasphemy under FC5? Kernel is 2.6.16-1.2080 (Yes, > because of nvidia...) > > aha! and a minor question: Release notes mentions, that fc5 doesn't > support serial mice. Now my broken installation uses perfectly my old > mouse (serial, of course), which is very good. Is there an "official" > possibility to use serial mice? > > Thanks in advance Giovanni You will be better off doing a clean install. There are issues even upgrade from FC4. -- Leon From sundaram at fedoraproject.org Fri May 5 08:17:46 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 05 May 2006 13:47:46 +0530 Subject: Help! fc2->fc5 In-Reply-To: <31940999.1146816329493.JavaMail.www-data@www2> References: <31940999.1146816329493.JavaMail.www-data@www2> Message-ID: <1146817066.3802.302.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-05 at 10:05 +0200, gbiczo at freestart.hu wrote: > Hi all, > > I tried to upgrade my FC 2 system to FC5. For some reason, the installation/upgrade process stopped, I retryed several times, but haden't success. The installation is thus broken. > I decided to upgrade the packages manually. Now two questions emerged. > > 1. Graphical package installation (pirut?) doesn't work, seems it cannot find repository data. How can it be told to "look into" the installation cds? Is pirut the tool I need to use? (manual installation/upgrade is a bit difficult: deps). http://fedoraproject.org/wiki/Bugs/FC5Common has a link to configure pirut to use a local repository. > > 2. Tried to compile a kernel module for my lt winmodem. insmod won't load the module, exits with interesting error messages. Has anybody tried such a blasphemy under FC5? > Kernel is 2.6.16-1.2080 (Yes, because of nvidia...) No idea. > > aha! and a minor question: Release notes mentions, that fc5 doesn't support serial mice. Now my broken installation uses perfectly my old mouse (serial, of course), which is very > good. Is there an "official" possibility to use serial mice? It might work but dont file bugs if it breaks. Thats why I wrote it up as formally not supported. Rahul From avi at argo.co.il Fri May 5 09:11:25 2006 From: avi at argo.co.il (Avi Kivity) Date: Fri, 05 May 2006 12:11:25 +0300 Subject: Help! fc2->fc5 In-Reply-To: References: <31940999.1146816329493.JavaMail.www-data@www2> Message-ID: <445B16BD.3090100@argo.co.il> Leon wrote: > You will be better off doing a clean install. There are issues even > upgrade from FC4. > What are the issues? I upgraded two machines (using yum upgrade) from FC4 without trouble. I'd like to upgrade our server next (reinstallation is not an option) and would like to avoid any known issues. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From alan at redhat.com Fri May 5 09:19:42 2006 From: alan at redhat.com (Alan Cox) Date: Fri, 5 May 2006 05:19:42 -0400 Subject: Help! fc2->fc5 In-Reply-To: <1146817066.3802.302.camel@sundaram.pnq.redhat.com> References: <31940999.1146816329493.JavaMail.www-data@www2> <1146817066.3802.302.camel@sundaram.pnq.redhat.com> Message-ID: <20060505091942.GA1469@devserv.devel.redhat.com> On Fri, May 05, 2006 at 01:47:46PM +0530, Rahul Sundaram wrote: > > good. Is there an "official" possibility to use serial mice? > > It might work but dont file bugs if it breaks. Thats why I wrote it up > as formally not supported. On the other hand - do file fixes 8) From sdl.web at gmail.com Fri May 5 10:46:24 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 11:46:24 +0100 Subject: Help! fc2->fc5 References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> Message-ID: Avi Kivity writes: > Leon wrote: >> You will be better off doing a clean install. There are issues even >> upgrade from FC4. >> > > What are the issues? I upgraded two machines (using yum upgrade) from > FC4 without trouble. I'd like to upgrade our server next > (reinstallation is not an option) and would like to avoid any known > issues. Apparently, how many issues depends on how many packages you installed. In my case, for a desktop user you probably will find the boot is slow and gnome behaves weirdly etc for an upgrade install. Not sure for a server. -- Leon From sdl.web at gmail.com Fri May 5 11:03:39 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 12:03:39 +0100 Subject: [BUG] Clock always faster Message-ID: Dear all, I have found my system clock 4 minutes faster than the standard time. I remembered I have sysced with a ntp server before. To be precise, it will get 1.029561 sec faster in a two-hour interval. Does anyone else have the same experience? Do you think it is due to hardware or the kernel? Thanks. -- Leon From avi at argo.co.il Fri May 5 11:06:30 2006 From: avi at argo.co.il (Avi Kivity) Date: Fri, 05 May 2006 14:06:30 +0300 Subject: Help! fc2->fc5 In-Reply-To: References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> Message-ID: <445B31B6.2030308@argo.co.il> Leon wrote: >> What are the issues? I upgraded two machines (using yum upgrade) from >> FC4 without trouble. I'd like to upgrade our server next >> (reinstallation is not an option) and would like to avoid any known >> issues. >> > > Apparently, how many issues depends on how many packages you > installed. In my case, for a desktop user you probably will find the > boot is slow and gnome behaves weirdly etc for an upgrade install. > Well, I boot rarely and use KDE. Can you point me to a known issues page? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From sdl.web at gmail.com Fri May 5 11:06:33 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 12:06:33 +0100 Subject: [BUG] Clock always faster References: Message-ID: Leon writes: > Dear all, > > I have found my system clock 4 minutes faster than the standard > time. I remembered I have sysced with a ntp server before. > > To be precise, it will get 1.029561 sec faster in a two-hour interval. > > Does anyone else have the same experience? Do you think it is due to > hardware or the kernel? > > Thanks. > -- > Leon I'm using FC5 with kernel 2.6.16-1.2096. -- Leon From avi at argo.co.il Fri May 5 11:10:05 2006 From: avi at argo.co.il (Avi Kivity) Date: Fri, 05 May 2006 14:10:05 +0300 Subject: [BUG] Clock always faster In-Reply-To: References: Message-ID: <445B328D.80300@argo.co.il> Leon wrote: > Dear all, > > I have found my system clock 4 minutes faster than the standard > time. I remembered I have sysced with a ntp server before. > > To be precise, it will get 1.029561 sec faster in a two-hour interval. > > Does anyone else have the same experience? Do you think it is due to > hardware or the kernel? > That's about 140 ppm (parts per million). Bad, but I guess within PC tolerances. Keep the machine on ntp at all times if possible. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From dimi at lattica.com Fri May 5 11:28:20 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 05 May 2006 07:28:20 -0400 Subject: rawhide report: 20060505 changes In-Reply-To: <200605050731.k457VBSf019005@porkchop.devel.redhat.com> References: <200605050731.k457VBSf019005@porkchop.devel.redhat.com> Message-ID: <1146828500.15988.8.camel@dimi> On Fri, 2006-05-05 at 03:31 -0400, Build System wrote: > rpm-4.4.2-23 > ------------ > * Thu May 04 2006 Jeremy Katz - 4.4.2-23 > - make rpm-libs requires on base package stronger Any plans on upgrading rpm past 4.4.2? And if not, why not? -- Dimi Paun Lattica, Inc. From sdl.web at gmail.com Fri May 5 11:53:16 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 12:53:16 +0100 Subject: Help! fc2->fc5 References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> <445B31B6.2030308@argo.co.il> Message-ID: Avi Kivity writes: > Leon wrote: > > > >>> What are the issues? I upgraded two machines (using yum upgrade) from >>> FC4 without trouble. I'd like to upgrade our server next >>> (reinstallation is not an option) and would like to avoid any known >>> issues. >>> >> >> Apparently, how many issues depends on how many packages you >> installed. In my case, for a desktop user you probably will find the >> boot is slow and gnome behaves weirdly etc for an upgrade install. >> > > Well, I boot rarely and use KDE. Can you point me to a known issues page? > > -- > Do not meddle in the internals of kernels, for they are subtle and quick to panic. I have nothing handy:-( Have you tried fedora related urls: http://forums.fedoraforum.org/ http://www.tuxforums.org/forum/ http://www.linuxquestions.org/questions/f35 ... Start from fc5, I try to configure my system so that is will be upgradable in the sense I can easily restore my settings even for a fresh install. Usually, I will try in order: 1. use a local conf file e.g. /etc/fonts/local.conf /etc/ld.so.conf.d/ 2. Try achieve the same in sh script in /etc/profile.d for example to add java envs etc. 3. Edit the conf file that comes with the rpm but document the change and pay attention to warnings during upgrade like xx has been saved to xx.rpmsave etc. 1. and 2 are to make sure the list of changes as short as possible. I hope this will help me when I upgrade to FC7. -- Leon From sdl.web at gmail.com Fri May 5 11:53:59 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 12:53:59 +0100 Subject: [BUG] Clock always faster References: <445B328D.80300@argo.co.il> Message-ID: Avi Kivity writes: > Leon wrote: >> Dear all, >> >> I have found my system clock 4 minutes faster than the standard >> time. I remembered I have sysced with a ntp server before. >> >> To be precise, it will get 1.029561 sec faster in a two-hour interval. >> >> Does anyone else have the same experience? Do you think it is due to >> hardware or the kernel? >> > > That's about 140 ppm (parts per million). Bad, but I guess within PC > tolerances. > > Keep the machine on ntp at all times if possible. > If it's a bug, I'd like to see it fixed:-) Thanks. -- Leon From mailinglists at erwinrol.com Fri May 5 11:59:29 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 13:59:29 +0200 Subject: License question Message-ID: <1146830369.2630.62.camel@xpc.home.erwinrol.com> Hey all, I don't know what the best Fedora list is to ask this question, because on the project website i didn't find a list that really fitted this topic. A while back i said i was working on a Open-Xchange version that could work with GCJ, so that in the end it could be included in Fedora (extras). Some parts of Open-Xchange , the HTML, pictures, docu, are under a CC license. The "Attribution-NonCommercial-ShareAlike 2.5? to be exact ( http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode ) Now some Debian people have a problem with this license as described here; http://people.debian.org/~evan/ccsummary.html The question is does Fedora accept works that are (or partly are) under the mentioned CC license? In the case of Open-Xchange we are talking about ~3.5MB of pictures and HTML code, which is tightly coupled to java backend code (that is GPLed). So rewriting the frontend is just a waste of time and writing a new groupware would probably be faster (especially since there still has to be done a lot of work to make it compile with GCJ). If there is a better place for this question please let me know. - Erwin From paul at city-fan.org Fri May 5 12:07:10 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 May 2006 13:07:10 +0100 Subject: License question In-Reply-To: <1146830369.2630.62.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> Message-ID: <1146830831.19738.47.camel@laurel.intra.city-fan.org> On Fri, 2006-05-05 at 13:59 +0200, Erwin Rol wrote: > Hey all, > > I don't know what the best Fedora list is to ask this question, because > on the project website i didn't find a list that really fitted this > topic. > > A while back i said i was working on a Open-Xchange version that could > work with GCJ, so that in the end it could be included in Fedora > (extras). Some parts of Open-Xchange , the HTML, pictures, docu, are > under a CC license. The "Attribution-NonCommercial-ShareAlike 2.5? to be > exact ( http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode ) > Now some Debian people have a problem with this license as described > here; http://people.debian.org/~evan/ccsummary.html > The question is does Fedora accept works that are (or partly are) under > the mentioned CC license? > > In the case of Open-Xchange we are talking about ~3.5MB of pictures and > HTML code, which is tightly coupled to java backend code (that is > GPLed). So rewriting the frontend is just a waste of time and writing a > new groupware would probably be faster (especially since there still has > to be done a lot of work to make it compile with GCJ). > > If there is a better place for this question please let me know. The answer for Fedora would be the same as for Debian - it's a non-free license (the non-commercial use restriction) and so unsuitable for inclusion in Fedora as it stands. You could always write to fedora-legal at redhat.com if you *really* want confirmation but I'm sure that's the response you'd get. Paul. From sundaram at fedoraproject.org Fri May 5 12:13:30 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 05 May 2006 17:43:30 +0530 Subject: License question In-Reply-To: <1146830369.2630.62.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> Message-ID: <1146831210.3802.336.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-05 at 13:59 +0200, Erwin Rol wrote: > Hey all, > > I don't know what the best Fedora list is to ask this question, because > on the project website i didn't find a list that really fitted this > topic. > > A while back i said i was working on a Open-Xchange version that could > work with GCJ, so that in the end it could be included in Fedora > (extras). Some parts of Open-Xchange , the HTML, pictures, docu, are > under a CC license. The "Attribution-NonCommercial-ShareAlike 2.5? to be > exact ( http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode ) > Now some Debian people have a problem with this license as described > here; http://people.debian.org/~evan/ccsummary.html > The question is does Fedora accept works that are (or partly are) under > the mentioned CC license? Good to hear that more work is being done on enabling Open-Xchange to work on a free software stack. Non commercial clauses are unacceptable for inclusion in Fedora Core & Extras since they dont meet the packaging guidelines. We cant generalize about CC licenses without talking about specific details within the licenses in the context of Fedora. I believe that the attribution, sharealike, public domain ones are acceptable within Fedora while the others are not among the spectrum of creative common licenses . For content that originates from Fedora, we have settled down on the OPL license with no additional clauses. http://fedoraproject.org/wiki/Legal/Licenses/OPL If you need a authoritative answer on any particular license, Greg Dek is out gateway http://fedora.redhat.com/About/contact.html In this case, I am pretty sure my answer is right. Rahul From andy at warmcat.com Fri May 5 12:17:34 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 05 May 2006 13:17:34 +0100 Subject: License question In-Reply-To: <1146831210.3802.336.camel@sundaram.pnq.redhat.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <1146831210.3802.336.camel@sundaram.pnq.redhat.com> Message-ID: <445B425E.6040402@warmcat.com> Rahul Sundaram wrote: > Non commercial clauses are unacceptable for inclusion in Fedora Core & > Extras since they dont meet the packaging guidelines. We cant generalize > about CC licenses without talking about specific details within the > licenses in the context of Fedora. I believe that the attribution, > sharealike, public domain ones are acceptable within Fedora while the > others are not among the spectrum of creative common licenses . I think you maybe mean "not among the spectrum of Free licenses". Noncommercial especially is a bit of a potential nightmare because 'commercial' is not properly defined. I hope the OP can go the whole hog and lose the commercial prohibition. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From jos at xos.nl Fri May 5 12:19:36 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 14:19:36 +0200 Subject: License question In-Reply-To: <1146830369.2630.62.camel@xpc.home.erwinrol.com>; from mailinglists@erwinrol.com on Fri, May 05, 2006 at 01:59:29PM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> Message-ID: <20060505141936.A20603@xos037.xos.nl> On Fri, May 05, 2006 at 01:59:29PM +0200, Erwin Rol wrote: > In the case of Open-Xchange we are talking about ~3.5MB of pictures and > HTML code, which is tightly coupled to java backend code (that is > GPLed). So rewriting the frontend is just a waste of time and writing a > new groupware would probably be faster (especially since there still has > to be done a lot of work to make it compile with GCJ). Referring to "writing a new groupware": what about putting the work in getting OpenGroupware.org suitable for Fedora? AFAIK OGo is licensed as GPL (and partly as LGPL). Unfortunately, OGo is w.r.t. packaging a real mess (last time I looked I saw that binary packages existed that had no source packages). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jos at xos.nl Fri May 5 12:21:43 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 14:21:43 +0200 Subject: License question In-Reply-To: <445B425E.6040402@warmcat.com>; from andy@warmcat.com on Fri, May 05, 2006 at 01:17:34PM +0100 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <1146831210.3802.336.camel@sundaram.pnq.redhat.com> <445B425E.6040402@warmcat.com> Message-ID: <20060505142143.B20603@xos037.xos.nl> On Fri, May 05, 2006 at 01:17:34PM +0100, Andy Green wrote: > Noncommercial especially is a bit of a potential nightmare because > 'commercial' is not properly defined. I hope the OP can go the whole Even if it *is* properly defined, it's unacceptable as OS license. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mailinglists at erwinrol.com Fri May 5 12:30:58 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 14:30:58 +0200 Subject: License question In-Reply-To: <445B425E.6040402@warmcat.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <1146831210.3802.336.camel@sundaram.pnq.redhat.com> <445B425E.6040402@warmcat.com> Message-ID: <1146832258.2630.75.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 13:17 +0100, Andy Green wrote: > Rahul Sundaram wrote: > > > Non commercial clauses are unacceptable for inclusion in Fedora Core & > > Extras since they dont meet the packaging guidelines. We cant generalize > > about CC licenses without talking about specific details within the > > licenses in the context of Fedora. I believe that the attribution, > > sharealike, public domain ones are acceptable within Fedora while the > > others are not among the spectrum of creative common licenses . > > I think you maybe mean "not among the spectrum of Free licenses". > Noncommercial especially is a bit of a potential nightmare because > 'commercial' is not properly defined. I hope the OP can go the whole > hog and lose the commercial prohibition. Well I had a "mega" discussion on the Open-Xchange list with the Netline people (the "owner" of Open-Xchange) and someone working on Debian packages. The result of that discussion seems to be it is the CC "Attribution-NonCommercial-ShareAlike 2.5? and stays that way. A second smaller problem was/is that Netline wants a copyright assignment for new code so they can use it in their commercial version. At the moment there are only two people "complaining" about the license, maybe they are willing to listen if more people politely ask to put the CC parts under a license that is acceptable for inclusion in Fedora and Debian. - Erwin From mailinglists at erwinrol.com Fri May 5 12:33:20 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 14:33:20 +0200 Subject: License question In-Reply-To: <20060505141936.A20603@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> Message-ID: <1146832401.2630.79.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 14:19 +0200, Jos Vos wrote: > On Fri, May 05, 2006 at 01:59:29PM +0200, Erwin Rol wrote: > > > In the case of Open-Xchange we are talking about ~3.5MB of pictures and > > HTML code, which is tightly coupled to java backend code (that is > > GPLed). So rewriting the frontend is just a waste of time and writing a > > new groupware would probably be faster (especially since there still has > > to be done a lot of work to make it compile with GCJ). > > Referring to "writing a new groupware": what about putting the work > in getting OpenGroupware.org suitable for Fedora? AFAIK OGo is > licensed as GPL (and partly as LGPL). Unfortunately, OGo is w.r.t. > packaging a real mess (last time I looked I saw that binary packages > existed that had no source packages). That is pretty much just a matter of taste, I really like the look and feel of Open-Xchange, especially the webmail part (which i dislike in OGo). But if it is really impossible to add Open-Xchange than, yes I will rather spend my time on OGo. - Erwin From nicu_fedora at nicubunu.ro Fri May 5 12:07:12 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 05 May 2006 15:07:12 +0300 Subject: License question In-Reply-To: <1146830369.2630.62.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> Message-ID: <445B3FF0.5070202@nicubunu.ro> Erwin Rol wrote: > > A while back i said i was working on a Open-Xchange version that could > work with GCJ, so that in the end it could be included in Fedora > (extras). Some parts of Open-Xchange , the HTML, pictures, docu, are > under a CC license. The "Attribution-NonCommercial-ShareAlike 2.5? to be > exact ( http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode ) > Now some Debian people have a problem with this license as described > here; http://people.debian.org/~evan/ccsummary.html > The question is does Fedora accept works that are (or partly are) under > the mentioned CC license? In my understanding, the "NonCommercial" part is a show stopper. > In the case of Open-Xchange we are talking about ~3.5MB of pictures and > HTML code, which is tightly coupled to java backend code (that is > GPLed). So rewriting the frontend is just a waste of time and writing a > new groupware would probably be faster (especially since there still has > to be done a lot of work to make it compile with GCJ). How about replacing this part with something under an acceptable license? The pictures consist of what? icons? -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From avi at argo.co.il Fri May 5 12:42:21 2006 From: avi at argo.co.il (Avi Kivity) Date: Fri, 05 May 2006 15:42:21 +0300 Subject: [BUG] Clock always faster In-Reply-To: References: <445B328D.80300@argo.co.il> Message-ID: <445B482D.8010806@argo.co.il> Leon wrote: > Avi Kivity writes: > > >> Leon wrote: >> >>> Dear all, >>> >>> I have found my system clock 4 minutes faster than the standard >>> time. I remembered I have sysced with a ntp server before. >>> >>> To be precise, it will get 1.029561 sec faster in a two-hour interval. >>> >>> Does anyone else have the same experience? Do you think it is due to >>> hardware or the kernel? >>> >>> >> That's about 140 ppm (parts per million). Bad, but I guess within PC >> tolerances. >> >> Keep the machine on ntp at all times if possible. >> >> > > If it's a bug, I'd like to see it fixed:-) Thanks. > It's just not-very-good hardware as far as I can tell. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From mailinglists at erwinrol.com Fri May 5 12:46:19 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 14:46:19 +0200 Subject: License question In-Reply-To: <445B3FF0.5070202@nicubunu.ro> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <445B3FF0.5070202@nicubunu.ro> Message-ID: <1146833179.2630.94.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 15:07 +0300, Nicu Buculei wrote: > Erwin Rol wrote: > > In the case of Open-Xchange we are talking about ~3.5MB of pictures and > > HTML code, which is tightly coupled to java backend code (that is > > GPLed). So rewriting the frontend is just a waste of time and writing a > > new groupware would probably be faster (especially since there still has > > to be done a lot of work to make it compile with GCJ). > > How about replacing this part with something under an acceptable > license? The pictures consist of what? icons? The pictures would be simple to replace, there are only a few icons (and they aren't even very pretty :-). The problem is the large part of HTML code with "tags" that get replaced by the back end. Replacing all this will be a very large task. It will also mean a fork from the original Open-Xchange which I think would be a shame. - Erwin From jos at xos.nl Fri May 5 12:51:06 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 14:51:06 +0200 Subject: License question In-Reply-To: <1146832258.2630.75.camel@xpc.home.erwinrol.com>; from mailinglists@erwinrol.com on Fri, May 05, 2006 at 02:30:58PM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <1146831210.3802.336.camel@sundaram.pnq.redhat.com> <445B425E.6040402@warmcat.com> <1146832258.2630.75.camel@xpc.home.erwinrol.com> Message-ID: <20060505145106.A20737@xos037.xos.nl> On Fri, May 05, 2006 at 02:30:58PM +0200, Erwin Rol wrote: > At the moment there are only two people "complaining" about the license, > maybe they are willing to listen if more people politely ask to put the > CC parts under a license that is acceptable for inclusion in Fedora and > Debian. Some people do not understand "true" Open Source, some people do not *want* to understand "true" Open Source. It's always the question in which group people belong, I have a strong feeling the Netline people belong in the last category. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From andy at warmcat.com Fri May 5 13:00:03 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 05 May 2006 14:00:03 +0100 Subject: License question In-Reply-To: <1146832258.2630.75.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <1146831210.3802.336.camel@sundaram.pnq.redhat.com> <445B425E.6040402@warmcat.com> <1146832258.2630.75.camel@xpc.home.erwinrol.com> Message-ID: <445B4C53.40806@warmcat.com> Erwin Rol wrote: >> Noncommercial especially is a bit of a potential nightmare because >> 'commercial' is not properly defined. > Well I had a "mega" discussion on the Open-Xchange list with the Netline > people (the "owner" of Open-Xchange) and someone working on Debian > packages. The result of that discussion seems to be it is the CC > "Attribution-NonCommercial-ShareAlike 2.5? and stays that way. A second > smaller problem was/is that Netline wants a copyright assignment for new > code so they can use it in their commercial version. Hum obviously no coincidence that they want to offer it commercially themselves and insist that the 'free' version is under noncommercial terms then, and the assignment is to guarantee they are in a position to enforce the situation. They can do what they like, but such a system AND inviting external patches you demand copyright assignments for is like being a little bit pregnant. > At the moment there are only two people "complaining" about the license, > maybe they are willing to listen if more people politely ask to put the > CC parts under a license that is acceptable for inclusion in Fedora and > Debian. The discussion seems to exist here: http://www.open-xchange.org/pipermail/general/2006-May/thread.html It seems the key question starts here: http://www.open-xchange.org/pipermail/general/2006-May/048756.html -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From jos at xos.nl Fri May 5 13:04:56 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 15:04:56 +0200 Subject: License question In-Reply-To: <1146832401.2630.79.camel@xpc.home.erwinrol.com>; from mailinglists@erwinrol.com on Fri, May 05, 2006 at 02:33:20PM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> Message-ID: <20060505150456.B20737@xos037.xos.nl> On Fri, May 05, 2006 at 02:33:20PM +0200, Erwin Rol wrote: > That is pretty much just a matter of taste, I really like the look and > feel of Open-Xchange, especially the webmail part (which i dislike in > OGo). But if it is really impossible to add Open-Xchange than, yes I > will rather spend my time on OGo. It's difficult to judge what package "the leading" groupware will be (if any), but until now I'd put my coins on OGo. I have only globally compared all the options (including suites like Horde etc.), but all options are either a complex mess (and extremely difficult to package) or they lack functionality or a big community (or both). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From benjamin.thery at bull.net Fri May 5 13:18:40 2006 From: benjamin.thery at bull.net (Benjamin Thery) Date: Fri, 05 May 2006 15:18:40 +0200 Subject: Old Flex version in FC5? In-Reply-To: <1146777918.5627.38.camel@atlantis.mpeters.local> References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <445A1007.4010106@math.unl.edu> <1146777918.5627.38.camel@atlantis.mpeters.local> Message-ID: <445B50B0.7070400@bull.net> Michael A. Peters wrote: > On Thu, 2006-05-04 at 09:30 -0500, Rex Dieter wrote: > >> Probably explains why Benjamin noticed other distros with 2 flex >> packages (one old, one new). Perhaps someone could review possibilities >> of dually-installed flex pkgs, and submit the "new" one to Extras. (: > > Does Debian install them parallel installable? Doesn't seem so. The files overwrite each others: http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=flex-old&version=unstable&arch=i386 > I remember this being discussed before in an Extras review - where > someone was submitting a package that needed the new flex. > > If I remember, the problem was that the new flex would have to be > installed in such a way that it was never used by mistake, and no one > had submitted a package yet. The package ended up being patched to not > need the new flex, and nothing more came of it. > > How many software packages out there do not build on Fedora Core for > lack of the new flex? -- B e n j a m i n T h e r y - BULL/DT/Open Software R&D http://www.bull.com From mailinglists at erwinrol.com Fri May 5 13:20:03 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 15:20:03 +0200 Subject: License question In-Reply-To: <20060505150456.B20737@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> Message-ID: <1146835203.2630.118.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 15:04 +0200, Jos Vos wrote: > On Fri, May 05, 2006 at 02:33:20PM +0200, Erwin Rol wrote: > > > That is pretty much just a matter of taste, I really like the look and > > feel of Open-Xchange, especially the webmail part (which i dislike in > > OGo). But if it is really impossible to add Open-Xchange than, yes I > > will rather spend my time on OGo. > > It's difficult to judge what package "the leading" groupware will be > (if any), but until now I'd put my coins on OGo. I have only globally > compared all the options (including suites like Horde etc.), but all > options are either a complex mess (and extremely difficult to package) > or they lack functionality or a big community (or both). Yes finding a good Free groupware is not easy, I would almost dare to say there are no good Free groupwares :-/ They all have some problems or missing features, most of them have the "major pain to setup" problem though, like OGo. - Erwin From jos at xos.nl Fri May 5 13:33:41 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 15:33:41 +0200 Subject: License question In-Reply-To: <1146835203.2630.118.camel@xpc.home.erwinrol.com>; from mailinglists@erwinrol.com on Fri, May 05, 2006 at 03:20:03PM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <1146835203.2630.118.camel@xpc.home.erwinrol.com> Message-ID: <20060505153341.C20737@xos037.xos.nl> On Fri, May 05, 2006 at 03:20:03PM +0200, Erwin Rol wrote: > Yes finding a good Free groupware is not easy, I would almost dare to > say there are no good Free groupwares :-/ They all have some problems or True, or maybe we have to add "not yet". > missing features, most of them have the "major pain to setup" problem > though, like OGo. It's the same in the ERP world, looking an Compiere, tinyERP, etc. :-(. And the "interesting" combinations of free and non-free things... B.t.w., not sure why RH has not yet put (al least not visible) some of their resources on properly packaging something like OGo, as groupware would be a welcome addition to RHEL too and I think it *is* doable, although it will cost some effort. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mailinglists at erwinrol.com Fri May 5 13:48:32 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 15:48:32 +0200 Subject: License question In-Reply-To: <20060505153341.C20737@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <1146835203.2630.118.camel@xpc.home.erwinrol.com> <20060505153341.C20737@xos037.xos.nl> Message-ID: <1146836913.2630.139.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 15:33 +0200, Jos Vos wrote: > On Fri, May 05, 2006 at 03:20:03PM +0200, Erwin Rol wrote: > > > Yes finding a good Free groupware is not easy, I would almost dare to > > say there are no good Free groupwares :-/ They all have some problems or > > True, or maybe we have to add "not yet". Yeah FOSS can do anything, just "not yet" ;-) > > missing features, most of them have the "major pain to setup" problem > > though, like OGo. > > It's the same in the ERP world, looking an Compiere, tinyERP, etc. :-(. > And the "interesting" combinations of free and non-free things... Yeah lot of companies seem to use FOSS as advertising "Our Free GPL blabla" and with a closer look all the good features are closed source. > B.t.w., not sure why RH has not yet put (al least not visible) some > of their resources on properly packaging something like OGo, as > groupware would be a welcome addition to RHEL too and I think it > *is* doable, although it will cost some effort. Yeah especially now Fedora has a great Directory Server and with the upcoming Samba 4 the next thing missing is a good groupware/ERP. These would be the perfect features for a small business, and if those businesses grow they are perfect clients for Red Hat. Maybe RH should not only look for someone to manage Evolution but at the same time someone for OGo and make them work together so Evolution integrates perfectly with OGo. - Erwin From dimi at lattica.com Fri May 5 13:49:57 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 5 May 2006 09:49:57 -0400 (EDT) Subject: License question In-Reply-To: <20060505150456.B20737@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> Message-ID: <35489.207.35.222.39.1146836997.squirrel@lattica.com> On Fri, May 5, 2006 9:04 am, Jos Vos wrote: > It's difficult to judge what package "the leading" groupware will be > (if any), but until now I'd put my coins on OGo. I have only globally > compared all the options (including suites like Horde etc.), but all > options are either a complex mess (and extremely difficult to package) > or they lack functionality or a big community (or both). Speaking of Exchange alternatives, how about things like: * http://zimbra.com/ * http://www.egroupware.org/ * http://www.citadel.org/ * http://www.exchange4linux.org/ * http://hula-project.org/ In particular Zimbra, it looks very good. Do people have any experience with any of these? -- Dimi Paun Lattica, Inc. From che666 at gmail.com Fri May 5 13:51:47 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 5 May 2006 15:51:47 +0200 Subject: [aiglx] repo -> outdated vte lib Message-ID: Hello! Actually the vte library in the aiglx repo needs an update. FC5 has vte 0.12.1 wheras aiglx comes with 0.12.0. As a result -> gnome-terminal doesent start anymore regards, Rudolf Kastl p.s. are there new packages coming soon? Simply ask because i also have that "blue everything" problem when turning metacitys composite manager on. Radeon 9000 mobile here. r250. From jos at xos.nl Fri May 5 14:03:28 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 16:03:28 +0200 Subject: License question In-Reply-To: <35489.207.35.222.39.1146836997.squirrel@lattica.com>; from dimi@lattica.com on Fri, May 05, 2006 at 09:49:57AM -0400 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> Message-ID: <20060505160328.D20737@xos037.xos.nl> On Fri, May 05, 2006 at 09:49:57AM -0400, Dimi Paun wrote: > In particular Zimbra, it looks very good. Do people have any > experience with any of these? Note the difference between the "Open Source edition" and the "Network edition"... Also not sure whether their addendum for the MPL is Open Source compliant. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mailinglists at erwinrol.com Fri May 5 14:06:04 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 16:06:04 +0200 Subject: License question In-Reply-To: <35489.207.35.222.39.1146836997.squirrel@lattica.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> Message-ID: <1146837964.2630.148.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 09:49 -0400, Dimi Paun wrote: > On Fri, May 5, 2006 9:04 am, Jos Vos wrote: > > It's difficult to judge what package "the leading" groupware will be > > (if any), but until now I'd put my coins on OGo. I have only globally > > compared all the options (including suites like Horde etc.), but all > > options are either a complex mess (and extremely difficult to package) > > or they lack functionality or a big community (or both). > > Speaking of Exchange alternatives, how about things like: > * http://zimbra.com/ > * http://www.egroupware.org/ > * http://www.citadel.org/ > * http://www.exchange4linux.org/ > * http://hula-project.org/ > > In particular Zimbra, it looks very good. Do people have any > experience with any of these? Zimbra also has most of its interesting features in the closed source version only http://zimbra.com/products/product_editions.html . Like Jos mentioned most groupwares are an interesting mix of Free and closed source things, where the "nice" features are in the closed source version. - Erwin From che666 at gmail.com Fri May 5 14:06:41 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 5 May 2006 16:06:41 +0200 Subject: Cannot log in to a GNOME desktop In-Reply-To: <1146791203.26527.5.camel@localhost.localdomain> References: <1146733408.32373.22.camel@localhost.localdomain> <1146791203.26527.5.camel@localhost.localdomain> Message-ID: 2006/5/5, Emeric Maschino : > > What can prevent a user to log in a GNOME session? When entering my > > username and password at the GDM log in screen, I immediately get a > > dialog box telling me that the X session lasts less than 10 sec and that > > some help can be provided by the ~/.xsession_error. Well, this file > > doesn't even exist. I've tried the "Last session" and "Default GNOME > > session" options in the GDM log in screen without a success. Same > > problem for root. This is on an Itanium workstation (ia64) with a fresh > > install of Fedora Core Rawhide on May 2nd, updated with the latest > > packages. I don't know if this problem also appears on other > > architectures. Roughly a month ago (before my filesystem problem), I > > didn't have this problem. But a lot of things have changed since... > > I've performed regression tests and finally isolate the faulty package: > it's gnome-session-2.14.1-2. Reverting to FC5 original gnome- > session-2.14.0-1 solves the problem. I don't know if other versions > where built in the meantime, so I can't precisely determine whether the > log in problem only appears with the latest gnome-session version or > not. Does this issue only affect ia64 systems or other architectures > too? Should I file a bug report? you have most probably found a regression bug... look if its already filed... if not... file it. regards, Rudolf Kastl > > ?meric > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dimi at lattica.com Fri May 5 14:07:01 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 5 May 2006 10:07:01 -0400 (EDT) Subject: License question In-Reply-To: <20060505160328.D20737@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <20060505160328.D20737@xos037.xos.nl> Message-ID: <60012.207.35.222.39.1146838021.squirrel@lattica.com> On Fri, May 5, 2006 10:03 am, Jos Vos wrote: > Note the difference between the "Open Source edition" and the > "Network edition"... Even the open source edition is looking good, and seems to offer quite a bit more then a snmp+imap server. > Also not sure whether their addendum for the MPL is Open Source > compliant. That's a good question. Is it? What problem do you think it has BTW? -- Dimi Paun Lattica, Inc. From dimi at lattica.com Fri May 5 14:12:41 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 5 May 2006 10:12:41 -0400 (EDT) Subject: License question In-Reply-To: <1146837964.2630.148.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <1146837964.2630.148.camel@xpc.home.erwinrol.com> Message-ID: <39481.207.35.222.39.1146838361.squirrel@lattica.com> On Fri, May 5, 2006 10:06 am, Erwin Rol wrote: > Zimbra also has most of its interesting features in the closed source > version only http://zimbra.com/products/product_editions.html . We are getting picky folks. Zimbra offers quite a bit in the free version, in fact it would be more than enough for a small-business, and surely a lot more than we have today. As for the "nice" closed features, while indeed nice, no free version even _claims_ that they are (or will be) supporting similar capabilities. So it's not like we're loosing anything :) Why should we fault them for not providing the world to us? They do provide quite a bit as it is. -- Dimi Paun Lattica, Inc. From che666 at gmail.com Fri May 5 14:17:02 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 5 May 2006 16:17:02 +0200 Subject: License question In-Reply-To: <60012.207.35.222.39.1146838021.squirrel@lattica.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <20060505160328.D20737@xos037.xos.nl> <60012.207.35.222.39.1146838021.squirrel@lattica.com> Message-ID: 2006/5/5, Dimi Paun : > > On Fri, May 5, 2006 10:03 am, Jos Vos wrote: > > Note the difference between the "Open Source edition" and the > > "Network edition"... > > Even the open source edition is looking good, and seems to offer > quite a bit more then a snmp+imap server. > > > Also not sure whether their addendum for the MPL is Open Source > > compliant. > > That's a good question. Is it? What problem do you think it has BTW? > > -- > Dimi Paun > Lattica, Inc. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > No one listed kolab(2) yet. Guess thats my part. regards, Rudolf Kastl From jos at xos.nl Fri May 5 14:21:31 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 16:21:31 +0200 Subject: License question In-Reply-To: <1146836913.2630.139.camel@xpc.home.erwinrol.com>; from mailinglists@erwinrol.com on Fri, May 05, 2006 at 03:48:32PM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <1146835203.2630.118.camel@xpc.home.erwinrol.com> <20060505153341.C20737@xos037.xos.nl> <1146836913.2630.139.camel@xpc.home.erwinrol.com> Message-ID: <20060505162131.E20737@xos037.xos.nl> On Fri, May 05, 2006 at 03:48:32PM +0200, Erwin Rol wrote: > Yeah FOSS can do anything, just "not yet" ;-) :-) > Yeah lot of companies seem to use FOSS as advertising "Our Free GPL > blabla" and with a closer look all the good features are closed source. Open Source is abused very often as a marketing tool. And this is done very intentionally, IMHO. > Yeah especially now Fedora has a great Directory Server and with the > upcoming Samba 4 the next thing missing is a good groupware/ERP. These > would be the perfect features for a small business, and if those > businesses grow they are perfect clients for Red Hat. I completely agree. A few people working on the (existing) tools from the RH/Fedora point of view would help a lot. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ajackson at redhat.com Fri May 5 13:21:47 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 05 May 2006 09:21:47 -0400 Subject: [aiglx] repo -> outdated vte lib In-Reply-To: References: Message-ID: <445B516B.8020400@redhat.com> Rudolf Kastl wrote: > p.s. are there new packages coming soon? Simply ask because i also > have that "blue everything" problem when turning metacitys composite > manager on. > Radeon 9000 mobile here. r250. This is a driver bug. I still have no idea what the fix is, and I've had basically no time to look at it on account of 7.1 release management taking higher priority. Until you see a rawhide update with a message saying "fixes blue screen of death", assume this hasn't been fixed. - ajax From mailinglists at erwinrol.com Fri May 5 14:23:15 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 05 May 2006 16:23:15 +0200 Subject: License question In-Reply-To: <39481.207.35.222.39.1146838361.squirrel@lattica.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <1146837964.2630.148.camel@xpc.home.erwinrol.com> <39481.207.35.222.39.1146838361.squirrel@lattica.com> Message-ID: <1146838995.2630.154.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 10:12 -0400, Dimi Paun wrote: > On Fri, May 5, 2006 10:06 am, Erwin Rol wrote: > > Zimbra also has most of its interesting features in the closed source > > version only http://zimbra.com/products/product_editions.html . > > We are getting picky folks. Zimbra offers quite a bit in the free > version, in fact it would be more than enough for a small-business, > and surely a lot more than we have today. > > As for the "nice" closed features, while indeed nice, no free version > even _claims_ that they are (or will be) supporting similar capabilities. > So it's not like we're loosing anything :) > > Why should we fault them for not providing the world to us? They do > provide quite a bit as it is. The problem is not that there are feature missing in the Free version, the problem is how do those companies react when someone implements those missing feature in the Free version ? Do they really want a community project like the Linux kernel or do they only want to have free advertising by the people that use the Free version? - Erwin From jdesbonnet at gmail.com Fri May 5 14:24:16 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Fri, 5 May 2006 15:24:16 +0100 Subject: [BUG] Clock always faster In-Reply-To: <445B482D.8010806@argo.co.il> References: <445B328D.80300@argo.co.il> <445B482D.8010806@argo.co.il> Message-ID: <1cef3e950605050724w6cc08888j3d7c3c05861596cf@mail.gmail.com> If a clock is found to be running predictibly fast or slow is it possible to correct that somehow? Presumably there is a register somewhere that specifies the number of clock cycles per unit time (?) On 5/5/06, Avi Kivity wrote: > > It's just not-very-good hardware as far as I can tell. > From nalin at redhat.com Fri May 5 14:24:45 2006 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 5 May 2006 10:24:45 -0400 Subject: AIGLX breaks XServer with new Repo In-Reply-To: References: <20060504192601.GA8365@redhat.com> Message-ID: <20060505142445.GA14102@redhat.com> On Fri, May 05, 2006 at 02:06:51AM -0400, Benjy Grogan wrote: > On 5/4/06, Nalin Dahyabhai wrote: > >On Thu, May 04, 2006 at 12:29:45AM -0400, Benjy Grogan wrote: > >> I had AIGLX working on FC5 using the old aiglx.repo that pointed to > >> Ray Strode's repo. I recently dropped in the new aiglx.repo that > >> Kristian Hogsberg posted a few weeks ago and the result was that my > >> XServer won't start anymore. > >[snip] > >> (EE) module ABI minor version (5) is newer than the server's version (4) > >[snip] > > > >Are you still using Xair (from the old xorg-x11-server-Xair package in > >Ray's repository, which is out of date) as your server? > > Yes, Xair was always at the top of the list in System Monitor in terms > of processor time. So, if that Xair should no longer be there, how do > I remove it and properly replace it with the right Xorg? First, remove the xorg-x11-server-Xair package. If you modified your desktop manager's configuration to call Xair instead of Xorg [1], you may need to change it back. If you use "startx" and modified your .xserverrc to call Xair instead of Xorg, revert that change. Cheers, Nalin [1] From an older revision of the wiki page: http://fedoraproject.org/wiki/RenderingProject/AiglxOnFedora?action=recall&rev=13 From jos at xos.nl Fri May 5 14:25:18 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 16:25:18 +0200 Subject: License question In-Reply-To: ; from che666@gmail.com on Fri, May 05, 2006 at 04:17:02PM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <20060505160328.D20737@xos037.xos.nl> <60012.207.35.222.39.1146838021.squirrel@lattica.com> Message-ID: <20060505162518.F20737@xos037.xos.nl> On Fri, May 05, 2006 at 04:17:02PM +0200, Rudolf Kastl wrote: > No one listed kolab(2) yet. Guess thats my part. Isn't that very KDE-specific? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From dimi at lattica.com Fri May 5 14:30:33 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 5 May 2006 10:30:33 -0400 (EDT) Subject: License question In-Reply-To: <1146838995.2630.154.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <1146837964.2630.148.camel@xpc.home.erwinrol.com> <39481.207.35.222.39.1146838361.squirrel@lattica.com> <1146838995.2630.154.camel@xpc.home.erwinrol.com> Message-ID: <35285.207.35.222.39.1146839433.squirrel@lattica.com> On Fri, May 5, 2006 10:23 am, Erwin Rol wrote: > The problem is not that there are feature missing in the Free version, > the problem is how do those companies react when someone implements > those missing feature in the Free version ? Yes, a pertinent question, but I guess we have to try and see :) Regardless, it does seems to me that the free version of Zimbra is a pretty polished offering. Question still stands: why not use that? -- Dimi Paun Lattica, Inc. From redhat at olen.net Fri May 5 14:32:35 2006 From: redhat at olen.net (Ola Thoresen) Date: Fri, 5 May 2006 14:32:35 +0000 (UTC) Subject: License question References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <39481.207.35.222.39.1146838361.squirrel@lattica.com> Message-ID: 2006-05-05 "Dimi Paun" wrote > > On Fri, May 5, 2006 10:06 am, Erwin Rol wrote: >> Zimbra also has most of its interesting features in the closed source >> version only http://zimbra.com/products/product_editions.html . > > We are getting picky folks. Zimbra offers quite a bit in the free > version, in fact it would be more than enough for a small-business, > and surely a lot more than we have today. The main issue I had last time I tested zimbra was that it had to "take over" the entire server (xen comes to mind, but that was not an option at the time). It would not allow you to use the existing accounts, imap-server, smtp-server and all other already running services. I'd prefer something that will live and play nicely with an existing installation, so I can access my mail with both mutt, imap, mapi and webmail - depending on where I am and what client I have available. Rgds. Ola Thoresen From rdieter at math.unl.edu Fri May 5 14:33:01 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 05 May 2006 09:33:01 -0500 Subject: License question References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <20060505160328.D20737@xos037.xos.nl> <60012.207.35.222.39.1146838021.squirrel@lattica.com> <20060505162518.F20737@xos037.xos.nl> Message-ID: Jos Vos wrote: > On Fri, May 05, 2006 at 04:17:02PM +0200, Rudolf Kastl wrote: > >> No one listed kolab(2) yet. Guess thats my part. > > Isn't that very KDE-specific? In general, no. -- Rex From lamont at gurulabs.com Fri May 5 14:39:35 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 5 May 2006 08:39:35 -0600 Subject: [BUG] Clock always faster In-Reply-To: <1cef3e950605050724w6cc08888j3d7c3c05861596cf@mail.gmail.com> References: <445B482D.8010806@argo.co.il> <1cef3e950605050724w6cc08888j3d7c3c05861596cf@mail.gmail.com> Message-ID: <200605050839.41086.lamont@gurulabs.com> On Friday 05 May 2006 08:24am, Joe Desbonnet wrote: > If a clock is found to be running predictibly fast or slow is it > possible to correct that somehow? Run ntpd. That will keep the system clock in sync. It could be a bug in the BIOS. I recently dealt with some AMD64 X2 boxes (from Alienware) that had a really big issue similar to this because of the way the BIOS was configuring (or not properly configuring) the APIC. If we ran an SMP kernel on those boxes under those conditions, the delay loop was seriously miscalibrated and we would see the clock stall & jump. It also made it extremely difficult to type as the briefest of touches to a key would cause anywhere from 2-20 keypresses to register, even after we had turned the keyboard repeat rates all the way down. Running a uniprocessor kernel cured all our woes. A little more testing pointed towards the APIC config, but the BIOS those boxes had didn't give us enough control to be 100% certain about that. Unfortunately, we were running in an isolated environment, so we couldn't check for nor try to pick up an updated BIOS for those boxes. [snip] -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dimi at lattica.com Fri May 5 14:41:41 2006 From: dimi at lattica.com (Dimi Paun) Date: Fri, 5 May 2006 10:41:41 -0400 (EDT) Subject: License question In-Reply-To: References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <39481.207.35.222.39.1146838361.squirrel@lattica.com> Message-ID: <51926.207.35.222.39.1146840101.squirrel@lattica.com> On Fri, May 5, 2006 10:32 am, Ola Thoresen wrote: > The main issue I had last time I tested zimbra was that it had to "take > over" the entire server (xen comes to mind, but that was not an option > at the time). That is indeed a nasty thing. I haven't personally installed Zimbra, but I was planning to do so soon, but this may be a deal breaker for me. > It would not allow you to use the existing accounts, imap-server, > smtp-server and all other already running services. > I'd prefer something that will live and play nicely with an existing > installation, so I can access my mail with both mutt, imap, mapi and > webmail - depending on where I am and what client I have available. But doesn't Zimbra offer IMAP/IMAPS support? What about POP/POPS? I thought it did... -- Dimi Paun Lattica, Inc. From jos at xos.nl Fri May 5 14:41:57 2006 From: jos at xos.nl (Jos Vos) Date: Fri, 5 May 2006 16:41:57 +0200 Subject: License question In-Reply-To: <35285.207.35.222.39.1146839433.squirrel@lattica.com>; from dimi@lattica.com on Fri, May 05, 2006 at 10:30:33AM -0400 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <35489.207.35.222.39.1146836997.squirrel@lattica.com> <1146837964.2630.148.camel@xpc.home.erwinrol.com> <39481.207.35.222.39.1146838361.squirrel@lattica.com> <1146838995.2630.154.camel@xpc.home.erwinrol.com> <35285.207.35.222.39.1146839433.squirrel@lattica.com> Message-ID: <20060505164157.G20737@xos037.xos.nl> On Fri, May 05, 2006 at 10:30:33AM -0400, Dimi Paun wrote: > Yes, a pertinent question, but I guess we have to try and see :) > Regardless, it does seems to me that the free version of Zimbra > is a pretty polished offering. Question still stands: why not use that? I think you can't compare it with functionality like in OGo (but I'd have to look in more detail to be sure about that). And Erwin made a good comment about the community aspect. There is no "community roadmap" possible for such a product, which is a huge disadvantage to take into account, no matter how nice the product looks. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From lamont at gurulabs.com Fri May 5 14:42:26 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 5 May 2006 08:42:26 -0600 Subject: Help! fc2->fc5 In-Reply-To: <445B16BD.3090100@argo.co.il> References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> Message-ID: <200605050842.26544.lamont@gurulabs.com> On Friday 05 May 2006 03:11am, Avi Kivity wrote: > Leon wrote: > > You will be better off doing a clean install. There are issues even > > upgrade from FC4. > > What are the issues? I upgraded two machines (using yum upgrade) from > FC4 without trouble. I'd like to upgrade our server next (reinstallation > is not an option) and would like to avoid any known issues. Then you need to upgrade from FC2 -> FC3 -> FC4 -> FC5. Also, don't do "yum upgrade", use anaconda, booting from a CD instead. Using "yum upgrade" there are 20 some odd "corner cases" and such that are not handled (things about the changes between FC4 -> FC5. Anaconda knows these things and gets things right. I had excellent results upgrading my FC4 notebook to FC5 using Anaconda. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From benjy.grogan at gmail.com Fri May 5 15:22:39 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 5 May 2006 11:22:39 -0400 Subject: [aiglx] repo -> outdated vte lib In-Reply-To: References: Message-ID: On 5/5/06, Rudolf Kastl wrote: > Hello! > > Actually the vte library in the aiglx repo needs an update. > > FC5 has vte 0.12.1 wheras aiglx comes with 0.12.0. > > As a result -> gnome-terminal doesent start anymore I'm experiencing this same problem with gnome-terminal. Is there another way of opening a console on fedora? Benjy > > regards, > Rudolf Kastl > > p.s. are there new packages coming soon? Simply ask because i also > have that "blue everything" problem when turning metacitys composite > manager on. > Radeon 9000 mobile here. r250. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From benjy.grogan at gmail.com Fri May 5 15:43:29 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 5 May 2006 11:43:29 -0400 Subject: AIGLX breaks XServer with new Repo In-Reply-To: <20060505142445.GA14102@redhat.com> References: <20060504192601.GA8365@redhat.com> <20060505142445.GA14102@redhat.com> Message-ID: On 5/5/06, Nalin Dahyabhai wrote: > On Fri, May 05, 2006 at 02:06:51AM -0400, Benjy Grogan wrote: > > On 5/4/06, Nalin Dahyabhai wrote: > > >On Thu, May 04, 2006 at 12:29:45AM -0400, Benjy Grogan wrote: > > >> I had AIGLX working on FC5 using the old aiglx.repo that pointed to > > >> Ray Strode's repo. I recently dropped in the new aiglx.repo that > > >> Kristian Hogsberg posted a few weeks ago and the result was that my > > >> XServer won't start anymore. > > >[snip] > > >> (EE) module ABI minor version (5) is newer than the server's version (4) > > >[snip] > > > > > >Are you still using Xair (from the old xorg-x11-server-Xair package in > > >Ray's repository, which is out of date) as your server? > > > > Yes, Xair was always at the top of the list in System Monitor in terms > > of processor time. So, if that Xair should no longer be there, how do > > I remove it and properly replace it with the right Xorg? > > First, remove the xorg-x11-server-Xair package. If you modified your > desktop manager's configuration to call Xair instead of Xorg [1], you > may need to change it back. > > If you use "startx" and modified your .xserverrc to call Xair instead of > Xorg, revert that change. Okay. I removed xorg-x11-server-Xair package and then removed 0=aiglx under [servers] from /etc/gdm/custom.conf and replaced it with 0=Standard under [servers]. That fixed GDM and now I can login. But before I login, and right after udev is started with an [OK] I get a black screen with a white cross. I have to type in CTRL+ALT+BACKSPACE and then bootup continues. Otherwise it just hangs there. A graphic screen never shows up and normally I get a grey screen that gives me the option of hiding/showing details. Eventually I come to a text login console, that quickly becomes the regular GDM visual console. So something is still a little messed. Do you have any idea what this could be? :) But at least I can get into my system now. Thanks! Benjy > > Cheers, > > Nalin > > [1] From an older revision of the wiki page: > http://fedoraproject.org/wiki/RenderingProject/AiglxOnFedora?action=recall&rev=13 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rdieter at math.unl.edu Fri May 5 15:42:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 05 May 2006 10:42:51 -0500 Subject: [aiglx] repo -> outdated vte lib References: Message-ID: Benjy Grogan wrote: > On 5/5/06, Rudolf Kastl wrote: >> Hello! >> >> Actually the vte library in the aiglx repo needs an update. >> >> FC5 has vte 0.12.1 wheras aiglx comes with 0.12.0. >> >> As a result -> gnome-terminal doesent start anymore > > I'm experiencing this same problem with gnome-terminal. Is there > another way of opening a console on fedora? kdebase's konsole -- Rex From mclasen at redhat.com Fri May 5 15:49:15 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 05 May 2006 11:49:15 -0400 Subject: [aiglx] repo -> outdated vte lib In-Reply-To: References: Message-ID: <1146844155.3893.1.camel@golem.boston.redhat.com> On Fri, 2006-05-05 at 10:42 -0500, Rex Dieter wrote: > Benjy Grogan wrote: > > > On 5/5/06, Rudolf Kastl wrote: > >> Hello! > >> > >> Actually the vte library in the aiglx repo needs an update. > >> > >> FC5 has vte 0.12.1 wheras aiglx comes with 0.12.0. > >> > >> As a result -> gnome-terminal doesent start anymore > > > > I'm experiencing this same problem with gnome-terminal. Is there > > another way of opening a console on fedora? > > kdebase's konsole > xterm From micwise at bellsouth.net Fri May 5 15:28:28 2006 From: micwise at bellsouth.net (micwise at bellsouth.net) Date: Fri, 5 May 2006 10:28:28 -0500 Subject: [aiglx] repo -> outdated vte lib Message-ID: <20060505152828.BEOQ18307.ibm70aec.bellsouth.net@mail.bellsouth.net> ctrl-alt-f1 gets you to a console. If you downgrade to vte it the aiglx repo, you can open gnome-terminal. Michael > > From: "Benjy Grogan" > Date: 2006/05/05 Fri AM 10:22:39 CDT > To: "Development discussions related to Fedora Core" > Subject: Re: [aiglx] repo -> outdated vte lib > > On 5/5/06, Rudolf Kastl wrote: > > Hello! > > > > Actually the vte library in the aiglx repo needs an update. > > > > FC5 has vte 0.12.1 wheras aiglx comes with 0.12.0. > > > > As a result -> gnome-terminal doesent start anymore > > I'm experiencing this same problem with gnome-terminal. Is there > another way of opening a console on fedora? > > Benjy > > > > > regards, > > Rudolf Kastl > > > > p.s. are there new packages coming soon? Simply ask because i also > > have that "blue everything" problem when turning metacitys composite > > manager on. > > Radeon 9000 mobile here. r250. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mpeters at mac.com Fri May 5 17:24:56 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 05 May 2006 10:24:56 -0700 Subject: Help! fc2->fc5 In-Reply-To: References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> Message-ID: <1146849897.2261.14.camel@atlantis.mpeters.local> On Fri, 2006-05-05 at 11:46 +0100, Leon wrote: > > Apparently, how many issues depends on how many packages you > installed. In my case, for a desktop user you probably will find the > boot is slow and gnome behaves weirdly etc for an upgrade install. 1) yum upgraded from fc4 to fc5 - had to, anaconda could not find the comps.xml file on DVD repeatedly, I think it was trying to get it before media finished mounting - pcmcia/cardbus support on fc5 DVD was broken, could not do network install So I did a clean install of FC4 on the hardware (preserving /home) upgraded kernel to latest fc4 kernel upgraded yum to latest fc4 yum upgraded fedora-release yum update did the rest. Works just as well as clean install fc5 boxes. So I'm guessing your issues are specific to your environment. From Axel.Thimm at ATrpms.net Fri May 5 17:53:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 5 May 2006 19:53:56 +0200 Subject: useradd -r should start at the top of available uids Message-ID: <20060505175356.GC1790@neu.nirvana> Currently the authoritative source of static uids/gids is /usr/share/doc/setup-*/uidgid The current LSB mandates that 0-99 are for static assignment and 100-499 are for dynamic assignment via useradd -r. We are already at the border and there have been some assignments beyond (that were just reverted) like 101 for gkrellmd. Security considerations create a demand for more static uid/gids and there have been some solutions suggested to effectively reserve some higher ranges for semi-static reservations. This clearly shows the demand for static uid/gid assignment. More on the security aspects can be found in the wiki. What I think will most probably happen is that LSB will revise the need and find that the weighing of static vs dynamic sytem accounts which currently is 1:4 needs to be rethought and maybe the bar lifted from 100 to 150/200 or. What the LSB cannot do is touch anything higher than 500 as that will break the users' playground (breaking OSes is OK for the LSB ;) To cut a long story short: We are currently allowed to use 100-499 for dynamic assignment, but we will most probably have to violate the LSB if a static uid/gid is needed as the range reserved for that is filled up. So it makes sense to think about moving dynamic allocation of uid/gid from the lower range to the upper range. E.g. the first useradd -r grabs 499, the next 498 and so on. That way dynamic allocation will not conflict with any (new) static assignments. That scheme is therefore future proof (at least more than the current) and will also survive any raising of the uid=100 border. This has already been filed in bugzilla, so maybe you'd like to comment there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190523 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shiva at sewingwitch.com Fri May 5 19:06:18 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 05 May 2006 12:06:18 -0700 Subject: Help! fc2->fc5 In-Reply-To: <200605050842.26544.lamont@gurulabs.com> References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> <200605050842.26544.lamont@gurulabs.com> Message-ID: <29B0F92D2CE8DD292B8C0571@[10.169.6.226]> On Friday, May 05, 2006 8:42 AM -0600 "Lamont R. Peterson" wrote: > Also, don't do "yum upgrade", use anaconda, booting from a CD instead. > Using "yum upgrade" there are 20 some odd "corner cases" and such that > are not handled (things about the changes between FC4 -> FC5. Anaconda > knows these things and gets things right. How does one identify these 20 issues? I'd like to look them over on my FC2 server before starting the upgrade process. (I plan to clone the disk and upgrade the clone. Call me paranoid. ;)) My practice is to copy the DVD ISO to the HD and then use askmethod to point the installer at the image on the HD. This has worked well for my desktop FC4 system. The only problem there was my very unusual grub setup (triple-booting WinXP, FC4 i386, and x86_64 from one FC4's /boot subdirectory). It took a little manual cleanup to get my grub setup working the way I wanted, after upgrading both partitions. And I haven't yet got the nVidia driver working. But I haven't looked at the latter problem very hard yet. From andy at warmcat.com Fri May 5 19:05:29 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 05 May 2006 20:05:29 +0100 Subject: [BUG] Clock always faster In-Reply-To: <200605050839.41086.lamont@gurulabs.com> References: <445B482D.8010806@argo.co.il> <1cef3e950605050724w6cc08888j3d7c3c05861596cf@mail.gmail.com> <200605050839.41086.lamont@gurulabs.com> Message-ID: <445BA1F9.3040909@warmcat.com> Lamont R. Peterson wrote: > It could be a bug in the BIOS. I recently dealt with some AMD64 X2 boxes > (from Alienware) that had a really big issue similar to this because of the > way the BIOS was configuring (or not properly configuring) the APIC. If we > ran an SMP kernel on those boxes under those conditions, the delay loop was > seriously miscalibrated and we would see the clock stall & jump. It also > made it extremely difficult to type as the briefest of touches to a key would > cause anywhere from 2-20 keypresses to register, even after we had turned the > keyboard repeat rates all the way down. > > > Sounds familiar: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55223 -Andy From lamont at gurulabs.com Fri May 5 19:18:10 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 5 May 2006 13:18:10 -0600 Subject: Help! fc2->fc5 In-Reply-To: <29B0F92D2CE8DD292B8C0571@[10.169.6.226]> References: <31940999.1146816329493.JavaMail.www-data@www2> <200605050842.26544.lamont@gurulabs.com> <29B0F92D2CE8DD292B8C0571@[10.169.6.226]> Message-ID: <200605051318.14980.lamont@gurulabs.com> On Friday 05 May 2006 01:06pm, Kenneth Porter wrote: > On Friday, May 05, 2006 8:42 AM -0600 "Lamont R. Peterson" > > wrote: > > Also, don't do "yum upgrade", use anaconda, booting from a CD instead. > > Using "yum upgrade" there are 20 some odd "corner cases" and such that > > are not handled (things about the changes between FC4 -> FC5. Anaconda > > knows these things and gets things right. > > How does one identify these 20 issues? Examine source for Anaconda and/or ask Anaconda developers. > I'd like to look them over on my FC2 > server before starting the upgrade process. The key thing is you can go FC2 -> FC4 or newer. Only from 1 version to the next. So, you have to update FC2 -> FC3, then FC3 -> FC4, then (finally) FC4 -> FC5. Those "20" (or so) issues that I mentioned ... that's just what goes on from FC4 -> FC5. I don't know how many such oddities are handled by upgrades to FC3 and FC4, but there are some things. Fedora releases are only tested for upgrading from one release to the next, never from older releases. > (I plan to clone the disk and > upgrade the clone. Call me paranoid. ;)) I won't, I tell you! You're not paranoid :) . Actually, that's just being smart. > My practice is to copy the DVD ISO to the HD and then use askmethod to > point the installer at the image on the HD. This has worked well for my > desktop FC4 system. The only problem there was my very unusual grub setup > (triple-booting WinXP, FC4 i386, and x86_64 from one FC4's /boot > subdirectory). It took a little manual cleanup to get my grub setup working > the way I wanted, after upgrading both partitions. And I haven't yet got > the nVidia driver working. But I haven't looked at the latter problem very > hard yet. I usually do network installs/upgrades with a boot.iso or PXE booting. Poe-taa-toe, poe-tah-toe. Yeah, I usually just let Anaconda rewrite GRUB configuration from scratch when I do an upgrade install, then fix it after the fact, if I need to (which is almost never needed). -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From avi at argo.co.il Fri May 5 19:39:48 2006 From: avi at argo.co.il (Avi Kivity) Date: Fri, 05 May 2006 22:39:48 +0300 Subject: Help! fc2->fc5 In-Reply-To: <200605051318.14980.lamont@gurulabs.com> References: <31940999.1146816329493.JavaMail.www-data@www2> <200605050842.26544.lamont@gurulabs.com> <29B0F92D2CE8DD292B8C0571@[10.169.6.226]> <200605051318.14980.lamont@gurulabs.com> Message-ID: <445BAA04.2050807@argo.co.il> Lamont R. Peterson wrote: > The key thing is you can go FC2 -> FC4 or newer. Only from 1 version to the > next. So, you have to update FC2 -> FC3, then FC3 -> FC4, then (finally) FC4 > -> FC5. > > Those "20" (or so) issues that I mentioned ... that's just what goes on from > FC4 -> FC5. I don't know how many such oddities are handled by upgrades to > FC3 and FC4, but there are some things. > > Fedora releases are only tested for upgrading from one release to the next, > never from older releases. > > My machine went the FC2 -> rawhide -> FC4 -> FC5 path through yum. There were no special problems (well, I lost networking in FC5, but that was not related to yum vs anaconda). You will have to edit some configuration files though, and likely disable selinux. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From wtogami at redhat.com Fri May 5 19:42:27 2006 From: wtogami at redhat.com (Warren Togami) Date: Fri, 05 May 2006 15:42:27 -0400 Subject: OFF-TOPIC Re: Help! fc2->fc5 In-Reply-To: <31940999.1146816329493.JavaMail.www-data@www2> References: <31940999.1146816329493.JavaMail.www-data@www2> Message-ID: <445BAAA3.2010008@redhat.com> gbiczo at freestart.hu wrote: > Hi all, > > I tried to upgrade my FC 2 system to FC5. For some reason, the installation/upgrade process stopped, I retryed several times, but haden't success. The installation is thus broken. > I decided to upgrade the packages manually. Now two questions emerged. > > 1. Graphical package installation (pirut?) doesn't work, seems it cannot find repository data. How can it be told to "look into" the installation cds? Is pirut the tool I need to use? (manual installation/upgrade is a bit difficult: deps). > > 2. Tried to compile a kernel module for my lt winmodem. insmod won't load the module, exits with interesting error messages. Has anybody tried such a blasphemy under FC5? > Kernel is 2.6.16-1.2080 (Yes, because of nvidia...) > > aha! and a minor question: Release notes mentions, that fc5 doesn't support serial mice. Now my broken installation uses perfectly my old mouse (serial, of course), which is very > good. Is there an "official" possibility to use serial mice? > Please refrain from user support questions on fedora-devel-list. The purpose of this list is for development discussion. Warren Togami wtogami at redhat.com From mpeters at mac.com Fri May 5 20:47:19 2006 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 05 May 2006 13:47:19 -0700 Subject: useradd -r should start at the top of available uids In-Reply-To: <20060505175356.GC1790@neu.nirvana> References: <20060505175356.GC1790@neu.nirvana> Message-ID: <1146862039.2261.23.camel@atlantis.mpeters.local> On Fri, 2006-05-05 at 19:53 +0200, Axel Thimm wrote: > > What I think will most probably happen is that LSB will revise the > need and find that the weighing of static vs dynamic sytem accounts > which currently is 1:4 needs to be rethought Yeah - I doubt there are very many systems that have more UIDs in the 100-499 range than in the 0-99 range. > and maybe the bar lifted > from 100 to 150/200 or. What the LSB cannot do is touch anything > higher than 500 as that will break the users' playground (breaking > OSes is OK for the LSB ;) > > To cut a long story short: We are currently allowed to use 100-499 for > dynamic assignment, but we will most probably have to violate the LSB > if a static uid/gid is needed as the range reserved for that is filled > up. So it makes sense to think about moving dynamic allocation of > uid/gid from the lower range to the upper range. E.g. the first > useradd -r grabs 499, the next 498 and so on. That way dynamic > allocation will not conflict with any (new) static assignments. That > scheme is therefore future proof (at least more than the current) and > will also survive any raising of the uid=100 border. I like that model. I also would like it, unless specifically told not to, to only grab a UID if the same GID is also available. IE if GID 499 is in use but UID 499 is not, don't use UID 499 and GID 498 - instead, use UID and GID 498 and leave UID 499 unused. From shiva at sewingwitch.com Fri May 5 21:04:15 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 05 May 2006 14:04:15 -0700 Subject: Help! fc2->fc5 In-Reply-To: <445BAA04.2050807@argo.co.il> References: <31940999.1146816329493.JavaMail.www-data@www2> <200605050842.26544.lamont@gurulabs.com> <29B0F92D2CE8DD292B8C0571@[10.169.6.226]> <200605051318.14980.lamont@gurulabs.com> <445BAA04.2050807@argo.co.il> Message-ID: <3680CCDB1402656D0F8AE1F1@[10.169.6.226]> On Friday, May 05, 2006 10:39 PM +0300 Avi Kivity wrote: > You will have to edit some configuration files though, and likely disable > selinux. That kind of thing I expect. I tar up /etc and /var before the upgrade and then look for what changed. From lamont at gurulabs.com Fri May 5 21:54:21 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Fri, 5 May 2006 15:54:21 -0600 Subject: Help! fc2->fc5 In-Reply-To: <445BAA04.2050807@argo.co.il> References: <31940999.1146816329493.JavaMail.www-data@www2> <200605051318.14980.lamont@gurulabs.com> <445BAA04.2050807@argo.co.il> Message-ID: <200605051554.27120.lamont@gurulabs.com> On Friday 05 May 2006 01:39pm, Avi Kivity wrote: [snip] > My machine went the FC2 -> rawhide -> FC4 -> FC5 path through yum. There > were no special problems (well, I lost networking in FC5, but that was > not related to yum vs anaconda). Yes, that will work, sometimes. I don't know the details of what Anaconda just deals with that yum has on code for, so, YMMV. > You will have to edit some configuration files though, and likely > disable selinux. I don't know if it you meant it this way, or not, but oh, please, don't just go straight to advising people to shut off SELinux. There are warts, yes, but *so* much good work has been done and contines to make SELinux work. There's already too many people out there who just say, "First thing to always do is turn off SELinux." -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shiva at sewingwitch.com Fri May 5 21:07:46 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 05 May 2006 14:07:46 -0700 Subject: Help! fc2->fc5 In-Reply-To: <200605051318.14980.lamont@gurulabs.com> References: <31940999.1146816329493.JavaMail.www-data@www2> <200605050842.26544.lamont@gurulabs.com> <29B0F92D2CE8DD292B8C0571@[10.169.6.226]> <200605051318.14980.lamont@gurulabs.com> Message-ID: <3C81FD88AD403D6662187DCA@[10.169.6.226]> On Friday, May 05, 2006 1:18 PM -0600 "Lamont R. Peterson" wrote: > The key thing is you can go FC2 -> FC4 or newer. Only from 1 version to > the next. So, you have to update FC2 -> FC3, then FC3 -> FC4, then > (finally) FC4 -> FC5. One reason I didn't update to FC4 was because of how rocky its introduction was. It took a few kernel updates before it stabilized. Instead, I've been hand-updating selected packages from Rawhide SRPM's. But satisfying the dependencies gets harder and harder over time as more things depend on major foundational packages that have changed over time, like udev and selinux. Mailman, for instance, ended up having tendrils going into packages I didn't want to update without a full system upgrade. From shiva at sewingwitch.com Fri May 5 22:30:09 2006 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 05 May 2006 15:30:09 -0700 Subject: Help! fc2->fc5 In-Reply-To: <200605051554.27120.lamont@gurulabs.com> References: <31940999.1146816329493.JavaMail.www-data@www2> <200605051318.14980.lamont@gurulabs.com> <445BAA04.2050807@argo.co.il> <200605051554.27120.lamont@gurulabs.com> Message-ID: <516DC9CAB0CD7DF348A73BD8@[10.169.6.226]> On Friday, May 05, 2006 3:54 PM -0600 "Lamont R. Peterson" wrote: > I don't know if it you meant it this way, or not, but oh, please, don't > just go straight to advising people to shut off SELinux. There are > warts, yes, but *so* much good work has been done and contines to make > SELinux work. There's already too many people out there who just say, > "First thing to always do is turn off SELinux." True. This is like the people from other distros who tell Redhat/Fedora users to "just install from source" or "just install from CPAN" instead of learning how to do things the RPM way. Some links to post in response to selinux problems: From sdl.web at gmail.com Fri May 5 22:40:36 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 23:40:36 +0100 Subject: [BUG] Clock always faster References: <445B482D.8010806@argo.co.il> <1cef3e950605050724w6cc08888j3d7c3c05861596cf@mail.gmail.com> <200605050839.41086.lamont@gurulabs.com> Message-ID: "Lamont R. Peterson" writes: > On Friday 05 May 2006 08:24am, Joe Desbonnet wrote: >> If a clock is found to be running predictibly fast or slow is it >> possible to correct that somehow? > > Run ntpd. That will keep the system clock in sync. > > It could be a bug in the BIOS. I recently dealt with some AMD64 X2 boxes > (from Alienware) that had a really big issue similar to this because of the > way the BIOS was configuring (or not properly configuring) the APIC. If we > ran an SMP kernel on those boxes under those conditions, the delay loop was > seriously miscalibrated and we would see the clock stall & jump. It also > made it extremely difficult to type as the briefest of touches to a key would > cause anywhere from 2-20 keypresses to register, even after we had turned the > keyboard repeat rates all the way down. > > Running a uniprocessor kernel cured all our woes. A little more testing > pointed towards the APIC config, but the BIOS those boxes had didn't give us > enough control to be 100% certain about that. Unfortunately, we were running > in an isolated environment, so we couldn't check for nor try to pick up an > updated BIOS for those boxes. I'm getting this in a laptop with one processor. > > [snip] > -- > Lamont R. Peterson > Senior Instructor > Guru Labs, L.C. [ http://www.GuruLabs.com/ ] > GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -- Leon From sdl.web at gmail.com Fri May 5 22:42:39 2006 From: sdl.web at gmail.com (Leon) Date: Fri, 05 May 2006 23:42:39 +0100 Subject: Help! fc2->fc5 References: <31940999.1146816329493.JavaMail.www-data@www2> <445B16BD.3090100@argo.co.il> <200605050842.26544.lamont@gurulabs.com> Message-ID: "Lamont R. Peterson" writes: > On Friday 05 May 2006 03:11am, Avi Kivity wrote: >> Leon wrote: >> > You will be better off doing a clean install. There are issues even >> > upgrade from FC4. >> >> What are the issues? I upgraded two machines (using yum upgrade) from >> FC4 without trouble. I'd like to upgrade our server next (reinstallation >> is not an option) and would like to avoid any known issues. > > Then you need to upgrade from FC2 -> FC3 -> FC4 -> FC5. > > Also, don't do "yum upgrade", use anaconda, booting from a CD instead. Using > "yum upgrade" there are 20 some odd "corner cases" and such that are not > handled (things about the changes between FC4 -> FC5. Anaconda knows these > things and gets things right. > > I had excellent results upgrading my FC4 notebook to FC5 using Anaconda. Good to know. I haven't tried Anaconda upgrade before. > -- > Lamont R. Peterson > Senior Instructor > Guru Labs, L.C. [ http://www.GuruLabs.com/ ] > GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -- Leon From wtogami at redhat.com Fri May 5 22:48:35 2006 From: wtogami at redhat.com (Warren Togami) Date: Fri, 05 May 2006 18:48:35 -0400 Subject: [BUG] Clock always faster In-Reply-To: References: Message-ID: <445BD643.4050001@redhat.com> Leon wrote: > Dear all, > > I have found my system clock 4 minutes faster than the standard > time. I remembered I have sysced with a ntp server before. > > To be precise, it will get 1.029561 sec faster in a two-hour interval. > > Does anyone else have the same experience? Do you think it is due to > hardware or the kernel? > > Thanks. Please refrain from posting user support questions like this on fedora-devel-list. The purpose of this list is for development discussion. Warren Togami wtogami at redhat.com From ericsbinaryworld at gmail.com Fri May 5 22:56:57 2006 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Fri, 05 May 2006 18:56:57 -0400 Subject: Latest Kernel causes problems with Video Card Message-ID: <445BD839.4070707@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When I upgraded to the latest kernel and then rebooted, in the part where the GUI is supposed to show all the processes beginning just stays back with my mouse as an X. When I rolled back to 2.6.16-1.2096_FC5 everything was fine again. Let me know what other data you need. - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEW9g4PvU+8ApmWXIRAnyEAJ4xOBDqpzdyK2aH55ZGidJEFs6ZXwCgiYAh WVIYEaaNU9Ox4DGpQ4beNLs= =VnY2 -----END PGP SIGNATURE----- From wtogami at redhat.com Fri May 5 23:12:17 2006 From: wtogami at redhat.com (Warren Togami) Date: Fri, 05 May 2006 19:12:17 -0400 Subject: OFF-TOPIC Re: Latest Kernel causes problems with Video Card In-Reply-To: <445BD839.4070707@gmail.com> References: <445BD839.4070707@gmail.com> Message-ID: <445BDBD1.6050604@redhat.com> Eric Mesa wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When I upgraded to the latest kernel and then rebooted, in the part > where the GUI is supposed to show all the processes beginning just > stays back with my mouse as an X. When I rolled back to > 2.6.16-1.2096_FC5 everything was fine again. > > Let me know what other data you need. > > - -- > Eric Mesa > ericsbinaryworld at gmail.com > Please refrain from user support questions on fedora-devel-list. The purpose of this list is for development discussion. The appropriate place for your question is Bugzilla and/or fedora-list. Warren Togami wtogami at redhat.com From sdl.web at gmail.com Fri May 5 23:15:05 2006 From: sdl.web at gmail.com (Leon) Date: Sat, 06 May 2006 00:15:05 +0100 Subject: Latest Kernel causes problems with Video Card References: <445BD839.4070707@gmail.com> Message-ID: Eric Mesa writes: > When I upgraded to the latest kernel and then rebooted, in the part > where the GUI is supposed to show all the processes beginning just > stays back with my mouse as an X. When I rolled back to > 2.6.16-1.2096_FC5 everything was fine again. > > Let me know what other data you need. > > -- > Eric Mesa > ericsbinaryworld at gmail.com > http://www.ericsbinaryworld.com > Note: All emails from this address should have a GPG signature. If > you have the proper setup you can use this to confirm my identity and > that the email was not changed in transit. Kernel version? -- Leon From steve at silug.org Sat May 6 00:02:29 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 5 May 2006 19:02:29 -0500 Subject: License question In-Reply-To: References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <39481.207.35.222.39.1146838361.squirrel@lattica.com> Message-ID: <20060506000229.GA21671@osiris.silug.org> On Fri, May 05, 2006 at 02:32:35PM +0000, Ola Thoresen wrote: > The main issue I had last time I tested zimbra was that it had to "take > over" the entire server (xen comes to mind, but that was not an option > at the time). > > It would not allow you to use the existing accounts, imap-server, > smtp-server and all other already running services. > I'd prefer something that will live and play nicely with an existing > installation, so I can access my mail with both mutt, imap, mapi and > webmail - depending on where I am and what client I have available. Hula works the same way, which is a shame because it is a *really* nice piece of software. Even being able to integrate into an existing LDAP directory would make it useful for me... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From steve at silug.org Sat May 6 00:03:50 2006 From: steve at silug.org (Steven Pritchard) Date: Fri, 5 May 2006 19:03:50 -0500 Subject: License question In-Reply-To: <1146830369.2630.62.camel@xpc.home.erwinrol.com> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> Message-ID: <20060506000350.GB21671@osiris.silug.org> On Fri, May 05, 2006 at 01:59:29PM +0200, Erwin Rol wrote: > A while back i said i was working on a Open-Xchange version that could > work with GCJ, so that in the end it could be included in Fedora > (extras). Some parts of Open-Xchange , the HTML, pictures, docu, are > under a CC license. The "Attribution-NonCommercial-ShareAlike 2.5? to be > exact ( http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode ) > Now some Debian people have a problem with this license as described > here; http://people.debian.org/~evan/ccsummary.html > The question is does Fedora accept works that are (or partly are) under > the mentioned CC license? Wasn't this a change in the latest version? If so, I suggest forking from the previous version, patching the code up to the latest version, and continuing from there... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From mailinglists at erwinrol.com Sat May 6 00:35:00 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 06 May 2006 02:35:00 +0200 Subject: License question In-Reply-To: <20060506000350.GB21671@osiris.silug.org> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060506000350.GB21671@osiris.silug.org> Message-ID: <1146875700.2630.177.camel@xpc.home.erwinrol.com> On Fri, 2006-05-05 at 19:03 -0500, Steven Pritchard wrote: > On Fri, May 05, 2006 at 01:59:29PM +0200, Erwin Rol wrote: > > A while back i said i was working on a Open-Xchange version that could > > work with GCJ, so that in the end it could be included in Fedora > > (extras). Some parts of Open-Xchange , the HTML, pictures, docu, are > > under a CC license. The "Attribution-NonCommercial-ShareAlike 2.5? to be > > exact ( http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode ) > > Now some Debian people have a problem with this license as described > > here; http://people.debian.org/~evan/ccsummary.html > > The question is does Fedora accept works that are (or partly are) under > > the mentioned CC license? > > Wasn't this a change in the latest version? If so, I suggest forking > from the previous version, patching the code up to the latest version, > and continuing from there... The older versions had the following questionable META-tags in all HTML files; IANAL so I can not judge if those "tags" would overrule the general COPYING file that mentioned the GPL, or if the COPYING (and also the license information of the website, which is now updated btw) would overrule those tags. Of course they could just have removed those tags and have the GPL "take over" via the COPYING file. But they didn't and until now they didn't really give an explanation why they didn't, the answer to that question was; -- begin quote -- the answers why we have chosen the Creative Common license are: - Open-Xchange includes images, html files, stylesheets and other content - Open-Xchange is using this license because we will face a huge change and it could be that the frontend can be used without the backend - The community ask for this (i do not mean the community you see here on the list - but you maybe can imagine that there are other communities behind Open-Xchange - not visible on the very first view) Just for your information, there were some other motivations i will not list today. -- end quote -- - Erwin From jos at xos.nl Sat May 6 06:31:36 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 6 May 2006 08:31:36 +0200 Subject: License question In-Reply-To: <1146875700.2630.177.camel@xpc.home.erwinrol.com>; from mailinglists@erwinrol.com on Sat, May 06, 2006 at 02:35:00AM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060506000350.GB21671@osiris.silug.org> <1146875700.2630.177.camel@xpc.home.erwinrol.com> Message-ID: <20060506083136.A27682@xos037.xos.nl> On Sat, May 06, 2006 at 02:35:00AM +0200, Erwin Rol wrote: > > > > > IANAL so I can not judge if those "tags" would overrule the general > COPYING file that mentioned the GPL, or if the COPYING (and also the > license information of the website, which is now updated btw) would > overrule those tags. If a license was included for the whole package, without mentioned exceptions, these copyright statements won't change that. Copyright and license are in fact different things. > Of course they could just have removed those tags and have the GPL "take > over" via the COPYING file. But they didn't and until now they didn't > really give an explanation why they didn't, the answer to that question > was; In fact, IMHO you better should put such copyright statements in every file, to protect it as much as possible. That you then license everything under the GPL is fine. > - The community ask for this (i do not mean the community you > see here on the list - but you maybe can imagine that there > are other communities behind Open-Xchange - not visible on the > very first view) They probably mean the commercial user community? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From buildsys at redhat.com Sat May 6 07:25:09 2006 From: buildsys at redhat.com (Build System) Date: Sat, 6 May 2006 03:25:09 -0400 Subject: rawhide report: 20060506 changes Message-ID: <200605060725.k467P9UZ025679@porkchop.devel.redhat.com> Updated Packages: busybox-1:1.1.2-2 ----------------- * Fri May 05 2006 Ivana Varekova - 1:1.1.2-1 - update to 1.1.2 cairo-1.1.6-5 ------------- * Fri May 05 2006 Carl Worth - 1.1.6-2 - Refuse to build pdf2svg to avoid depending on newer poppler * Fri May 05 2006 Carl Worth - 1.1.6-1 - Update to new upstream 1.1.6 * Wed May 03 2006 Carl Worth - 1.1.4-2 - Revert upstream commit that introduced a dependency on a newer poppler version for the PDF tests. cscope-15.5-13.4 ---------------- * Fri May 05 2006 Neil Horman - Checking in sysdir change for bz 190580 cups-1:1.2-0.5.rc3.4 -------------------- * Fri May 05 2006 Tim Waugh 1:1.2-0.5.rc3.4 - Sync to svn5493. * Fri May 05 2006 Tim Waugh 1:1.2-0.5.rc3.3 - Sync to svn5491. * Fri Apr 28 2006 Tim Waugh - Sync to svn5470. - No longer need link, CAN-2005-0064, or no-propagate-ipp-port patches. - Switch to upstream PIE implementation (every single binary is PIE). - Extend relro to all binaries. - Better rpath patch. ddd-3.3.11-6 ------------ * Fri May 05 2006 Adam Jackson - 3.3.11-6 - Remove spurious libXp dependency firefox-1.5.0.3-2 ----------------- * Thu May 04 2006 Christopher Aillon - 1.5.0.3-2 - Firefox 1.5.0.3 glibc-2.4.90-6 -------------- * Fri May 05 2006 Jakub Jelinek 2.4.90-6 - update from CVS - rebuilt using fixed rpm * Fri May 05 2006 Jakub Jelinek 2.4.90-5 - update from CVS - some NIS+ fixes - allow overriding rfc3484 address sorting tables for getaddrinfo through /etc/gai.conf (sample config file included in %doc directory) glibc-kernheaders-3.0-27 ------------------------ * Sat May 06 2006 David Woodhouse 3.0-27 - Fix up '(__force...' etc too. * Sat May 06 2006 David Woodhouse 3.0-26 - Use sed to remove __user, __iomem, __force, __attribute_const__ - Change all 'inline' to '__inline__' * Sat May 06 2006 David Woodhouse 3.0-25 - Update from 2.6.17-rc3. More cleanups, new syscalls on PPC gsl-1.8-1 --------- * Fri May 05 2006 Ivana Varekova - 1.8-1 - update to 1.8 gtk2-2.9.0-2 ------------ * Fri May 05 2006 Matthias Clasen - 2.9.0-1 - Update to 2.9.0 gtk2-engines-2.7.4-7 -------------------- * Fri May 05 2006 Matthias Clasen - 2.7.4-4 - Rebuild against GTK+ 2.9.0 - Require GTK+ 2.9.0 hal-0.5.7-6 ----------- * Fri May 05 2006 John (J5) Palmieri - 0.5.7-6 - Add fix so gnome-power-manager handles lid opens correctly now * Mon Apr 24 2006 John (J5) Palmieri - 0.5.7-5 - ifnarch the pm-utils requires for s390 and s390x * Wed Apr 19 2006 Matthias Clasen - 0.5.7-4 - Add Requires on pm-utils >= 0.10-1 (#185134, Andrew Overholt) kernel-2.6.16-1.2195_FC6 ------------------------ * Fri May 05 2006 Dave Jones - 2.6.17rc3-git11 * Fri May 05 2006 David Woodhouse - Fix #190776 by rediffing the patch so it actually gets applied properly - Fix the machine check too. * Fri May 05 2006 David Woodhouse - Remove bcm43xx-assoc-on-startup patch. I don't think the original problem is fixed upstream yet, but this patch causes BZ #190776. libgnomeui-2.15.1cvs20060505-2 ------------------------------ * Fri May 05 2006 Matthias Clasen - 2.15.1.cvs20060505-2 - Update to a cvs snapshot that supports the new GTK+ filechooser backend API - Require GTK+ 2.9.0 libpfm-3.2-0.060421.3 --------------------- * Fri May 05 2006 Will Cohen - fno-strict-aliasing so ia64 builds. * Fri May 05 2006 Will Cohen - make sure that perfmon_compat.h installed for ia64. * Thu May 04 2006 Will Cohen - Update to libpfm-3.2-060421. librsvg2-2.14.3-3 ----------------- * Fri May 05 2006 Matthias Clasen 2.14.3-3 - Rebuild against new GTK+ - Require GTK+ 2.9.0 libwmf-0.2.8.4-7 ---------------- * Fri May 05 2006 Matthias Clasen 0.2.8.4-7 - Rebuild against the new GTK+ - Require GTK+ 2.9.0 logwatch-7.3-2 -------------- * Fri May 05 2006 Ivana Varekova 7.3-2 - added tests to file creation and access, clean up resulting files when logwatch fails (upstream change) (#190498) * Mon Mar 27 2006 Ivana Varekova 7.3-1 - update to 7.3 - added samba, up2date * Fri Mar 17 2006 Ivana Varekova 7.2.1-1 - update to 7.2.1 - update nosegfault, pam_unix, http patches - added sshd, smart, named, audit, secure and mountd services patches openswan-2.4.5-1 ---------------- * Fri May 05 2006 Harald Hoyer - 2.4.5-1 - version 2.4.5 pfmon-3.2-0.060426.2 -------------------- * Fri May 05 2006 Will Cohen - Do not use the unwind libraries. * Thu May 04 2006 Will Cohen - Update to pfmon-3.2-060426. policycoreutils-1.30.6-4 ------------------------ * Thu May 04 2006 Dan Walsh 1.30.6-4 - Add secon program - Add translations redhat-artwork-0.243-1 ---------------------- * Fri May 05 2006 Matthias Clasen 0.243-1 - Rebuild against new GTK+ - Require GTK+ 2.9.0 * Thu Mar 30 2006 Than Ngo 0.242-1 - fix cosmetic bug in kwin decoration rpm-4.4.2-24 ------------ * Thu May 04 2006 Paul Nasrat - 4.4.2-24 - File classification with autoReq off (#190488) system-config-kickstart-2.6.10-1 -------------------------------- * Fri May 05 2006 Chris Lumens 2.6.10-1 - Fix unencrypted root password traceback (#190487). - Try harder to get a base repo enabled (#190508). system-config-printer-0.7.7-2 ----------------------------- * Fri May 05 2006 Tim Waugh 0.7.7-2 - Ship PAM and userhelper files. - Requires usermode. - Added missing options.py file. - Fix getClasses() in pycups. tetex-3.0-23 ------------ * Fri May 05 2006 Adam Jackson 3.0-23 - Remove spurious Xprint dependency xen-3.0.2-4 ----------- * Fri May 05 2006 Jeremy Katz - 3.0.2-4 - update to new snapshot (changeset 9925) xfig-3.2.4-20 ------------- * Fri May 05 2006 Than Ngo 3.2.4-20 - fix #169330, wrong docdir - fix #187902, no parameter negotiation for xfig - fix #182451, switch xfig's pdf viewer to evince xpdf-1:3.01-13 -------------- * Fri May 05 2006 Adam Jackson 1:3.01-13 - Remove spurious libXp dependency Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From j.w.r.degoede at hhs.nl Sat May 6 07:25:04 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 06 May 2006 09:25:04 +0200 Subject: License question In-Reply-To: <20060506083136.A27682@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060506000350.GB21671@osiris.silug.org> <1146875700.2630.177.camel@xpc.home.erwinrol.com> <20060506083136.A27682@xos037.xos.nl> Message-ID: <445C4F50.80200@hhs.nl> Jos Vos wrote: > On Sat, May 06, 2006 at 02:35:00AM +0200, Erwin Rol wrote: > >> >> >> >> >> IANAL so I can not judge if those "tags" would overrule the general >> COPYING file that mentioned the GPL, or if the COPYING (and also the >> license information of the website, which is now updated btw) would >> overrule those tags. > > If a license was included for the whole package, without mentioned > exceptions, these copyright statements won't change that. Copyright > and license are in fact different things. > IANAL, but I agree. If you think this groupware is worth it, I would say try to find others who agree (the Debian packager for a start) build a small team and fork it. Don't forget to make much noise about the fork on every Linux related site (send out a press release) so that you can quickly build a _real_ community. Regards, Hans From jos at xos.nl Sat May 6 07:37:19 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 6 May 2006 09:37:19 +0200 Subject: License question In-Reply-To: <445C4F50.80200@hhs.nl>; from j.w.r.degoede@hhs.nl on Sat, May 06, 2006 at 09:25:04AM +0200 References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060506000350.GB21671@osiris.silug.org> <1146875700.2630.177.camel@xpc.home.erwinrol.com> <20060506083136.A27682@xos037.xos.nl> <445C4F50.80200@hhs.nl> Message-ID: <20060506093719.A28157@xos037.xos.nl> On Sat, May 06, 2006 at 09:25:04AM +0200, Hans de Goede wrote: > IANAL, but I agree. If you think this groupware is worth it, I would say > try to find others who agree (the Debian packager for a start) build a > small team and fork it. Don't forget to make much noise about the fork > on every Linux related site (send out a press release) so that you can > quickly build a _real_ community. Don't underestimate the work, especially as the package is not a "clean" piece of software already, it does not work yet with GCJ (if I understood Erwin correctly), etc. For that you really need a very motivated team and I think it's worth first investigating of OGo is really not worth a try. A few years ago someone I know has tested SLOX (the SuSE Linux bundles with Open Xchange in those days) for his organisation and he said it didn't work ok (various technical problems, IIRC) and he then moved to the Horde suite. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From j.w.r.degoede at hhs.nl Sat May 6 07:51:23 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 06 May 2006 09:51:23 +0200 Subject: License question In-Reply-To: <20060506093719.A28157@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060506000350.GB21671@osiris.silug.org> <1146875700.2630.177.camel@xpc.home.erwinrol.com> <20060506083136.A27682@xos037.xos.nl> <445C4F50.80200@hhs.nl> <20060506093719.A28157@xos037.xos.nl> Message-ID: <445C557B.1060802@hhs.nl> Jos Vos wrote: > On Sat, May 06, 2006 at 09:25:04AM +0200, Hans de Goede wrote: > >> IANAL, but I agree. If you think this groupware is worth it, I would say >> try to find others who agree (the Debian packager for a start) build a >> small team and fork it. Don't forget to make much noise about the fork >> on every Linux related site (send out a press release) so that you can >> quickly build a _real_ community. > > Don't underestimate the work, especially as the package is not a > "clean" piece of software already, it does not work yet with GCJ > (if I understood Erwin correctly), etc. > > For that you really need a very motivated team and I think it's > worth first investigating of OGo is really not worth a try. > Agreed, hence I wrote: "If you think this groupware is worth it" So be warned (twice): don't underestimate the work. This is why I said you need to build a team first. Regards, Hans From mailinglists at erwinrol.com Sat May 6 10:42:06 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 06 May 2006 12:42:06 +0200 Subject: rawhide report: 20060506 changes In-Reply-To: <200605060725.k467P9UZ025679@porkchop.devel.redhat.com> References: <200605060725.k467P9UZ025679@porkchop.devel.redhat.com> Message-ID: <1146912126.2630.180.camel@xpc.home.erwinrol.com> I saw the following two errors. Cleanup : hal ##################### [ 83/108] /var/tmp/rpm-tmp.28344: line 4: z#fi: command not found error: %postun(hal-0.5.7-5.x86_64) scriptlet failed, exit status 127 ... Cleanup : hal ##################### [104/108] /var/tmp/rpm-tmp.27315: line 4: z#fi: command not found error: %postun(hal-0.5.7-5.i386) scriptlet failed, exit status 127 From jamatos at fc.up.pt Sat May 6 11:15:07 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 6 May 2006 12:15:07 +0100 Subject: rawhide report: 20060506 changes In-Reply-To: <200605060725.k467P9UZ025679@porkchop.devel.redhat.com> References: <200605060725.k467P9UZ025679@porkchop.devel.redhat.com> Message-ID: <200605061215.07945.jamatos@fc.up.pt> On Saturday 06 May 2006 08:25, Build System wrote: > gsl-1.8-1 > --------- > * Fri May 05 2006 Ivana Varekova - 1.8-1 > - update to 1.8 I will this here before filling a bugzilla report: Is there any reason to not to update gsl for FC-5 (and eventually FC-4)? gsl seems a very stable project 1.8 has very few new features, it has several bugfixes. This seems a package worth updating and with almost no other dependencies as it sometimes happens with other Core packages. -- Jos? Ab?lio From jfrieben at freesurf.fr Sat May 6 12:17:29 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sat, 6 May 2006 14:17:29 +0200 (CEST) Subject: OFF-TOPIC Re: rawhide report: 20060506 changes In-Reply-To: <200605061215.07945.jamatos@fc.up.pt> References: <200605061215.07945.jamatos@fc.up.pt> Message-ID: <32926.194.94.224.254.1146917849.squirrel@jose.freesurf.fr> 1. This a topic for "fedora-list". 2. The rawhide package is likely to also install on FC5. 3. In case it doesn't, try "rpmbuild --rebuild gsl-1.8-1.src.rpm" to build the binary packages for FC5. You might have to install some additional FC5 devel packages though. > On Saturday 06 May 2006 08:25, Build System wrote: >> gsl-1.8-1 >> --------- >> * Fri May 05 2006 Ivana Varekova - 1.8-1 >> - update to 1.8 > > I will this here before filling a bugzilla report: > > Is there any reason to not to update gsl for FC-5 (and eventually > FC-4)? > > gsl seems a very stable project 1.8 has very few new features, it has > several bugfixes. > > This seems a package worth updating and with almost no other > dependencies as > it sometimes happens with other Core packages. > > -- > Jos? Ab?lio > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From mailinglists at erwinrol.com Sat May 6 12:56:44 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 06 May 2006 14:56:44 +0200 Subject: OFF-TOPIC not on topic Message-ID: <1146920205.2630.190.camel@xpc.home.erwinrol.com> Are we really going to see a "OFF-TOPIC" reply to every second mail that might be a bit of topic ? Cause those "warnings" are more off-topic than some mails that might have better be send to the fedora-list. If you feel the need to point out the failure of these "uneducated" persons that dare to send off-topic mails, just send them a private reply, instead of pointing out how stupid they are on a public mailing list. Yeah I know, this mail is off-topic ;-) - Erwin From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat May 6 13:33:30 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 6 May 2006 15:33:30 +0200 Subject: rawhide report: 20060506 changes In-Reply-To: <1146912126.2630.180.camel@xpc.home.erwinrol.com> References: <200605060725.k467P9UZ025679@porkchop.devel.redhat.com> <1146912126.2630.180.camel@xpc.home.erwinrol.com> Message-ID: <20060506153330.3caa74f9@python2> Erwin Rol wrote : > I saw the following two errors. > > Cleanup : hal ##################### > [ 83/108] > /var/tmp/rpm-tmp.28344: line 4: z#fi: command not found > error: %postun(hal-0.5.7-5.x86_64) scriptlet failed, exit status 127 > > > ... > > > Cleanup : hal ##################### > [104/108] > /var/tmp/rpm-tmp.27315: line 4: z#fi: command not found > error: %postun(hal-0.5.7-5.i386) scriptlet failed, exit status 127 I spotted that one too, and already included the fix in a proposed patch that also fixes other issues with the hal package (the most important one being that it owns many directories under /usr/share/locale) : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190655 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2181_FC6 Load : 1.44 0.94 0.46 From che666 at gmail.com Sat May 6 13:49:59 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Sat, 6 May 2006 15:49:59 +0200 Subject: [aiglx] repo -> outdated vte lib In-Reply-To: References: Message-ID: yum install Terminal this way you dont need to install kdebase :) 2006/5/5, Benjy Grogan : > On 5/5/06, Rudolf Kastl wrote: > > Hello! > > > > Actually the vte library in the aiglx repo needs an update. > > > > FC5 has vte 0.12.1 wheras aiglx comes with 0.12.0. > > > > As a result -> gnome-terminal doesent start anymore > > I'm experiencing this same problem with gnome-terminal. Is there > another way of opening a console on fedora? > > Benjy > > > > > regards, > > Rudolf Kastl > > > > p.s. are there new packages coming soon? Simply ask because i also > > have that "blue everything" problem when turning metacitys composite > > manager on. > > Radeon 9000 mobile here. r250. > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From bruno at wolff.to Sat May 6 14:44:19 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 6 May 2006 09:44:19 -0500 Subject: Latest Kernel causes problems with Video Card In-Reply-To: <445BD839.4070707@gmail.com> References: <445BD839.4070707@gmail.com> Message-ID: <20060506144419.GB20774@wolff.to> On Fri, May 05, 2006 at 18:56:57 -0400, Eric Mesa wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When I upgraded to the latest kernel and then rebooted, in the part > where the GUI is supposed to show all the processes beginning just > stays back with my mouse as an X. When I rolled back to > 2.6.16-1.2096_FC5 everything was fine again. > > Let me know what other data you need. It would help to know which kernel "the latest" was. If it was 2107, update to 2111. From sundaram at fedoraproject.org Sat May 6 16:25:43 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 06 May 2006 21:55:43 +0530 Subject: OFF-TOPIC not on topic In-Reply-To: <1146920205.2630.190.camel@xpc.home.erwinrol.com> References: <1146920205.2630.190.camel@xpc.home.erwinrol.com> Message-ID: <1146932743.4310.19.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-06 at 14:56 +0200, Erwin Rol wrote: > Are we really going to see a "OFF-TOPIC" reply to every second mail that > might be a bit of topic ? Cause those "warnings" are more off-topic than > some mails that might have better be send to the fedora-list. If you > feel the need to point out the failure of these "uneducated" persons > that dare to send off-topic mails, just send them a private reply, > instead of pointing out how stupid they are on a public mailing list. > > Yeah I know, this mail is off-topic ;-) When off topic posts occur repeatedly and the level of usefulness of discussions in this list begin to go too low, it is better to point things out publicly in a attempt to improve the signal<->noise level even when the attempt to do that does indeed temporarily push it even lower and discussions about such things does not help that either. Some have given up that fight and moved discussions over to fedora- maintainers but I think thats the wrong solution. Rahul From steve at silug.org Sat May 6 16:26:40 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 6 May 2006 11:26:40 -0500 Subject: License question In-Reply-To: <20060506093719.A28157@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060506000350.GB21671@osiris.silug.org> <1146875700.2630.177.camel@xpc.home.erwinrol.com> <20060506083136.A27682@xos037.xos.nl> <445C4F50.80200@hhs.nl> <20060506093719.A28157@xos037.xos.nl> Message-ID: <20060506162640.GA15825@osiris.silug.org> On Sat, May 06, 2006 at 09:37:19AM +0200, Jos Vos wrote: > On Sat, May 06, 2006 at 09:25:04AM +0200, Hans de Goede wrote: > > IANAL, but I agree. If you think this groupware is worth it, I would say > > try to find others who agree (the Debian packager for a start) build a > > small team and fork it. Don't forget to make much noise about the fork > > on every Linux related site (send out a press release) so that you can > > quickly build a _real_ community. > > Don't underestimate the work, especially as the package is not a > "clean" piece of software already, it does not work yet with GCJ > (if I understood Erwin correctly), etc. Erwin has patches for the previous version that make it work with GCJ. http://www.redhat.com/archives/fedora-devel-list/2006-February/msg00924.html > For that you really need a very motivated team and I think it's > worth first investigating of OGo is really not worth a try. OGo was in pretty sorry shape a few months ago when I last tried it. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From sundaram at fedoraproject.org Sat May 6 16:34:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 06 May 2006 22:04:56 +0530 Subject: License question In-Reply-To: <20060505153341.C20737@xos037.xos.nl> References: <1146830369.2630.62.camel@xpc.home.erwinrol.com> <20060505141936.A20603@xos037.xos.nl> <1146832401.2630.79.camel@xpc.home.erwinrol.com> <20060505150456.B20737@xos037.xos.nl> <1146835203.2630.118.camel@xpc.home.erwinrol.com> <20060505153341.C20737@xos037.xos.nl> Message-ID: <1146933296.4310.26.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-05 at 15:33 +0200, Jos Vos wrote: > B.t.w., not sure why RH has not yet put (al least not visible) some > of their resources on properly packaging something like OGo, as > groupware would be a welcome addition to RHEL too and I think it > *is* doable, although it will cost some effort. Not sure what Red Hat long term plans are in solving the problem of proving good open source groupware solutions if it indeed gets around to doing that based on customer demands and other strategic considerations. Usually there are more than enough problems to solve that Red Hat has to prioritize between them. The advantage and plan of Fedora is that people outside of Red Hat can help solve these by leveraging whatever infrastructure and other work that Red Hat already does within the Fedora space and thats exactly what is happening now. Rahul From jamatos at fc.up.pt Sat May 6 19:03:43 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 6 May 2006 20:03:43 +0100 Subject: OFF-TOPIC Re: rawhide report: 20060506 changes In-Reply-To: <32926.194.94.224.254.1146917849.squirrel@jose.freesurf.fr> References: <200605061215.07945.jamatos@fc.up.pt> <32926.194.94.224.254.1146917849.squirrel@jose.freesurf.fr> Message-ID: <200605062003.43594.jamatos@fc.up.pt> On Saturday 06 May 2006 13:17, Joachim Frieben wrote: > 1. This a topic for "fedora-list". I am subscribed in 9 fedora lists, including fedora-list, so clearly that was not my understanding. I hope that the discussion bellow justify this view. > 2. The rawhide package is likely to also install on FC5. I agree. That is one of the points. > 3. In case it doesn't, try "rpmbuild --rebuild gsl-1.8-1.src.rpm" > to build the binary packages for FC5. You might have to install > some additional FC5 devel packages though. As I have told before that is not the case. $ repoquery --repoid=development --requires gsl /sbin/install-info /sbin/ldconfig libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libgsl.so.0 libgslcblas.so.0 libm.so.6 libm.so.6(GLIBC_2.0) I wanted to point that if this was an Extras package this would probably have a more frequent update cycle closely related with package release than with the distribution release. This is one of the packages where I feel that it looses for not belonging to Extras. If the omission of this motivation made the message off-topic then I apologize but clearly I think that message belongs here. Since it is expected that Core retains one good package from every area and since gsl is one of a kind according to present goals I don't expect to see gsl moving to Extras so I bring this subject here where I think it the right forum to discuss this issue. PS: In no way this should be understand as any kind of personall attack including you or the package maintainer, in case it was not clear. -- Jos? Ab?lio From benjy.grogan at gmail.com Sat May 6 19:29:51 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Sat, 6 May 2006 15:29:51 -0400 Subject: AIGLX breaks XServer with new Repo In-Reply-To: References: <20060504192601.GA8365@redhat.com> <20060505142445.GA14102@redhat.com> Message-ID: With an update to the latest kernel 2.6.16-2111 all is good. So thanks. I'll get back to testing the latest aiglx now. Benjy On 5/5/06, Benjy Grogan wrote: > On 5/5/06, Nalin Dahyabhai wrote: > > On Fri, May 05, 2006 at 02:06:51AM -0400, Benjy Grogan wrote: > > > On 5/4/06, Nalin Dahyabhai wrote: > > > >On Thu, May 04, 2006 at 12:29:45AM -0400, Benjy Grogan wrote: > > > >> I had AIGLX working on FC5 using the old aiglx.repo that pointed to > > > >> Ray Strode's repo. I recently dropped in the new aiglx.repo that > > > >> Kristian Hogsberg posted a few weeks ago and the result was that my > > > >> XServer won't start anymore. > > > >[snip] > > > >> (EE) module ABI minor version (5) is newer than the server's version (4) > > > >[snip] > > > > > > > >Are you still using Xair (from the old xorg-x11-server-Xair package in > > > >Ray's repository, which is out of date) as your server? > > > > > > Yes, Xair was always at the top of the list in System Monitor in terms > > > of processor time. So, if that Xair should no longer be there, how do > > > I remove it and properly replace it with the right Xorg? > > > > First, remove the xorg-x11-server-Xair package. If you modified your > > desktop manager's configuration to call Xair instead of Xorg [1], you > > may need to change it back. > > > > If you use "startx" and modified your .xserverrc to call Xair instead of > > Xorg, revert that change. > > Okay. I removed xorg-x11-server-Xair package and then removed 0=aiglx > under [servers] from /etc/gdm/custom.conf and replaced it with > 0=Standard under [servers]. That fixed GDM and now I can login. > > But before I login, and right after udev is started with an [OK] I get > a black screen with a white cross. I have to type in > CTRL+ALT+BACKSPACE and then bootup continues. Otherwise it just hangs > there. A graphic screen never shows up and normally I get a grey > screen that gives me the option of hiding/showing details. Eventually > I come to a text login console, that quickly becomes the regular GDM > visual console. > > So something is still a little messed. Do you have any idea what this > could be? :) > > But at least I can get into my system now. Thanks! > > Benjy > > > > > > Cheers, > > > > Nalin > > > > [1] From an older revision of the wiki page: > > http://fedoraproject.org/wiki/RenderingProject/AiglxOnFedora?action=recall&rev=13 > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From chris at tylers.info Sat May 6 19:40:14 2006 From: chris at tylers.info (Chris Tyler) Date: Sat, 06 May 2006 15:40:14 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <20060506160003.2BE4973AD0@hormel.redhat.com> References: <20060506160003.2BE4973AD0@hormel.redhat.com> Message-ID: <1146944414.21352.190.camel@concord2.proximity.on.ca> The /sbin and /usr/sbin directories contain many utilities that are useful to non-superusers, such as ifconfig, netstat, arp, fuser, lsusb, runlevel, dumpe2fs, hwclock, lsof, traceroute, and many others. Obviously, most of those utilities can do -more- when run as superuser, but that doesn't diminish their value to mortals. For years, one of the first changes I've made to my Fedora (and RHL) systems is to comment out 'if' in /etc/profile that adds "/sbin:/usr/sbin:/usr/local/sbin" only to the path of the superuser: # Path manipulation #if [ $EUID = 0 ]; then pathmunge /sbin pathmunge /usr/sbin pathmunge /usr/local/sbin #fi Here's my question: Why don't we take that 'if' in the default /etc/profile, so those directories are in everyone's (default) PATH? Reasoning: - This change may encourage users to perform more tasks as non-superuser, which can only be a Good Thing(tm). - Utilities which a mortal user can't/shouldn't use are already protected from execution by permission or other mechanisms (e.g., explicit checks in 'neat' and 'lokkit'). - The hit for the additional path searching is miniscule. Really. Thoughts? (Am I missing something?) -- Chris Tyler From bruno at wolff.to Sat May 6 19:51:29 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 6 May 2006 14:51:29 -0500 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1146944414.21352.190.camel@concord2.proximity.on.ca> References: <20060506160003.2BE4973AD0@hormel.redhat.com> <1146944414.21352.190.camel@concord2.proximity.on.ca> Message-ID: <20060506195129.GC4087@wolff.to> On Sat, May 06, 2006 at 15:40:14 -0400, Chris Tyler wrote: > > For years, one of the first changes I've made to my Fedora (and RHL) > systems is to comment out 'if' in /etc/profile that adds > "/sbin:/usr/sbin:/usr/local/sbin" only to the path of the superuser: > > Thoughts? (Am I missing something?) I do the same thing. From moe at blagblagblag.org Sat May 6 20:24:08 2006 From: moe at blagblagblag.org (jeff) Date: Sat, 06 May 2006 14:24:08 -0600 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1146944414.21352.190.camel@concord2.proximity.on.ca> References: <20060506160003.2BE4973AD0@hormel.redhat.com> <1146944414.21352.190.camel@concord2.proximity.on.ca> Message-ID: <445D05E8.3000704@blagblagblag.org> Chris Tyler wrote: > The /sbin and /usr/sbin directories contain many utilities that are > useful to non-superusers, such as ifconfig, netstat, arp, fuser, lsusb, > runlevel, dumpe2fs, hwclock, lsof, traceroute, and many others. > Obviously, most of those utilities can do -more- when run as superuser, > but that doesn't diminish their value to mortals. I once asked about this wrt `ifconfig` in #fedora and got lashed as if I asked for mp3 support or something... I believe the correct answer is not to add sbin to users' paths, but to move binaries out of sbin and into bin and symlink them so they don't break old scripts. By my reading, this is what the FHS implies, but there is lots of inertia to such a change. /sbin: "Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16 Note "root-only" /usr/sbin: "This directory contains any non-essential binaries used exclusively by the system administrator" http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE25 Note "EXCLUSIVELY" For this reason a few years ago `traceroute` was moved out of sbin. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18313 I encounter this issue all the time ("how come `ifconfig` isn't installed on my system?")--I even heard it this morning... In sum, it would be a nice change, but it's highly unlikely. As I was told, "it's been discussed over & over and the netgods have made their decision". -Jeff From camilo at mesias.co.uk Sat May 6 20:44:26 2006 From: camilo at mesias.co.uk (Cam) Date: Sat, 06 May 2006 21:44:26 +0100 Subject: [aiglx] repo -> outdated vte lib In-Reply-To: References: Message-ID: <445D0AAA.7040909@mesias.co.uk> Rudolf >> I'm experiencing this same problem with gnome-terminal. Is there >> another way of opening a console on fedora? Same here. Alt-F2 and 'xterm' to the rescue ;-) -Cam -- <-- camilo at mesias.co.uk From cra at WPI.EDU Sat May 6 20:28:41 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 6 May 2006 16:28:41 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1146944414.21352.190.camel@concord2.proximity.on.ca> References: <20060506160003.2BE4973AD0@hormel.redhat.com> <1146944414.21352.190.camel@concord2.proximity.on.ca> Message-ID: <20060506202841.GK27389@angus.ind.WPI.EDU> On Sat, May 06, 2006 at 03:40:14PM -0400, Chris Tyler wrote: > Here's my question: Why don't we take that 'if' in the > default /etc/profile, so those directories are in everyone's (default) > PATH? I admit that have the sbin directories in my path, but it does actually cause a problem in a few cases, one being consolehelper. e.g. ethereal uses consolehelper to request the root password for more functionality, but only for /usr/bin/ethereal, not /usr/sbin/ethereal: -rwxr-xr-x 1 root root 1437856 Apr 25 11:20 /usr/sbin/ethereal lrwxrwxrwx 1 root root 13 Apr 27 05:52 /usr/bin/ethereal -> consolehelper If I just type "ethereal" and execute the copy in /usr/sbin as a normal user, then I never get prompted and I cannot use the features that require root privs, such as capturing packets. From smooge at gmail.com Sat May 6 21:15:19 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 6 May 2006 15:15:19 -0600 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <445D05E8.3000704@blagblagblag.org> References: <20060506160003.2BE4973AD0@hormel.redhat.com> <1146944414.21352.190.camel@concord2.proximity.on.ca> <445D05E8.3000704@blagblagblag.org> Message-ID: <80d7e4090605061415hfd71986r16bc6cbbd00b348e@mail.gmail.com> On 5/6/06, jeff wrote: > Chris Tyler wrote: > > The /sbin and /usr/sbin directories contain many utilities that are > > useful to non-superusers, such as ifconfig, netstat, arp, fuser, lsusb, > > runlevel, dumpe2fs, hwclock, lsof, traceroute, and many others. > > Obviously, most of those utilities can do -more- when run as superuser, > > but that doesn't diminish their value to mortals. > > I once asked about this wrt `ifconfig` in #fedora and got lashed as if I > asked for mp3 support or something... > > I believe the correct answer is not to add sbin to users' paths, but to > move binaries out of sbin and into bin and symlink them so they don't > break old scripts. By my reading, this is what the FHS implies, but > there is lots of inertia to such a change. > > /sbin: "Utilities used for system administration (and other root-only > commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16 > The 'and' in that sentance is probably incorrect as in (or other root-only commands). Many of the commands listed in the original email: ifconfig, netstat, arp, fuser, lsusb, runlevel, dumpe2fs, hwclock, lsof, traceroute, are considered classical system administration commands. The standard user is not supposed to have any need to use any of them. [In the sense that if they are using them they are doing system administraction duties and probably should know what they are doing.] In some environments letting regular users is highly frowned on or disallowed (I have had to write a script that basically did a chmod o-rwx /usr/sbin/* to meet certain security policies). In other environments.. the exact opposite is the required. The current layout is sort of the middle ground in my opinion. -- Stephen J Smoogen. CSIRT/Linux System Administrator From i.pilcher at comcast.net Sat May 6 21:15:27 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Sat, 06 May 2006 16:15:27 -0500 Subject: libusb scanner In-Reply-To: <20060504170532.GA17007@devserv.devel.redhat.com> References: <1146741861.2630.12.camel@xpc.home.erwinrol.com> <20060504170532.GA17007@devserv.devel.redhat.com> Message-ID: Bill Nottingham wrote: > What *should* happen is that the udev rules in /etc/udev/rules.d/60-libsane.rules > get run, making a scanner- symlink to /dev/bus/usb/XXX. This > device is then chown'ed via pam_console, later by udev. It's possible that the OP's scanner simply isn't listed in /etc/udev/rules.d/60-libsane.rules. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From mailinglists at erwinrol.com Sat May 6 21:38:37 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 06 May 2006 23:38:37 +0200 Subject: libusb scanner In-Reply-To: References: <1146741861.2630.12.camel@xpc.home.erwinrol.com> <20060504170532.GA17007@devserv.devel.redhat.com> Message-ID: <1146951517.2630.237.camel@xpc.home.erwinrol.com> On Sat, 2006-05-06 at 16:15 -0500, Ian Pilcher wrote: > Bill Nottingham wrote: > > What *should* happen is that the udev rules in /etc/udev/rules.d/60-libsane.rules > > get run, making a scanner- symlink to /dev/bus/usb/XXX. This > > device is then chown'ed via pam_console, later by udev. > > It's possible that the OP's scanner simply isn't listed in > /etc/udev/rules.d/60-libsane.rules. Hmmm the HP 6300C is there and I just tried it again and now the scanner is listed when i start up Kooka as a normal user. Was this a recent change to udev ? Or sane ? - Erwin From mpeters at mac.com Sun May 7 05:33:41 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 06 May 2006 22:33:41 -0700 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1146944414.21352.190.camel@concord2.proximity.on.ca> References: <20060506160003.2BE4973AD0@hormel.redhat.com> <1146944414.21352.190.camel@concord2.proximity.on.ca> Message-ID: <1146980022.8410.46.camel@atlantis.mpeters.local> On Sat, 2006-05-06 at 15:40 -0400, Chris Tyler wrote: > The /sbin and /usr/sbin directories contain many utilities that are > useful to non-superusers, such as ifconfig, netstat, arp, fuser, lsusb, > runlevel, dumpe2fs, hwclock, lsof, traceroute, and many others. > Obviously, most of those utilities can do -more- when run as superuser, > but that doesn't diminish their value to mortals. > > For years, one of the first changes I've made to my Fedora (and RHL) > systems is to comment out 'if' in /etc/profile that adds > "/sbin:/usr/sbin:/usr/local/sbin" only to the path of the superuser: > > # Path manipulation > #if [ $EUID = 0 ]; then > pathmunge /sbin > pathmunge /usr/sbin > pathmunge /usr/local/sbin > #fi > > Here's my question: Why don't we take that 'if' in the > default /etc/profile, so those directories are in everyone's (default) > PATH? Reasoning: Users who need it can add the following to their bash ~/.profile file: export PATH=$PATH:/sbin:/usr/sbin (or /sbin:/usr/sbin:$PATH ) or create symlinks to what they need in ~/bin/ or create a bashe alias or ... There is no need for /sbin, /usr/sbin, /usr/local/sbin to be in the path of unprivileged user by default. Users can change that themselves if they need them in their path - either temporarily or permanently. From buildsys at redhat.com Sun May 7 08:04:09 2006 From: buildsys at redhat.com (Build System) Date: Sun, 7 May 2006 04:04:09 -0400 Subject: rawhide report: 20060507 changes Message-ID: <200605070804.k47849DS000806@porkchop.devel.redhat.com> Updated Packages: glibc-kernheaders-3.0-29 ------------------------ * Sun May 07 2006 David Woodhouse 3.0-29 - Remove asm/semaphore.h, asm/mmu.h - Replace asm/atomic.h with a simple #error - Add #warning to asm/io.h * Sat May 06 2006 David Woodhouse 3.0-28 - Remove include/media/ since Mauro says we don't need it kernel-2.6.16-1.2196_FC6 ------------------------ * Sat May 06 2006 Dave Jones - 2.6.17rc3-git12 tmpwatch-2.9.7-1 ---------------- * Sat May 06 2006 Miloslav Trmac - 2.9.7-1 - Add --nosymlinks (#190691) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From paul at cypherpunks.ca Sun May 7 15:38:20 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Sun, 7 May 2006 17:38:20 +0200 (CEST) Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1146980022.8410.46.camel@atlantis.mpeters.local> References: <20060506160003.2BE4973AD0@hormel.redhat.com> <1146944414.21352.190.camel@concord2.proximity.on.ca> <1146980022.8410.46.camel@atlantis.mpeters.local> Message-ID: On Sat, 6 May 2006, Michael A. Peters wrote: > On Sat, 2006-05-06 at 15:40 -0400, Chris Tyler wrote: > > The /sbin and /usr/sbin directories contain many utilities that are > > useful to non-superusers, such as ifconfig, netstat, arp, fuser, lsusb, > > runlevel, dumpe2fs, hwclock, lsof, traceroute, and many others. > > Obviously, most of those utilities can do -more- when run as superuser, > > but that doesn't diminish their value to mortals. > > > > For years, one of the first changes I've made to my Fedora (and RHL) > > systems is to comment out 'if' in /etc/profile that adds > > "/sbin:/usr/sbin:/usr/local/sbin" only to the path of the superuser: I have to agree here. It is the first thing I do. And I shouldn't need to do it. The second thing I do is remove the aliases in /root/.bashrc. That I can understand, and I don't mind doing, since this protects newby users with root privs. > > Here's my question: Why don't we take that 'if' in the > > default /etc/profile, so those directories are in everyone's (default) > > PATH? Reasoning: > > Users who need it can add the following to their bash ~/.profile file: > > export PATH=$PATH:/sbin:/usr/sbin > > (or /sbin:/usr/sbin:$PATH ) The point is not that they can do it, the point is that: 1) it does not add any security to the system not having these in the path 2) it is annoying for experienced users who are used to these commands being in their path. 3) There is no penalty for giving mortals these extra commands. So instead of telling us how we can fix it in 5 ways on every single box we install, tell us what the harm would be if mortals have these commands. Paul From vonbrand at inf.utfsm.cl Sun May 7 20:38:55 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 07 May 2006 16:38:55 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: Your message of "Sun, 07 May 2006 17:38:20 +0200." Message-ID: <200605072038.k47KcuUx008814@pincoya.inf.utfsm.cl> Paul Wouters wrote: [...] > The point is not that they can do it, the point is that: > > 1) it does not add any security to the system not having these in the > path Right. > 2) it is annoying for experienced users who are used to these commands > being in their path. They fix that once for their account, no sweat. > 3) There is no penalty for giving mortals these extra commands. Confused end-users who wonder what all the weird commands do is a penalty. > So instead of telling us how we can fix it in 5 ways on every single box > we install, tell us what the harm would be if mortals have these > commands. I do remember times before /sbin and /usr/sbin... the change was done quite a while back to segregate administration commands from end-user commands. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Sun May 7 20:33:54 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 07 May 2006 16:33:54 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: Your message of "Sat, 06 May 2006 14:24:08 CST." <445D05E8.3000704@blagblagblag.org> Message-ID: <200605072033.k47KXs5g008766@pincoya.inf.utfsm.cl> jeff wrote: > Chris Tyler wrote: > > The /sbin and /usr/sbin directories contain many utilities that are > > useful to non-superusers, such as ifconfig, netstat, arp, fuser, lsusb, > > runlevel, dumpe2fs, hwclock, lsof, traceroute, and many others. > > Obviously, most of those utilities can do -more- when run as superuser, > > but that doesn't diminish their value to mortals. [...] > I believe the correct answer is not to add sbin to users' paths, but > to move binaries out of sbin and into bin and symlink them so they > don't break old scripts. By my reading, this is what the FHS implies, > but there is lots of inertia to such a change. > /sbin: "Utilities used for system administration (and other root-only > commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16 > > Note "root-only" Note "system administration"... > /usr/sbin: "This directory contains any non-essential binaries used > exclusively by the system administrator" > http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE25 > > Note "EXCLUSIVELY" Probably an overstatement. > For this reason a few years ago `traceroute` was moved out of sbin. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18313 That is sensible. But ifconfig(8) is not for luser consumption, and so are lots of others. If you do want them, go /sbin/ifconfig etc. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From link at pobox.com Mon May 8 09:04:25 2006 From: link at pobox.com (Terje Bless) Date: Mon, 8 May 2006 11:04:25 +0200 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <200605072033.k47KXs5g008766@pincoya.inf.utfsm.cl> Message-ID: Horst von Brand wrote: >ifconfig(8) is not for luser consumption, and so are lots of others. `ifconfig` is _also_ for system administrators. Regular users ? my Oracle DBAs, say ? have a legitimate need to check the output of ifconfig on occasion; and I would just as soon not have to fiddle with paths or aliases for all those accounts on all the systems I administer. I also find it annoying that I either have to type the full path ? particularly as it means I have to remember which of /bin:/usr/bin:/sbin:/usr/sbin the utility in questions resides in ? or become root just to check ifconfig output. Utilities that serve a useful purpose for non-root users should by default be available in non-root users' path; if in no other way then at least by way of a symlink in the ?unprivileged? directory. Conversely, utilities that non-root users should not be allowed to use need to be protected in an effective manner; and removing the directory from their path is not it. This isn't even security by obscurity, it's security by obtuseness. -- >For all I know they probably have a standard for >which direction to put the thread on a bolt. That would be ISO 261:1973. -- John Cowan From Lam at Lam.pl Mon May 8 10:31:29 2006 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 08 May 2006 12:31:29 +0200 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <200605072038.k47KcuUx008814@pincoya.inf.utfsm.cl> References: <200605072038.k47KcuUx008814@pincoya.inf.utfsm.cl> Message-ID: <1147084289.2944.21.camel@pensja.lam.pl> Dnia 07-05-2006, nie o godzinie 16:38 -0400, Horst von Brand napisa?(a): > They fix that once for their account, no sweat. Once for every account on every machine. > > 3) There is no penalty for giving mortals these extra commands. > Confused end-users who wonder what all the weird commands do is a penalty. My FC5: [lam at pensja ~]$ ls -1 /bin /usr/bin | wc -l 2511 [lam at pensja ~]$ ls -1 /sbin /usr/sbin | wc -l 616 So 2500 commands doesn't confuse anyone and any end-user knows exactly what those commands do? I know I don't with over a decade of Linux experience. Per cent, I know more commands from sbins than from bins. > I do remember times before /sbin and /usr/sbin... the change was done quite > a while back to segregate administration commands from end-user commands. I don't remember such times. While I and everyone else in this thread understand why some commands can be really root-only, most of them work for users anyhow, any user can use them anyhow and they're useful to users anyhow, they're just not in the path. Can you explain to me why there's /bin/traceroute, but /usr/sbin/mtr? This is the one symlink I do every time. Debian has it in /usr/bin IIRC. Ask for other examples and 100 people will step up. The wrong thing IMHO would be having /sbin before /bin in the search path. As someone stated earlier, it can break consolehelper symlinks. Other than that, either let's make a symlinking-fest or add them to the path as many suggest, only after /bin and co. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 8 14:57:12 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 8 May 2006 16:57:12 +0200 Subject: Composite extension breaks proprietary flash plugin Message-ID: <20060508165712.62df3404@python2> Hi, Just to point out that enabling the "Composite" extension in Rawhide's Xorg to try out Aiglx makes firefox exit with a nasty X error when it tries to use the flash plugin. Unless this is a bug in Xorg (which I doubt), it's now up to Macromedia to fix the issue. I just wanted to point it out to other Rawhide testers that could have been having the same issue without knowing any workaround ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2196_FC6 Load : 0.92 1.01 0.58 From wtogami at redhat.com Mon May 8 15:16:33 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 08 May 2006 11:16:33 -0400 Subject: Composite extension breaks proprietary flash plugin In-Reply-To: <20060508165712.62df3404@python2> References: <20060508165712.62df3404@python2> Message-ID: <445F60D1.5000404@redhat.com> Matthias Saou wrote: > Hi, > > Just to point out that enabling the "Composite" extension in Rawhide's > Xorg to try out Aiglx makes firefox exit with a nasty X error when it tries > to use the flash plugin. > > Unless this is a bug in Xorg (which I doubt), it's now up to Macromedia to > fix the issue. I just wanted to point it out to other Rawhide testers that > could have been having the same issue without knowing any workaround ;-) > > Matthias > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155582 That bug is tracked here. Until this is fixed, you can workaround that issue with export XLIB_SKIP_ARGB_VISUALS=1 before running firefox. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=189808 Flash Linux Bug Tracker Warren Togami wtogami at redhat.com From telent998 at 126.com Mon May 8 15:41:37 2006 From: telent998 at 126.com (telent998) Date: Mon, 8 May 2006 23:41:37 +0800 (CST) Subject: help me------------why FC5 can't find my keyboard and mouse?? Message-ID: <445F66B1.0000AC.07871@m62.126.com> hi all yesterday I installed FC5 on my computer.All is right when installing.But after rebooting,I found that when booting,my keyboaed and mouse is Ok.And when screen appear to Xwindows,I want to login in and then find my keyboard and mouse could not move!! My keyboard and mouse is all PS/2.and My display adaper is onboard(intel 915gl). please help me .... I need your help. best regards lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at lovesunix.net Mon May 8 15:51:26 2006 From: david at lovesunix.net (David Nielsen) Date: Mon, 08 May 2006 17:51:26 +0200 Subject: help me------------why FC5 can't find my keyboard and mouse?? In-Reply-To: <445F66B1.0000AC.07871@m62.126.com> References: <445F66B1.0000AC.07871@m62.126.com> Message-ID: <1147103486.16952.22.camel@localhost.localdomain> man, 08 05 2006 kl. 23:41 +0800, skrev telent998: > > hi all > > > yesterday I installed FC5 on my computer.All is right when > installing.But after rebooting,I found that when booting,my keyboaed > and mouse is Ok.And when screen > appear to Xwindows,I want to login in and then find my keyboard and > mouse could not move!! > My keyboard and mouse is all PS/2.and My display adaper is > onboard(intel 915gl). > please help me .... > I need your help. > best regards > > lin Try the fedora list, this is development list other than that you need to provide more information like the layout for the trusty userbase - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From buildsys at redhat.com Mon May 8 16:23:04 2006 From: buildsys at redhat.com (Build System) Date: Mon, 8 May 2006 12:23:04 -0400 Subject: rawhide report: 20060508 changes Message-ID: <200605081623.k48GN4Un031226@porkchop.devel.redhat.com> Updated Packages: kdebase-6:3.5.2-7 ----------------- * Thu May 04 2006 Than Ngo 6:3.5.2-7 - use XDG_CONFIG_DIRS for kde menu #178320 php-pear-1:1.4.9-2 ------------------ * Mon May 08 2006 Joe Orton 1:1.4.9-2 - update to 1.4.9 (thanks to Remi Collet, #183359) - package /usr/share/pear/.pkgxml (#190252) - update to XML_RPC-1.4.8 - bundle the v3.0 LICENSE file * Tue Feb 28 2006 Joe Orton 1:1.4.6-2 - set cache_dir directory, own /var/cache/php-pear * Mon Jan 30 2006 Joe Orton 1:1.4.6-1 - update to 1.4.6 - require php >= 5.1.0 (#178821) policycoreutils-1.30.6-5 ------------------------ * Sun May 07 2006 Dan Walsh 1.30.6-5 - Fix genhomedircon to catch duplicate homedir problem Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From notting at redhat.com Mon May 8 17:15:14 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 8 May 2006 13:15:14 -0400 Subject: libusb scanner In-Reply-To: <1146951517.2630.237.camel@xpc.home.erwinrol.com> References: <1146741861.2630.12.camel@xpc.home.erwinrol.com> <20060504170532.GA17007@devserv.devel.redhat.com> <1146951517.2630.237.camel@xpc.home.erwinrol.com> Message-ID: <20060508171514.GA28648@devserv.devel.redhat.com> Erwin Rol (mailinglists at erwinrol.com) said: > On Sat, 2006-05-06 at 16:15 -0500, Ian Pilcher wrote: > > Bill Nottingham wrote: > > > What *should* happen is that the udev rules in /etc/udev/rules.d/60-libsane.rules > > > get run, making a scanner- symlink to /dev/bus/usb/XXX. This > > > device is then chown'ed via pam_console, later by udev. > > > > It's possible that the OP's scanner simply isn't listed in > > /etc/udev/rules.d/60-libsane.rules. > > Hmmm the HP 6300C is there and I just tried it again and now the scanner > is listed when i start up Kooka as a normal user. Was this a recent > change to udev ? Or sane ? Pre-FC5. Bill From d.lesca at solinos.it Mon May 8 17:45:08 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Mon, 08 May 2006 19:45:08 +0200 Subject: Linux ATM: usbatm.c: OAM support Message-ID: <1147110309.3356.943.camel@lesca.home.solinos.it> Hi, someone can explain me why the official kernel do not include in usbatm.c the OAM support patch? (see below) I need this support an now I want apply this patch to the FC5 standard kernel. I have the usbatm.c whit the patch, howto I can rebuild it without rebuild all component of kernel ? Please, someone can help me to do that? I am not a kernel's Guru :-( Many thanks Dario Lesca ------- Messaggio inoltrato ------- > Da: Aurelio Arroyo > A: Dario Lesca > Cc: usbatm at lists.infradead.org > Oggetto: RE: [Linux-ATM-General] Activate OAM support > Data: Mon, 8 May 2006 17:49:30 +0200 (CEST) > > > Yesterday I have install a new server bind to a new > > Telecom (italy) ADSL > > (2048Kb down/640Kb Op), the adsl line up but when I > > generate TCP traffic > > (ping) I got the "OAM not supported" into > > /var/log/messages and the > > traffic not work. > > > > Is the OAM support not present the my problem? > > The OAM support must enabled in kernel space? > > How to I can activate the OAM Support? > > > > I think this error are from usbatm module: > http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=blob;h=c1211fc037d997b8a30cee323ded090d72d9da63;hb=bf7d8bacaaf241a0f0157986fd4e1e6834873d50;f=drivers/usb/atm/usbatm.c#l325 > > This is a old patch to usbatm: > http://sourceforge.net/mailarchive/message.php?msg_id=11685926 > > A version of usbatm.c with OAM (But not full sync with > last kernel version, - mutex, kzalloc, etc -): > http://cvs.sourceforge.net/viewcvs.py/zyxel630-11/amedyn2/module/usbatm.c?rev=1.13&view=log > > > Please, confirm that the change work for you. I don't > remember why usbatm don't have this patch. > > > > > ______________________________________________ > LLama Gratis a cualquier PC del Mundo. > Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. > http://es.voice.yahoo.com -- Dario Lesca From dcbw at redhat.com Mon May 8 18:44:46 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 08 May 2006 14:44:46 -0400 Subject: Linux ATM: usbatm.c: OAM support In-Reply-To: <1147110309.3356.943.camel@lesca.home.solinos.it> References: <1147110309.3356.943.camel@lesca.home.solinos.it> Message-ID: <1147113887.5797.4.camel@dhcp83-74.boston.redhat.com> On Mon, 2006-05-08 at 19:45 +0200, Dario Lesca wrote: > Hi, someone can explain me why the official kernel do not include in > usbatm.c the OAM support patch? (see below) Fedora tracks the upstream kernel as closely as possible. Therefore, if you want a patch in Fedora, you need to get it merged with the Linux kernel. Either submit the patch yourself (to the Linux Kernel Mailing List), or better yet, get the maintainer of the patch to submit it. > I need this support an now I want apply this patch to the FC5 standard > kernel. > > I have the usbatm.c whit the patch, howto I can rebuild it without > rebuild all component of kernel ? If the patch is to a kernel _module_, then you can rebuild that module fairly easily. Get the 'kernel-devel' package for your kernel (ie, 'yum install kernel-devel'), and then cd into the directory of the module. Assuming the makefile is set up right (which should have been done for you), you can: make -C /lib/modules/`uname -r`/build M=`pwd` modules And your module will build. Then copy the .ko file to /lib/modules/`uname -r`/... over top of the stock version, but make _sure_ to back up the stock version of the module before copying the new one over it. Dan > Please, someone can help me to do that? I am not a kernel's Guru :-( > > Many thanks > > Dario Lesca > > ------- Messaggio inoltrato ------- > > Da: Aurelio Arroyo > > A: Dario Lesca > > Cc: usbatm at lists.infradead.org > > Oggetto: RE: [Linux-ATM-General] Activate OAM support > > Data: Mon, 8 May 2006 17:49:30 +0200 (CEST) > > > > > Yesterday I have install a new server bind to a new > > > Telecom (italy) ADSL > > > (2048Kb down/640Kb Op), the adsl line up but when I > > > generate TCP traffic > > > (ping) I got the "OAM not supported" into > > > /var/log/messages and the > > > traffic not work. > > > > > > Is the OAM support not present the my problem? > > > The OAM support must enabled in kernel space? > > > How to I can activate the OAM Support? > > > > > > > I think this error are from usbatm module: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=blob;h=c1211fc037d997b8a30cee323ded090d72d9da63;hb=bf7d8bacaaf241a0f0157986fd4e1e6834873d50;f=drivers/usb/atm/usbatm.c#l325 > > > > This is a old patch to usbatm: > > http://sourceforge.net/mailarchive/message.php?msg_id=11685926 > > > > A version of usbatm.c with OAM (But not full sync with > > last kernel version, - mutex, kzalloc, etc -): > > http://cvs.sourceforge.net/viewcvs.py/zyxel630-11/amedyn2/module/usbatm.c?rev=1.13&view=log > > > > > > Please, confirm that the change work for you. I don't > > remember why usbatm don't have this patch. > > > > > > > > > > ______________________________________________ > > LLama Gratis a cualquier PC del Mundo. > > Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. > > http://es.voice.yahoo.com > -- > Dario Lesca > From vonbrand at inf.utfsm.cl Mon May 8 19:47:33 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 08 May 2006 15:47:33 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: Your message of "Mon, 08 May 2006 11:04:25 +0200." Message-ID: <200605081947.k48JlX7x006681@laptop11.inf.utfsm.cl> Terje Bless wrote: > Horst von Brand wrote: > >ifconfig(8) is not for luser consumption, and so are lots of others. > `ifconfig` is _also_ for system administrators. Regular users ??? my > Oracle DBAs, say ??? Those aren't "regular users" by a /very/ long shot in my book. > have a legitimate need to check the output of > ifconfig on occasion; and I would just as soon not have to fiddle with > paths or aliases for all those accounts on all the systems I administer. Set up a generic .bashrc for those special accounts then... > I also find it annoying that I either have to type the full path ??? > particularly as it means I have to remember which of > /bin:/usr/bin:/sbin:/usr/sbin the utility in questions resides in ??? or > become root just to check ifconfig output. Use aliases. > Utilities that serve a useful purpose for non-root users should by > default be available in non-root users' path; if in no other way then at > least by way of a symlink in the ???unprivileged??? directory. They are in /bin and /usr/bin. What is in /sbin or /usr/sbin is /not/ for regular user consumption. If they need it, they aren't regular users. > Conversely, utilities that non-root users should not be allowed to use > need to be protected in an effective manner; ... by permission to run only by selected user/group, by internal checks in the utility, by permission checks in the kernel; where you /must/ rely only on the last for real security, just exactly as this has worked from day one (or thereabouts) in Unix... > and removing the directory > from their path is not it. This isn't even security by obscurity, it's > security by obtuseness. It has nothing whatsoever to do with security, and everything with not confusing random users with commands they can't use sensibly. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From paul at cypherpunks.ca Mon May 8 20:03:02 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 8 May 2006 22:03:02 +0200 (CEST) Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <200605081947.k48JlX7x006681@laptop11.inf.utfsm.cl> References: <200605081947.k48JlX7x006681@laptop11.inf.utfsm.cl> Message-ID: > > `ifconfig` is _also_ for system administrators. Regular users ??? my > > Oracle DBAs, say ??? > > Those aren't "regular users" by a /very/ long shot in my book. In that case, there are no "regular users" on most linux servers. In which case you only make the case for allowing commands like ifconfig to be used by everyone (since most linux servers have no "regular users"). > > I also find it annoying that I either have to type the full path ??? > > particularly as it means I have to remember which of > > /bin:/usr/bin:/sbin:/usr/sbin the utility in questions resides in ??? or > > become root just to check ifconfig output. > > Use aliases. The point here was not that it was impossible to overcome. The point being made was that a majority of the users want commands in /sbin and /usr/sbin to be in their path, even if they do not have root permission on them. > They are in /bin and /usr/bin. What is in /sbin or /usr/sbin is /not/ for > regular user consumption. If they need it, they aren't regular users. You are confusing "regular users" with "endusers that only click icons". Those click-users are not running a terminal window, so they have no issues with wether there are 2500 or 3000 commands in their path. However, those who do run a terminal, tend to really enjoy using commands like "ip", "ifconfig", "ping" and "traceroute". > > Conversely, utilities that non-root users should not be allowed to use > > need to be protected in an effective manner; > > ... by permission to run only by selected user/group, by internal checks in > the utility, by permission checks in the kernel; where you /must/ rely > only on the last for real security, just exactly as this has worked from > day one (or thereabouts) in Unix... This is not a security issue. No security is gained from needing to type "/sbin/ifconfig" over "ifconfig". > > and removing the directory > > from their path is not it. This isn't even security by obscurity, it's > > security by obtuseness. > > It has nothing whatsoever to do with security, and everything with not > confusing random users with commands they can't use sensibly. Oh come on. A lot of unix commands are two letters long. This has nothing to do with protecting the user, and has all to do with sysadmins wanting to cut down on typing. 2500 vs 3000 commands is not going to make a different to the enduser that "needs protection". And on the other side, if we do believe we need to help and protect these users, then i should file a bug report against "cal 5" because it displays the year 5 instead of the current year, fifth month. Let's dump some legacy guys. I can understand /foo versus /usr/foo, as we can still do shared /usr readonly mounts, but the distinction between /bin and /sbin is silly. And that's why people here are annoyed by it, they always have to make this change on any fresh install of redhat. Paul From resqe1a0 at verizon.net Mon May 8 21:46:13 2006 From: resqe1a0 at verizon.net (Ron Watson) Date: Mon, 08 May 2006 17:46:13 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: References: <200605081947.k48JlX7x006681@laptop11.inf.utfsm.cl> Message-ID: <445FBC25.6000407@verizon.net> An HTML attachment was scrubbed... URL: From mharris at mharris.ca Tue May 9 01:55:45 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 08 May 2006 21:55:45 -0400 Subject: xorg-x11- packaging prefix In-Reply-To: <20060503082035.GB27035@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> Message-ID: <445FF6A1.2060704@mharris.ca> Axel Thimm wrote: > Hi, > > Should packages with source from outside of the xorg-x11 tree carry > this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like > often used "for " or is it a cendor prefix, e.g. "by > "? No, they should not use the xorg-x11 prefix, nor Xorg, etc. Only software which is officially released by the X.Org foundation should contain the X.Org name/trademark, etc. as far as I understand. > How would a 3rd party driver package be best named? For the other open source drivers we include for the Xorg server which are not part of the Xorg X11 distribution itself, we name them the same name their upstream project uses. ie: The "linuxwacom" project provides the "linuxwacom" driver, which we package as "linuxwacom" rpm package name. The same thing is done for the synaptics input driver, as it is also not part of X.Org X11. There is currently no standardization outside of X.Org as to how to name driver CVS/git/svn/etc. repositories, nor tarball names, rpm package names, etc. so it is more or less up to the project or vendor how to name their software. It is recommended though to avoid using the X.Org name both to clearly indicate to users that the software is not part of the X.Org project, and to honour the X.Org trademark.[1] > xorg-x11-drv- or <3rd-party-vendor>-drv-? Not xorg-x11-drv-*, as that suggests to users that the software came from X.Org, which is untrue if the software did not come from X.Org. Any other naming is probably sufficient, such as: fglrx-$version-$release.src.rpm nvidia-$version-$release.src.rpm etc.. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Tue May 9 02:02:01 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 08 May 2006 22:02:01 -0400 Subject: xorg-x11- packaging prefix In-Reply-To: <20060503121024.GI27035@neu.nirvana> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> Message-ID: <445FF819.7030708@mharris.ca> Axel Thimm wrote: > On Wed, May 03, 2006 at 01:54:17PM +0200, Arjan van de Ven wrote: >> On Wed, 2006-05-03 at 12:58 +0200, dragoran wrote: >>> Axel Thimm wrote: >>>> Should packages with source from outside of the xorg-x11 tree carry >>>> this prefix (e.g. ivtv, nvidia, ati, etc)? E.g. is this a prefix like >>>> often used "for " or is it a cendor prefix, e.g. "by >>>> "? >>>> >>>> How would a 3rd party driver package be best named? >>>> xorg-x11-drv- or <3rd-party-vendor>-drv-? >>>> >>> I would say use >>> >>> xorg-x11-drv- >>> >>> the second one only confuses users. >> but xorg-x11 is the name of the upstream vendor, and probably >> trademarked or close to that. So I would suggest to not do that; even if >> it's not a legal trademark, it makes sure that users realize where it >> comes from (and thus where to report bugs ;) > > Which brings us back to the question, does the prefix really imply "by > " or "for ". Usually in packaging practice > "-foo" means foo built for , e.g. the miriads of > perl-XXX packages, now python-XXX, too, java-XXX, gkrellm-XXX, and all > other module- or plugin-type packages. I'm the one who created the package naming of xorg-x11-* originally, which some other distributions have also went along with since then as well. My choice of "xorg-x11" as the prefix for X packages was intended specifically to: - indicate that the software is an official part of the X.Org X11 distribution - allow users to see all of the X.Org supplied software grouped together in directory listings, etc. - make it easier for me (and others) to write scripts to automate various parts of the development process, via globbing and other mechanisms. The xorg-x11 rpm package prefix was thus intended to say "This software is part of the official X.Org X11 distribution." and not "This software is compatible with and/or intended for use with $same", just to be clear. ;o) > I don't mind either way, I just want to hear a clear statement from > the X11 packaging folks. Personally I tend to hear the sound of the > vendor in it, but I see many folks suggesting to use it as a domain > prefix. That's why I'm bringing it up. It's the vendor. Those who are suggesting it is a prefix for use by random 3rd party drivers and/or other 3rd party software are sadly mistaken, but nonetheless contributing their opinions in a useful manner. ;o) They now stand corrected however. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Tue May 9 02:07:41 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 08 May 2006 22:07:41 -0400 Subject: xorg-x11- packaging prefix In-Reply-To: <1146677614.28311.6.camel@rousalka.dyndns.org> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <1146677614.28311.6.camel@rousalka.dyndns.org> Message-ID: <445FF96D.2030101@mharris.ca> Nicolas Mailhot wrote: > Le mercredi 03 mai 2006 ? 14:10 +0200, Axel Thimm a ?crit : > >> Which brings us back to the question, does the prefix really imply "by >> " or "for ". Usually in packaging practice >> "-foo" means foo built for , e.g. the miriads of >> perl-XXX packages, now python-XXX, too, java-XXX, > > There are no miriads of java-XXX precisely because "java" is not a code > provider. > > You *do* have miriads of jakarta-XXX packages because jakarta represents > the org which produces the code in question (likewise you have > classpathx-XXX packages) > > I believe the perl-XXXX are close to being a cpan-XXXX synonym. > > IMHO the prefix means "code closely associated to project foo", either > because foo is the upstream project or it's a well-known extension of > foo which can easily be found from foo website. But in the end it's a > packager preference. Which would be an incorrect interpretation of what I chose the prefix for. It is true that I (or anyone) can not prevent someone from abusing this namespace in any enforceable manner, however I hope people have the decency to understand and respect the choice and not step all over the namespace due to differing opinions. We do not want to see a tonne of bug reports hitting X.Org nor Red Hat bugzilla from people using packages named "xorg-x11-anything" which is software not actually produced or provided by X.Org. Labelling things that did not come from X.Org with the xorg-x11 prefix, will suggest to people that said software did come from X.Org, as all X packaging historically had the upstream X implementation provider's name as the prefix. ie: XFree86-* xorg-x11-* Please keep the xorg-x11 namespace clean and reserved for software produced and distributed by the X.Org Foundation officially, to which the trademark is owned. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Tue May 9 02:09:46 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 08 May 2006 22:09:46 -0400 Subject: xorg-x11- packaging prefix In-Reply-To: <1146718221.4263.10.camel@thl.ct.heise.de> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> <1146718221.4263.10.camel@thl.ct.heise.de> Message-ID: <445FF9EA.9070005@mharris.ca> Thorsten Leemhuis wrote: >> I've added an entry to >> http://fedoraproject.org/wiki/Packaging/NamingGuidelines >> >> "Addon Packages (x11 drivers)" > > No offense, but I removed it again. Changes to these kind of documents > are best (read "best" -- not "have to be") discussed with FESCo, on > fedora-packaging and/or with spot, the original author and maintainer of > this document and the Packaging Guidelines in general. > > BTW: Shortly before FC5 was released there was a irc-discussion > regarding the package naming of the proprietary nvidia and fglrx > drivers. It was on #fedora-extras (spot was involved in that discussion, > too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg > drivers". And that's what livna did for FC5 then. > > We should probably discuss this during the next FESCo-Meeting with spot. I'm rather surprised about that. I wasn't on such mailing lists, but since I was the one who chose the naming, I'd have expected to have at least been contacted by someone to determine what the package naming rationale was. Houston, we've lost communication! -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From chris at tylers.info Tue May 9 03:39:08 2006 From: chris at tylers.info (Chris Tyler) Date: Mon, 08 May 2006 23:39:08 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <20060507160008.16655732A0@hormel.redhat.com> References: <20060507160008.16655732A0@hormel.redhat.com> Message-ID: <1147145948.21352.334.camel@concord2.proximity.on.ca> Here's a related issue with the PATHs (which is why I change the /etc/profile on my systems): a simple 'su' won't munge the superuser directories into the PATH, because /etc/profile isn't invoked. If the superuser directories are in the default PATH, a plain 'su' becomes a lot more useful (and yes, 'su -' works, but then you lose the current directory). An alternative would be to put path munging code in /etc/bashrc (or, somehow, the PAM config for 'su'). Horst von Brand wrote: > But ifconfig(8) is not for luser consumption, and so are lots of > others. I have troubles comprehending that statement. What tool would you recommend if a unprivileged user wanted to know the IP address of the system? 'cat /sys/class/net/eth0/address' ? Or is it useful for an unprivileged user to know the WCHAN of running processes (/bin/ps), the current keymappings (/bin/dumpkeys), and the date and time that the kernel was compiled (/bin/uname -a), but not the IP address? Realistically (these days), there's a good chance that an inexperienced user won't be on the command line at all (but that's a far cry from saying that 'bash is not for luser consumption'). Leszek Matok wrote: > The wrong thing IMHO would be having /sbin before /bin in the search > path. As someone stated earlier, it can break consolehelper symlinks. > Other than that, either let's make a symlinking-fest or add them to > the path as many suggest, only after /bin and co. Agreed - the code in /etc/profile should probably read: # Path manipulation if [ "$EUID" = 0 ]; then pathmunge /sbin pathmunge /usr/sbin pathmunge /usr/local/sbin else pathmunge /sbin after pathmunge /usr/sbin after pathmunge /usr/local/sbin after fi This is better than a symlink-fest because the sites that really don't want the users to know their IP address can change it easily :-) The downside is that the path order is potentially less secure after an 'su'. Bugzilla 191135. -- Chris Tyler From paul at cypherpunks.ca Tue May 9 03:44:15 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 9 May 2006 05:44:15 +0200 (CEST) Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1147145948.21352.334.camel@concord2.proximity.on.ca> References: <20060507160008.16655732A0@hormel.redhat.com> <1147145948.21352.334.camel@concord2.proximity.on.ca> Message-ID: On Mon, 8 May 2006, Chris Tyler wrote: > Agreed - the code in /etc/profile should probably read: > > # Path manipulation > if [ "$EUID" = 0 ]; then > pathmunge /sbin > pathmunge /usr/sbin > pathmunge /usr/local/sbin > else > pathmunge /sbin after > pathmunge /usr/sbin after > pathmunge /usr/local/sbin after > fi But that would break syntax highlighting in vi for root when invoked as "vi" instead of "vim". Though leaving out a root check does that as well. Paul From perbj at sbcglobal.net Tue May 9 05:27:56 2006 From: perbj at sbcglobal.net (Per Bjornsson) Date: Mon, 08 May 2006 22:27:56 -0700 Subject: Linux ATM: usbatm.c: OAM support In-Reply-To: <1147113887.5797.4.camel@dhcp83-74.boston.redhat.com> References: <1147110309.3356.943.camel@lesca.home.solinos.it> <1147113887.5797.4.camel@dhcp83-74.boston.redhat.com> Message-ID: <1147152477.3429.2.camel@minicooper> On Mon, 2006-05-08 at 14:44 -0400, Dan Williams wrote: > And your module will build. Then copy the .ko file > to /lib/modules/`uname -r`/... over top of the stock version, but make > _sure_ to back up the stock version of the module before copying the new > one over it. Hmm, isn't it actually sufficient to copy the module into /lib/modules/`uname -r`/updates/ for it to override the original one? (Perhaps a depmod is needed too though?) /Per From fedora at leemhuis.info Tue May 9 05:40:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 09 May 2006 07:40:08 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <445FF9EA.9070005@mharris.ca> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> <1146718221.4263.10.camel@thl.ct.heise.de> <445FF9EA.9070005@mharris.ca> Message-ID: <1147153208.4115.27.camel@thl.ct.heise.de> Hi! Reply out-of-order Am Montag, den 08.05.2006, 22:09 -0400 schrieb Mike A. Harris: > Thorsten Leemhuis wrote: > Houston, we've lost communication! Yes, that's why we IMHO need a real "Fedora Packaging Board" that handles such things. Otherwise we run into a situation where foo at redhat.com and foo at im.interested.in.fedora say foobar while bar at redhat.com and bar at im.interested.in.fedora say barfoo. :-/ > > BTW: Shortly before FC5 was released there was a irc-discussion > > regarding the package naming of the proprietary nvidia and fglrx > > drivers. It was on #fedora-extras (spot was involved in that discussion, > > too) -- the consensus was "use prefix xorg-x11-drv even for non-Xorg > > drivers". And that's what livna did for FC5 then. > > We should probably discuss this during the next FESCo-Meeting with spot. > > I'm rather surprised about that. I wasn't on such mailing lists, but > since I was the one who chose the naming, I'd have expected to have > at least been contacted by someone to determine what the package > naming rationale was. Yes, that would have been the best. But I don't think the end result would have been different. Here are some quotes from the IRC discussion: x> | if we would package gatos-driver or some other external drivers for X what naming scheme would we use? x> | xorg-x11-drv-foo? x> | But that would give users the impression that this driver is from xorg :-| x> | the repo-that-must-not-be-named is working on updated nvidia and ati packages for fc5 and is unsure how to name the packages :-| y> | x: i think xorg-x11-drv-foo is the most obvious answer y> | x: since we don't ever assume that the perl-* packages come from perl.org y> | it would be erroneous to assume that the xorg-* packages come from xorg y> | just that they are reliant upon, and add functionality to perl, or xorg x> | thx spot; the repo-that-must-not-be-named will then probably use xorg-x11-drv-nvidia and xorg-x11-drv-fglrx in the future y> | works for me. BTW, the relevant part of the package naming guidelines (that are for Core and Extras these days) starts at: http://www.fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e865dfbf5ffb4156a1bdf299ace96f48af903a7a Quote: > Addon Packages (General) > If a new package is considered an "addon" package that enhances or > adds a new functionality to an existing Fedora Core or Fedora Extras > package without being useful on its own, its name should reflect this > fact. > > The new package ("child") should prepend the "parent" package in its > name, in the format: %{parent}-%{child} There is more in the wiki. Yes, I know that some people don't like this scheme. But at least one general scheme is better than a lot of different schemes. CU thl From nicolas.mailhot at laposte.net Tue May 9 06:31:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 09 May 2006 08:31:24 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <1147153208.4115.27.camel@thl.ct.heise.de> References: <20060503082035.GB27035@neu.nirvana> <44588CCD.8090502@feuerpokemon.de> <1146657258.3122.7.camel@laptopd505.fenrus.org> <20060503121024.GI27035@neu.nirvana> <4458C69F.7010308@redhat.com> <20060504003942.GA14427@neu.nirvana> <20060504005254.GB14427@neu.nirvana> <1146718221.4263.10.camel@thl.ct.heise.de> <445FF9EA.9070005@mharris.ca> <1147153208.4115.27.camel@thl.ct.heise.de> Message-ID: <1147156286.29994.17.camel@rousalka.dyndns.org> Le mardi 09 mai 2006 ? 07:40 +0200, Thorsten Leemhuis a ?crit : > > Addon Packages (General) > > If a new package is considered an "addon" package that enhances or > > adds a new functionality to an existing Fedora Core or Fedora Extras > > package without being useful on its own, its name should reflect this > > fact. > > > > The new package ("child") should prepend the "parent" package in its > > name, in the format: %{parent}-%{child} > > There is more in the wiki. Yes, I know that some people don't like this > scheme. But at least one general scheme is better than a lot of > different schemes. I'm afraid there is no general case. The wiki can say whatever it wants, wiki-produced prefixes are so far much less numerous than existing prefixes. And a lot of the time existing prefixes are careful like in the xorg-x11 case about where they lay the blame. When you maintain a large set of packages you absolutely do not want your relations with upstream to sour because someone misled by package names complained at their door (another reason is different orgs follow different conventions, you may repaint a package with a common prefix it will still feel alien to the user if it's produced by someone else) Like I wrote before, java packages for example follow the same convention as the xorg packages. I'd be very careful not to ignore the reasons people who actually had to maintain large numbers of related packages for several years choose the existing de facto namespace rules. I'm far from sure the current FE rule has carefully balanced ls convenience with long-temr packaging convenience Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Tue May 9 07:16:51 2006 From: buildsys at redhat.com (Build System) Date: Tue, 9 May 2006 03:16:51 -0400 Subject: rawhide report: 20060509 changes Message-ID: <200605090716.k497GplR012990@porkchop.devel.redhat.com> New package xulrunner XUL Runner. Updated Packages: anaconda-11.1.0.10-1 -------------------- * Mon May 08 2006 Chris Lumens 11.1.0.10-1 - s390x build fix. * Mon May 08 2006 Chris Lumens 11.1.0.9-1 - Fix cmdline installs (clumens, pnasrat). - Enable multirepo support in kickstart (clumens, pnasrat). - Begin IPv6 preparations (dcantrel). - More release notes viewer fixes (dcantrel). cups-1:1.2.0-2 -------------- * Mon May 08 2006 Tim Waugh 1:1.2.0-2 - 1.2.0. dhcp-12:3.0.4-1 --------------- * Sat May 06 2006 Jason Vas Dias - 12:3.0.4-1 - Upgrade to upstream version 3.0.4, released Friday 2006-05-05 . - Add new dhclient command line arguments: -H : parse as dhclient.conf 'send host-name "";' -F : parse as dhclient.conf 'send fqdn.fqdn "";' -T : parse as dhclient.conf 'timeout ;' * Thu Mar 02 2006 Jason Vas Dias - 11:3.0.3-26 - fix bug 181908: enable dhclient to operate on IBM zSeries z/OS linux guests: o add -I dhclient command line option o add -B "always broadcast" dhclient command line option o add 'bootp-broadcast-always;' dhclient.conf statement * Mon Feb 20 2006 Jason Vas Dias - 11:3.0.3-24 - Apply upstream fix for bug 176615 / ISC RT#15811 gaim-1:1.5.0-17.fc6 ------------------- * Fri Apr 28 2006 Warren Togami - 1:1.5.0-17 - 184: silc crash fix (#190152) gcc-4.1.0-14 ------------ * Mon May 08 2006 Jakub Jelinek 4.1.0-14 - update from gcc-4_1-branch (-r113489:113623) - PRs c++/27422, c++/27427, fortran/24813, fortran/25099, fortran/25681, fortran/27269, fortran/27324, libfortran/26985, objc/27240, target/26481, target/26765, tree-optimization/25985, tree-optimization/27151 - fix zero size field handling in structalias (Richard Guenther, PR tree-optimization/27409) - fix PR tree-optimization/27136 (Richard Guenther) - fix classification of invalid struct types on x86_64 (Volker Reichelt, PR target/27421) gtk2-2.9.0-4 ------------ * Mon May 08 2006 Matthias Clasen - 2.9.0-4 - Bump required versions of GLib, Pango and cairo - Add conflicts to force updating theme engine packages kdelibs-6:3.5.2-3 ----------------- * Wed May 03 2006 Than Ngo 6:3.5.2-3 - fix #173235, disable kmail debug info #173235 - use XDG_CONFIG_DIRS for kde menu #178320 - don't use private API with newer CUPS >=1.2 * Fri Apr 21 2006 Than Ngo 6:3.5.2-2 - apply patch to fix crash kdeprint krb5-1.4.3-6 ------------ * Fri Apr 28 2006 Nalin Dahyabhai 1.4.3-6 - adjust the patch which removes the use of rpath to also produce a krb5-config which is okay in multilib environments (#190118) - make the name-of-the-tempfile comment which compile_et adds to error code headers always list the same file to avoid conflicts on multilib installations - strip SIZEOF_LONG out of krb5.h so that it doesn't conflict on multilib boxes - strip GSS_SIZEOF_LONG out of gssapi.h so that it doesn't conflict on mulitlib boxes * Fri Apr 14 2006 Stepan Kasal 1.4.3-5 - Fix formatting typo in kinit.1 (krb5-kinit-man-typo.patch) * Fri Feb 10 2006 Jesse Keating 1.4.3-4.1 - bump again for double-long bug on ppc(64) libsemanage-1.6.7-1 ------------------- * Mon May 08 2006 Dan Walsh - 1.6.7-1 - Upgrade to latest from NSA * Merged fix warnings patch from Karl MacMillan. libsepol-1.12.9-1 ----------------- * Mon May 08 2006 Dan Walsh 1.12.9-1 - Upgrade to latest from NSA * Dropped tests from all Makefile target. * Merged fix warnings patch from Karl MacMillan. * Merged libsepol test framework patch from Karl MacMillan. mailman-3:2.1.8-1 ----------------- * Mon May 08 2006 Harald Hoyer - 3:2.1.8-1 - version 2.1.8 nss_ldap-250-4 -------------- * Mon May 08 2006 Nalin Dahyabhai - 250-4 - update the list of local users to include named,avahi,haldaemon (from #186527) pango-1.13.0-1 -------------- * Mon May 08 2006 Matthias Clasen - 1.13.0-1 - Update to 1.13.0 policycoreutils-1.30.8-1 ------------------------ * Mon May 08 2006 Dan Walsh 1.30.8-1 - Update to upstream * Merged fix warnings patch from Karl MacMillan. * Merged patch from Dan Walsh. This includes audit2allow changes for analysis plugins, internationalization support for several additional programs and added po files, some fixes for semanage, and several cleanups. It also adds a new secon utility. quagga-0:0.98.6-2 ----------------- * Mon May 08 2006 Jay Fenlason 0:0.98.6-2 - Upgrade to new upstream version, closing security problems: bz#191081 CVE-2006-2223 Quagga RIPd information disclosure bz#191085 CVE-2006-2224 Quagga RIPd route injection rsync-2.6.8-2 ------------- * Mon May 08 2006 Jay Fenlason 2.6.8-2 - New upstream release - Use the upstream xattr patch instead of mine. This closes bz#190208 CVE-2006-2083 rsync buffer overflow issue scim-1.4.4-16 ------------- * Tue May 09 2006 Jens Petersen - 1.4.4-16 - update to scim-bridge 0.1.7 - improve qtimm setup in xinput.d file * Tue Apr 18 2006 Jens Petersen - 1.4.4-15 - scim-bridge-0.1.6 * Mon Apr 10 2006 Jens Petersen - 1.4.4-14 - subpackage scim-bridge and add xinput.d file for scim-bridge - add scim_ver and scim_bridge_ver selinux-policy-2.2.38-1 ----------------------- * Fri May 05 2006 Dan Walsh 2.2.38-1 - Update to upstream telnet-1:0.17-36 ---------------- * Mon May 08 2006 Harald Hoyer - 1:0.17-36 - patch to remove gethostbyname() (bug #190296) vte-0.12.1-3 ------------ * Mon May 08 2006 Kristian H??gsberg 0.12.1-3 - Bump and rebuild in rawhide. * Mon May 08 2006 Kristian H??gsberg 0.12.1-2.fc5aiglx - Build with fc5aiglx sub-release for FC5 AIGLX repository. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From link at pobox.com Tue May 9 08:29:58 2006 From: link at pobox.com (Terje Bless) Date: Tue, 9 May 2006 10:29:58 +0200 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <200605081947.k48JlX7x006681@laptop11.inf.utfsm.cl> Message-ID: [ BTW, your MUA seems to drop the Content-Type field. ] Horst von Brand wrote: >Terje Bless wrote: >>`ifconfig` is _also_ for system administrators. Regular users ? my >>Oracle DBAs, say ? > >Those aren't "regular users" by a /very/ long shot in my book. Fine. My web hosting clients with SSH access then. But if you allow your DBAs root access I feel for you, I really do. :-) >They are in /bin and /usr/bin. What is in /sbin or /usr/sbin is /not/ for >regular user consumption. If they need it, they aren't regular users. Then we differ in opinion on this point. My opinion is that these commands are also suitable for regular users with the exception of those that have EUID=0 checks or permissions settings that explicitly prevent non-root users from executing them (probably because their operation is potentially destructive). If these are the semantics you wish to attach to "sbin" then many of the commands currently there should be moved _away_ and into the regular user's path. >It has nothing whatsoever to do with security, and everything with not >confusing random users with commands they can't use sensibly. Again, by this reasoning, things like ifconfig should then be moved out of the sbin directories and into the user path as "random users" _can_ use these "sensibly". But such a distinction seems highly artificial to me. I concur with Paul Wouters and Ron Watson elsewhere in this thread; "protecting users from confusion" is a rationalization at best, the distinction ? if any is warranted ? must be along lines like statically/dynamically linked or available before network is up (cf. /usr) etc. -- ?Look Mike, I like you. I like the way you handle yourself. You seem like a reasonable man. Why don't we make a deal. What's it worth to you to drag your considerable talents back to the gutter you crawled out of?? ?Carl Evello?, Kiss Me Deadly (1955); From gilboad at gmail.com Tue May 9 08:39:58 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 09 May 2006 11:39:58 +0300 Subject: vim7 is out... rawhide/extra? Message-ID: <1147163998.19582.9.camel@gilboa-work-dev> Hello all, First, anyone has any idea when vim7-release will be released into rawhide? Second, will it be possible to push it downstream, either as an upgrade, or by using FE? (Can FE replace core component?) Gilboa From rob at choralone.org Tue May 9 08:45:34 2006 From: rob at choralone.org (Rob Andrews) Date: Tue, 9 May 2006 09:45:34 +0100 Subject: vim7 is out... rawhide/extra? In-Reply-To: <1147163998.19582.9.camel@gilboa-work-dev> References: <1147163998.19582.9.camel@gilboa-work-dev> Message-ID: <20060509084534.GA31960@testure.choralone.org> On 09-May-2006 09:39.58 (BST), Gilboa Davara wrote: > First, anyone has any idea when vim7-release will be released into > rawhide? core/development/SRPMS/vim-7.0.g001-1.src.rpm ? Chances are that if you've run yum update of late then you're already running it :) -- rob andrews :: pgp 0xb35ff721 :: rob at choralone.org From avi at argo.co.il Tue May 9 08:45:49 2006 From: avi at argo.co.il (Avi Kivity) Date: Tue, 09 May 2006 11:45:49 +0300 Subject: rawhide report: 20060509 changes In-Reply-To: <200605090716.k497GplR012990@porkchop.devel.redhat.com> References: <200605090716.k497GplR012990@porkchop.devel.redhat.com> Message-ID: <446056BD.6040209@argo.co.il> Build System wrote: > New package xulrunner > XUL Runner. > > This is not very descriptive. Are there any guidelines for descriptions? (it's a bit disappointing to find that guidelines are necessary for this). Is there any point in posting patches for old packages? -- error compiling committee.c: too many arguments to function From rob at choralone.org Tue May 9 08:46:57 2006 From: rob at choralone.org (Rob Andrews) Date: Tue, 9 May 2006 09:46:57 +0100 Subject: vim7 is out... rawhide/extra? In-Reply-To: <20060509084534.GA31960@testure.choralone.org> References: <1147163998.19582.9.camel@gilboa-work-dev> <20060509084534.GA31960@testure.choralone.org> Message-ID: <20060509084657.GA32302@testure.choralone.org> On 09-May-2006 09:45.34 (BST), Rob Andrews wrote: > > First, anyone has any idea when vim7-release will be released into > > rawhide? > core/development/SRPMS/vim-7.0.g001-1.src.rpm ? > Chances are that if you've run yum update of late then you're already > running it :) Arg, shoot me. g001 != release. Sorry about that. -- rob andrews :: pgp 0xb35ff721 :: rob at choralone.org From link at pobox.com Tue May 9 08:52:25 2006 From: link at pobox.com (Terje Bless) Date: Tue, 9 May 2006 10:52:25 +0200 Subject: xorg-x11- packaging prefix In-Reply-To: <445FF819.7030708@mharris.ca> Message-ID: Mike A. Harris wrote: >- indicate that the software is an official part of the X.Org X11 >distribution Perhaps symptomatic of the rationale being insufficiently mnemonic. :-) I know my expectation of a common packaging prefix is a) one of namespace and b) imposed by the distribution (not upstream). This implies that perl-* packages are all packages that the distributor deems related to Perl (modules, supporting utilities, etc.) but excepting "applications" that happen to be implemented in Perl. I would hold similar expectations for python-* and java-*. In the xorg-x11-* case I would definitely expect a driver, say, in this namespace to be in that namespace _because_ it is compatible with and supporting, extending, or augmenting "xorg-x11". However, I would certainly understand ? and possibly also advocate ? that a suitable entity is given authority over a given namespace to avoid clashes. This latter should not require trademark protection to enforce within a distribution, but it may be X is a special case and with additional requirements to reflect its more cross-distribution needs. BTW, this isn't an argument that one or another set of packages should be renamed. I think, rather, that I conclude Fedora needs to come up with a general namespace policy that ensure _all_ namespaces have the same underlying semantics and then take whatever suitable steps to bring the distribution into compliance with that. -- ?Terje, you are a sick and twisted individual, and I think I speak for all of us when I say, ?Thank you!?? -- John Gruber From emeric.maschino at jouy.inra.fr Tue May 9 10:24:11 2006 From: emeric.maschino at jouy.inra.fr (Emeric Maschino) Date: Tue, 09 May 2006 12:24:11 +0200 Subject: Uninstall of hal-0.5.7-5 fails Message-ID: <1147170251.18740.12.camel@localhost.localdomain> Hi, I've noticed the following error during the upgrade from hal-0.5.7-5 to hal-0.5.7-6: Cleanup : hal ##################### [ 95/101] /var/tmp/rpm-tmp.50206: line 4: z#fi: command not found error: %postun(hal-0.5.7-5.ia64) scriptlet failed, exit status 127 Cleanup : hal ##################### [ 96/101] Unfortunately, /var/tmp/rpm-tmp.5020 already disappeared. Thus: [emeric at zx6000 ~]$ rpm -q hal hal-0.5.7-5 hal-0.5.7-6 Is there something I can try to solve the problem? Is this issue generic or specific to the ia64 (Itanium) architecture? Many thanks, ?meric From karsten at redhat.de Tue May 9 10:01:51 2006 From: karsten at redhat.de (Karsten Hopp) Date: Tue, 09 May 2006 12:01:51 +0200 Subject: vim7 is out... rawhide/extra? In-Reply-To: <20060509084534.GA31960@testure.choralone.org> References: <1147163998.19582.9.camel@gilboa-work-dev> <20060509084534.GA31960@testure.choralone.org> Message-ID: <4460688F.4010404@redhat.de> Rob Andrews schrieb: > On 09-May-2006 09:39.58 (BST), Gilboa Davara wrote: > > First, anyone has any idea when vim7-release will be released into > > rawhide? > > core/development/SRPMS/vim-7.0.g001-1.src.rpm ? > > Chances are that if you've run yum update of late then you're already > running it :) > I've tried to build it yesterday and didn't notice the build failure as the window with the output was buried under several other windows. The build has been fixed and will vim-7.0 show up in Rawhide quite soon. I'll give it one or two weeks and release updates for FC4/5 when nothing serious shows up. Karsten -- Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From gilboad at gmail.com Tue May 9 11:31:18 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 09 May 2006 14:31:18 +0300 Subject: vim7 is out... rawhide/extra? In-Reply-To: <4460688F.4010404@redhat.de> References: <1147163998.19582.9.camel@gilboa-work-dev> <20060509084534.GA31960@testure.choralone.org> <4460688F.4010404@redhat.de> Message-ID: <1147174278.14691.2.camel@gilboa-work-dev> On Tue, 2006-05-09 at 12:01 +0200, Karsten Hopp wrote: > Rob Andrews schrieb: > > On 09-May-2006 09:39.58 (BST), Gilboa Davara wrote: > > > First, anyone has any idea when vim7-release will be released into > > > rawhide? > > > > core/development/SRPMS/vim-7.0.g001-1.src.rpm ? > > > > Chances are that if you've run yum update of late then you're already > > running it :) > > > > I've tried to build it yesterday and didn't notice the build failure as the window > with the output was buried under several other windows. > The build has been fixed and will vim-7.0 show up in Rawhide quite soon. I'll give > it one or two weeks and release updates for FC4/5 when nothing serious shows up. > > Karsten > Great, thanks. FYI. I've been using the rawhide SRPM rebuild(s) on FC5/64, FC4/i386 and RHEL4/64 for quite some time now (since the first release of vim7 rawhide packages) and it worked like a champ. Gilboa From jkeating at redhat.com Tue May 9 12:37:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 May 2006 08:37:05 -0400 Subject: rawhide report: 20060509 changes In-Reply-To: <446056BD.6040209@argo.co.il> References: <200605090716.k497GplR012990@porkchop.devel.redhat.com> <446056BD.6040209@argo.co.il> Message-ID: <1147178226.2126.23.camel@ender> On Tue, 2006-05-09 at 11:45 +0300, Avi Kivity wrote: > This is not very descriptive. Are there any guidelines for > descriptions? > (it's a bit disappointing to find that guidelines are necessary for > this). This seems to have been included accidentally. It was supposed to be built for the OLPC project, but was not quite ready yet (hadn't been reviewed or anything) for rawhide. I'm investigating what happened. > Is there any point in posting patches for old packages? I don't follow the question... -- 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 avi at argo.co.il Tue May 9 13:37:00 2006 From: avi at argo.co.il (Avi Kivity) Date: Tue, 09 May 2006 16:37:00 +0300 Subject: rawhide report: 20060509 changes In-Reply-To: <1147178226.2126.23.camel@ender> References: <200605090716.k497GplR012990@porkchop.devel.redhat.com> <446056BD.6040209@argo.co.il> <1147178226.2126.23.camel@ender> Message-ID: <44609AFC.5010303@argo.co.il> Jesse Keating wrote: > >> Is there any point in posting patches for old packages? >> > > I don't follow the question... > There are some packages (mostly X stuff) with self referential descriptions: libXmu - "X.Org X11 libXmu/libXmuu runtime libraries" libsilc - "SILC Client Library libraries for SILC client" (4 unique words in a 7-word sentence :) perl-Tree-Simple - "A simple tree object." There aren't many (less than I remembered) so the situation is not bad. -- error compiling committee.c: too many arguments to function From vonbrand at inf.utfsm.cl Tue May 9 13:51:00 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 09 May 2006 09:51:00 -0400 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: Your message of "Mon, 08 May 2006 23:39:08 -0400." <1147145948.21352.334.camel@concord2.proximity.on.ca> Message-ID: <200605091351.k49Dp0Yq003070@laptop11.inf.utfsm.cl> Chris Tyler wrote: > Here's a related issue with the PATHs (which is why I change > the /etc/profile on my systems): a simple 'su' won't munge the superuser > directories into the PATH, because /etc/profile isn't invoked. If the > superuser directories are in the default PATH, a plain 'su' becomes a > lot more useful (and yes, 'su -' works, but then you lose the current > directory). An alternative would be to put path munging code > in /etc/bashrc (or, somehow, the PAM config for 'su'). "su -" is safer... Or use sudo(1) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From sundaram at fedoraproject.org Tue May 9 14:34:49 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 09 May 2006 20:04:49 +0530 Subject: rawhide report: 20060509 changes In-Reply-To: <44609AFC.5010303@argo.co.il> References: <200605090716.k497GplR012990@porkchop.devel.redhat.com> <446056BD.6040209@argo.co.il> <1147178226.2126.23.camel@ender> <44609AFC.5010303@argo.co.il> Message-ID: <1147185289.4310.160.camel@sundaram.pnq.redhat.com> On Tue, 2006-05-09 at 16:37 +0300, Avi Kivity wrote: > Jesse Keating wrote: > > > >> Is there any point in posting patches for old packages? > >> > > > > I don't follow the question... > > > There are some packages (mostly X stuff) with self referential descriptions: > > libXmu - "X.Org X11 libXmu/libXmuu runtime libraries" > libsilc - "SILC Client Library libraries for SILC client" (4 unique > words in a 7-word sentence :) > perl-Tree-Simple - "A simple tree object." > > There aren't many (less than I remembered) so the situation is not bad. If you are planning to provide patches to fix these descriptions better, go ahead. Might also add fedora-package-review list to the bug report CC list. Rahul From lamont at gurulabs.com Tue May 9 15:05:28 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 9 May 2006 09:05:28 -0600 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1147145948.21352.334.camel@concord2.proximity.on.ca> References: <20060507160008.16655732A0@hormel.redhat.com> <1147145948.21352.334.camel@concord2.proximity.on.ca> Message-ID: <200605090905.33682.lamont@gurulabs.com> On Monday 08 May 2006 09:39pm, Chris Tyler wrote: > Here's a related issue with the PATHs (which is why I change > the /etc/profile on my systems): a simple 'su' won't munge the superuser > directories into the PATH, because /etc/profile isn't invoked. If the > superuser directories are in the default PATH, a plain 'su' becomes a > lot more useful (and yes, 'su -' works, but then you lose the current > directory). An alternative would be to put path munging code > in /etc/bashrc (or, somehow, the PAM config for 'su'). The $PATH & pwd being "changed" when properly using "su -", is not the only difference. There are other things that are not happening properly when you simply "su" instead of having su provide a login shell. Some of these other things are subtle and can bite without being noticed. The real issue is that running su without the "-" means that you have not set up your environment properly for the target user (usually root, but it *can* be almost any user); some things are set up and other things are not. The "only" reason most people get into the bad practice of (sometimes?) running "su" instead of "su -" (like they should *always* do unless they _really_ know what they are doing, and even then...), is because of the new shell's pwd being the new user's home directory. That's easy to fix, though. Here are two methods I have used: 1. Run pwd first and use the mouse (if you can): $ pwd /usr/share/doc/foo-1.0.0/stuff/things [select this with the mouse] $ su - Password: # cd [middle click the mouse, or type the path] This technique works on systems that I don't use regularly (or are not mine). 2. I place the attached little script into my /etc/ directory and add this to ~/.bashrc (following the inclusion of /etc/bashrc) for each user who wants to use it: # Setup the color prompt. if [ -r /etc/bash-colorprompt ]; then . /etc/bash-colorprompt fi This creates a nice, easy to read (partly thanks to some color, IMHO), two line prompt like: [ lamontp at corsair /usr/share/doc/kernel-xxx/Documentation ] 2006/05/09 09:00:04 [0]$ Since I left a space between the machine name and the path, it's easy to double click it with the mouse to copy it, either before or after I run "su -". If you are at a virtual terminal, it's easy to read it and using tab completion, it's easy to get back to the path or (if you have a working console mouse setup) to also select and middle-click paste it. In both cases, running "su -" isn't hard to do and you have things set up correctly. [snip] So, I say don't change the path setups. They already work correctly. However, the ifconfig command is one that I might consider doing something about. Taking a quick peek at /sbin/ and /bin/sbin/, I don't see any other commands that I would consider placing within "easy reach" of regular users. Perhaps moving ifconfig to /bin/ or creating a symlink in /bin/ifconfig -> /sbin/ifconfig or creating an "ifstat" (or "ifinfo" or "ifconf" or "ifconfig"?) script to go with ifup & ifdown, making it available to regular users. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] GPG Key fingerprint: F98C E31A 5C4C 834A BCAB 8CB3 F980 6C97 DC0D D409 -------------- next part -------------- A non-text attachment was scrubbed... Name: bash-colorprompt Type: application/x-shellscript Size: 1093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cjb at mrao.cam.ac.uk Tue May 9 15:14:50 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Tue, 09 May 2006 11:14:50 -0400 Subject: Uninstall of hal-0.5.7-5 fails References: <1147170251.18740.12.camel@localhost.localdomain> Message-ID: <873bfj1b85.fsf@mrao.cam.ac.uk> >> On Tue, 09 May 2006 12:24:11, Emeric Maschino said: > Is there something I can try to solve the problem? Is this issue > generic or specific to the ia64 (Itanium) architecture? Generic, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190655. -- Chris Ball From bruno at wolff.to Tue May 9 15:37:42 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 9 May 2006 10:37:42 -0500 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <200605090905.33682.lamont@gurulabs.com> References: <20060507160008.16655732A0@hormel.redhat.com> <1147145948.21352.334.camel@concord2.proximity.on.ca> <200605090905.33682.lamont@gurulabs.com> Message-ID: <20060509153742.GA15672@wolff.to> On Tue, May 09, 2006 at 09:05:28 -0600, "Lamont R. Peterson" wrote: > > The "only" reason most people get into the bad practice of (sometimes?) > running "su" instead of "su -" (like they should *always* do unless they > _really_ know what they are doing, and even then...), is because of the new > shell's pwd being the new user's home directory. That's easy to fix, though. People also like to run in a familiar environment. If you have root and your account set up differently, this makes it easier to make mistakes. If there are several people who have root access, su - only gives you one environment when there is demand for more than one environment. From emeric.maschino at jouy.inra.fr Tue May 9 15:45:10 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Tue, 9 May 2006 17:45:10 +0200 Subject: Uninstall of hal-0.5.7-5 fails In-Reply-To: <873bfj1b85.fsf@mrao.cam.ac.uk> References: <1147170251.18740.12.camel@localhost.localdomain> <873bfj1b85.fsf@mrao.cam.ac.uk> Message-ID: <1147189510.4460b906bbab3@www.jouy.inra.fr> Wow, I even didn't pay attention to this bug with such a title! Many thanks Chris. > > Is there something I can try to solve the problem? Is this issue > > generic or specific to the ia64 (Itanium) architecture? > > Generic, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190655. From cmadams at hiwaay.net Tue May 9 15:45:49 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 9 May 2006 10:45:49 -0500 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <1147145948.21352.334.camel@concord2.proximity.on.ca> References: <20060507160008.16655732A0@hormel.redhat.com> <1147145948.21352.334.camel@concord2.proximity.on.ca> Message-ID: <20060509154548.GH1371863@hiwaay.net> Once upon a time, Chris Tyler said: > Horst von Brand wrote: > > But ifconfig(8) is not for luser consumption, and so are lots of > > others. > > I have troubles comprehending that statement. What tool would you > recommend if a unprivileged user wanted to know the IP address of the > system? 'cat /sys/class/net/eth0/address' ? > > Or is it useful for an unprivileged user to know the WCHAN of running > processes (/bin/ps), the current keymappings (/bin/dumpkeys), and the > date and time that the kernel was compiled (/bin/uname -a), but not the > IP address? To me, this is justification for moving ifconfig to /bin, fuser to /usr/bin, etc. If something has use to non-superusers, it should not be in /sbin, /usr/sbin, etc. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mpeters at mac.com Tue May 9 20:10:11 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 09 May 2006 13:10:11 -0700 Subject: /sbin:/usr/sbin in mortal's PATH In-Reply-To: <20060509154548.GH1371863@hiwaay.net> References: <20060507160008.16655732A0@hormel.redhat.com> <1147145948.21352.334.camel@concord2.proximity.on.ca> <20060509154548.GH1371863@hiwaay.net> Message-ID: <1147205411.27330.40.camel@atlantis.mpeters.local> On Tue, 2006-05-09 at 10:45 -0500, Chris Adams wrote: > > To me, this is justification for moving ifconfig to /bin, fuser to > /usr/bin, etc. If something has use to non-superusers, it should not be > in /sbin, /usr/sbin, etc. That should only be done with symlinks because it is expected that they be where they are by existing scripts - which often call them full path for security reasons. From mpeters at mac.com Wed May 10 00:10:16 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 09 May 2006 17:10:16 -0700 Subject: xorg-x11- packaging prefix In-Reply-To: References: Message-ID: <1147219816.27330.60.camel@atlantis.mpeters.local> On Tue, 2006-05-09 at 10:52 +0200, Terje Bless wrote: > Mike A. Harris wrote: > > >- indicate that the software is an official part of the X.Org X11 > >distribution > > Perhaps symptomatic of the rationale being insufficiently mnemonic. :-) > > > I know my expectation of a common packaging prefix is a) one of namespace and b) > imposed by the distribution (not upstream). This implies that perl-* packages > are all packages that the distributor deems related to Perl (modules, supporting > utilities, etc.) but excepting "applications" that happen to be implemented in > Perl. I would hold similar expectations for python-* and java-*. > > In the xorg-x11-* case I would definitely expect a driver, say, in this > namespace to be in that namespace _because_ it is compatible with and > supporting, extending, or augmenting "xorg-x11". > > However, I would certainly understand ? and possibly also advocate ? that a > suitable entity is given authority over a given namespace to avoid clashes. The name spaces are important. There's in issue being discussed in extras right now because the muse add-on for emacs was simply named muse - and not emacs-muse Now there is a piece of software that SHOULD be called muse, but because the emacs namespace was not used - there is already a package called muse. > > This latter should not require trademark protection to enforce within a > distribution, but it may be X is a special case and with additional requirements > to reflect its more cross-distribution needs. I think if documentation is clear that the xorg is there to designate a namespace, there shouldn't be a problem. The namespace-name does not indicate that the package is part of the namespace project. > > > BTW, this isn't an argument that one or another set of packages should be > renamed. I think, rather, that I conclude Fedora needs to come up with a general > namespace policy that ensure _all_ namespaces have the same underlying semantics > and then take whatever suitable steps to bring the distribution into compliance > with that. Agreed. From buildsys at redhat.com Wed May 10 07:12:33 2006 From: buildsys at redhat.com (Build System) Date: Wed, 10 May 2006 03:12:33 -0400 Subject: rawhide report: 20060510 changes Message-ID: <200605100712.k4A7CXYt014340@porkchop.devel.redhat.com> Removed package xulrunner Updated Packages: binutils-2.17.50.0.1-1 ---------------------- * Tue May 09 2006 Jakub Jelinek 2.17.50.0.1-1 - update to 2.17.50.0.1 cvs-1.11.21-4 ------------- * Tue May 09 2006 Martin Stransky - 1.11.21-4 - fix for #189858 - /etc/profile.d/cvs.sh overwrite personal settings - fix for #190009 - rcs2log uses obsolete sort option eog-2.15.1-1 ------------ * Tue May 09 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 - Remove workaround for a long-fixed bug evince-0.5.2-1 -------------- * Tue May 09 2006 Matthias Clasen - 0.5.2-1 - update to 0.5.2 g-wrap-1.9.6-4 -------------- * Tue May 09 2006 Bill Nottingham 1.9.6-4 - rebuild against new guile gcalctool-5.8.10-1 ------------------ * Tue May 09 2006 Matthias Clasen 5.8.10-1 - Update to 5.8.10 gedit-1:2.15.1-1 ---------------- * Tue May 09 2006 Matthias Clasen 2.15.1-1 - Update to 2.15.1 gimp-2:2.2.11-4 --------------- * Tue May 09 2006 Nils Philippsen - 2:2.2.11-4 - don't use long deprecated libpng API (#191027, patch by Manish Singh) * Thu Apr 20 2006 Nils Philippsen - 2:2.2.11-3 - only use pkgconfig if needed in gimptool, require pkgconfig in devel subpackage (#189314, #189371) * Wed Apr 19 2006 Nils Philippsen - 2:2.2.11-2 - require pkgconfig (#189314) gnome-desktop-2.15.1-1 ---------------------- * Tue May 09 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 gnome-games-1:2.15.1-1 ---------------------- * Wed May 10 2006 Matthias Clasen - 1:2.15.1-1 - Update to 2.15.1 * Tue May 09 2006 Ray Strode - 1:2.14.1-4 - rebuild gnome-icon-theme-2.15.1-1 ------------------------- * Tue May 09 2006 Matthias Clasen 2.15.1-1 - Update to 2.15.1 gnome-utils-1:2.15.0-1 ---------------------- * Tue May 09 2006 Matthias Clasen 2.15.0-1 - Update to 2.15.0 gnucash-1.9.5-3 --------------- * Tue May 09 2006 Bill Nottingham - 1.9.5-3 - rebuild against new guile () - silence warnings guile-5:1.8.0-2 --------------- * Tue May 09 2006 Bill Nottingham - 5:1.8.0-2 - don't package /usr/share/info/dir * Tue May 09 2006 Miroslav Lichvar - 5:1.8.0-1 - update to guile-1.8.0 - fix slib.scm for slib-3a3 - install guile-tut info - move guile.m4 to devel package - spec cleanup hal-0.5.7-7 ----------- * Mon May 08 2006 John (J5) Palmieri - 0.5.7-7 - Removed typo from spec * Fri May 05 2006 John (J5) Palmieri - 0.5.7-6 - Add fix so gnome-power-manager handles lid opens correctly now * Mon Apr 24 2006 John (J5) Palmieri - 0.5.7-5 - ifnarch the pm-utils requires for s390 and s390x icon-naming-utils-0.7.2-1 ------------------------- * Tue May 09 2006 Matthias Clasen - 0.7.2-1 - Update to 0.7.2 icu-3.4-9 --------- * Tue May 09 2006 Caolan McNamara - 3.4-9 - rh#190879# backport fix intltool-0.34.90.cvs20060509-1 ------------------------------ * Tue May 09 2006 Matthias Clasen 0.34.90.cvs20060509-1 - Update to a cvs snapshot to allow building gnome 2.15 kernel-2.6.16-1.2200_FC6 ------------------------ * Tue May 09 2006 Dave Jones - 2.6.17rc3-git17 * Mon May 08 2006 Dave Jones - 2.6.17rc3-git15 libselinux-1.30.6-2 ------------------- * Tue May 09 2006 Dan Walsh 1.30.6-2 - Add Russell's AVC patch to handle large numbers * Mon May 08 2006 Dan Walsh 1.30.6-1 - Upgrade to latest from NSA * Merged getfscreatecon man page fix from Dan Walsh. * Updated booleans(8) man page to drop references to the old booleans file and to note that setsebool can be used to set the boot-time defaults via -P. * Mon May 08 2006 Dan Walsh 1.30.5-1 - Upgrade to latest from NSA * Merged fix warnings patch from Karl MacMillan. * Merged setrans client support from Dan Walsh. This removes use of libsetrans. * Merged patch to eliminate use of PAGE_SIZE constant from Dan Walsh. * Merged swig typemap fixes from Glauber de Oliveira Costa. libstdc++so7-4.2.0-0.6.20060428 ------------------------------- * Tue May 09 2006 Jens Petersen - 4.2.0-0.6.20060428 - fix ppc target in wrapper script mkinitrd-5.0.38-1 ----------------- * Tue May 09 2006 Peter Jones - 5.0.38-1 - handle bringing up multiple network devices (katzj) - make "withusb=yes" default - add --without-usb - make usb load [euo]hci_hcd correctly net-tools-1.60-70 ----------------- * Tue May 09 2006 Radek Vok??l - 1.60-70 - add netdevice.h, fix x25 - fix ifconfig crash when interface name is too long (#190703) * Tue May 02 2006 Radek Vok??l - 1.60-69 - fix arp man page to correspond to man ethers (#190425) pcre-6.6-1 ---------- * Tue May 09 2006 Than Ngo 6.6-1 - update to 6.6 - fix multilib problem selinux-policy-2.2.38-2 ----------------------- * Mon May 08 2006 Dan Walsh 2.2.38-2 - Allow execution of cvs command slib-3a3-1 ---------- * Tue May 09 2006 Miroslav Lichvar 3a3-1 - update to slib3a3 - install info, remove html - fix typo in description (#189650) * Mon Feb 27 2006 Miroslav Lichvar 3a1-6 - spec cleanup udev-091-3 ---------- * Tue May 09 2006 Harald Hoyer - 091-3 - corrected some rules vim-2:7.0.000-2 --------------- * Tue May 09 2006 Karsten Hopp 7.0.000-2 - bump epoch, the buildsystem thinks 7.0.000-2 is older than 7.0.g001-1 although rpm is quite happy with it. * Mon May 08 2006 Karsten Hopp 7.0.000-1 - vim-7.0 - Spell checking support for about 50 languages - Intelligent completion for C, HTML, Ruby, Python, PHP, etc. - Tab pages, each containing multiple windows - Undo branches: never accidentally lose text again - Vim script supports Lists and Dictionaries (similar to Python) - Vim script profiling - Improved Unicode support - Highlighting of cursor line, cursor column and matching braces - Translated manual pages support. - Internal grep; works on all platforms, searches compressed files - Browsing remote directories, zip and tar archives - Printing multi-byte text - find details about the changes since vim-6.4 with :help version7 - fix SE Linux context of temporary (.swp) files (#189968) - /bin/vi /vim-minimal is now using /etc/virc to avoid .rpmnew files when updating vte-0.13.0-1 ------------ * Tue May 09 2006 Matthias Clasen 0.13.0-1 - Update to 0.13.0 - Remove "experimental" from descriptions xdelta-1.1.3-18 --------------- * Fri May 05 2006 Ludek Smid 1.1.3-18 - patches created on i386 fail to apply on x86_64 (#190406) yelp-2.15.1-1 ------------- * Tue May 09 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnome-terminal - 2.14.1-11.i386 requires libvte.so.4 libselinux - 1.30.6-2.i386 requires setransd libvte-java - 0.11.11.0.20060301.rh1-1.2.i386 requires libvte.so.4 rhgb - 0.16.3-1.i386 requires libvte.so.4 Broken deps for ia64 ---------------------------------------------------------- gnome-terminal - 2.14.1-11.ia64 requires libvte.so.4()(64bit) libselinux - 1.30.6-2.ia64 requires setransd libvte-java - 0.11.11.0.20060301.rh1-1.2.ia64 requires libvte.so.4()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhgb - 0.16.3-1.ia64 requires libvte.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- gnome-terminal - 2.14.1-11.ppc requires libvte.so.4 libselinux - 1.30.6-2.ppc requires setransd libvte-java - 0.11.11.0.20060301.rh1-1.2.ppc requires libvte.so.4 rhgb - 0.16.3-1.ppc requires libvte.so.4 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-terminal - 2.14.1-11.ppc64 requires libvte.so.4()(64bit) hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libselinux - 1.30.6-2.ppc64 requires setransd libvte-java - 0.11.11.0.20060301.rh1-1.2.ppc64 requires libvte.so.4()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-terminal - 2.14.1-11.s390 requires libvte.so.4 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libselinux - 1.30.6-2.s390 requires setransd libvte-java - 0.11.11.0.20060301.rh1-1.2.s390 requires libvte.so.4 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-terminal - 2.14.1-11.s390x requires libvte.so.4()(64bit) hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libselinux - 1.30.6-2.s390 requires setransd libselinux - 1.30.6-2.s390x requires setransd rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnome-terminal - 2.14.1-11.x86_64 requires libvte.so.4()(64bit) libselinux - 1.30.6-2.x86_64 requires setransd libselinux - 1.30.6-2.i386 requires setransd libvte-java - 0.11.11.0.20060301.rh1-1.2.x86_64 requires libvte.so.4()(64bit) rhgb - 0.16.3-1.x86_64 requires libvte.so.4()(64bit) From gilboad at gmail.com Wed May 10 12:16:45 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Wed, 10 May 2006 15:16:45 +0300 Subject: rawhide report: 20060510 changes In-Reply-To: <200605100712.k4A7CXYt014340@porkchop.devel.redhat.com> References: <200605100712.k4A7CXYt014340@porkchop.devel.redhat.com> Message-ID: <1147263405.14691.28.camel@gilboa-work-dev> On Wed, 2006-05-10 at 03:12 -0400, Build System wrote: > > vim-2:7.0.000-2 > --------------- > * Tue May 09 2006 Karsten Hopp 7.0.000-2 > - bump epoch, the buildsystem thinks 7.0.000-2 is older than 7.0.g001-1 > although rpm is quite happy with it. > > * Mon May 08 2006 Karsten Hopp 7.0.000-1 > - vim-7.0 > - Spell checking support for about 50 languages > - Intelligent completion for C, HTML, Ruby, Python, PHP, etc. > - Tab pages, each containing multiple windows > - Undo branches: never accidentally lose text again > - Vim script supports Lists and Dictionaries (similar to Python) > - Vim script profiling > - Improved Unicode support > - Highlighting of cursor line, cursor column and matching braces > - Translated manual pages support. > - Internal grep; works on all platforms, searches compressed files > - Browsing remote directories, zip and tar archives > - Printing multi-byte text > - find details about the changes since vim-6.4 with :help version7 > > - fix SE Linux context of temporary (.swp) files (#189968) > - /bin/vi /vim-minimal is now using /etc/virc to avoid .rpmnew files > when updating Thanks! FYI, Seems to build and work just fine (minimal sanity checks) on FC5/64 and RHEL4/64. (COS4.3) Gilboa From jfrieben at freesurf.fr Wed May 10 14:59:45 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 10 May 2006 16:59:45 +0200 (CEST) Subject: rawhide report: 20060510 changes In-Reply-To: <200605100712.k4A7CXYt014340@porkchop.devel.redhat.com> References: <200605100712.k4A7CXYt014340@porkchop.devel.redhat.com> Message-ID: <13285.194.94.224.254.1147273185.squirrel@arlette.freesurf.fr> I wonder if the #RPM# changelog is the right place for such a loquacious description of application changes though. This is not package related. > > * Mon May 08 2006 Karsten Hopp 7.0.000-1 > - vim-7.0 > - Spell checking support for about 50 languages > - Intelligent completion for C, HTML, Ruby, Python, PHP, etc. > - Tab pages, each containing multiple windows > - Undo branches: never accidentally lose text again > - Vim script supports Lists and Dictionaries (similar to Python) > - Vim script profiling > - Improved Unicode support > - Highlighting of cursor line, cursor column and matching braces > - Translated manual pages support. > - Internal grep; works on all platforms, searches compressed files - > Browsing remote directories, zip and tar archives > - Printing multi-byte text > - find details about the changes since vim-6.4 with :help version7 > > - fix SE Linux context of temporary (.swp) files (#189968) > - /bin/vi /vim-minimal is now using /etc/virc to avoid .rpmnew files > when updating > From che666 at gmail.com Wed May 10 19:56:47 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 10 May 2006 21:56:47 +0200 Subject: new project: fedora-mirror Message-ID: Hello to you, I started a new Project called fedora-mirror. It is based on skvidals great reposync tool now in latest yum-utils for fedora mirror generation. Heres the info: http://fedoraproject.org/wiki/Projects/fedora-mirror regards, Rudolf Kastl From Axel.Thimm at ATrpms.net Wed May 10 22:01:06 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 11 May 2006 00:01:06 +0200 Subject: FC5 ISO Re-Spins In-Reply-To: <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> Message-ID: <20060510220106.GA31836@neu.nirvana> On Mon, May 01, 2006 at 02:38:26PM -0500, Robert 'Bob' Jensen wrote: > On Mon, 2006-05-01 at 13:03 -0400, Jesse Keating wrote: > > > > Can you show me how it failed on i386? What were your steps, where did > > it go boom? Tracebacks or whatnot from the boom? > > Here is the output at the point of failure > > [bob-local at spinmaster x86_64]$ pwd > /var/www/mirror/fedora/linux/5/x86_64 > [bob-local at spinmaster x86_64]$ pkgorder /var/www/mirror/fedora/linux/5/x86_64/iso-build_bob-local x86_64 Fedora | tee /var/www/mirror/fedora/linux/5/x86_64/iso-build_pkgfile_bob-local > kernel-2.6.16-1.2096_FC5.x86_64.rpm > kernel-xen0-2.6.16-1.2096_FC5.x86_64.rpm > kernel-xenU-devel-2.6.16-1.2096_FC5.x86_64.rpm > kernel-xen0-devel-2.6.16-1.2096_FC5.x86_64.rpm > kernel-xenU-2.6.16-1.2096_FC5.x86_64.rpm > Traceback (most recent call last): > File "/usr/lib/anaconda-runtime/pkgorder", line 159, in ? > addGroups(ds, ["Core", "Base", "Text-based Internet"]) > File "/usr/lib/anaconda-runtime/pkgorder", line 97, in addGroups > ds.resolveDeps() > File "/usr/lib/anaconda/yuminstall.py", line 303, in resolveDeps > unresolved = self.tsCheck(unresolved) > File "/usr/lib/anaconda/yuminstall.py", line 329, in tsCheck > dep = self._provideToPkg(req) > File "/usr/lib/anaconda/yuminstall.py", line 280, in _provideToPkg > best = self.bestPackagesFromList(satisfiers)[0] > IndexError: list index out of range I get similar results when trying to do the same for ppc on x86_64. Is this considered a bug in pkgorder? createrepo works fine cross-arch (or at least seems to do so). Should I file a bug? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Thu May 11 03:36:46 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 11 May 2006 03:36:46 +0000 (UTC) Subject: Old Flex version in FC5? References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <20060504164022.40dff0e1@duras.int.addix.net> <445A18D2.9040102@research.att.com> Message-ID: John Ellson research.att.com> writes: > These tools need extra care when updating. Absolutely. Would there be interest in having a flex-reentrant (based on 2.5.33) package in Extras (in parallel with existing flex) that would install itself in /opt/flex, as per: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES With such approach, both pieces of software could exist on the system at the same time without, with the old, proven flex being the default. The reentrant flex would be completely invisible in terms of binary paths, libraries, man pages etc., until explicity referenced by other software needing this kind of functionality. PS. I'm aware that /opt isn't the most popular choice (*cough* is completely against policy *cough*) for Fedora [Extras] packages, but in this particular case it may give us some optional (pun intended :-) functionality that we otherwise wouldn't have. -- Bojan From bojan at rexursive.com Thu May 11 04:15:12 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 11 May 2006 04:15:12 +0000 (UTC) Subject: Old Flex version in FC5? References: <4459C76E.30705@bull.net> <4459F48A.6070901@math.unl.edu> <1146746422.5294.100.camel@mccallum.corsepiu.local> <20060504164022.40dff0e1@duras.int.addix.net> <445A18D2.9040102@research.att.com> Message-ID: Bojan Smojver rexursive.com> writes: > Would there be interest in having a flex-reentrant (based on 2.5.33) package in > Extras Something like this: ftp://ftp.rexursive.com/pub/flex/flex-reentrant.spec -- Bojan From hk at isphuset.no Thu May 11 07:05:06 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 11 May 2006 09:05:06 +0200 Subject: FC5 ISO Re-Spins In-Reply-To: <20060510220106.GA31836@neu.nirvana> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <20060510220106.GA31836@neu.nirvana> Message-ID: <1147331106.28230.16.camel@linux> On Thu, 2006-05-11 at 00:01 +0200, Axel Thimm wrote: *snip* > I get similar results when trying to do the same for ppc on x86_64. > > Is this considered a bug in pkgorder? createrepo works fine cross-arch > (or at least seems to do so). Should I file a bug? The utils have not been made with cross-arch building in mind and will not work by design. I hope it will be remade to work cross arch but from what I saw when investigating it it would not be an easy task. What I consider a bug however is that it does not just check arch and tell you it won't work. Would be much cleaner imho. -HK From buildsys at redhat.com Thu May 11 07:39:37 2006 From: buildsys at redhat.com (Build System) Date: Thu, 11 May 2006 03:39:37 -0400 Subject: rawhide report: 20060511 changes Message-ID: <200605110739.k4B7dbVn021121@porkchop.devel.redhat.com> New package mcstrans SELinux Translation Daemon Removed package alchemist Updated Packages: SysVinit-2.86-4 --------------- * Wed May 10 2006 Bill Nottingham - 2.86-3 - fix potential under-copy of proc title (#188160, ) device-mapper-1.02.06-1.0 ------------------------- * Wed May 10 2006 Alasdair Kergon - 1.02.06-1.0 - Minor fixes upstream. dhcpv6-0.10-18 -------------- * Wed May 10 2006 Jason Vas Dias - 0.10-18 - Make server send client the IPv6 address prefix in address lease; make client use it - prevent netlink.c generating error log message for NLMSG_DONE - fix netlink.c IFLA_PROTINFO handling now that kernel defines it - fix memory leak in client6_addr create_iaid - disable 'install -s' for binaries epiphany-2.15.1-1 ----------------- * Wed May 10 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 gdm-1:2.15.0-1 -------------- * Wed May 10 2006 Matthias Clasen > - 1:2.15.0-1 - Update to 2.15.0 glibc-kernheaders-3.0-30 ------------------------ * Wed May 10 2006 David Woodhouse 3.0-30 - Add asm-s390/z90crypt.h - Add linux/usbdevice_fs.h, linux/usb_ch9.h gnome-session-2.15.1-1 ---------------------- * Wed May 10 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 gnome-speech-0.3.10-1 --------------------- * Wed May 10 2006 Matthias Clasen - 0.3.10-1 - Update to 0.3.10 gnome-system-monitor-2.14.2-2 ----------------------------- * Wed May 10 2006 Matthias Clasen 2.14.2-2 - Update to 2.14.2 gnome-terminal-2.14.1-12 ------------------------ * Wed May 10 2006 Matthias Clasen 2.14.1-12 - Rebuild gnome-themes-2.15.1-1 --------------------- * Wed May 10 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 gok-1.0.8-2 ----------- * Wed May 10 2006 Matthias Clasen 1.0.8-2 - Update to 1.0.8 hplip-0.9.11-3 -------------- * Wed May 10 2006 Tim Waugh 0.9.11-3 - Move hpijs to 0.9.11 too. * Wed May 10 2006 Tim Waugh 0.9.11-2 - 0.9.11. - Keep hpijs at 0.9.8 for now. libgsf-1.14.1-2 --------------- * Wed May 10 2006 Matthias Clasen 1.14.1-2 - Update to 1.14.1 libgtk-java-2.8.4-1 ------------------- * Wed May 10 2006 Stepan Kasal - 2.8.4-1 - Incorporated the three patches to the spec file. - Removed Makefile.jni from the cellrenderer patch. - Fixed the treerowreferences patch according to Adam's advice. * Tue May 09 2006 Adam Jocksch - 2.8.4-0 - Committed patches for treerowreferences, treemodelsort functions, and cellrenderer properties, no changes to spec file. librsvg2-2.15.0-1 ----------------- * Wed May 10 2006 Matthias Clasen 2.15.0-1 - Update to 2.15.0 - Don't ship static libs libvte-java-0.11.11.0.20060301.rh1-2 ------------------------------------ * Wed May 10 2006 Matthias Clasen - 0.11.11.0.20060301.rh1-2 - Rebuild linuxwacom-0:0.7.4_1-1 ---------------------- * Wed May 10 2006 Kristian H??gsberg 0:0.7.4_1-1 - Update to 0.7.4-1 release. - Change udev rule to use == instead of = for matching kernel name (#191248). - Drop linuxwacom-0.7.2-modular-sdk.patch and pass --with-xorg-sdk=/usr. - Change udev rule to be 60-wacom.rules instead of 10-wacom.rules. - Update linuxwacom-fsp.patch to patch Makefile.in instead so we avoid rerunning auto*. mkinitrd-5.0.39-1 ----------------- * Wed May 10 2006 Peter Jones - 5.0.39-1 - handle [eou]hci_hcd even _more_ correctly ;) module-init-tools-3.3-0.pre1.1 ------------------------------ * Wed May 10 2006 Harald Hoyer 3.3-0.pre1.1 - version 3.3-pre1 - added blacklist-compat and ghosted empty /etc/modprobe.conf.dist nautilus-cd-burner-2.15.1-1 --------------------------- * Wed May 10 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 nmap-2:4.03-1 ------------- * Wed May 10 2006 Karsten Hopp 4.03-1 - update to 4.03, this fixes #184286 - remove duplicate menu entry in 'Internet' (#183056) - fix possible tmpdir race condition during build (#158996) pam-0.99.4.0-1 -------------- * Wed May 10 2006 Tomas Mraz 0.99.4.0-1 - upgrade to new upstream version - make pam_console_apply not dependent on glib - support large uids in pam_tally, pam_tally2 * Thu May 04 2006 Tomas Mraz 0.99.3.0-5 - the namespace instance init script is now in /etc/security (#190148) - pam_namespace: added missing braces (#190026) - pam_tally(2): never call fclose twice on the same FILE (from upstream) * Wed Apr 26 2006 Tomas Mraz 0.99.3.0-4 - fixed console device class for irda (#189966) - make pam_console_apply fail gracefully when a class is missing policycoreutils-1.30.8-2 ------------------------ * Wed May 10 2006 Dan Walsh 1.30.8-2 - Fix exception on bad file_context postfix-2:2.2.10-2 ------------------ * Wed May 10 2006 Thomas Woerner 2:2.2.10-2 - added RELRO security protection qt-1:3.3.6-3 ------------ * Tue May 09 2006 Than Ngo 1:3.3.6-3 - add subpackage qt-devel-docs #191099 * Thu Apr 13 2006 Than Ngo 1:3.3.6-2 - fix xorg prefix #188510 rhgb-0.16.3-2 ------------- * Wed May 10 2006 Matthias Clasen - 0.16.3-2 - Rebuild selinux-policy-2.2.38-3 ----------------------- * Wed May 10 2006 Dan Walsh 2.2.38-3 - Clean up spec file - Transition from unconfined_t to prelink_t tetex-3.0-24 ------------ * Wed May 10 2006 Jindrich Novy 3.0-24 - fix case sensitivity of file extensions (#188701) unifdef-1.171-3.fc6 ------------------- vim-2:7.0.005-2 --------------- * Wed May 10 2006 Karsten Hopp 7.0.005-2 - patchlevel 005 - move older changelogs (<7.0) into a file, no need to keep them in the rpm database vnc-4.1.1-38 ------------ * Wed May 10 2006 Jitka Kudrnacova 4.1.1-38 - fixed crash of Xnvc caused by a NULL pointer in interfaces (bug #187607) - This also fixes crash of Xvnc when vpnc is running (bug #187069) - don't build on ppc64 due to intermittent build problems zenity-2.15.1-1 --------------- * Tue May 09 2006 Matthias Clasen 2.15.1-1 - Update to 2.15.1 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist Broken deps for ppc ---------------------------------------------------------- system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 system-config-httpd - 5:1.3.3-1.1.noarch requires alchemist system-config-netboot - 0.1.40-1.FC6.noarch requires alchemist From pemboa at gmail.com Thu May 11 09:09:40 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 11 May 2006 04:09:40 -0500 Subject: Empty boot.log In-Reply-To: <16de708d0605100028i3d1fcb30tee253701b007892d@mail.gmail.com> References: <16de708d0605100028i3d1fcb30tee253701b007892d@mail.gmail.com> Message-ID: <16de708d0605110209j624a413cm87f5acba2a5d8f4d@mail.gmail.com> Hello, I have posted this to the general list, and got a difficult to believe response, so I am reposting here in the hope of a more insider response. (not to at all belittle the only person who has responded to me os far) I am trying to figure out a problem that I am having with my madwifi supported wifi card not loading properly. As a result, i noticed that all my boot.log files are empty. What could be causing this? Please advise. Thank you. Arthur -- To be updated... From Lam at Lam.pl Thu May 11 10:51:26 2006 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 11 May 2006 12:51:26 +0200 Subject: Empty boot.log In-Reply-To: <16de708d0605110209j624a413cm87f5acba2a5d8f4d@mail.gmail.com> References: <16de708d0605100028i3d1fcb30tee253701b007892d@mail.gmail.com> <16de708d0605110209j624a413cm87f5acba2a5d8f4d@mail.gmail.com> Message-ID: <1147344686.2771.9.camel@pensja.lam.pl> Dnia 11-05-2006, czw o godzinie 04:09 -0500, Arthur Pemberton napisa?(a): > i noticed that > all my boot.log files are empty. What could be causing this? Mine too. All the "initlog" lines in /etc/rc.d/init.d/functions are commented out in FC5, there's no longer re-running /etc/rc.d/rc.sysinit through initlog -r. You know the cause now, it's intentional :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From hk at isphuset.no Thu May 11 11:51:07 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 11 May 2006 13:51:07 +0200 Subject: php deps on postgresql-libs? Message-ID: <1147348268.28230.27.camel@linux> First of all I'd like to mention that I only need the cli version of php, just so I can run some simple management scripts and cron jobs on servers with no web interface. Some are simple scripts called via snmpd. Unfortunately we have no php-cli package, so we need to use the php package. This results in the following output from yum: Installing: php i386 5.1.2-5 core 3.5 M Installing for dependencies: apr i386 1.2.2-7.2 core 121 k apr-util i386 1.2.2-4.2 core 74 k aspell i386 12:0.60.3-5 core 959 k aspell-en i386 50:6.0-2 core 1.6 M curl i386 7.15.1-3 updates 265 k httpd i386 2.2.0-5.1.2 core 1.1 M libidn i386 0.6.2-1.1 core 191 k php-pear noarch 1:1.4.6-2.1 updates 351 k postgresql-libs i386 8.1.3-1 core 193 k This is way overkill for my situation, but what really makes me wonder is why php depends on postgresql-libs. I thought I had to install php-pgsql for that...? And please consider splitting php-cli out in a separate package for FC6, it'd make a minimal server install much neater. Even adding a php-cli that would conflict with the normal php package could work. Also, what if I wanted to use lighttpd instead of httpd? -HK From rdieter at math.unl.edu Thu May 11 12:19:37 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 11 May 2006 07:19:37 -0500 Subject: php deps on postgresql-libs? References: <1147348268.28230.27.camel@linux> Message-ID: Hans Kristian Rosbach wrote: > And please consider splitting php-cli out in a separate > package for FC6, it'd make a minimal server install much > neater. Even adding a php-cli that would conflict > with the normal php package could work. > > Also, what if I wanted to use lighttpd instead of httpd? So it doesn't get lost, you'd best file this request against Core/php at bugzilla.redhat.com -- Rex From sundaram at fedoraproject.org Thu May 11 12:36:50 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 11 May 2006 18:06:50 +0530 Subject: php deps on postgresql-libs? In-Reply-To: References: <1147348268.28230.27.camel@linux> Message-ID: <1147351010.4310.237.camel@sundaram.pnq.redhat.com> On Thu, 2006-05-11 at 07:19 -0500, Rex Dieter wrote: > Hans Kristian Rosbach wrote: > > > And please consider splitting php-cli out in a separate > > package for FC6, it'd make a minimal server install much > > neater. Even adding a php-cli that would conflict > > with the normal php package could work. > > > > Also, what if I wanted to use lighttpd instead of httpd? > > So it doesn't get lost, you'd best file this request against Core/php at > bugzilla.redhat.com https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177821 Rahul From hk at isphuset.no Thu May 11 12:43:13 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 11 May 2006 14:43:13 +0200 Subject: php deps on postgresql-libs? In-Reply-To: <1147351010.4310.237.camel@sundaram.pnq.redhat.com> References: <1147348268.28230.27.camel@linux> <1147351010.4310.237.camel@sundaram.pnq.redhat.com> Message-ID: <1147351393.28230.30.camel@linux> On Thu, 2006-05-11 at 18:06 +0530, Rahul Sundaram wrote: > On Thu, 2006-05-11 at 07:19 -0500, Rex Dieter wrote: > > Hans Kristian Rosbach wrote: > > > > > And please consider splitting php-cli out in a separate > > > package for FC6, it'd make a minimal server install much > > > neater. Even adding a php-cli that would conflict > > > with the normal php package could work. > > > > > > Also, what if I wanted to use lighttpd instead of httpd? > > > > So it doesn't get lost, you'd best file this request against Core/php at > > bugzilla.redhat.com > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177821 > WONTFIX? Too bad. Didn't find that when searching so the first one might be a little dupe. Hopefully the pgsql one isn't a dupe too. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191366 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191367 -HK From rob at choralone.org Thu May 11 13:03:34 2006 From: rob at choralone.org (Rob Andrews) Date: Thu, 11 May 2006 14:03:34 +0100 Subject: php deps on postgresql-libs? In-Reply-To: <1147348268.28230.27.camel@linux> References: <1147348268.28230.27.camel@linux> Message-ID: <20060511130334.GA25024@testure.choralone.org> On 11-May-2006 12:51.07 (BST), Hans Kristian Rosbach wrote: > This is way overkill for my situation, but what really > makes me wonder is why php depends on postgresql-libs. > I thought I had to install php-pgsql for that...? It's the apr-util package that requires postgresql-libs. A side effect of php requiring httpd is that httpd requires apr and apr-util, which brings in the other dependancies. The debian php packages separate the apache 1.3, apache 2.x and CLI SAPI modules into separate packages. Even if it's a WONTFIX, it shouldn't be too much work to shift /usr/bin/php into a php-cli and the /usr/lib/httpd/libphp4.so module into a php-apache package and turn the 'php' package into a metapackage to satisfy dependancies. -- rob andrews :: pgp 0xb35ff721 :: rob at choralone.org From david at lovesunix.net Thu May 11 14:00:55 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 11 May 2006 16:00:55 +0200 Subject: rawhide report: 20060511 changes In-Reply-To: <200605110739.k4B7dbVn021121@porkchop.devel.redhat.com> References: <200605110739.k4B7dbVn021121@porkchop.devel.redhat.com> Message-ID: <1147356055.9978.48.camel@localhost.localdomain> tor, 11 05 2006 kl. 03:39 -0400, skrev Build System: > > selinux-policy-2.2.38-3 > ----------------------- > * Wed May 10 2006 Dan Walsh 2.2.38-3 > - Clean up spec file > - Transition from unconfined_t to prelink_t semodule: error while loading shared libraries: /lib64/ld-linux-x86-64.so.2: cannot apply additional memory protection after relocation: Permission denied In addition the hal package from yesterday complains about: /var/tmp/rpm-tmp.11644: line 4: z#fi: command not found error: %postun(hal-0.5.7-5.x86_64) scriptlet failed, exit status 127 /var/tmp/rpm-tmp.89794: line 4: z#fi: command not found error: %postun(hal-0.5.7-6.x86_64) scriptlet failed, exit status 127 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From hk at isphuset.no Thu May 11 14:07:44 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Thu, 11 May 2006 16:07:44 +0200 Subject: php deps on postgresql-libs? In-Reply-To: <20060511130334.GA25024@testure.choralone.org> References: <1147348268.28230.27.camel@linux> <20060511130334.GA25024@testure.choralone.org> Message-ID: <1147356464.28230.37.camel@linux> On Thu, 2006-05-11 at 14:03 +0100, Rob Andrews wrote: > On 11-May-2006 12:51.07 (BST), Hans Kristian Rosbach wrote: > > This is way overkill for my situation, but what really > > makes me wonder is why php depends on postgresql-libs. > > I thought I had to install php-pgsql for that...? > > It's the apr-util package that requires postgresql-libs. A side effect of > php requiring httpd is that httpd requires apr and apr-util, which > brings in the other dependancies. Ah, of course. Sorry about that. This allergy is taking away all my energy, I should have thought about looking at the dependancy tree. I want the winter back! > The debian php packages separate the apache 1.3, apache 2.x and CLI SAPI > modules into separate packages. Even if it's a WONTFIX, it shouldn't be > too much work to shift /usr/bin/php into a php-cli and the > /usr/lib/httpd/libphp4.so module into a php-apache package and turn the > 'php' package into a metapackage to satisfy dependancies. That would be a nice solution. -HK From mpeters at mac.com Thu May 11 14:33:05 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 11 May 2006 07:33:05 -0700 Subject: php deps on postgresql-libs? In-Reply-To: <1147356464.28230.37.camel@linux> References: <1147348268.28230.27.camel@linux> <20060511130334.GA25024@testure.choralone.org> <1147356464.28230.37.camel@linux> Message-ID: <1147357985.13740.5.camel@atlantis.mpeters.local> On Thu, 2006-05-11 at 16:07 +0200, Hans Kristian Rosbach wrote: > > > The debian php packages separate the apache 1.3, apache 2.x and CLI SAPI > > modules into separate packages. Even if it's a WONTFIX, it shouldn't be > > too much work to shift /usr/bin/php into a php-cli and the > > /usr/lib/httpd/libphp4.so module into a php-apache package and turn the > > 'php' package into a metapackage to satisfy dependancies. > > That would be a nice solution. Maybe I smoked too much magic mushrooms, but I could swear that /usr/bin/php use to be part of a different package in Red Hat - I think it was php-cgi or some such. That would have been Red Hat 6 or 7. From emeric.maschino at jouy.inra.fr Thu May 11 15:18:52 2006 From: emeric.maschino at jouy.inra.fr (=?ISO-8859-1?Q?=C9meric?= Maschino) Date: Thu, 11 May 2006 17:18:52 +0200 Subject: Cannot log in to a GNOME desktop In-Reply-To: References: <1146733408.32373.22.camel@localhost.localdomain> <1146791203.26527.5.camel@localhost.localdomain> Message-ID: <1147360732.2983.5.camel@giulietta.jouy.inra.fr> Hi Rudolf and the list, I just realized that I didn't link to the bug report. Here is it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191156 Cheers, ?meric > > I've performed regression tests and finally isolate the faulty package: > > it's gnome-session-2.14.1-2. Reverting to FC5 original gnome- > > session-2.14.0-1 solves the problem. I don't know if other versions > > where built in the meantime, so I can't precisely determine whether the > > log in problem only appears with the latest gnome-session version or > > not. Does this issue only affect ia64 systems or other architectures > > too? Should I file a bug report? > > you have most probably found a regression bug... look if its already > filed... if not... file it. > > regards, > Rudolf Kastl From philipp_subx at redfish-solutions.com Thu May 11 18:05:44 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 11 May 2006 12:05:44 -0600 Subject: Dependency version mismatch w/ libsepol & libsepol-devel Message-ID: <44637CF8.3030908@redfish-solutions.com> I'm running FC5 on an i686 machine, and have yum nightly updates enabled. I had to rebuild anaconda recently, which required (amongst other things) libsepol-devel. I tried to install libsepol-devel, but it wouldn't install with libsepol-1.12.6-1 (latest). I had to rpm --nodeps -e libsepol-1.12.6 (yikes!), reboot into rescue mode, wget libsepol-1.12.4, and rpm -i --root /mnt/sysimage to install it back. Major pain. Is this a known issue? -Philip From linux_4ever at yahoo.com Thu May 11 18:12:34 2006 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 11 May 2006 11:12:34 -0700 (PDT) Subject: Dependency version mismatch w/ libsepol & libsepol-devel In-Reply-To: <44637CF8.3030908@redfish-solutions.com> Message-ID: <20060511181234.48856.qmail@web51514.mail.yahoo.com> >Is this a known issue? It is now...I'm fixing the spec file, but I'm not sure about pushing just this fix out as an update. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bojan at rexursive.com Thu May 11 19:36:28 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 12 May 2006 05:36:28 +1000 Subject: Firefox update forgotten for FC5? Message-ID: <1147376188.2201.1.camel@coyote.rexursive.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191144 Any ideas why this wasn't rebuilt for FC5? -- Bojan From chitlesh at fedoraproject.org Thu May 11 23:36:48 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 12 May 2006 01:36:48 +0200 Subject: redhat/fedora distros: su versus su - Message-ID: <13dbfe4f0605111636n4e4e9389r25fcc47ea1243b58@mail.gmail.com> Hello here, Last time at LinuxTag Wiesbaden, someone asked me why in RedHat/Fedora distros, /sbin is not in the PATH for _su_ example ifconfig but as _su -_, /sbin is in the PATH? He also pointed out that in other distros like Mandriva and Suse it is not the case. Can anyone answer this so that I could document myself :) regards, Chitlesh Goorah -- http://clunixchit.blogspot.com From peter at thecodergeek.com Thu May 11 23:46:48 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 11 May 2006 16:46:48 -0700 (PDT) Subject: redhat/fedora distros: su versus su - In-Reply-To: <13dbfe4f0605111636n4e4e9389r25fcc47ea1243b58@mail.gmail.com> References: <13dbfe4f0605111636n4e4e9389r25fcc47ea1243b58@mail.gmail.com> Message-ID: <54798.127.0.0.1.1147391208.squirrel@www.thecodergeek.com> Chitlesh GOORAH wrote: > Hello here, > Last time at LinuxTag Wiesbaden, someone asked me why in RedHat/Fedora > distros, > /sbin is not in the PATH for _su_ > example ifconfig > but as _su -_, /sbin is in the PATH? As I understand it, "su" merely grants you root priveleges (changes your effective user/group IDs), while "su -" grants you a full login shell as the root user (hence the profile/environment changes). > He also pointed out that in other distros like Mandriva and Suse it is > not the case. I'm not certain, but 'su' might be aliased to 'su -' or something similar (perhaps for "user-friendliness"?) -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From michael at knox.net.nz Thu May 11 23:47:09 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 12 May 2006 11:47:09 +1200 Subject: redhat/fedora distros: su versus su - In-Reply-To: <13dbfe4f0605111636n4e4e9389r25fcc47ea1243b58@mail.gmail.com> References: <13dbfe4f0605111636n4e4e9389r25fcc47ea1243b58@mail.gmail.com> Message-ID: <4463CCFD.8050202@knox.net.nz> Chitlesh GOORAH wrote: > Hello here, > Last time at LinuxTag Wiesbaden, someone asked me why in RedHat/Fedora > distros, > /sbin is not in the PATH for _su_ > example ifconfig > but as _su -_, /sbin is in the PATH? > > He also pointed out that in other distros like Mandriva and Suse it is > not the case. > > Can anyone answer this so that I could document myself :) > > regards, > Chitlesh Goorah su - takes the root user's enviroment varibles, su by itself does not. When you call just su, your (mortal users) enviroment varibles are used. Thats my understanding. Michael From nman64 at n-man.com Fri May 12 04:37:59 2006 From: nman64 at n-man.com (Patrick W. Barnes) Date: Thu, 11 May 2006 23:37:59 -0500 Subject: redhat/fedora distros: su versus su - In-Reply-To: <4463CCFD.8050202@knox.net.nz> References: <13dbfe4f0605111636n4e4e9389r25fcc47ea1243b58@mail.gmail.com> <4463CCFD.8050202@knox.net.nz> Message-ID: <200605112338.02645.nman64@n-man.com> On Thursday 11 May 2006 18:47, "Michael J. Knox" wrote: > Chitlesh GOORAH wrote: > > Hello here, > > Last time at LinuxTag Wiesbaden, someone asked me why in RedHat/Fedora > > distros, > > /sbin is not in the PATH for _su_ > > example ifconfig > > but as _su -_, /sbin is in the PATH? > > > > He also pointed out that in other distros like Mandriva and Suse it is > > not the case. > > > > Can anyone answer this so that I could document myself :) > > > > regards, > > Chitlesh Goorah > > su - takes the root user's enviroment varibles, su by itself does not. > When you call just su, your (mortal users) enviroment varibles are used. > > Thats my understanding. > > Michael I've not looked, but it is likely that those other distributions include /sbin in the default PATH for regular users, which is the real cause of the different behavior on those systems. 'su' and 'su -' actually behave the same on those systems, but 'su' would inherit only the user's PATH settings, so /sbin would be available only if it is in the user's PATH, which it is not the default on Fedora. 'su -', which creates a login shell, would use only root's PATH, which includes /sbin by default on Fedora. The tools in /sbin, /usr/sbin and /usr/local/sbin are generally intended for use by root, so it makes sense to exclude those paths for regular users. As a side note, the same truths apply to sudo. Simple use of sudo to specify a command will require an absolute path, while 'sudo bash --login' will create a login shell and will provide /sbin in the PATH environment variable. If a user prefers to have /sbin included in the PATH variable for regular users, the adjustment can be made in ~/.bash_profile for each user or system-wide by adding a new script in /etc/profile.d/ with lines that appear as: pathmunge /sbin pathmunge /usr/sbin pathmunge /usr/local/sbin You can find the lines that provide the default behavior in /etc/profile. For the sake of maintainability, you should not modify that file, but you can override or extend it instead using the above outlined methods. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ LinkedIn: http://www.linkedin.com/in/nman64 Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Fri May 12 08:06:25 2006 From: buildsys at redhat.com (Build System) Date: Fri, 12 May 2006 04:06:25 -0400 Subject: rawhide report: 20060512 changes Message-ID: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> New package alchemist A multi-sourced configuration back-end. Updated Packages: agg-2.4-1 --------- * Wed May 10 2006 Caolan McNamara - 2.4-1 - next version anthy-7710-1.fc6 ---------------- * Thu May 11 2006 Akira TAGOH - 7710-1 - New upstream snapshot release. * Mon Apr 24 2006 Akira TAGOH - 7622-1 - New upstream snapshot release. - removed unnecessary patches: - anthy-2832.patch - anthy-2834.patch * Fri Mar 17 2006 Akira TAGOH - 7500-1 - New upstream release. - larning words works now. (#178764) - anthy-2832.patch: patch from upstream that fixes wrong order of candidate list. - anthy-2834.patch: patch from upstream that fixes unexpected word segment. - anthy-gcanna-nakaguro.patch: added a word to dictionary to convert nakaguro to slash. apr-1.2.7-4 ----------- * Mon May 08 2006 Joe Orton 1.2.7-4 - use multilib parallel-installation wrapper hack for apr.h * Tue May 02 2006 Joe Orton 1.2.7-3 - fix installbuilddir in apr-1-config device-mapper-1.02.07-1.0 ------------------------- * Thu May 11 2006 Alasdair Kergon - 1.02.07-1.0 - Build new upstream version. dosfstools-2.11-5 ----------------- * Thu May 11 2006 Peter Vrabec 2.11-5 - fix work with disk image files > 4GB (#191198) evolution-data-server-1.7.1-1 ----------------------------- * Wed May 10 2006 Matthew Barnes - 1.7.1-1 - Update to 1.7.1 - Bump eds_base_version from 1.6 to 1.8. - Disable evolution-data-server-1.2.0-validatehelo.patch (accepted upstream). glib-java-0.2.4-2 ----------------- * Wed May 10 2006 Ben Konrath - 0.2.4-2 - Add -X option when zipping up the sources. This is needed for multilib. glibc-2.4.90-7 -------------- * Thu May 11 2006 Jakub Jelinek 2.4.90-7 - update from CVS - fix tcgetattr (#177965) - fix (#191264) gnome-screensaver-2.15.1-1 -------------------------- * Wed May 10 2006 Matthias Clasen 2.15.1-1 - Update to 2.15.1 gnome-terminal-2.14.1-13 ------------------------ * Thu May 11 2006 Matthias Clasen 2.14.1-13 - Close the about dialog httpd-2.2.2-3 ------------- * Thu May 11 2006 Joe Orton 2.2.2-3 - build DSOs using -z relro linker flag hwdata-0.180-1 -------------- * Thu May 11 2006 Phil Knirsch - 0.180-1 - Updated and added some MonitorsDB entries * Tue May 02 2006 Phil Knirsch - 0.179-1 - Updated PCI ids from upstream (#180402) - Fixed missing monitor entry in MonitorsDB (#189446) * Wed Mar 01 2006 Phil Knirsch - 0.178-1 - Commented out the VT lines at the end of usb.ids as our tools don't handle them properly. kernel-2.6.16-1.2202_FC6 ------------------------ * Thu May 11 2006 Dave Jones - 2.6.17rc4 libgtk-java-2.8.4-2 ------------------- * Thu May 11 2006 Stepan Kasal - 2.8.4-2 - Fix a typo in the Makefile.jni snippet. - Re-run autotools. libidn-0.6.2-3 -------------- * Thu May 11 2006 Joe Orton 0.6.2-3 - make idn-int.h multilib-safe * Wed Feb 22 2006 Joe Orton 0.6.2-2 - disable C# support (#182393) mcstrans-0.1.2-1 ---------------- metacity-2.15.2-1 ----------------- * Thu May 11 2006 Soren Sandmann 2.15.2-1 - Update to metacity 2.15.2 * Tue Apr 18 2006 Kristian H??gsberg 2.15.0-6 - Bump for fc5-bling build. nautilus-2.14.1-3 ----------------- * Fri May 12 2006 Matthias Clasen - 2.14.1-3 - Close the about dialog * Tue Apr 11 2006 Matthias Clasen - 2.14.1-2 - Update to 2.14.1 * Mon Mar 13 2006 Matthias Clasen - 2.14.0-1 - Update to 2.14.0 ntp-4.2.0.a.20050816-14 ----------------------- * Thu May 11 2006 Miroslav Lichvar - 4.2.0.a.20050816-14 - modify ntp.conf, change default restrict, remove broadcastdelay, use fedora.pool.ntp.org (#189667) - don't install drift file - remove unsupported options from ntptrace manpage (#137717) - fix default paths in manpages for ntp-keygen and ntpdate openssl-0.9.8b-1 ---------------- * Thu May 11 2006 Tomas Mraz - 0.9.8b-1 - upgrade to new version, stays ABI compatible - there is no more linux/config.h (it was empty anyway) selinux-policy-2.2.38-5 ----------------------- * Thu May 11 2006 Dan Walsh 2.2.38-5 - Add acquire service for mono. * Thu May 11 2006 Dan Walsh 2.2.38-4 - Turn off allow_execmem boolean - Allow ftp dac_override when allowed to access users homedirs smartmontools-1:5.36-1 ---------------------- * Thu May 11 2006 Tomas Mraz - 1:5.36-1 - new upstream version - included patch with support for cciss controllers (#191288) spamassassin-3.1.1-2.fc6 ------------------------ * Tue May 09 2006 Warren Togami - 3.0.5-4 - Preserve timestamp and context of /etc/sysconfig/spamassassin (#178580) sysstat-6.0.2-1 --------------- * Fri May 05 2006 Ivana Varekova 6.0.2-1 - update to 6.0.2 - remove asm/page.h used sysconf command to get PAGE_SIZE system-config-securitylevel-1.6.19-2 ------------------------------------ * Thu May 11 2006 Chris Lumens 1.6.19-2 - Require iptables-ipv6. tzdata-2006g-1 -------------- * Thu May 11 2006 Petr Machata - 2006g-1 - Honduras chose to follow Guatemala and will observe DST May/6 to Sep/2 - Nicaragua updates vim-2:7.0.010-1 --------------- * Thu May 11 2006 Karsten Hopp 7.0.010-1 - patchlevel 010 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From skvidal at linux.duke.edu Fri May 12 12:11:01 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 12 May 2006 08:11:01 -0400 Subject: rawhide report: 20060512 changes In-Reply-To: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> References: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> Message-ID: <1147435862.1934.0.camel@cutter> On Fri, 2006-05-12 at 04:06 -0400, Build System wrote: > New package alchemist > A multi-sourced configuration back-end. > > Why is alchemist back? -sv From jkeating at redhat.com Fri May 12 13:28:43 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 May 2006 09:28:43 -0400 Subject: rawhide report: 20060512 changes In-Reply-To: <1147435862.1934.0.camel@cutter> References: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> <1147435862.1934.0.camel@cutter> Message-ID: <1147440523.3529.4.camel@ender> On Fri, 2006-05-12 at 08:11 -0400, seth vidal wrote: > Why is alchemist back? system-config-netboot still uses it. Whoops. :/ -- 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 kevin.kofler at chello.at Fri May 12 17:55:30 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 12 May 2006 17:55:30 +0000 (UTC) Subject: rawhide report: 20060512 changes References: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> Message-ID: > evolution-data-server-1.7.1-1 > ----------------------------- > * Wed May 10 2006 Matthew Barnes redhat.com> - 1.7.1-1 > - Update to 1.7.1 > - Bump eds_base_version from 1.6 to 1.8. > - Disable evolution-data-server-1.2.0-validatehelo.patch (accepted upstream). Careful, because it looks like this has been sabotaged again in CVS (see David Woodhouse's blog). Kevin Kofler From emeric.maschino at jouy.inra.fr Fri May 12 21:08:35 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Fri, 12 May 2006 23:08:35 +0200 Subject: Problems with mcstrans Message-ID: <1147468115.4464f95330262@www.jouy.inra.fr> Hi, Since the switch from libsetrans to mcstrans (0.1.1-1 and 0.1.2-1 tested) two days ago, I'm experiencing several issues on my Itanium workstation. During startup, sm-client takes a long time (1-2 minutes) to start. Well in fact, it fails to start with the following error: file_contexts: invalid context system_u:object_r:sendmail_var_run_t:s0 matchpathcon (/var/run/sm-client.pid) failed Invalid argument More annoying, xfs fails to start too and thus gdm can't start the X server. I've also noticed that the HDD activity LED keeps busy. Indeed, my /var/log/messages file is flooded with lines like these: May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (4) May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (6) Always the same lines with fd (4) and fd (6). Due to this abnormal HDD activity, my system is not very responsive. Once mcstransd is manually stopped, I can restart xfs and then the X server. The Fedora Devel list or bugzilla have no information regarding these issues. Are they specific to the ia64 platform? Cheers, ?meric From wwoods at redhat.com Fri May 12 21:42:00 2006 From: wwoods at redhat.com (Will Woods) Date: Fri, 12 May 2006 17:42:00 -0400 Subject: Fedora Core package cleanup project Message-ID: <1147470120.18573.7.camel@metroid.rdu.redhat.com> I'm announcing the start of a new QA project, and I'm asking for your help. In the past, Core packages have not been held to the same standards as Extras. We want to fix this! We're starting by cleaning up the spec files so that Core packages can all be built using Mock. (If you aren't familiar with Mock, it's a cool RPM build tool that we use to build Fedora Extras.) This is where you come in: We need people to attempt Mock builds of Fedora Core packages, and file bugs when they find packages that don't build. Doing so will earn you the thanks and respect of your peers, but as an added incentive we're going to give away free stuff (!) to people who help out. Filing a bug on a broken package will earn you one Karma Point. If you include a patch that makes that package build successfully, you'll get five Karma Points. These will be redeemable for cool stuff from the Red Hat Cool Stuff Store (at an exchange rate to be determined once we figure out how much stuff we're actually allowed to give away :) For more info, check out: http://fedoraproject.org/wiki/QA/FixBuildRequires Ok? OK! Let's get testin'! -w -------------- 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 toshio at tiki-lounge.com Fri May 12 21:54:34 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 12 May 2006 14:54:34 -0700 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <1147470874.3949.20.camel@localhost> On Fri, 2006-05-12 at 17:42 -0400, Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. (If you aren't > familiar with Mock, it's a cool RPM build tool that we use to build > Fedora Extras.) > > This is where you come in: We need people to attempt Mock builds of > Fedora Core packages, and file bugs when they find packages that don't > build. Is this cleanup just targeted at getting things to build in mock for now or should other points on the packaging guidelines also be filed if noticed? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri May 12 22:01:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 May 2006 18:01:27 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147470874.3949.20.camel@localhost> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> Message-ID: <1147471287.3529.34.camel@ender> On Fri, 2006-05-12 at 14:54 -0700, Toshio Kuratomi wrote: > Is this cleanup just targeted at getting things to build in mock for > now > or should other points on the packaging guidelines also be filed if > noticed? > JUST BuildRequires please. This will make it much easier to validate the patches coming in. This is the first step in a longer process. -- 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 pemboa at gmail.com Fri May 12 22:34:35 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 12 May 2006 17:34:35 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <16de708d0605121534n3c56191bicac8da7c5367317f@mail.gmail.com> On 5/12/06, Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. (If you aren't > familiar with Mock, it's a cool RPM build tool that we use to build > Fedora Extras.) > > This is where you come in: We need people to attempt Mock builds of > Fedora Core packages, and file bugs when they find packages that don't > build. > > Doing so will earn you the thanks and respect of your peers, but as an > added incentive we're going to give away free stuff (!) to people who > help out. > > Filing a bug on a broken package will earn you one Karma Point. If you > include a patch that makes that package build successfully, you'll get > five Karma Points. These will be redeemable for cool stuff from the Red > Hat Cool Stuff Store (at an exchange rate to be determined once we > figure out how much stuff we're actually allowed to give away :) > > For more info, check out: > http://fedoraproject.org/wiki/QA/FixBuildRequires > > Ok? OK! Let's get testin'! > A full tutorial/howto on how to go about doing this might be helpful. I currently have the time and a spare machine to help in this. Just not the know how. Arthur Pemberton -- To be updated... From tibbs at math.uh.edu Fri May 12 23:00:35 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 12 May 2006 18:00:35 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <16de708d0605121534n3c56191bicac8da7c5367317f@mail.gmail.com> (Arthur Pemberton's message of "Fri, 12 May 2006 17:34:35 -0500") References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <16de708d0605121534n3c56191bicac8da7c5367317f@mail.gmail.com> Message-ID: >>>>> "AP" == Arthur Pemberton writes: AP> A full tutorial/howto on how to go about doing this might be AP> helpful. I currently have the time and a spare machine to help in AP> this. Just not the know how. Well, getting a basic mock setup is pretty easy; just "yum install mock" and then add yourself to the mock group. Then you can do something like: mock -r fedora-development-x86_64-core.cfg --debug /path/to/src.rpm to build that package for rawhide, x86_64 (assuming you have an x86_64 machine). However, it will be awfully slow because each build has to download and install 110MB of packages. I get around this by having a complete local Fedora mirror and editing the configuration files in /etc/mock to point to it; others install a Squid proxy which means you'll only have to download each package once. - J<. From michael at knox.net.nz Fri May 12 23:04:10 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 13 May 2006 11:04:10 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <4465146A.9040302@knox.net.nz> The "fixbuildrequires" script referenced in the wiki doesn't seem to exist. Michael Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. (If you aren't > familiar with Mock, it's a cool RPM build tool that we use to build > Fedora Extras.) > > This is where you come in: We need people to attempt Mock builds of > Fedora Core packages, and file bugs when they find packages that don't > build. > > Doing so will earn you the thanks and respect of your peers, but as an > added incentive we're going to give away free stuff (!) to people who > help out. > > Filing a bug on a broken package will earn you one Karma Point. If you > include a patch that makes that package build successfully, you'll get > five Karma Points. These will be redeemable for cool stuff from the Red > Hat Cool Stuff Store (at an exchange rate to be determined once we > figure out how much stuff we're actually allowed to give away :) > > For more info, check out: > http://fedoraproject.org/wiki/QA/FixBuildRequires > > Ok? OK! Let's get testin'! > > -w > > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From dwmw2 at infradead.org Fri May 12 23:45:15 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 13 May 2006 00:45:15 +0100 Subject: rawhide report: 20060512 changes In-Reply-To: References: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> Message-ID: <1147477515.2794.568.camel@pmac.infradead.org> On Fri, 2006-05-12 at 17:55 +0000, Kevin Kofler wrote: > Careful, because it looks like this has been sabotaged again in CVS There's an alternative patch in CVS now. It's not quite as good, because we now just use an IP literal in HELO all the time rather than using the hostname as RFC2821 says we 'SHOULD'. But at least there's no chance that we'll use underscores and be completely syntactically invalid :) -- dwmw2 From jkeating at redhat.com Fri May 12 23:56:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 May 2006 19:56:05 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <4465146A.9040302@knox.net.nz> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4465146A.9040302@knox.net.nz> Message-ID: <1147478165.11744.0.camel@ender> On Sat, 2006-05-13 at 11:04 +1200, Michael J Knox wrote: > The "fixbuildrequires" script referenced in the wiki doesn't seem to > exist. It's not a script, and the wiki states that the module doesn't exist yet. We're working on that. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Fri May 12 23:58:26 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 13 May 2006 11:58:26 +1200 Subject: Fedora Core package cleanup project In-Reply-To: <1147478165.11744.0.camel@ender> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <4465146A.9040302@knox.net.nz> <1147478165.11744.0.camel@ender> Message-ID: <44652122.7060206@knox.net.nz> Jesse Keating wrote: > On Sat, 2006-05-13 at 11:04 +1200, Michael J Knox wrote: >> The "fixbuildrequires" script referenced in the wiki doesn't seem to >> exist. > > It's not a script, and the wiki states that the module doesn't exist > yet. We're working on that. > > OK.. Sorry to have misinformed. Glad to hear its been worked on :) Michael From hoover at deadmoose.com Sat May 13 00:01:29 2006 From: hoover at deadmoose.com (Bill Hoover) Date: Fri, 12 May 2006 17:01:29 -0700 Subject: rawhide report: 20060512 changes In-Reply-To: References: <200605120806.k4C86PMg019611@porkchop.devel.redhat.com> Message-ID: <1147478489.23861.0.camel@fc5test.deadmoose.com> On Fri, 2006-05-12 at 17:55 +0000, Kevin Kofler wrote: > > evolution-data-server-1.7.1-1 > > ----------------------------- > > * Wed May 10 2006 Matthew Barnes redhat.com> - 1.7.1-1 > > - Update to 1.7.1 > > - Bump eds_base_version from 1.6 to 1.8. > > - Disable evolution-data-server-1.2.0-validatehelo.patch (accepted upstream). > > Careful, because it looks like this has been sabotaged again in CVS (see David > Woodhouse's blog). > > Kevin Kofler > I just filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191567 because e-d-s 1.7.1-1 doesn't support SSL IMAP connections. I had to back off to the previous to be able to use my mail. From dennis at ausil.us Sat May 13 00:15:27 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 12 May 2006 19:15:27 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <1147471287.3529.34.camel@ender> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> Message-ID: <200605121915.27827.dennis@ausil.us> On Friday 12 May 2006 5:01 pm, Jesse Keating wrote: > On Fri, 2006-05-12 at 14:54 -0700, Toshio Kuratomi wrote: > > Is this cleanup just targeted at getting things to build in mock for > > now > > or should other points on the packaging guidelines also be filed if > > noticed? > > JUST BuildRequires please. This will make it much easier to validate > the patches coming in. This is the first step in a longer process. the Wiki says to assign yourself to packages. Im in the process of throwing fc-5 into a plague server for building on sparc. I have quite a few build logs already, should I start throwing what i have so far at bugzilla? Dennis From sundaram at fedoraproject.org Sat May 13 00:18:54 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 13 May 2006 05:48:54 +0530 Subject: Fedora Core package cleanup project In-Reply-To: <200605121915.27827.dennis@ausil.us> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> <200605121915.27827.dennis@ausil.us> Message-ID: <1147479534.4310.323.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-12 at 19:15 -0500, Dennis Gilmore wrote: > On Friday 12 May 2006 5:01 pm, Jesse Keating wrote: > > On Fri, 2006-05-12 at 14:54 -0700, Toshio Kuratomi wrote: > > > Is this cleanup just targeted at getting things to build in mock for > > > now > > > or should other points on the packaging guidelines also be filed if > > > noticed? > > > > JUST BuildRequires please. This will make it much easier to validate > > the patches coming in. This is the first step in a longer process. > > the Wiki says to assign yourself to packages. Im in the process of throwing > fc-5 into a plague server for building on sparc. I have quite a few build > logs already, should I start throwing what i have so far at bugzilla? > That would be pretty helpful, yes and dont forget to add the bug report to the main tracker bug too. Rahul From dakingun at gmail.com Sat May 13 02:33:25 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 12 May 2006 22:33:25 -0400 Subject: Problems with mcstrans In-Reply-To: <1147468115.4464f95330262@www.jouy.inra.fr> References: <1147468115.4464f95330262@www.jouy.inra.fr> Message-ID: On 5/12/06, ?meric Maschino wrote: > Hi, > > Since the switch from libsetrans to mcstrans (0.1.1-1 and 0.1.2-1 tested) two > days ago, I'm experiencing several issues on my Itanium workstation. During > startup, sm-client takes a long time (1-2 minutes) to start. Well in fact, it > fails to start with the following error: > > file_contexts: invalid context system_u:object_r:sendmail_var_run_t:s0 > matchpathcon (/var/run/sm-client.pid) failed Invalid argument > > More annoying, xfs fails to start too and thus gdm can't start the X server. > I've also noticed that the HDD activity LED keeps busy. Indeed, my > /var/log/messages file is flooded with lines like these: > > May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes > May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (4) > May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes > May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (6) > > Always the same lines with fd (4) and fd (6). > > Due to this abnormal HDD activity, my system is not very responsive. Once > mcstransd is manually stopped, I can restart xfs and then the X server. > > The Fedora Devel list or bugzilla have no information regarding these issues. > Are they specific to the ia64 platform? I don't think so, I'm experiencing same issue on x86_64. Hopefully tomorrow's update will cure it. Cheers, Deji From mpeters at mac.com Sat May 13 08:30:45 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 13 May 2006 01:30:45 -0700 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <1147509045.6910.39.camel@atlantis.mpeters.local> On Fri, 2006-05-12 at 17:42 -0400, Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. I would like to see some tracker bug, like filesystem blockers. IE - my understanding is that database servers, web servers, ftp servers, etc. should make use of /srv for example - Apache default content dirs should be /srv/www/{cgi-bin,html} - and the icons/default error pages etc. should be /usr/share etc. Also - I think gnome games puts its score files in /var/lib/games instead of /var/games (but extras use /var/games for score files AFAIK) From gauret at free.fr Sat May 13 08:36:13 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 13 May 2006 10:36:13 +0200 Subject: Fedora Core package cleanup project References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> Message-ID: Jesse Keating wrote: > On Fri, 2006-05-12 at 14:54 -0700, Toshio Kuratomi wrote: >> Is this cleanup just targeted at getting things to build in mock for >> now or should other points on the packaging guidelines also be filed if >> noticed? > > JUST BuildRequires please. This will make it much easier to validate > the patches coming in. This is the first step in a longer process. When you want to discover other missing points in the packaging guidelines, I have written a small script to automate these QA checks. It tries to be the "rpmlint" of Fedora Extras packages (but it only operates on srpms) You'll find a more detailed description on my wiki page: http://fedoraproject.org/wiki/AurelienBompard It still gives a lot of false positives, but it can be helpful (at least it was helpful to me) If you use it, let me know if there are things to improve. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon." -- Susan Ertz From gajownik at fedora.pl Sat May 13 08:45:38 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 13 May 2006 10:45:38 +0200 Subject: Fedora Core package cleanup project In-Reply-To: <1147509045.6910.39.camel@atlantis.mpeters.local> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147509045.6910.39.camel@atlantis.mpeters.local> Message-ID: <44659CB2.3010605@fedora.pl> Dnia 05/13/2006 10:31 AM, U?ytkownik Michael A. Peters napisa?: > I would like to see some tracker bug, like filesystem blockers. > > IE - my understanding is that database servers, web servers, ftp > servers, etc. should make use of /srv https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172152 -- ^_* From karsten at redhat.de Sat May 13 08:58:02 2006 From: karsten at redhat.de (Karsten Hopp) Date: Sat, 13 May 2006 10:58:02 +0200 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <20060513085802.GA27328@redhat.de> > Doing so will earn you the thanks and respect of your peers, but as an > added incentive we're going to give away free stuff (!) to people who > help out. > > Filing a bug on a broken package will earn you one Karma Point. If you > include a patch that makes that package build successfully, you'll get > five Karma Points. These will be redeemable for cool stuff from the Red > Hat Cool Stuff Store (at an exchange rate to be determined once we > figure out how much stuff we're actually allowed to give away :) > > For more info, check out: > http://fedoraproject.org/wiki/QA/FixBuildRequires > I've already build ~470 packages, 97 failed so far. Is anyone willing to help out filing bus ? I don't need any karma points and I'm not sure I'd qualify anyway. Karsten -- It might look like I'm doing nothing, but at the cellular level I'm really quite busy. From emeric.maschino at jouy.inra.fr Sat May 13 10:23:00 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Sat, 13 May 2006 12:23:00 +0200 Subject: Problems with mcstrans In-Reply-To: References: <1147468115.4464f95330262@www.jouy.inra.fr> Message-ID: <1147515780.4465b38430287@www.jouy.inra.fr> > > Hi, > > > > Since the switch from libsetrans to mcstrans (0.1.1-1 and 0.1.2-1 tested) > two > > days ago, I'm experiencing several issues on my Itanium workstation. During > > startup, sm-client takes a long time (1-2 minutes) to start. Well in fact, > it > > fails to start with the following error: > > > > file_contexts: invalid context system_u:object_r:sendmail_var_run_t:s0 > > matchpathcon (/var/run/sm-client.pid) failed Invalid argument > > > > More annoying, xfs fails to start too and thus gdm can't start the X > server. > > I've also noticed that the HDD activity LED keeps busy. Indeed, my > > /var/log/messages file is flooded with lines like these: > > > > May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes > > May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (4) > > May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes > > May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (6) > > > > Always the same lines with fd (4) and fd (6). > > > > Due to this abnormal HDD activity, my system is not very responsive. Once > > mcstransd is manually stopped, I can restart xfs and then the X server. > > > > The Fedora Devel list or bugzilla have no information regarding these > issues. > > Are they specific to the ia64 platform? > > I don't think so, I'm experiencing same issue on x86_64. Hopefully > tomorrow's update will cure it. Problem still present on ia64 with today's updates: mcstrans-0.1.3-1, selinux-policy-*-2.2.38-6 and autit-libs-*-1.2.2-1. ?meric From mike at miketc.com Sat May 13 11:41:20 2006 From: mike at miketc.com (Mike Chambers) Date: Sat, 13 May 2006 06:41:20 -0500 Subject: Fedora Core package cleanup project In-Reply-To: <20060513085802.GA27328@redhat.de> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <20060513085802.GA27328@redhat.de> Message-ID: <1147520480.6480.0.camel@scrappy.miketc.com> On Sat, 2006-05-13 at 10:58 +0200, Karsten Hopp wrote: > I've already build ~470 packages, 97 failed so far. Is anyone willing to > help out filing bus ? I don't need any karma points and I'm not sure I'd > qualify anyway. Don't know about patching, but I can help submit bugs. Email me off line if not already have any takers? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you aren't getting any!" From mike at miketc.com Sat May 13 12:43:04 2006 From: mike at miketc.com (Mike Chambers) Date: Sat, 13 May 2006 07:43:04 -0500 Subject: Rawhide status Message-ID: <1147524185.2171.5.camel@scrappy.miketc.com> I tried a couple of things in rawhide this morning... 1 - updated evolution/evolution-data-server and kept getting an error about... undefined symbol: g_type_register_static_simple 2 - Also tried a rawhide install this morning, but anaconda wanted to use vesa driver on my video (ATI Radeon 9000 Pro) and couldn't find it. Then proceeded to use text mode and it crashed. Traceback (most recent call last): File "/usr/bin/anaconda", line 938, in ? anaconda.intf.run(anaconda.id, anaconda.dispatch) File "/usr/lib/anaconda/text.py", line 512, in run rc = win(self.screen, anaconda) File "/usr/lib/anaconda/textw/network_text.py", line 271, in __call__ ns1Entry.set(network.primaryNS) NameError: global name 'network' is not defined Hope this helps, -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you aren't getting any!" From mpeters at mac.com Sat May 13 12:52:50 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 13 May 2006 05:52:50 -0700 Subject: Fedora Core package cleanup project In-Reply-To: <44659CB2.3010605@fedora.pl> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147509045.6910.39.camel@atlantis.mpeters.local> <44659CB2.3010605@fedora.pl> Message-ID: <1147524770.6910.44.camel@atlantis.mpeters.local> On Sat, 2006-05-13 at 10:45 +0200, Dawid Gajownik wrote: > Dnia 05/13/2006 10:31 AM, U?ytkownik Michael A. Peters napisa?: > > > I would like to see some tracker bug, like filesystem blockers. > > > > IE - my understanding is that database servers, web servers, ftp > > servers, etc. should make use of /srv > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172152 That's good - but a tracker bug that other bugs could be added to as a blocker makes it easy to look at what packages need to have stuff moved around for FHS compliance. From bdpepple at ameritech.net Sat May 13 12:46:28 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 13 May 2006 08:46:28 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <20060513085802.GA27328@redhat.de> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <20060513085802.GA27328@redhat.de> Message-ID: <1147524388.26948.1.camel@shuttle.piedmont.com> On Sat, 2006-05-13 at 10:58 +0200, Karsten Hopp wrote: > > Doing so will earn you the thanks and respect of your peers, but as an > > added incentive we're going to give away free stuff (!) to people who > > help out. > > > > Filing a bug on a broken package will earn you one Karma Point. If you > > include a patch that makes that package build successfully, you'll get > > five Karma Points. These will be redeemable for cool stuff from the Red > > Hat Cool Stuff Store (at an exchange rate to be determined once we > > figure out how much stuff we're actually allowed to give away :) > > > > For more info, check out: > > http://fedoraproject.org/wiki/QA/FixBuildRequires > > > > I've already build ~470 packages, 97 failed so far. Is anyone willing to > help out filing bus ? I don't need any karma points and I'm not sure I'd > qualify anyway. > Karsten, I've got free time today and would be willing to help you. Just forward me the necessary information and I'll help with opening bugs and creating patches. /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 txtoth at gmail.com Sat May 13 14:20:09 2006 From: txtoth at gmail.com (Xavier Toth) Date: Sat, 13 May 2006 14:20:09 +0000 Subject: Fwd: kernel 'make rpm', kadischi and kernel version disconnect In-Reply-To: References: Message-ID: I'm hoping someone on this list will have some thoughts related to this problem. ---------- Forwarded message ---------- From: Xavier Toth Date: May 12, 2006 3:32 PM Subject: kernel 'make rpm', kadischi and kernel version disconnect To: fedora-livecd-list at redhat.com I'm building a kernel rpm which then I'm trying to build a livecd with for testing purposes. In my case I've edited the kernel Makefile setting EXTRAVERSION = _1.2185.2.1_FC6.lspp.21, I used '_' instead of '-' because of rpmbuild doesn't like '-'. I build the rpm and then copy kernel-2.6.16_1.2185.2.1_FC6.lspp.21-1.rpm to /tmp/fc5/Fedora/RPMS and run createrepo followed by 'kadischi /tmp/fc5 /tmp/fedora-live.iso'. When kadischi get to the point of running initrd the following happens: making initrd image /tmp/livecd-build_no28/system/lib/modules/2.6.16_1.2185.2.1_FC6.lspp.21-1 is not a directory. *** Fatal error: /usr/local/share/kadischi/livecd-mkinitrd.sh returned non zero (256) exit code. Aborting execution. There is a /tmp/livecd-build_no28/system/lib/modules/2.6.16_1.2185.2.1_FC6.lspp.21 directory. I see that there is a disconnect related to the release number (-1) between the kernel rpm build and kadischi but it's unclear where to fix this in the kernel build or kadischi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Sat May 13 14:32:39 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 13 May 2006 10:32:39 -0400 Subject: Fedora Core package cleanup project In-Reply-To: References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> Message-ID: <1147530760.11744.11.camel@ender> On Sat, 2006-05-13 at 10:36 +0200, Aurelien Bompard wrote: > When you want to discover other missing points in the packaging > guidelines, > I have written a small script to automate these QA checks. It tries to > be > the "rpmlint" of Fedora Extras packages (but it only operates on > srpms) rpmlint works on srpms and rpms, why couldn't you help to improve rpmlint? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Sat May 13 14:33:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 13 May 2006 10:33:47 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147524770.6910.44.camel@atlantis.mpeters.local> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147509045.6910.39.camel@atlantis.mpeters.local> <44659CB2.3010605@fedora.pl> <1147524770.6910.44.camel@atlantis.mpeters.local> Message-ID: <1147530827.11744.13.camel@ender> On Sat, 2006-05-13 at 05:52 -0700, Michael A. Peters wrote: > > That's good - but a tracker bug that other bugs could be added to as a > blocker makes it easy to look at what packages need to have stuff > moved > around for FHS compliance. > That's (possibly) another event for another time. This event is just about BuildRequires (and other failures to build in Mock) -- 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 arjan at fenrus.demon.nl Sat May 13 16:08:50 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 13 May 2006 18:08:50 +0200 Subject: Fwd: kernel 'make rpm', kadischi and kernel version disconnect In-Reply-To: References: Message-ID: <1147536530.3217.9.camel@laptopd505.fenrus.org> On Sat, 2006-05-13 at 14:20 +0000, Xavier Toth wrote: > I'm hoping someone on this list will have some thoughts related to > this problem. I assume you build this rpm using the fedora src.rpm and specfile? Because if not then you really should... ;) From mrsam at courier-mta.com Sat May 13 16:53:30 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 13 May 2006 12:53:30 -0400 Subject: Optimizing kernel-devel Message-ID: After drinking yet another half a dozen cups of tea while waiting for both kernel-devel and kernel-devel-smp to install, I have an idea how to fix this mess: 1) Add one more file to kernel-devel and kernel-devel-smp packages, whose contents are the output of: cd $RPM_BUILD_ROOT/usr/src/kernels/<> find . -type f -print | sort | xargs md5sum >../<>.md5sum 2) %post would then simply read all .md5sum files, reconcile them, and know exactly what to hard link. I'd be surprised if this will not speed things up by at least a factor of 10. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From arjan at fenrus.demon.nl Sat May 13 17:02:40 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 13 May 2006 19:02:40 +0200 Subject: Optimizing kernel-devel In-Reply-To: References: Message-ID: <1147539761.3217.11.camel@laptopd505.fenrus.org> On Sat, 2006-05-13 at 12:53 -0400, Sam Varshavchik wrote: > After drinking yet another half a dozen cups of tea while waiting for both > kernel-devel and kernel-devel-smp to install, I have an idea how to fix this > mess: > > 1) Add one more file to kernel-devel and kernel-devel-smp packages, whose > contents are the output of: > > cd $RPM_BUILD_ROOT/usr/src/kernels/<> > find . -type f -print | sort | xargs md5sum >../<>.md5sum > > 2) %post would then simply read all .md5sum files, reconcile them, and know > exactly what to hard link. > > I'd be surprised if this will not speed things up by at least a factor of > 10. another one would be to make a kernel-devel-base, which works for all versions, and which just has filenames that are the md5sums of all the headers. The kernel-devel package would then only contain symlinks to the md5sum filenames ;) (yes it's a hack, and yes it's grossly horrible :) From mrsam at courier-mta.com Sat May 13 17:20:02 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 13 May 2006 13:20:02 -0400 Subject: Optimizing kernel-devel References: <1147539761.3217.11.camel@laptopd505.fenrus.org> Message-ID: Arjan van de Ven writes: > On Sat, 2006-05-13 at 12:53 -0400, Sam Varshavchik wrote: >> After drinking yet another half a dozen cups of tea while waiting for both >> kernel-devel and kernel-devel-smp to install, I have an idea how to fix this >> mess: >> >> 1) Add one more file to kernel-devel and kernel-devel-smp packages, whose >> contents are the output of: >> >> cd $RPM_BUILD_ROOT/usr/src/kernels/<> >> find . -type f -print | sort | xargs md5sum >../<>.md5sum >> >> 2) %post would then simply read all .md5sum files, reconcile them, and know >> exactly what to hard link. >> >> I'd be surprised if this will not speed things up by at least a factor of >> 10. > > another one would be to make a kernel-devel-base, which works for all > versions, and which just has filenames that are the md5sums of all the > headers. The kernel-devel package would then only contain symlinks to > the md5sum filenames ;) > > (yes it's a hack, and yes it's grossly horrible :) You will also need to figure out how to create one that will hold all files that will go into every kernel release in the foreseeable future. This one's really a no-brainer. You're now forking/execing about seven thousand times, one for each file in the kernel-devel package, and reading and computing the checksum, every time you install a -devel package. Compare that against computing the checksums only once, when the package gets built, using only a fraction of the fork/exec pairs. Then you can install the package on a thousand machines, and each install merely reads all .md5sum files, finds the dupes, and creates the links. The way this is done now is very inefficient. I could see how it happened -- oh, yeah, no big deal, just slap on a find+exec of hardlink. No sweat. But, the consequences of doing so were never considered. The Perl script to reconcile the .md5 files, and create the hard links, is laughably trivial. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From nutello at sweetness.com Sat May 13 17:27:45 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Sat, 13 May 2006 19:27:45 +0200 Subject: Optimizing kernel-devel In-Reply-To: References: <1147539761.3217.11.camel@laptopd505.fenrus.org> Message-ID: <20060513172745.GA31666@plain.rackshack.net> On Sat, May 13, 2006 at 01:20:02PM -0400, Sam Varshavchik wrote: > The Perl script to reconcile the .md5 files, and create the hard links, is > laughably trivial. Can you run rpmquery in a postinstall script, without causing deadlocks? If so, there's no need for the .md5 files, since RPM is already computing the checksums once: rpmquery kernel-devel-2.x.y-z --qf '[%{FILEMD5S} %{FILENAMES}\n]' | grep ^[0-9a-f] -- Rudi From jpmahowald at gmail.com Sat May 13 19:13:11 2006 From: jpmahowald at gmail.com (John Mahowald) Date: Sat, 13 May 2006 14:13:11 -0500 Subject: Firefox update forgotten for FC5? In-Reply-To: <1147376188.2201.1.camel@coyote.rexursive.com> References: <1147376188.2201.1.camel@coyote.rexursive.com> Message-ID: <3ea997540605131213q20579a3dl732d209e2bf582ac@mail.gmail.com> On 5/11/06, Bojan Smojver wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191144 > > Any ideas why this wasn't rebuilt for FC5? > >From package update list, seems to have been released the same day you wrote this. From nicolas.mailhot at laposte.net Sat May 13 18:55:16 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 13 May 2006 20:55:16 +0200 (CEST) Subject: Optimizing kernel-devel In-Reply-To: <1147539761.3217.11.camel@laptopd505.fenrus.org> References: <1147539761.3217.11.camel@laptopd505.fenrus.org> Message-ID: <60953.81.64.156.253.1147546516.squirrel@rousalka.dyndns.org> Le Sam 13 mai 2006 19:02, Arjan van de Ven a ?crit : > > another one would be to make a kernel-devel-base, which works for all > versions, and which just has filenames that are the md5sums of all the > headers. The kernel-devel package would then only contain symlinks to > the md5sum filenames ;) BTW, did anyone ever tried to add a special version-arch file to the kernel packages, that the module packages built against this kernel could depend on? Could be more sane than playing in-spec or in-yum dependency tricks Regards, -- Nicolas Mailhot From rdieter at math.unl.edu Sat May 13 19:30:46 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 13 May 2006 14:30:46 -0500 Subject: Optimizing kernel-devel References: <1147539761.3217.11.camel@laptopd505.fenrus.org> <20060513172745.GA31666@plain.rackshack.net> Message-ID: Rudi Chiarito wrote: > On Sat, May 13, 2006 at 01:20:02PM -0400, Sam Varshavchik wrote: >> The Perl script to reconcile the .md5 files, and create the hard links, >> is laughably trivial. > > Can you run rpmquery in a postinstall script, without causing deadlocks? Probably, but it's still not a good idea. -- Rex From mailinglists at erwinrol.com Sat May 13 19:42:27 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 13 May 2006 21:42:27 +0200 Subject: missing symbol in evolution Message-ID: <446636A3.8090200@erwinrol.com> Evolution broke, it now always shows the following error and exits; evolution: symbol lookup error: /usr/lib64/evolution/2.8/components/libevolution-mail.so: undefined symbol: camel_smime_context_new - Erwin From yaneti at declera.com Sat May 13 20:31:53 2006 From: yaneti at declera.com (Yanko Kaneti) Date: Sat, 13 May 2006 23:31:53 +0300 Subject: missing symbol in evolution In-Reply-To: <446636A3.8090200@erwinrol.com> References: <446636A3.8090200@erwinrol.com> Message-ID: <1147552313.19776.10.camel@indigo.declera.com> On Sat, 2006-05-13 at 21:42 +0200, Erwin Rol wrote: > Evolution broke, it now always shows the following error and exits; > > evolution: symbol lookup error: > /usr/lib64/evolution/2.8/components/libevolution-mail.so: undefined > symbol: camel_smime_context_new evolution-data-server built without SSL (hence SMIME) support due to some configure/nss/nsrp miscommunication. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191567 (btw, I believe this mail is better suited for the test list https://www.redhat.com/mailman/listinfo/fedora-test-list ) Yanko From fedora at soeterbroek.com Sat May 13 20:40:04 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Sat, 13 May 2006 22:40:04 +0200 Subject: Fedora Core package cleanup project In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <44664424.8090002@soeterbroek.com> Will Woods wrote: > I'm announcing the start of a new QA project, and I'm asking for your > help. > > In the past, Core packages have not been held to the same standards as > Extras. We want to fix this! We're starting by cleaning up the spec > files so that Core packages can all be built using Mock. (If you aren't > familiar with Mock, it's a cool RPM build tool that we use to build > Fedora Extras.) > > This is where you come in: We need people to attempt Mock builds of > Fedora Core packages, and file bugs when they find packages that don't > build. I have mock-build several FC packages from devel today and I am running into the same missing dependencies every time: libX11 and libX11-devel (present in FC5) are not in devel. What is/should it be replaced with? Joost Soeterbroek From txtoth at gmail.com Sat May 13 20:40:29 2006 From: txtoth at gmail.com (Xavier Toth) Date: Sat, 13 May 2006 20:40:29 +0000 Subject: Fwd: kernel 'make rpm', kadischi and kernel version disconnect In-Reply-To: <1147536530.3217.9.camel@laptopd505.fenrus.org> References: <1147536530.3217.9.camel@laptopd505.fenrus.org> Message-ID: Yes, I'm using a fedora src.rpm but the build contains a script named mkspec which the build uses to generate kernel.spec. On 5/13/06, Arjan van de Ven wrote: > > On Sat, 2006-05-13 at 14:20 +0000, Xavier Toth wrote: > > I'm hoping someone on this list will have some thoughts related to > > this problem. > > > I assume you build this rpm using the fedora src.rpm and specfile? > Because if not then you really should... ;) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Sat May 13 21:13:30 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 13 May 2006 16:13:30 -0500 Subject: Fedora Core package cleanup project References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <44664424.8090002@soeterbroek.com> Message-ID: Joost Soeterbroek wrote: > I have mock-build several FC packages from devel today and I am running > into the same missing dependencies every time: libX11 and libX11-devel > (present in FC5) are not in devel. It's just the usual rawhide/development breakage, hopefully to be fixed real soon. -- Rex From gauret at free.fr Sun May 14 01:47:49 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 14 May 2006 03:47:49 +0200 Subject: Fedora Core package cleanup project References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> <1147530760.11744.11.camel@ender> Message-ID: Jesse Keating wrote: > rpmlint works on srpms and rpms, why couldn't you help to improve > rpmlint? Because my script tries to do more, for example rebuilding the srpm in mock, diffing the spec file since the last review, displaying the files list and ask for approval, etc... It is very very tied to the Fedora packaging guidelines, while rpmlint is generic and distro independant. But it's true that some tests are generic enough to go into rpmlint, I'll contact them. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Go away or I will replace you with a very small shell script From kmaraas at broadpark.no Sun May 14 11:02:08 2006 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sun, 14 May 2006 13:02:08 +0200 Subject: Rawhide status In-Reply-To: <1147524185.2171.5.camel@scrappy.miketc.com> References: <1147524185.2171.5.camel@scrappy.miketc.com> Message-ID: <1147604528.3904.6.camel@rivendell> l?r, 13,.05.2006 kl. 07.43 -0500, skrev Mike Chambers: > I tried a couple of things in rawhide this morning... > > 1 - updated evolution/evolution-data-server and kept getting an error > about... > > undefined symbol: g_type_register_static_simple > > 2 - Also tried a rawhide install this morning, but anaconda wanted to > use vesa driver on my video (ATI Radeon 9000 Pro) and couldn't find it. > Then proceeded to use text mode and it crashed. > I saw the same thing with this in a laptop: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M > Traceback (most recent call last): > File "/usr/bin/anaconda", line 938, in ? > anaconda.intf.run(anaconda.id, anaconda.dispatch) > File "/usr/lib/anaconda/text.py", line 512, in run > rc = win(self.screen, anaconda) > File "/usr/lib/anaconda/textw/network_text.py", line 271, in __call__ > ns1Entry.set(network.primaryNS) > NameError: global name 'network' is not defined > I got this one if I chose to use DHCP for eth0, but not enable the interface at boot time, did you do the same? My install continued when I left both boxes checked in that dialog. Other things I noticed: - Couldn't find '/' in any of the scandinavian keyboard layouts (could be me not knowing where to look though) - Seems like some files are plain missing from rawhide. I installed the FC5 versions of them and got up and running after a lot of manual trial and error. The files are: libX11-* libXmu-* libXt-* - gdk-pixbuf.loaders and pango.modules were empty, causing a lot of problems. Programs having problems were referencing /etc/pango/pango.modules, but the file was in /etc/pango/$arch or something? Is that the right place for them? Same for gdk-pixbuf.loaders Cheers Kjartan From mike at miketc.com Sun May 14 12:15:24 2006 From: mike at miketc.com (Mike Chambers) Date: Sun, 14 May 2006 07:15:24 -0500 Subject: Rawhide status In-Reply-To: <1147604528.3904.6.camel@rivendell> References: <1147524185.2171.5.camel@scrappy.miketc.com> <1147604528.3904.6.camel@rivendell> Message-ID: <1147608924.1697.1.camel@scrappy.miketc.com> On Sun, 2006-05-14 at 13:02 +0200, Kjartan Maraas wrote: > l?r, 13,.05.2006 kl. 07.43 -0500, skrev Mike Chambers: > > Traceback (most recent call last): > > File "/usr/bin/anaconda", line 938, in ? > > anaconda.intf.run(anaconda.id, anaconda.dispatch) > > File "/usr/lib/anaconda/text.py", line 512, in run > > rc = win(self.screen, anaconda) > > File "/usr/lib/anaconda/textw/network_text.py", line 271, in __call__ > > ns1Entry.set(network.primaryNS) > > NameError: global name 'network' is not defined > > > I got this one if I chose to use DHCP for eth0, but not enable the > interface at boot time, did you do the same? My install continued when I > left both boxes checked in that dialog. Mine wasn't the same. I setup static IP and to activate (well not sure it got that far) on boot and got the crash. And it wouldn't continue, although I have the .txt file it asked me if I wanted to save. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you aren't getting any!" From buildsys at redhat.com Sun May 14 17:02:20 2006 From: buildsys at redhat.com (Build System) Date: Sun, 14 May 2006 13:02:20 -0400 Subject: rawhide report: 20060514 changes Message-ID: <200605141702.k4EH2KkZ011580@porkchop.devel.redhat.com> New package libX11 X.Org X11 libX11 runtime library New package libXau X.Org X11 libXau runtime library New package libXmu X.Org X11 libXmu/libXmuu runtime libraries Updated Packages: (none) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From fedora at camperquake.de Sun May 14 19:49:45 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 14 May 2006 21:49:45 +0200 Subject: Optimizing kernel-devel In-Reply-To: References: Message-ID: <20060514214945.1b1ed2b0@nausicaa.camperquake.de> Hi. Sam Varshavchik wrote: > I'd be surprised if this will not speed things up by at least a factor > of 10. You could also add "HARDLINK=no" to /etc/sysconfig/kernel, which will prevent the %post script from doing any hardlinking at all. -- "In our world, software has to be small, has to be debugged, has to ship as part of a major initiative, has to avoid compatibility problems, has to avoid end user calls." -- Bill Gates From bdpepple at ameritech.net Sun May 14 22:04:37 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 14 May 2006 18:04:37 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147471287.3529.34.camel@ender> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> Message-ID: <1147644277.21672.2.camel@shuttle.piedmont.com> On Fri, 2006-05-12 at 18:01 -0400, Jesse Keating wrote: > On Fri, 2006-05-12 at 14:54 -0700, Toshio Kuratomi wrote: > > Is this cleanup just targeted at getting things to build in mock for > > now > > or should other points on the packaging guidelines also be filed if > > noticed? > > > > JUST BuildRequires please. This will make it much easier to validate > the patches coming in. This is the first step in a longer process. I've noticed that a bunch of packages are failing in Mock, due to 'which' not being installed. Did this use to be in the base-install packages before? /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 skvidal at linux.duke.edu Sun May 14 22:11:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 14 May 2006 18:11:29 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147644277.21672.2.camel@shuttle.piedmont.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> <1147644277.21672.2.camel@shuttle.piedmont.com> Message-ID: <1147644689.8403.41.camel@cutter> On Sun, 2006-05-14 at 18:04 -0400, Brian Pepple wrote: > On Fri, 2006-05-12 at 18:01 -0400, Jesse Keating wrote: > > On Fri, 2006-05-12 at 14:54 -0700, Toshio Kuratomi wrote: > > > Is this cleanup just targeted at getting things to build in mock for > > > now > > > or should other points on the packaging guidelines also be filed if > > > noticed? > > > > > > > JUST BuildRequires please. This will make it much easier to validate > > the patches coming in. This is the first step in a longer process. > > I've noticed that a bunch of packages are failing in Mock, due to > 'which' not being installed. Did this use to be in the base-install > packages before? > is this on FC5? if so make sure your mock config is modified like russel harrison mentioned or you'll always see this failure. -sv From bdpepple at ameritech.net Mon May 15 02:11:50 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sun, 14 May 2006 22:11:50 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147644689.8403.41.camel@cutter> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147470874.3949.20.camel@localhost> <1147471287.3529.34.camel@ender> <1147644277.21672.2.camel@shuttle.piedmont.com> <1147644689.8403.41.camel@cutter> Message-ID: <1147659110.5683.0.camel@shuttle.piedmont.com> On Sun, 2006-05-14 at 18:11 -0400, seth vidal wrote: > On Sun, 2006-05-14 at 18:04 -0400, Brian Pepple wrote: > > I've noticed that a bunch of packages are failing in Mock, due to > > 'which' not being installed. Did this use to be in the base-install > > packages before? > > > > is this on FC5? > > if so make sure your mock config is modified like russel harrison > mentioned or you'll always see this failure. Thanks, that solved the problem. /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 buildsys at redhat.com Mon May 15 07:38:18 2006 From: buildsys at redhat.com (Build System) Date: Mon, 15 May 2006 03:38:18 -0400 Subject: rawhide report: 20060515 changes Message-ID: <200605150738.k4F7cIvq017145@porkchop.devel.redhat.com> New package libX11 X.Org X11 libX11 runtime library New package libXau X.Org X11 libXau runtime library New package libXmu X.Org X11 libXmu/libXmuu runtime libraries Updated Packages: anthy-7714-1.fc6 ---------------- * Mon May 15 2006 Akira TAGOH - 7714-1 - New upstream snapshot release. evolution-connector-2.7.1-2 --------------------------- * Sun May 14 2006 Matthew Barnes - 2.7.1-2 - Forgot to add evolution-exchange-2.7.1-fix_version.patch to CVS. * Fri May 12 2006 Matthew Barnes - 2.7.1-1 - Update to 2.7.1 - Add some comments about the `plibdir' variable. - Add --enable-gtk-doc to the `configure' invocation. - Add temporary patch evolution-exchange-2.7.1-fix_version.patch. evolution-data-server-1.7.1-2 ----------------------------- * Sun May 14 2006 Matthew Barnes - 1.7.1-2 - Add temporary patch evolution-data-server-1.7.1-nss_auto_detect.patch to help `configure' detect the SSL modules (closes #191567). gcc-4.1.0-16 ------------ * Sat May 13 2006 Jakub Jelinek 4.1.0-16 - update from gcc-4_1-branch (-r113637:113722) - PRs bootstrap/26872, c++/27547, fortran/20460, fortran/24549, middle-end/27384, middle-end/27488, target/26545, target/27158 - fix libgcj.pc location and content on x86_64, ppc64 and s390x (#185230) - make __dso_handle const, so that it is added into .data.rel.ro section in shared libraries - fix a typo in __builtin_object_size computation (Richard Guenther, PR tree-optimization/27532) - fix ICE on -O0 -g if static local variables are in unreachable code blocks (Jan Hubicka, PR debug/26881) - fix ICEs with conflicts across abnormal edges (Zdenek Dvorak, PRs tree-optimization/27283, tree-optimization/27548, tree-optimization/27549) - warn about OpenMP section 2.9 region nesting violations - fix OpenMP fortran array REDUCTION with -fbounds-check (PR fortran/27446) - fix OpenMP {{FIRST,LAST}PRIVATE,REDUCTION} in orphaned construct on Fortran dummy argument (PR middle-end/27416) - fix ICE on #pragma omp for unsigned iteration variable (PR c/27499) * Tue May 09 2006 Jakub Jelinek 4.1.0-15 - update from gcc-4_1-branch (-r113623:113637) - PR fortran/27378 - update from trunk (-r109500:109501, -r109670:109671, -r111341:111342, -r111704:111705, -r112546:112547, -r113111:113112, -r113339:113341, -r113511:113513) - fix loop peeling (Zdenek Dvorak, #190039, PR rtl-optimization/27335) gedit-1:2.15.1-2 ---------------- * Sat May 13 2006 Dan Williams - 2.15.1-2 - Work around gnome.org #341055 (gedit doesn't remember previous open/save dir) hplip-0.9.11-4 -------------- * Mon May 15 2006 Tim Waugh 0.9.11-4 - Patchlevel 2. jwhois-3.2.3-5 -------------- * Mon May 15 2006 Miloslav Trmac - 3.2.3-5 - Update to upstream config as of May 15 2006 (#191291) - Add more IPv6 address ranges (#191290, original patch by Peter Bieringer) mrtg-2.14.3-1 ------------- * Mon May 15 2006 Miloslav Trmac - 2.14.3-1 - Update to mrtg-2.14.3 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From linux_4ever at yahoo.com Mon May 15 10:30:51 2006 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 15 May 2006 03:30:51 -0700 (PDT) Subject: Problems with mcstrans In-Reply-To: <1147468115.4464f95330262@www.jouy.inra.fr> Message-ID: <20060515103051.75943.qmail@web51507.mail.yahoo.com> >May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes >May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (4) I'm looking into this problem now. If you are not using any MCS translations, I'd recommend just doing "chkconfig --del mcstrans" for the time being. We should have fixed packages later today. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mailinglists at erwinrol.com Mon May 15 12:02:55 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 15 May 2006 14:02:55 +0200 Subject: weird firefox problem Message-ID: <1147694575.5250.39.camel@xpc.home.erwinrol.com> After clicking a link Firefox sometimes opens a new window that only holds the page where the link points to. The firefox main window stays empty and never gets updated anymore. When clicking "back" the main window has the previous page again, and the new window stays empty. When closing that new window firefox exits as if the main window was closed. One place where this happens a lot is heise.de, for example i just had it when clicking the first forum link on this page; http://www.heise.de/newsticker/foren/go.shtml?list=1&forum_id=97683 Has anybody else ever seen this problem, or would it just be a messed up firefox on my system ? BTW this is a 64bit AMD system. - Erwin From andy at warmcat.com Mon May 15 12:05:39 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 15 May 2006 13:05:39 +0100 Subject: weird firefox problem In-Reply-To: <1147694575.5250.39.camel@xpc.home.erwinrol.com> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> Message-ID: <44686E93.6060005@warmcat.com> Erwin Rol wrote: > After clicking a link Firefox sometimes opens a new window that only > holds the page where the link points to. The firefox main window stays > empty and never gets updated anymore. When clicking "back" the main > window has the previous page again, and the new window stays empty. When > closing that new window firefox exits as if the main window was closed. > > One place where this happens a lot is heise.de, for example i just had > it when clicking the first forum link on this page; > http://www.heise.de/newsticker/foren/go.shtml?list=1&forum_id=97683 > > Has anybody else ever seen this problem, or would it just be a messed up > firefox on my system ? > > BTW this is a 64bit AMD system. Yep I have it too... 64bit AMD system but 32-bit firefox. This is going through squid on another box. Not sure from which direction this is coming. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From mailinglists at erwinrol.com Mon May 15 12:17:25 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 15 May 2006 14:17:25 +0200 Subject: weird firefox problem In-Reply-To: <44686E93.6060005@warmcat.com> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> <44686E93.6060005@warmcat.com> Message-ID: <1147695445.5250.50.camel@xpc.home.erwinrol.com> On Mon, 2006-05-15 at 13:05 +0100, Andy Green wrote: > Erwin Rol wrote: > > After clicking a link Firefox sometimes opens a new window that only > > holds the page where the link points to. The firefox main window stays > > empty and never gets updated anymore. When clicking "back" the main > > window has the previous page again, and the new window stays empty. When > > closing that new window firefox exits as if the main window was closed. > > > > One place where this happens a lot is heise.de, for example i just had > > it when clicking the first forum link on this page; > > http://www.heise.de/newsticker/foren/go.shtml?list=1&forum_id=97683 > > > > Has anybody else ever seen this problem, or would it just be a messed up > > firefox on my system ? > > > > BTW this is a 64bit AMD system. > > Yep I have it too... 64bit AMD system but 32-bit firefox. This is going > through squid on another box. Not sure from which direction this is coming. What kind of firefox (if at all) plugins do you have ? for a while i thought the tabbed-browsing one was the problem, but it also happened with out it. I had it on another page where there where frames, and all 3 frames ended up being a own toplevel window. - Erwin From andy at warmcat.com Mon May 15 12:26:57 2006 From: andy at warmcat.com (Andy Green) Date: Mon, 15 May 2006 13:26:57 +0100 Subject: weird firefox problem In-Reply-To: <1147695445.5250.50.camel@xpc.home.erwinrol.com> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> <44686E93.6060005@warmcat.com> <1147695445.5250.50.camel@xpc.home.erwinrol.com> Message-ID: <44687391.7020705@warmcat.com> Erwin Rol wrote: > What kind of firefox (if at all) plugins do you have ? for a while i > thought the tabbed-browsing one was the problem, but it also happened > with out it. > > I had it on another page where there where frames, and all 3 frames > ended up being a own toplevel window. Apparently I have a large number of language packs, the Sage and Chatzilla plugins. However... the URL example you gave above is fine for me. Here's a broken one for me: http://www.silicon.com/silicon/software/os/0,39024651,39158866,00.htm -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From mailinglists at erwinrol.com Mon May 15 12:33:24 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 15 May 2006 14:33:24 +0200 Subject: weird firefox problem In-Reply-To: <44687391.7020705@warmcat.com> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> <44686E93.6060005@warmcat.com> <1147695445.5250.50.camel@xpc.home.erwinrol.com> <44687391.7020705@warmcat.com> Message-ID: <1147696404.5250.53.camel@xpc.home.erwinrol.com> On Mon, 2006-05-15 at 13:26 +0100, Andy Green wrote: > Erwin Rol wrote: > > > What kind of firefox (if at all) plugins do you have ? for a while i > > thought the tabbed-browsing one was the problem, but it also happened > > with out it. > > > > I had it on another page where there where frames, and all 3 frames > > ended up being a own toplevel window. > > Apparently I have a large number of language packs, the Sage and > Chatzilla plugins. However... the URL example you gave above is fine > for me. Here's a broken one for me: > > http://www.silicon.com/silicon/software/os/0,39024651,39158866,00.htm That works for me. The example i gave also works for me, because it almost never is reproducible. It smells a bit like a race condition. - Erwin From dwalsh at redhat.com Mon May 15 13:54:58 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 May 2006 09:54:58 -0400 Subject: Problems with mcstrans In-Reply-To: <20060515103051.75943.qmail@web51507.mail.yahoo.com> References: <20060515103051.75943.qmail@web51507.mail.yahoo.com> Message-ID: <44688832.701@redhat.com> Steve G wrote: >> May 13 00:22:05 localhost mcstransd: Could not allocate 1953724787 bytes >> May 13 00:22:05 localhost mcstransd: Servicing of request failed for fd (4) >> > > I'm looking into this problem now. If you are not using any MCS translations, I'd > recommend just doing "chkconfig --del mcstrans" for the time being. We should > have fixed packages later today. > > -Steve > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > Turns out to be a 64 bit problem. libselinux was using 32 bit int, and mctrans was expecting 64 bit int for size. Fixed version will be in tonights rawhide, available now at ftp://people.redhat.com/dwalsh/SELinux/Fedora From ajackson at redhat.com Mon May 15 13:24:46 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 15 May 2006 09:24:46 -0400 Subject: rawhide report: 20060515 changes In-Reply-To: <200605150738.k4F7cIvq017145@porkchop.devel.redhat.com> References: <200605150738.k4F7cIvq017145@porkchop.devel.redhat.com> Message-ID: <4468811E.2020204@redhat.com> Build System wrote: > New package libX11 > X.Org X11 libX11 runtime library > > New package libXau > X.Org X11 libXau runtime library > > New package libXmu > X.Org X11 libXmu/libXmuu runtime libraries My apologies to anyone who was hit by these blipping in and out of existance, I shot myself in the foot while updating them. Things should be working now, let me know if you hit anything else weird. - ajax From katzj at redhat.com Mon May 15 15:16:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 15 May 2006 11:16:49 -0400 Subject: FC5 ISO Re-Spins In-Reply-To: <1147331106.28230.16.camel@linux> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <20060510220106.GA31836@neu.nirvana> <1147331106.28230.16.camel@linux> Message-ID: <1147706209.7705.5.camel@orodruin.boston.redhat.com> On Thu, 2006-05-11 at 09:05 +0200, Hans Kristian Rosbach wrote: > On Thu, 2006-05-11 at 00:01 +0200, Axel Thimm wrote: > *snip* > > I get similar results when trying to do the same for ppc on x86_64. > > > > Is this considered a bug in pkgorder? createrepo works fine cross-arch > > (or at least seems to do so). Should I file a bug? > > The utils have not been made with cross-arch building in mind and will > not work by design. I hope it will be remade to work cross arch but > from what I saw when investigating it it would not be an easy task. Correct. We'd like to get there, but there's some non-trivial work to be done. > What I consider a bug however is that it does not just check arch and > tell you it won't work. Would be much cleaner imho. If it's not in bugzilla... ;-) Seriously, file a bug and we can easily make it error out if you're running on an incompatible arch. But I know that by the time I finish catching up with mail, I will have forgotten about this. Jeremy From katzj at redhat.com Mon May 15 15:26:54 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 15 May 2006 11:26:54 -0400 Subject: Fedora Core package cleanup project In-Reply-To: <1147509045.6910.39.camel@atlantis.mpeters.local> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <1147509045.6910.39.camel@atlantis.mpeters.local> Message-ID: <1147706814.7705.8.camel@orodruin.boston.redhat.com> On Sat, 2006-05-13 at 01:30 -0700, Michael A. Peters wrote: > On Fri, 2006-05-12 at 17:42 -0400, Will Woods wrote: > > I'm announcing the start of a new QA project, and I'm asking for your > > help. > > > > In the past, Core packages have not been held to the same standards as > > Extras. We want to fix this! We're starting by cleaning up the spec > > files so that Core packages can all be built using Mock. > > I would like to see some tracker bug, like filesystem blockers. Anyone can really start a tracker bug -- so file a bug against 'distribution' with comments about tracking FHS compliance and then start making bugs block it. By doing so and publicizing it among people that are willing to help solve the problems, progress can be made. Jeremy From katzj at redhat.com Mon May 15 15:30:51 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 15 May 2006 11:30:51 -0400 Subject: Rawhide status In-Reply-To: <1147524185.2171.5.camel@scrappy.miketc.com> References: <1147524185.2171.5.camel@scrappy.miketc.com> Message-ID: <1147707052.7705.10.camel@orodruin.boston.redhat.com> On Sat, 2006-05-13 at 07:43 -0500, Mike Chambers wrote: > Traceback (most recent call last): > File "/usr/bin/anaconda", line 938, in ? > anaconda.intf.run(anaconda.id, anaconda.dispatch) > File "/usr/lib/anaconda/text.py", line 512, in run > rc = win(self.screen, anaconda) > File "/usr/lib/anaconda/textw/network_text.py", line 271, in __call__ > ns1Entry.set(network.primaryNS) > NameError: global name 'network' is not defined Went ahead and fixed this up Jeremy From katzj at redhat.com Mon May 15 15:32:14 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 15 May 2006 11:32:14 -0400 Subject: Rawhide status In-Reply-To: <1147604528.3904.6.camel@rivendell> References: <1147524185.2171.5.camel@scrappy.miketc.com> <1147604528.3904.6.camel@rivendell> Message-ID: <1147707134.7705.12.camel@orodruin.boston.redhat.com> On Sun, 2006-05-14 at 13:02 +0200, Kjartan Maraas wrote: > - Seems like some files are plain missing from rawhide. I installed the > FC5 versions of them and got up and running after a lot of manual trial > and error. The files are: libX11-* libXmu-* libXt-* This has been mentioned a few times I think and should be fixed now > - gdk-pixbuf.loaders and pango.modules were empty, causing a lot of > problems. Programs having problems were > referencing /etc/pango/pango.modules, but the file was > in /etc/pango/$arch or something? Is that the right place for them? Same > for gdk-pixbuf.loaders The files are probably empty because the scriptlets failed because of no libX11. Jeremy From katzj at redhat.com Mon May 15 15:34:33 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 15 May 2006 11:34:33 -0400 Subject: Optimizing kernel-devel In-Reply-To: References: Message-ID: <1147707273.7705.14.camel@orodruin.boston.redhat.com> On Sat, 2006-05-13 at 12:53 -0400, Sam Varshavchik wrote: > After drinking yet another half a dozen cups of tea while waiting for both > kernel-devel and kernel-devel-smp to install, I have an idea how to fix this > mess: [snip] > I'd be surprised if this will not speed things up by at least a factor of > 10. Doesn't sound unreasonable... want to provide a patch? :-) Jeremy From steve at silug.org Mon May 15 16:09:17 2006 From: steve at silug.org (Steven Pritchard) Date: Mon, 15 May 2006 11:09:17 -0500 Subject: weird firefox problem In-Reply-To: <1147694575.5250.39.camel@xpc.home.erwinrol.com> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> Message-ID: <20060515160917.GA18704@osiris.silug.org> On Mon, May 15, 2006 at 02:02:55PM +0200, Erwin Rol wrote: > Has anybody else ever seen this problem, or would it just be a messed up > firefox on my system ? I have been having the same problem every few days since upgrading to FC5. I did a little bit of poking around bugzilla.mozilla.org, but I didn't find any reports that looked like this problem. > BTW this is a 64bit AMD system. Same here, but I'm running a 32-bit firefox. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From emeric.maschino at jouy.inra.fr Mon May 15 16:52:22 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Mon, 15 May 2006 18:52:22 +0200 Subject: Problems with mcstrans In-Reply-To: <44688832.701@redhat.com> References: <20060515103051.75943.qmail@web51507.mail.yahoo.com> <44688832.701@redhat.com> Message-ID: <1147711942.4468b1c631c8b@www.jouy.inra.fr> > Turns out to be a 64 bit problem. libselinux was using 32 bit int, and > mctrans was expecting 64 bit int for size. > > Fixed version will be in tonights rawhide, available now at > > ftp://people.redhat.com/dwalsh/SELinux/Fedora I confirm that mcstrans-0.1.4-1.ia64.rpm available at the above location solved the problem on my Itanium workstation. Many thanks, ?meric From emeric.maschino at jouy.inra.fr Mon May 15 17:11:30 2006 From: emeric.maschino at jouy.inra.fr (=?iso-8859-1?b?yW1lcmlj?= Maschino) Date: Mon, 15 May 2006 19:11:30 +0200 Subject: Problems with mcstrans In-Reply-To: <1147711942.4468b1c631c8b@www.jouy.inra.fr> References: <20060515103051.75943.qmail@web51507.mail.yahoo.com> <44688832.701@redhat.com> <1147711942.4468b1c631c8b@www.jouy.inra.fr> Message-ID: <1147713090.4468b642abddc@www.jouy.inra.fr> > I confirm that mcstrans-0.1.4-1.ia64.rpm available at the above location > solved the problem on my Itanium workstation. Just a few AVCs: May 15 18:40:57 localhost kernel: audit(1147711245.436:4): avc: denied { read write } for pid=1573 comm="mcstransd" name="0" dev=devpts ino=2 scontext=system _u:system_r:setrans_t:s0 tcontext=system_u:object_r:initrc_devpts_t:s0 tclass=ch r_file May 15 18:40:57 localhost kernel: audit(1147711245.436:5): avc: denied { read write } for pid=1573 comm="mcstransd" name="0" dev=devpts ino=2 scontext=system _u:system_r:setrans_t:s0 tcontext=system_u:object_r:initrc_devpts_t:s0 tclass=ch r_file May 15 18:40:57 localhost kernel: audit(1147711245.436:6): avc: denied { read write } for pid=1573 comm="mcstransd" name="0" dev=devpts ino=2 scontext=system _u:system_r:setrans_t:s0 tcontext=system_u:object_r:initrc_devpts_t:s0 tclass=ch r_file May 15 18:40:57 localhost kernel: audit(1147711245.512:7): avc: denied { sys_r esource } for pid=1573 comm="mcstransd" capability=24 scontext=system_u:system_ r:setrans_t:s0 tcontext=system_u:system_r:setrans_t:s0 tclass=capability Cheers, ?meric From buildsys at redhat.com Tue May 16 08:32:31 2006 From: buildsys at redhat.com (Build System) Date: Tue, 16 May 2006 04:32:31 -0400 Subject: rawhide report: 20060516 changes Message-ID: <200605160832.k4G8WVk0011931@porkchop.devel.redhat.com> Removed package libsetrans Updated Packages: anaconda-11.1.0.11-1 -------------------- * Mon May 15 2006 Chris Lumens 11.1.0.11-1 - Fix anaconda class typos (katzj). - Unmount media after running post scripts (#191381). - Fix VNC installs. - Support --mtu= in kickstart files (#191328). - Rework release notes viewer (dcantrel). - Fix upgrade traceback. - Fix console keymaps (pjones, #190983, #191541). - Allow USB and firewire installs, with a warning (pjones). arts-8:1.5.2-2 -------------- * Mon May 15 2006 Than Ngo 8:1.5.2-2 - fix multilib issue authconfig-5.2.4-1 ------------------ * Fri May 12 2006 Tomas Mraz - 5.2.4-1 - added crond to the services restarted after firstboot (#187334) - when checking nscd status redirect output to /dev/null (#188555) * Tue Mar 21 2006 Tomas Mraz - 5.2.3-1 - make smb.conf and krb5.conf loading more robust (#185766) * Mon Feb 27 2006 Tomas Mraz - 5.2.2-1 - add try_first_pass option to pam_unix for better integration with individual service configurations (#182350) - updated translations bluez-utils-2.25-8 ------------------ * Mon May 15 2006 Dan Walsh - 2.25-8 * Add /var/lib/bluetooth to be owned by package coreutils-5.95-2 ---------------- * Mon May 15 2006 Tim Waugh 5.95-2 - 5.95. crash-4.0-2.26.4 ---------------- * Mon May 15 2006 Dave Anderson - 4.0-2.26.4 - Updated crash.patch such that is not #include'd by s390_dump.c; IBM did not make the file s390[s] only; BZ #192719 * Mon May 15 2006 Dave Anderson - 4.0-2.26.3 - Updated crash.patch such that is not #include'd by vas_crash.h; only ia64 build complained; BZ #191719 * Mon May 15 2006 Dave Anderson - 4.0-2.26.2 - Updated crash.patch such that is not #include'd by lkcd_x86_trace.c; also for BZ #191719 dasher-4.0.2-2.1 ---------------- * Mon May 15 2006 John (J5) Palmieri - 4.0.2-2.1 - bump and rebuild dbus-0.61-5.1 ------------- * Mon May 15 2006 John (J5) Palmieri - 0.61-5.1 - Bump and rebuild. Add a BR and R for libX11 desktop-printing-0.19-7.1 ------------------------- * Mon May 15 2006 John (J5) Palmieri - 0.19-7.1 - bump and rebuild * Tue Feb 21 2006 Than Ngo 0.19-7 - only show in GNOME evolution-sharp-0.11.1-1 ------------------------ * Mon May 15 2006 Matthew Barnes 0.11.1-1 - Update to 0.11.1 - Remove evolution-sharp-0.10.2-evolibdir.patch (fixed upstream). - Remove pkg-config hunk from evolution-sharp-evo26.patch (fixed upstream). - Add evolution-sharp-0.11.1-evo28.patch for compatibility with Evolution 2.8. expect-5.43.0-5 --------------- * Mon May 15 2006 David Cantrell - 5.43.0-5 - BuildRequires libX11-devel firstboot-1.4.8-2 ----------------- * Mon May 15 2006 Chris Lumens 1.4.8-2 - Require system-logos instead of an OS-specific package (#191407). gcc-4.1.0-17 ------------ * Sun May 14 2006 Jakub Jelinek 4.1.0-17 - make -mtune=z9-109 the default on s390{,x} (#184630) gkrellm-2.2.9-2 --------------- * Mon May 15 2006 Karsten Hopp 2.2.9-2 - fix header file conflict between 32bit and 64bit archs glib2-2.11.1-1 -------------- * Mon May 15 2006 Matthias Clasen - 2.11.1-1 - Update to 2.11.1 gnome-mag-0.12.4-1.1 -------------------- * Mon May 15 2006 John (J5) Palmieri - 0.12.4-1.1 - bump and rebuild gnome-mount-0.4-6 ----------------- * Mon May 15 2006 John (J5) Palmieri - 0.4-6 - Patch from Brian Pepple Add BR for gnome-keyring-devel & libgnomeui-devel. gnome-power-manager-2.15.2-1 ---------------------------- * Mon May 15 2006 John (J5) Palmieri - 2.15.2-1 - Update to upstream version 2.15.2 * Mon May 15 2006 John (J5) Palmieri - 2.15.1-3 - Add BR for desktop-file-utils * Mon May 15 2006 John (J5) Palmieri - 2.15.1-1.1 - bump and rebuild gnome-volume-manager-1.5.15-1.1 ------------------------------- * Mon May 15 2006 John (J5) Palmieri - 1.5.15-1.1 - bump and rebuild gnopernicus-1.0.4-2.2 --------------------- * Mon May 15 2006 John (J5) Palmieri - 1.0.4-2.1 - bump and rebuild gok-1.0.8-2.1 ------------- * Mon May 15 2006 John (J5) Palmieri - 1.0.8-2.1 - bump and rebuild hal-0.5.7-8 ----------- * Mon May 15 2006 John (J5) Palmieri - 0.5.7-8 - Patch from Brian Pepple Add BR for dbus-glib ipvsadm-1.24-8 -------------- * Mon May 15 2006 Phil Knirsch - 1.24-8 - Added missing prereq to chkconfig isdn4k-utils-3.2-46 ------------------- * Mon May 15 2006 Than Ngo 3.2-46 - fix #191754, buildrequire on libXext-devel jwhois-3.2.3-6 -------------- * Tue May 16 2006 Miloslav Trmac - 3.2.3-6 - Fix some uninitialized memory accesses - Fix a typo in the ipv6 patch kernel-2.6.16-1.2203_FC6 ------------------------ * Sun May 14 2006 Dave Jones - 2.6.17rc4-git2 libgnomecups-0.2.2-4 -------------------- * Mon May 15 2006 John (J5) Palmieri - 0.2.2-4 - Patch from n0dalus - add build requires libgpg-error-1.3-2 ------------------ * Mon May 15 2006 Karsten Hopp 1.3-2 - switch to pkgconfig so that gpg-error-config can be the same on 32bit and 64bit archs libsepol-1.12.10-1 ------------------ * Mon May 15 2006 Dan Walsh 1.12.10-1 - Upgrade to latest from NSA * Merged patch to revert role/user decl upgrade from Karl MacMillan. * Thu May 11 2006 Steve Grubb 1.12.9 - Couple minor spec file clean ups man-pages-2.32-1 ---------------- * Mon May 15 2006 Ivana Varekova 2.32-1 - update to 2.32 - add gai.conf.5 man page (#191656) * Tue Apr 18 2006 Ivana Varekova 2.29-1 - update to 2.29 - fix sigprocmask(2) man page (#189121) * Thu Mar 16 2006 Ivana Varekova 2.25-2 - fix MALLOC_CHECK_ description (#185502) mcstrans-0.1.4-2 ---------------- * Mon May 15 2006 Dan Walsh 0.1.4-1 - Add patch from sgrubb - Fix 64 bit size problems - Increase the open file limit - Make sure maximum size is not exceeded openCryptoki-2.2.4-1 -------------------- * Fri May 12 2006 Phil Knirsch - 2.2.4-1 - Updated to opencryptoki-2.2.4 (#184631) * Thu Feb 09 2006 Phil Knirsch - 2.1.6-3 - Updated openssl-devel buildprereq as we need a new version. pirut-1.0.3-1 ------------- * Mon May 15 2006 Jeremy Katz - 1.0.3-1 - fix plugin type bug (#191630) - keep apply at bottom of the window (#191721) - Catch config errors and give a nice dialog (#191013) - Allow --config with pirut (#189804) policycoreutils-1.30.9-2 ------------------------ * Mon May 15 2006 James Antill 1.30.9-2 - Add secon man page and prompt options. * Mon May 15 2006 Dan Walsh 1.30.9-1 - Update to upstream * Fixed audit2allow and po Makefiles for DESTDIR= builds. * Merged .po file patch from Dan Walsh. * Merged bug fix for genhomedircon. pykickstart-0.28-1 ------------------ * Mon May 15 2006 Chris Lumens 0.28-1 - Support --mtu for the network command (#191328). - Accept --isUtc for backwards compatibility. python-2.4.3-3 -------------- * Mon May 15 2006 Mihai Ibanescu - 2.4.3-3 - rebuilt to fix broken libX11 dependency * Wed Apr 12 2006 Jeremy Katz - 2.4.3-2 - rebuild with new gcc to fix #188649 * Thu Apr 06 2006 Mihai Ibanescu - 2.4.3-1 - Updated to 2.4.3 qt-1:3.3.6-4 ------------ * Mon May 15 2006 Than Ngo 1:3.3.6-4 - fix multilib issue scim-1.4.4-17 ------------- * Tue May 16 2006 Jens Petersen - 1.4.4-17 - update to scim-bridge 0.1.8 (#191329) - test factory-menu-singlet-submenus-187027.patch to avoid having language submenus for a single IME * Tue May 09 2006 Jens Petersen - 1.4.4-16 - update to scim-bridge 0.1.7 - improve qtimm setup in xinput.d file * Tue Apr 18 2006 Jens Petersen - 1.4.4-15 - scim-bridge-0.1.6 selinux-policy-2.2.39-2 ----------------------- * Mon May 15 2006 Dan Walsh 2.2.39-2 - Fixes for amavis * Mon May 15 2006 Dan Walsh 2.2.39-1 - Update from upstream stardict-2.4.5-2.4 ------------------ system-config-lvm-1.0.17-1.0 ---------------------------- * Fri May 12 2006 Stanko Kupcevic 1.0.17-1.0 - Fixes for 175077, 171117, 175131, 176967, enable mirroring, 159455, 159456 * Thu Feb 16 2006 Jim Parsons 1.0.16-1.0 - Disabled mirroring support in UI. * Tue Feb 14 2006 Stanko Kupcevic 1.0.14-1.0 - Fixes for bz180281, 159457, 180269. Mirroring support available with constants in lvmui_constants file by setting MIRRORING_UI_SUPPORT to True system-config-printer-0.7.8-1 ----------------------------- * Mon May 15 2006 Tim Waugh 0.7.8-1 - Updated to pycups-1.9.10. - Updated to system-config-printer-0.7.8. * Fri May 05 2006 Tim Waugh - Fix pycups segfault. tix-1:8.4.0-9 ------------- * Mon May 15 2006 David Cantrell - 1:8.4.0-9 - BuildRequires libX11-devel yelp-2.15.1-3 ------------- * Mon May 15 2006 Matthew Barnes - 2.15.1-3 - Bump mozilla_version from 1.7.12 to 1.7.13 (closes #190880). * Mon May 15 2006 Matthew Barnes - 2.15.1-2 - Add build requirements: startup-notification-devel libgnomeprintui22-devel libXt-devel Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From andy at warmcat.com Tue May 16 08:44:19 2006 From: andy at warmcat.com (Andy Green) Date: Tue, 16 May 2006 09:44:19 +0100 Subject: weird firefox problem In-Reply-To: <20060515160917.GA18704@osiris.silug.org> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> <20060515160917.GA18704@osiris.silug.org> Message-ID: <446990E3.7080209@warmcat.com> Steven Pritchard wrote: > On Mon, May 15, 2006 at 02:02:55PM +0200, Erwin Rol wrote: >> Has anybody else ever seen this problem, or would it just be a messed up >> firefox on my system ? > > I have been having the same problem every few days since upgrading to > FC5. > > I did a little bit of poking around bugzilla.mozilla.org, but I didn't > find any reports that looked like this problem. > >> BTW this is a 64bit AMD system. > > Same here, but I'm running a 32-bit firefox. Me too... there's a little gotcha there for updates actually... if you stick the i386 version of firefox on an x86_64 install then it won't get updated by yum update, since the yum.repos.d files are pointing to the x86_64 repos... I just updated mine by hand and we'll see if its any better. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From fedora at leemhuis.info Tue May 16 09:16:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 May 2006 11:16:23 +0200 Subject: weird firefox problem In-Reply-To: <446990E3.7080209@warmcat.com> References: <1147694575.5250.39.camel@xpc.home.erwinrol.com> <20060515160917.GA18704@osiris.silug.org> <446990E3.7080209@warmcat.com> Message-ID: <1147770983.2469.16.camel@thl.ct.heise.de> Am Dienstag, den 16.05.2006, 09:44 +0100 schrieb Andy Green: > Steven Pritchard wrote: > > On Mon, May 15, 2006 at 02:02:55PM +0200, Erwin Rol wrote: > >> BTW this is a 64bit AMD system. > > Same here, but I'm running a 32-bit firefox. > > Me too... there's a little gotcha there for updates actually... if you > stick the i386 version of firefox on an x86_64 install then it won't get > updated by yum update, since the yum.repos.d files are pointing to the > x86_64 repos... I just updated mine by hand and we'll see if its any better. Add a yum repo file to /etc/yum.repos.d with something like the below to get automatic updates for a i386 firefox on a x86_64 machine. --- [core-i386] enabled=1 name=Fedora Core $releasever - $basearch baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/i386/os/ gpgcheck=1 failovermethod=priority includepkgs=firefox libgnomeui libbonoboui libgnome [updates-released-i386] enabled=1 name=Fedora Core $releasever - i386 - Released Updates baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/i386/ gpgcheck=1 failovermethod=priority includepkgs=firefox libgnomeui libbonoboui libgnome --- But this is getting off topic here on the list. CU thl From hk at isphuset.no Tue May 16 11:56:19 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 16 May 2006 13:56:19 +0200 Subject: FC5 ISO Re-Spins In-Reply-To: <1147706209.7705.5.camel@orodruin.boston.redhat.com> References: <1146482913.2609.10.camel@compaqlaptop> <1146500938.29359.10.camel@cbcclt02.cbcchome.cbccgroup.com> <1146503003.810.62.camel@dhcp83-49.boston.redhat.com> <1146512306.29359.25.camel@cbcclt02.cbcchome.cbccgroup.com> <20060510220106.GA31836@neu.nirvana> <1147331106.28230.16.camel@linux> <1147706209.7705.5.camel@orodruin.boston.redhat.com> Message-ID: <1147780579.3247.1.camel@linux> On Mon, 2006-05-15 at 11:16 -0400, Jeremy Katz wrote: > On Thu, 2006-05-11 at 09:05 +0200, Hans Kristian Rosbach wrote: > > What I consider a bug however is that it does not just check arch and > > tell you it won't work. Would be much cleaner imho. > > If it's not in bugzilla... ;-) > > Seriously, file a bug and we can easily make it error out if you're > running on an incompatible arch. But I know that by the time I finish > catching up with mail, I will have forgotten about this. But what would I target it against? I'd like it (and other anaconda bugs) fixed in FC5 tree, but you'd probably only want to touch the rawhide tree.. -HK From hhoffman at ip-solutions.net Tue May 16 12:10:57 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 16 May 2006 08:10:57 -0400 Subject: FC5 Xen latest updates Message-ID: <4469C151.1010502@ip-solutions.net> Hi, Just installed FC5 w/Xen on a new box. After install I reboot and do a xm list and can see dom0. I run yum update and xend can no longer start. I've tried disabling SELINUX but to no avail. Any ideas? Thanks, Harry -- Harry Hoffman Integrated Portable Solutions, LLC 877.846.5927 ext 1000 http://www.ip-solutions.net/ From gianluca.cecchi at gmail.com Tue May 16 16:26:00 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 16 May 2006 18:26:00 +0200 Subject: question about creation of updated DVD iso Message-ID: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> I have read instructions at http://fedoranews.org/contributors/gene_czarcinski/update_distro/ I have basically one question: how to update the vmlinuz and initrd.img files to put under isolinux directory of CD/DVD, so that the installation kernel is the 2111 one and not the default 2054? Do I have to compile the kernel source rpm with any specific target? I remember in rh el 3 I was able to use a specific config file for the installation kernel... but it seems it is not here in Fedora. Is it the i586 one? And what about the initrd.img file generation? Thanks in advance for your answers. Bye, Gianluca From gianluca.cecchi at gmail.com Tue May 16 16:32:06 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 16 May 2006 18:32:06 +0200 Subject: FC5 Xen latest updates Message-ID: <561c252c0605160932s35b57705r43604d89822c73da@mail.gmail.com> On Tue, 16 May 2006 08:10:57 -0400 Harry Hoffman wrote: > I run yum update and xend can no longer start. See at these two bugs for FC5: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190899 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191237 In rawhide I think it is already fixed. Near coming 2118 kernel, or later, will fix it in FC5 too. I'm waiting for it too. Gianluca From docs-list at fedoralinks.org Tue May 16 17:15:35 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Tue, 16 May 2006 12:15:35 -0500 Subject: question about creation of updated DVD iso In-Reply-To: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> Message-ID: <446A08B7.3030202@fedoralinks.org> Gianluca Cecchi wrote: > I have read instructions at > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > I have basically one question: how to update the vmlinuz and > initrd.img files to put under isolinux directory of CD/DVD, so that > the installation kernel is the 2111 one and not the default 2054? > Do I have to compile the kernel source rpm with any specific target? > I remember in rh el 3 I was able to use a specific config file for the > installation kernel... > but it seems it is not here in Fedora. > Is it the i586 one? And what about the initrd.img file generation? > Thanks in advance for your answers. > Bye, > Gianluca > The instructions you have referenced will not work on Fedora Core 5, Anaconda has changed. The Fedora Unity Project (http://fedoraunity.org/) will be releasing updated "respun" ISOs with in the next week, the i386 has completed testing, once the x86_64 is tested they will be announcing on the announce list. Robert 'Bob' Jensen Fedora Documentation Project Fedora Release Notes Editor-In-Chief http://fedoraproject.org/wiki/BobJensen From docs-list at fedoralinks.org Tue May 16 17:03:43 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Tue, 16 May 2006 12:03:43 -0500 Subject: question about creation of updated DVD iso In-Reply-To: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> Message-ID: <446A05EF.1070201@fedoralinks.org> Gianluca Cecchi wrote: > I have read instructions at > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > I have basically one question: how to update the vmlinuz and > initrd.img files to put under isolinux directory of CD/DVD, so that > the installation kernel is the 2111 one and not the default 2054? > Do I have to compile the kernel source rpm with any specific target? > I remember in rh el 3 I was able to use a specific config file for the > installation kernel... > but it seems it is not here in Fedora. > Is it the i586 one? And what about the initrd.img file generation? > Thanks in advance for your answers. > Bye, > Gianluca > The instructions you have referenced will not work on Fedora Core 5, Anaconda has changed. The Fedora Unity Project (http://fedoraunity.org/) will be releasing updated "respun" ISOs with in the next week, the i386 has completed testing, once the x86_64 is tested they will be announcing on the announce list. Robert 'Bob' Jensen Fedora Documentation Project Fedora Release Notes Editor-In-Chief http://fedoraproject.org/wiki/BobJensen From Liste at famillecollet.com Tue May 16 17:06:42 2006 From: Liste at famillecollet.com (Remi Collet) Date: Tue, 16 May 2006 19:06:42 +0200 Subject: question about creation of updated DVD iso In-Reply-To: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> Message-ID: <446A06A2.10704@FamilleCollet.com> Gianluca Cecchi a ?crit : > I have read instructions at > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > I have basically one question: how to update the vmlinuz and > initrd.img files to put under isolinux directory of CD/DVD, so that > the installation kernel is the 2111 one and not the default 2054? It's the "buildinstall" job. So, nothing to do. From janina at rednote.net Tue May 16 19:08:39 2006 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 May 2006 15:08:39 -0400 Subject: python(abi) present, but blocking rpm -i Message-ID: <20060516190839.GA6168@rednote.net> I've built an rpm with a build dependency on python => 2.4. The buildrequires is explicitly stated in the .spec, and the build proceeds uneventfully. However, I cannot install the resulting rpm--on the very machine where I built it. The message is "requires python(abi)." Meanwhile: rpm -q --whatprovides "python(abi)" returns "python-2.4.2-3.2.1," which is installed. How can this be? Is this an rpm problem? A python problem? Or some kind of problem with my package source? Thanks in advance for any guidance. PS: The package is a new Gnome screen reader called Orcaunder active development by Sun. Janina Sajka Phone: +1.240.715.1272 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From saugart at mazunetworks.com Tue May 16 19:46:52 2006 From: saugart at mazunetworks.com (Steven Augart) Date: Tue, 16 May 2006 15:46:52 -0400 Subject: python(abi) present, but blocking rpm -i In-Reply-To: <20060516190839.GA6168@rednote.net> References: <20060516190839.GA6168@rednote.net> Message-ID: <1147808812.3627.12.camel@saugart-t41.mazunetworks.com> On Tue, 2006-05-16 at 15:08 -0400, Janina Sajka wrote: > I've built an rpm with a build dependency on python => 2.4. The > buildrequires is explicitly stated in the .spec, and the build proceeds > uneventfully. However, I cannot install the resulting rpm--on the very > machine where I built it. The message > is "requires python(abi)." Meanwhile: > > rpm -q --whatprovides "python(abi)" > > returns "python-2.4.2-3.2.1," which is installed. > > How can this be? Is this an rpm problem? A python problem? Or some kind > of problem with my package source? It certainly can't be a Python problem; it's got to be RPM or your source, and I'll hope it's your source. First of all, I'll assume you're using FC5, especially given your Python package rev number. Second, On my FC5 development machine, there are a number of packages that require python(abi) = 2.4, but I don't see any that use a "=>" operator the way you do. If it's good enough for them, perhaps it might be for you too. Third, if you're willing to settle for python(abi) = 2.4, then you might want to look at the source for one of those packages and copy the Requires line out of the .spec file directly via cut-and-paste, and see if that solves your problem. Fourth, if you want to get a list of the names of such packages, here's how to do it in Bash. (You could certainly figure it out yourself in a minute or two, but since I already wrote it, it's faster to cut-and-paste sometimes): rpm -q -a > rpm-q-a for r in $(< rpm-q-a ); do rpm -q --requires $r | fgrep "python(abi)" && echo "^^^^ PKG: $r" done From pemboa at gmail.com Tue May 16 20:59:36 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 16 May 2006 15:59:36 -0500 Subject: Where to start with making a device driver Message-ID: <16de708d0605161359k29362d93mcfd5fe5acd9cc866@mail.gmail.com> I have just purchased a Royal ezVue5 PDA (I don't exactly think it deserves the genre of PDA, but oh well) just for the sole purpose of writing a driver for it to connect to it LInux side via USB. Of course, it comes with a CD for Windows drivers. But.. not exactly a Windows person. I know some C++, and I am learning more (CS major). I prefer python, but would exactly say that I am better in it. I learned to code in Pascal/Delphi. So what I want to ask of this is where do I start? What do I read up on? What do I need, etc. I have been bored lately (waiting to get accepted to G-SOC) and this is the only interesting coding project that I could think of. Please advise. Arthur Pemberton BTW, if there is a better list for this, point me there. Just that Fedora is my distro of choice. -- To be updated... From dhollis at davehollis.com Tue May 16 21:27:59 2006 From: dhollis at davehollis.com (David Hollis) Date: Tue, 16 May 2006 17:27:59 -0400 Subject: Where to start with making a device driver In-Reply-To: <16de708d0605161359k29362d93mcfd5fe5acd9cc866@mail.gmail.com> References: <16de708d0605161359k29362d93mcfd5fe5acd9cc866@mail.gmail.com> Message-ID: <1147814879.2562.18.camel@dhollis-lnx.sunera.com> On Tue, 2006-05-16 at 15:59 -0500, Arthur Pemberton wrote: > I have just purchased a Royal ezVue5 PDA (I don't exactly think it > deserves the genre of PDA, but oh well) just for the sole purpose of > writing a driver for it to connect to it LInux side via USB. Of > course, it comes with a CD for Windows drivers. But.. not exactly a > Windows person. I know some C++, and I am learning more (CS major). I > prefer python, but would exactly say that I am better in it. I learned > to code in Pascal/Delphi. > > So what I want to ask of this is where do I start? What do I read up > on? What do I need, etc. I have been bored lately (waiting to get > accepted to G-SOC) and this is the only interesting coding project > that I could think of. Your best bet would be on the linux-usb-devel list. Being a USB PDA, it probably could be made to work with little fuss or muss with the usbnet driver, or maybe one of the gadget drivers. -- David Hollis -------------- 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 Frank at lists.sytes.net Tue May 16 23:11:41 2006 From: Frank at lists.sytes.net (Frank) Date: Wed, 17 May 2006 01:11:41 +0200 Subject: rpm broken ? Message-ID: <20060516230948.A6CEB76877@mail.figaro.fr> Today i noticed on FC5 with all updates: [root at client ~]# rpm rpm: error while loading shared libraries: libsqlite3.so.0: cannot open shared object file: Error 27 locate libsqlite3.so.0 /usr/lib/libsqlite3.so.0 /usr/lib/libsqlite3.so.0.8.6 [root at client ~]# Regards From rwwyatt01 at gmail.com Tue May 16 23:53:09 2006 From: rwwyatt01 at gmail.com (Randy Wyatt) Date: Tue, 16 May 2006 16:53:09 -0700 Subject: rpm broken ? In-Reply-To: <20060516230948.A6CEB76877@mail.figaro.fr> References: <20060516230948.A6CEB76877@mail.figaro.fr> Message-ID: <34e52d0c0605161653t7700d264r4cc68460f8d7604d@mail.gmail.com> On 5/16/06, Frank wrote: > Today i noticed on FC5 with all updates: > > [root at client ~]# rpm > rpm: error while loading shared libraries: libsqlite3.so.0: cannot open > shared object file: Error 27 > > locate libsqlite3.so.0 > /usr/lib/libsqlite3.so.0 > /usr/lib/libsqlite3.so.0.8.6 > [root at client ~]# > > Regards > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Are you running with SELINUX ? From smooge at gmail.com Wed May 17 02:04:19 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 16 May 2006 20:04:19 -0600 Subject: rpm broken ? In-Reply-To: <20060516230948.A6CEB76877@mail.figaro.fr> References: <20060516230948.A6CEB76877@mail.figaro.fr> Message-ID: <80d7e4090605161904h68aec408p2f53d88b42f84ab5@mail.gmail.com> On 5/16/06, Frank wrote: > Today i noticed on FC5 with all updates: > > [root at client ~]# rpm > rpm: error while loading shared libraries: libsqlite3.so.0: cannot open > shared object file: Error 27 > > locate libsqlite3.so.0 > /usr/lib/libsqlite3.so.0 > /usr/lib/libsqlite3.so.0.8.6 > [root at client ~]# > > Regards > The first thing to see is if selinux logged a problem? Look in dmesg or do a audit2allow -d to see if it caught any thing. I do not see any problems with updates myself at the moment on my 20 machines... but something local might have spewed stuff. More first step if selinux caught something is to check that the md5sum is ok (hard when rpm is what is needing it..) and then trying a restorecon -v /usr/lib/libsql* > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From rdieter at math.unl.edu Wed May 17 02:36:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 16 May 2006 21:36:43 -0500 Subject: rpm broken ? In-Reply-To: <20060516230948.A6CEB76877@mail.figaro.fr> References: <20060516230948.A6CEB76877@mail.figaro.fr> Message-ID: <446A8C3B.8070001@math.unl.edu> Frank wrote: > Today i noticed on FC5 with all updates: > > [root at client ~]# rpm > rpm: error while loading shared libraries: libsqlite3.so.0: cannot open > shared object file: Error 27 > > locate libsqlite3.so.0 > /usr/lib/libsqlite3.so.0 > /usr/lib/libsqlite3.so.0.8.6 > [root at client ~]# Try # /sbin/ldconfig -- Rex From davej at redhat.com Wed May 17 02:31:57 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 16 May 2006 22:31:57 -0400 Subject: FC5 Xen latest updates In-Reply-To: <4469C151.1010502@ip-solutions.net> References: <4469C151.1010502@ip-solutions.net> Message-ID: <20060517023157.GA30691@redhat.com> On Tue, May 16, 2006 at 08:10:57AM -0400, Harry Hoffman wrote: > Hi, > > Just installed FC5 w/Xen on a new box. After install I reboot and do a > xm list and can see dom0. > > I run yum update and xend can no longer start. I've tried disabling > SELINUX but to no avail. Is that running the 2111 kernel ? Seems that Xen broke :-/ Try the 2118 kernel from http://people.redhat.com/davej/kernels/Fedora/ (That'll go to updates-testing tomorrow, and all being well, updates-final shortly afterwards) Dave -- http://www.codemonkey.org.uk From buildsys at redhat.com Wed May 17 07:39:19 2006 From: buildsys at redhat.com (Build System) Date: Wed, 17 May 2006 03:39:19 -0400 Subject: rawhide report: 20060517 changes Message-ID: <200605170739.k4H7dJh3019784@porkchop.devel.redhat.com> Updated Packages: OpenIPMI-2.0.6-1 ---------------- * Tue May 16 2006 Phil Knirsch 2.0.6-1 - Fixed bug with type conversion in ipmitool (#191091) - Added python bindings - Split off perl and python bindings in separate subpackages - Dropped obsolete patches - Added missing buildprereq on readline-devel - Made it install the python bindings properly on 64bit archs * Mon May 15 2006 Phil Knirsch - Updated ipmitool to 1.8.8 - Updated OpenIPMI to 2.0.6 PyQt-3.16-2 ----------- * Tue May 16 2006 Karsten Hopp 3.16-2 - add some buildrequirements. anaconda-11.1.0.12-1 -------------------- * Tue May 16 2006 Jeremy Katz - 11.1.0.12-1 - Make mousedev loading less verbose for built-in case (#191814) - Ellipsize text (roozbeh, #191844) - Some more threads for release notes (dcantrel) - Remove lots of help related stuff (clumens) - Handle empty drive lists better looking for usb-storage and firewire (pjones) - Try to make ppc64 trees installable - Lots of cleanup to the scripts dir. apr-1.2.7-6 ----------- * Tue May 16 2006 Joe Orton 1.2.7-6 - BR e2fsprogs-devel for libuuid * Mon May 08 2006 Joe Orton 1.2.7-4 - use multilib parallel-installation wrapper hack for apr.h * Tue May 02 2006 Joe Orton 1.2.7-3 - fix installbuilddir in apr-1-config audit-1.2.2-2 ------------- * Tue May 16 2006 David Woodhouse 1.2.2-2 - Require kernel-headers, not glibc-kernheaders. Again. autoconf-2.59-8 --------------- * Tue May 16 2006 Karsten Hopp 2.59-8 - try to link with libX11 instead of libXt autofs-1:4.1.4-23 ----------------- * Tue May 16 2006 Ian Kent - 1:4.1.4-23 - add patch to ignore the "bg" and "fg" mount options as they aren't relevant for autofs mounts (bz #184386). bluez-utils-2.25-9 ------------------ * Tue May 16 2006 Karsten Hopp 2.25-9 - buildrequire libusb-devel, otherwise dfutool,avctrl,bccmd,hid2hci won't get built in a mock environment boost-1.33.1-6 -------------- * Tue May 16 2006 Karsten Hopp 1.33.1-6 - buildrequire python-devel for Python.h cadaver-0.22.3-3 ---------------- * Tue May 16 2006 Karsten Hopp 0.22.3-3 - buildrequires readline-devel cairo-1.1.6-6 ------------- * Tue May 16 2006 Karsten Hopp 1.1.6-6 - buildrequire libxml2-devel * Fri May 05 2006 Carl Worth - 1.1.6-2 - Refuse to build pdf2svg to avoid depending on newer poppler * Fri May 05 2006 Carl Worth - 1.1.6-1 - Update to new upstream 1.1.6 coreutils-5.95-3 ---------------- * Tue May 16 2006 Tim Waugh 5.95-3 - Upstream patch to fix cp -p when proc is not mounted (bug #190601). - BuildRequires libacl-devel. * Mon May 15 2006 Tim Waugh - Fixed pr in multibyte locales (bug #189663). cups-1:1.2.0-3 -------------- * Tue May 16 2006 Tim Waugh 1:1.2.0-3 - Added image library build requirements. - The devel package requires gnutls-devel (bug #191908). cyrus-sasl-2.1.21-12 -------------------- * Tue May 16 2006 Nalin Dahyabhai 2.1.21-12 - add conditionalized build dependency on openldap-devel (#191855) - patch md5global.h to be the same on all architectures dhcp-12:3.0.4-2 --------------- * Tue May 16 2006 Jason Vas Dias - 12:3.0.4-2 - Fix bug 191470: prevent dhcpd writing 8 byte dhcp-lease-time option in packets on 64-bit platforms * Sun May 14 2006 Jason Vas Dias - 12:3.0.4-2 - Add the libdhcp4client library package for use by the new libdhcp package, which enables dhclient to be invoked by programs in a single process from the library. The normal dhclient code is unmodified by this. * Mon May 08 2006 Jason Vas Dias - 12:3.0.4-2 - Add new dhclient command line argument: -V dmraid-1.0.0.rc11-FC6 --------------------- * Tue May 16 2006 Heinz Mauelshagen - 1.0.0.rc11-FC6 - rebuilt for FC6 with better tag * Tue May 16 2006 Heinz Mauelshagen - 1.0.0.rc11-FC5_7.2 - rebuilt for FC5 * Tue May 16 2006 Heinz Mauelshagen - 1.0.0.rc11-FC5_7.1 - jm.c: checksum() calculation - misc.c: support "%d" in p_fmt and fix segfault with wrong format identifier - nv.c: size fix in setup_rd() - activate.c: o striped devices could end on non-chunk boundaries o calc_region_size() calculated too small sizes causing large dirty logs in memory - isw.c: set raid5 type to left asymmetric - toollib.c: fixed 'No RAID...' message - support selection of RAID5 allocation algorithm in metadata format handlers - build gcalctool-5.8.13-1 ------------------ * Tue May 16 2006 Matthias Clasen 5.8.13-1 - Update to 5.8.13 glibc-kernheaders-3.0-32 ------------------------ * Tue May 16 2006 David Woodhouse 3.0-32 - Remove struct fddi_statistics from if_fdds.h (#192006) * Tue May 16 2006 David Woodhouse 3.0-31 - Update from 2.6.17-rc4. New S390 syscalls. - Add (#191883) gnome-games-1:2.15.1-2 ---------------------- * Tue May 16 2006 Ray Strode - 1:2.15.1-2 - Apply spec file patch from Hooman Mesgary to conditionallly compile out some of the games (bug 192001) gnome-icon-theme-2.15.2-1 ------------------------- * Tue May 16 2006 Matthias Clasen 2.15.2-1 - Update to 2.15.2 gnome-spell-1.0.7-2 ------------------- * Mon May 15 2006 Matthew Barnes - 1.0.7-2 - Own the /usr/lib/gnome-spell directory (closes #169278). * Mon May 15 2006 Matthew Barnes - 1.0.7-1 - Update to 1.0.7 - Disable pspell compatibility layer (added 3 years ago). - Update gnome-spell-1.0.4-multilib.patch and rename it to version 1.0.7. gnome-terminal-2.15.0-1 ----------------------- * Tue May 16 2006 Matthias Clasen 2.15.0-1 - Update to 2.15.0 gnome-themes-2.15.2-1 --------------------- * Tue May 16 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 gnutls-1.2.10-2 --------------- * Tue May 16 2006 Tomas Mraz - 1.2.10-2 - added missing buildrequires gtk2-2.9.1-1 ------------ * Tue May 16 2006 Matthias Clasen - 2.9.1-1 - Update to 2.9.1 * Mon May 08 2006 Matthias Clasen - 2.9.0-4 - Bump required versions of GLib, Pango and cairo - Add conflicts to force updating theme engine packages * Fri May 05 2006 Matthias Clasen - 2.9.0-1 - Update to 2.9.0 gtkhtml3-3.11.2-1 ----------------- * Tue May 16 2006 Matthew Barnes - 3.11.2-1 - Update to 3.11.2 guile-5:1.8.0-3 --------------- * Tue May 16 2006 Miroslav Lichvar - 5:1.8.0-3 - don't package .la files and static libraries (#191595) - move module .so files from devel to main package intltool-0.35.0-1 ----------------- * Tue May 16 2006 Matthias Clasen 0.35.0-1 - Update to 0.35.1 kdebase-6:3.5.2-9 ----------------- * Tue May 16 2006 Than Ngo 6:3.5.2-9 - fix 186425, KDE Terminal Sessions applet does not display konsole bookmarks * Fri May 12 2006 Than Ngo 6:3.5.2-8 - fix 190836, xmTextFieldClass widgets don't work properly - fix 153202, startkde gets wrong field from space_tmp/space_home with finnish kdelibs-6:3.5.2-4 ----------------- * Tue May 16 2006 Than Ngo 6:3.5.2-4 - rebuild against new qt to fix multilib issue - fix #178323, add KDE_IS_PRELINKED/KDE_NO_IPV60 kdenetwork-7:3.5.2-2 -------------------- * Tue May 16 2006 Than Ngo 7:3.5.2-2 - rebuilt againts new qt to fix multilib problem kernel-2.6.16-1.2204_FC6 ------------------------ * Tue May 16 2006 David Woodhouse - 2.6.17rc4-git3 libgcrypt-1.2.2-2 ----------------- * Tue May 16 2006 Nalin Dahyabhai 1.2.2-2 - remove file conflicts in libgcrypt-config by making the 64-bit version think the libraries are in /usr/lib (which is wrong, but which it also prunes from the suggest --libs output, so no harm done, hopefully) libofx-0.8.0-2.3 ---------------- * Mon May 15 2006 Brian Pepple - 0.8.0-2.3 - Add BR for curl-devel. libselinux-1.30.7-1 ------------------- * Tue May 16 2006 Dan Walsh 1.30.7-1 - Upgrade to latest from NSA * Merged setrans client cleanup patch from Steve Grubb. libusb-0.1.12-2 --------------- * Fri May 05 2006 Jindrich Novy 0.1.12-2 - add docbook-utils-pdf BuildRequires (#191744) * Mon Mar 06 2006 Jindrich Novy 0.1.12-1 - update to 0.1.12 - drop .format, .searchorder patches, applied upstream libwmf-0.2.8.4-8 ---------------- * Tue May 16 2006 Caolan McNamara 0.2.8.4-8 - rh#191971# BuildRequires mcstrans-0.1.5-1 ---------------- * Mon May 15 2006 Dan Walsh 0.1.5-1 - Fix sighup handling mozplugger-1.7.3-3 ------------------ * Tue May 16 2006 Than Ngo 1.7.3-3 - fix #191969, Missing BuildRequire on libXt-devel - adjust mozpluggerc for FC nano-1.3.11-1 ------------- * Tue May 16 2006 David Woodhouse - 1.3.11-1 - Update to 1.3.11 - BuildRequires: groff (#191946) nss_ldap-250-5 -------------- * Tue May 16 2006 Nalin Dahyabhai - 250-5 - adjust nss_ldap's makefile rule to more correctly deduce the right soversion for nsswitch modules (#191927) nut-2.0.3-2 ----------- * Tue May 16 2006 Than Ngo 2.0.3-2 - fix #191914, BR fontconfig-devel for cgi pam-0.99.4.0-2 -------------- * Tue May 16 2006 Tomas Mraz 0.99.4.0-2 - pam_console_apply shouldn't access /var when called with -r (#191401) - actually apply the large-uid patch - don't build hmactest in pam_timestamp so openssl-devel is not required - add missing buildrequires (#191915) * Wed May 10 2006 Tomas Mraz 0.99.4.0-1 - upgrade to new upstream version - make pam_console_apply not dependent on glib - support large uids in pam_tally, pam_tally2 * Thu May 04 2006 Tomas Mraz 0.99.3.0-5 - the namespace instance init script is now in /etc/security (#190148) - pam_namespace: added missing braces (#190026) - pam_tally(2): never call fclose twice on the same FILE (from upstream) pango-1.13.1-2 -------------- * Tue May 16 2006 Matthias Clasen - 1.13.1-2 - Update to 1.13.1 python-urlgrabber-2.9.9-1 ------------------------- * Tue May 16 2006 Jeremy Katz - 2.9.9-1 - update to 2.9.9 selinux-doc-1.26-1 ------------------ * Tue May 16 2006 Dan Walsh 1.26-1 - Update to NSA Release version * Updated version for release. selinux-policy-2.2.40-1 ----------------------- * Tue May 16 2006 Dan Walsh 2.2.40-1 - Update from upstream synaptics-0:0.14.4-7 -------------------- * Tue May 16 2006 Kristian H??gsberg - 0:0.14.4-7 - Add missing build requires for libXext. tn5250-0.17.3-2 --------------- * Tue May 16 2006 Karsten Hopp 0.17.3-2 - add buildrequirement openssl-devel (#191875, Andreas Thienemann) transfig-1:3.2.4-15 ------------------- * Tue May 16 2006 Than Ngo 3.2.4-15 - fix #164140, transfig creates wrong dependencies for -L pstex * Tue May 16 2006 Than Ngo 3.2.4-14 - fix #191825, buildrequire on imake - fix #173748, fig2dev still refers to /usr/X11R6/lib/X11/rgb.txt tvtime-1.0.1-5 -------------- * Tue May 16 2006 Than Ngo 1.0.1-5 - add BR on libXt-devel * Mon Feb 27 2006 Than Ngo 1.0.1-4 - fix post install script error #182895 xfig-3.2.4-21 ------------- * Tue May 16 2006 Than Ngo 3.2.4-21 - fix #191816, Xaw3d build problem xorg-x11-drv-fbdev-0.2.0-2 -------------------------- * Tue May 16 2006 Adam Jackson 0.2.0-2 - Move debugging output from compile-time option to run-time option. zenity-2.15.2-1 --------------- * Tue May 16 2006 Matthias Clasen 2.15.2-1 - Update to 2.15.2 - Remove po/LINGUAS fixes Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 From Frank at lists.sytes.net Wed May 17 10:33:44 2006 From: Frank at lists.sytes.net (Frank) Date: Wed, 17 May 2006 12:33:44 +0200 Subject: rpm broken ? In-Reply-To: <34e52d0c0605161653t7700d264r4cc68460f8d7604d@mail.gmail.com> References: <20060516230948.A6CEB76877@mail.figaro.fr> <34e52d0c0605161653t7700d264r4cc68460f8d7604d@mail.gmail.com> Message-ID: <20060517103154.8793F76877@mail.figaro.fr> > On 5/16/06, Frank wrote: > > Today i noticed on FC5 with all updates: > > > > [root at client ~]# rpm > > rpm: error while loading shared libraries: libsqlite3.so.0: cannot open > > shared object file: Error 27 > > > > locate libsqlite3.so.0 > > /usr/lib/libsqlite3.so.0 > > /usr/lib/libsqlite3.so.0.8.6 > > [root at client ~]# > > > > Regards > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Are you running with SELINUX ? > NO [root at client ~]# audit2allow -d /usr/bin/audit2allow: No AVC messages found. [root at client ~]# restorecon -v /usr/lib/libsql* [root at client ~]# /sbin/ldconfig The Problem still persists: [root at client ~]# rpm rpm: error while loading shared libraries: libsqlite3.so.0: cannot open shared object file: Error 27 iam unable to use yum, iam unable to install anything with rpm what is this ? From fedora at wir-sind-cool.org Wed May 17 11:18:55 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 17 May 2006 13:18:55 +0200 Subject: python(abi) present, but blocking rpm -i In-Reply-To: <20060516190839.GA6168@rednote.net> References: <20060516190839.GA6168@rednote.net> Message-ID: <20060517131855.259fa60d.fedora@wir-sind-cool.org> On Tue, 16 May 2006 15:08:39 -0400, Janina Sajka wrote: > I've built an rpm with a build dependency on python => 2.4. The > buildrequires is explicitly stated in the .spec, and the build proceeds > uneventfully. However, I cannot install the resulting rpm--on the very > machine where I built it. The message > is "requires python(abi)." The full and unmodified error message may be relevant. Your quoted error message contains a period at the end which could be a cut'n'paste error, a mistake in the .spec file or the result of even a different bug. You can also show us the output of: rpm -q --requires your-binary-rpm-here > Meanwhile: > > rpm -q --whatprovides "python(abi)" > > returns "python-2.4.2-3.2.1," which is installed. From fedora at wir-sind-cool.org Wed May 17 11:20:53 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 17 May 2006 13:20:53 +0200 Subject: rpm broken ? In-Reply-To: <446A8C3B.8070001@math.unl.edu> References: <20060516230948.A6CEB76877@mail.figaro.fr> <446A8C3B.8070001@math.unl.edu> Message-ID: <20060517132053.00c21bd3.fedora@wir-sind-cool.org> On Tue, 16 May 2006 21:36:43 -0500, Rex Dieter wrote: > Frank wrote: > > Today i noticed on FC5 with all updates: > > > > [root at client ~]# rpm > > rpm: error while loading shared libraries: libsqlite3.so.0: cannot open > > shared object file: Error 27 > > > > locate libsqlite3.so.0 > > /usr/lib/libsqlite3.so.0 > > /usr/lib/libsqlite3.so.0.8.6 > > [root at client ~]# > > Try > # /sbin/ldconfig But "Error 27"? That is "File too large", provided that it isn't supposed to be a custom error number. From thingsmith at comcast.net Wed May 17 11:43:02 2006 From: thingsmith at comcast.net (Harry Smith) Date: Wed, 17 May 2006 04:43:02 -0700 Subject: FC5 and IBM x366 Video Problem Message-ID: <6.2.5.6.2.20060517043739.01e220c0@comcast.net> I have been given a couple of IBM e-Series x 366 machines to use for a project. I can install FC5 x86-64 with no problems. It detects a ATI 7000 /7100 video card and on first boot everything seem fine. When I reboot, I am hitting the black screen of nothing. Are there any problems with FC5 or ATI driver on the IBM x366 ? Thanks Harry Smith From nphilipp at redhat.com Wed May 17 12:24:33 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 17 May 2006 14:24:33 +0200 Subject: python(abi) present, but blocking rpm -i In-Reply-To: <20060517131855.259fa60d.fedora@wir-sind-cool.org> References: <20060516190839.GA6168@rednote.net> <20060517131855.259fa60d.fedora@wir-sind-cool.org> Message-ID: <1147868674.2458.14.camel@gibraltar.stuttgart.redhat.com> On Wed, 2006-05-17 at 13:18 +0200, Michael Schwendt wrote: > On Tue, 16 May 2006 15:08:39 -0400, Janina Sajka wrote: > > > I've built an rpm with a build dependency on python => 2.4. The > > buildrequires is explicitly stated in the .spec, and the build proceeds > > uneventfully. However, I cannot install the resulting rpm--on the very > > machine where I built it. The message > > is "requires python(abi)." > > The full and unmodified error message may be relevant. Your quoted error > message contains a period at the end which could be a cut'n'paste error, > a mistake in the .spec file or the result of even a different bug. > > You can also show us the output of: > > rpm -q --requires your-binary-rpm-here rather: rpm -qp --requires Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From katzj at redhat.com Wed May 17 18:07:59 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 17 May 2006 14:07:59 -0400 Subject: Heads-up: Requiring PAE for running Xen Message-ID: <1147889279.13113.22.camel@aglarond.local> As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are 1) Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels 2) Switch the 32-bit xen kernels to require PAE. For most "current" non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :) Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all. Jeremy From dwmw2 at infradead.org Wed May 17 20:42:26 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 17 May 2006 21:42:26 +0100 Subject: Do not BuildRequires: glibc-kernheaders In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <1147898546.8013.12.camel@shinybook.infradead.org> The glibc-kernheaders packages provides 'kernel-headers'. If you need to require a specific _version_, you should use that. But if you just need to require that it exists, you don't need to do anything -- the standard gcc development packages depend on it. If there's a file missing from /usr/include/linux or /usr/include/asm when you try to build, that's either a bug in the glibc-kernheaders package, or a bug in the package you're trying to build. If it's a kernel header you _should_ be using from userspace, assume the former and file a bug against glibc-kernheaders. If the latter, fix it not to include kernel headers. Do _NOT_ add 'BuildRequires: glibc-kernheaders' to any packages. That will break. Soon. -- dwmw2 From jochen.wiedmann at gmail.com Wed May 17 20:48:43 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Wed, 17 May 2006 22:48:43 +0200 Subject: Sun JRE or JDK to enter core, or at least extras? Message-ID: <446B8C2B.8050003@gmail.com> Hi, any comments on http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? I understand this as an indicator, that the Sun JDK and JRE should now be distributable via Fedora Core or Extras? If so, I would very much like to see this. Regards, Jochen From windenntw at gmail.com Wed May 17 20:49:03 2006 From: windenntw at gmail.com (Antonio Vargas) Date: Wed, 17 May 2006 22:49:03 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1147889279.13113.22.camel@aglarond.local> References: <1147889279.13113.22.camel@aglarond.local> Message-ID: <69304d110605171349o65d40cadn7d63fd869b341e83@mail.gmail.com> On 5/17/06, Jeremy Katz wrote: > As we move forward with Xen enablement, there's a desire for > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > options for handling this are > 1) Another kernel. This is bad due to > a) we're running out of CD space already > b) keeping things matched up between the HV and the guest kernels > c) migration is worlds of pain with two types of kernels > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > non-laptop hardware, this is a non-issue. It does mean that xen won't > work a lot of earlier PentiumM laptops > 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of > RAM > 4) Make the PAE code handled at runtime. This is a pretty non-trivial > amount of work :) > > Given these, we're looking at going with #2 and thus only having Xen > work on PAE-capable hardware in the development tree. And we're > planning to try to execute this switchover the beginning of next week. > Note that this will not affect bare metal installs at all. > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > xen always needed p6 hardware (didnt run on k6-II for example), and AFAIK p6 supports PAE always, so not any lose here i think -- Greetz, Antonio Vargas aka winden of network http://wind.codepixel.com/ windNOenSPAMntw at gmail.com thesameasabove at amigascne.org Every day, every year you have to work you have to study you have to scene. From skvidal at linux.duke.edu Wed May 17 20:56:11 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 17 May 2006 16:56:11 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446B8C2B.8050003@gmail.com> References: <446B8C2B.8050003@gmail.com> Message-ID: <1147899371.12565.22.camel@cutter> On Wed, 2006-05-17 at 22:48 +0200, Jochen Wiedmann wrote: > Hi, > > any comments on > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > I understand this as an indicator, that the Sun JDK and JRE should now > be distributable via Fedora Core or Extras? If so, I would very much > like to see this. > it is not free software. fedora is about free software: http://fedoraproject.org/wiki/Overview#head-c12f7664badb48c91c2cf8547a450fcaed001de0 -sv From mpeters at mac.com Wed May 17 21:01:59 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 14:01:59 -0700 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446B8C2B.8050003@gmail.com> References: <446B8C2B.8050003@gmail.com> Message-ID: <1147899719.20963.42.camel@atlantis.mpeters.local> On Wed, 2006-05-17 at 22:48 +0200, Jochen Wiedmann wrote: > Hi, > > any comments on > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > I understand this as an indicator, that the Sun JDK and JRE should now > be distributable via Fedora Core or Extras? If so, I would very much > like to see this. > > Regards, > > Jochen > I'm not sure, but I think the license is still not sufficiently open for inclusion in Core. It might be open enough for livna or (preferably) JPackage. Also, I don't think they provide a proper 64-bit or PPC package, whearas Red Hat and friends are working on a stack that does, a stack that is open. From mpeters at mac.com Wed May 17 21:09:49 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 17 May 2006 14:09:49 -0700 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446B8C2B.8050003@gmail.com> References: <446B8C2B.8050003@gmail.com> Message-ID: <1147900189.20963.45.camel@atlantis.mpeters.local> On Wed, 2006-05-17 at 22:48 +0200, Jochen Wiedmann wrote: > Hi, > > any comments on > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > I understand this as an indicator, that the Sun JDK and JRE should now > be distributable via Fedora Core or Extras? If so, I would very much > like to see this. This pretty much kills it: 2c. ``you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software'' -=- Looking on the JPackage list, they are not interested in it either - and seem to be quite surprised at the Sun claim that they were "working with JPackage" in their FAQ. The word "lie" seemed to come up more than once. From jkeating at redhat.com Wed May 17 21:38:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 May 2006 17:38:22 -0400 Subject: Development push delayed tonight Message-ID: <1147901902.7823.25.camel@dhcp83-49.boston.redhat.com> The automated development push has been disabled for tonight (tomorrow morning). This is so that I can push it by hand and introduce the new layout. Specifically so that I can fix things if they break when pushing the new layout. Target arrival of the development tree on the mirrors is 11:00am Eastern Daylight Time (EDT). -- 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 Axel.Thimm at ATrpms.net Wed May 17 21:42:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 17 May 2006 23:42:43 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1147889279.13113.22.camel@aglarond.local> References: <1147889279.13113.22.camel@aglarond.local> Message-ID: <20060517214243.GC17312@neu.nirvana> On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > As we move forward with Xen enablement, there's a desire for > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > options for handling this are > 1) Another kernel. This is bad due to > a) we're running out of CD space already > b) keeping things matched up between the HV and the guest kernels > c) migration is worlds of pain with two types of kernels > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > non-laptop hardware, this is a non-issue. It does mean that xen won't > work a lot of earlier PentiumM laptops How do I know if my laptop if affected? :) > 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of > RAM > 4) Make the PAE code handled at runtime. This is a pretty non-trivial > amount of work :) > > Given these, we're looking at going with #2 and thus only having Xen > work on PAE-capable hardware in the development tree. And we're > planning to try to execute this switchover the beginning of next week. > Note that this will not affect bare metal installs at all. > > Jeremy > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Wed May 17 21:48:03 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 17 May 2006 16:48:03 -0500 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <1147900189.20963.45.camel@atlantis.mpeters.local> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> Message-ID: <20060517214803.GF1164619@hiwaay.net> Once upon a time, Michael A. Peters said: > On Wed, 2006-05-17 at 22:48 +0200, Jochen Wiedmann wrote: > > any comments on > > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > > I understand this as an indicator, that the Sun JDK and JRE should now > > be distributable via Fedora Core or Extras? If so, I would very much > > like to see this. > > This pretty much kills it: > > 2c. ``you do not combine, configure or distribute the Software to run in > conjunction with any additional software that implements the same or > similar functionality or APIs as the Software'' The DLJ FAQ also has these interesting statements: - Distribute the entire JDK - no subsetting. Note - the README file has the specifics of what you must distribute, and what can be omitted. Fedora couldn't split it up into sub-packages unless they all depended on each other (all or nothing). - Use the JDK only to design, develop, test, and run Java programs on your OS - you may not use it or parts of it for other purposes. "your OS" - can I install Fedora with a JDK and develop Java programs for Windows? - Present for acceptance any end user licenses that are part of the JDK, if such licenses are included in the generic install bundle provided to you for repackaging. Click-through license required - not acceptable, especially during install (how would an automated kickstart even do this?). - Indemnify Sun against claims arising from your OS or your violation of the DLJ (or any applicable law) Note that you are not responsible for changes made to your OS distribution by downstream users or distributors when such changes are out of your control. I don't think Fedora is going to indemnify anyone. - Ship only a compatible JDK on your OS. If notified of an incompatibility, you must correct it and offer a patch or replacement to downstream recipients within 90 days, or stop shipment and notify downstream recipients. If Sun notifies Fedora of an incompatibility in a release after that release is end-of-life, Fedora still has to release an update or withdraw Java for that release (since Fedora Legacy is currently run by others it may not qualify). > Looking on the JPackage list, they are not interested in it either - and > seem to be quite surprised at the Sun claim that they were "working with > JPackage" in their FAQ. The word "lie" seemed to come up more than once. The only reference to jpackage I see is "We are looking forward to collaborating with jpackage.org ...". I don't see anything that says they already were working with them. This is all aside from the fact that Fedora is about Open Source software (which Sun's JDK/JRE are still not). Even if that changed, the above problems would appear to make it impossible to include it in Fedora. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dwmw2 at infradead.org Wed May 17 21:46:22 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 17 May 2006 23:46:22 +0200 Subject: Do not BuildRequires: glibc-kernheaders In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <000001c679fb$56947580$ba00000a@grecom.local> The glibc-kernheaders packages provides 'kernel-headers'. If you need to require a specific _version_, you should use that. But if you just need to require that it exists, you don't need to do anything -- the standard gcc development packages depend on it. If there's a file missing from /usr/include/linux or /usr/include/asm when you try to build, that's either a bug in the glibc-kernheaders package, or a bug in the package you're trying to build. If it's a kernel header you _should_ be using from userspace, assume the former and file a bug against glibc-kernheaders. If the latter, fix it not to include kernel headers. Do _NOT_ add 'BuildRequires: glibc-kernheaders' to any packages. That will break. Soon. -- dwmw2 -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From jkeating at redhat.com Wed May 17 21:46:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 May 2006 23:46:22 +0200 Subject: Development push delayed tonight Message-ID: <000201c679fb$56cb6400$ba00000a@grecom.local> The automated development push has been disabled for tonight (tomorrow morning). This is so that I can push it by hand and introduce the new layout. Specifically so that I can fix things if they break when pushing the new layout. Target arrival of the development tree on the mirrors is 11:00am Eastern Daylight Time (EDT). -- 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: -------------- next part -------------- -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From jkeating at redhat.com Wed May 17 21:46:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 May 2006 23:46:23 +0200 Subject: Development push delayed tonight Message-ID: <000701c679fb$5712f450$ba00000a@grecom.local> The automated development push has been disabled for tonight (tomorrow morning). This is so that I can push it by hand and introduce the new layout. Specifically so that I can fix things if they break when pushing the new layout. Target arrival of the development tree on the mirrors is 11:00am Eastern Daylight Time (EDT). -- 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: -------------- next part -------------- -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From wtogami at redhat.com Wed May 17 22:04:29 2006 From: wtogami at redhat.com (Warren Togami) Date: Wed, 17 May 2006 18:04:29 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <20060517214803.GF1164619@hiwaay.net> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> Message-ID: <446B9DED.2080101@redhat.com> Chris Adams wrote: > The only reference to jpackage I see is "We are looking forward to > collaborating with jpackage.org ...". I don't see anything that says > they already were working with them. > If there is anything positive about this news, it looks theoretically possible that jpackage.org could distribute the JDK directly instead of requiring people to build their own RPM from .spec. Aside from this, yes, Fedora distributes only 100% Free and Open Source Software. And Red Hat continues its goal of implementing the entire Java stack as FOSS, in gcj + Classpath. Do not sacrifice liberty for a little short-term convenience. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Wed May 17 22:14:58 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 17 May 2006 18:14:58 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <20060517214803.GF1164619@hiwaay.net> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> Message-ID: <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> On 5/17/06, Chris Adams wrote: > - Present for acceptance any end user licenses that are part of the > JDK, if such licenses are included in the generic install bundle > provided to you for repackaging. > > Click-through license required - not acceptable, especially during > install (how would an automated kickstart even do this?). If the same trick the rpms for flash use is acceptable, then there isnt a problem. The flash rpms detect if there is a valid X display available, if there is there is a click through window with a timeout. If that window times out or if there is no X display to attach to, the package install completes but flash is left unconfigured until the license agreement process is run again manually. Whether or not that is acceptable is a question Sun will have to answer. -jef"not holding his breath"spaleta From jreiser at BitWagon.com Wed May 17 22:27:51 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 17 May 2006 15:27:51 -0700 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060517214243.GC17312@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060517214243.GC17312@neu.nirvana> Message-ID: <446BA367.5000100@BitWagon.com> > How do I know if my laptop if affected? :) $ grep ' pae ' < /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm So that machine has the necessary harware. If ' pae ' is missing, then such a machine does not have good enough hardware. -- From cmadams at hiwaay.net Wed May 17 22:28:33 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 17 May 2006 17:28:33 -0500 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> Message-ID: <20060517222833.GA731374@hiwaay.net> Once upon a time, Jeff Spaleta said: > On 5/17/06, Chris Adams wrote: > > - Present for acceptance any end user licenses that are part of the > > JDK, if such licenses are included in the generic install bundle > > provided to you for repackaging. > > > >Click-through license required - not acceptable, especially during > >install (how would an automated kickstart even do this?). > > If the same trick the rpms for flash use is acceptable, then there > isnt a problem. Somewhere I think it said the license had to be accepted "before install". > -jef"not holding his breath"spaleta Given all the other issues, I don't think it really matters. The conflict with GCJ and such is a much bigger issue; I don't see Fedora dropping GCJ or the alternatives system that allows either GCJ or the Sun JDK for development. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Axel.Thimm at ATrpms.net Wed May 17 22:31:09 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 18 May 2006 00:31:09 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <446BA367.5000100@BitWagon.com> References: <1147889279.13113.22.camel@aglarond.local> <20060517214243.GC17312@neu.nirvana> <446BA367.5000100@BitWagon.com> Message-ID: <20060517223109.GF17312@neu.nirvana> On Wed, May 17, 2006 at 03:27:51PM -0700, John Reiser wrote: > > How do I know if my laptop if affected? :) > > $ grep ' pae ' < /proc/cpuinfo > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > > So that machine has the necessary harware. If ' pae ' is missing, > then such a machine does not have good enough hardware. That already kills my 1 1/2 year old laptop :( -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Wed May 17 22:32:22 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 17 May 2006 17:32:22 -0500 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446B9DED.2080101@redhat.com> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <446B9DED.2080101@redhat.com> Message-ID: <20060517223221.GB731374@hiwaay.net> Once upon a time, Warren Togami said: > If there is anything positive about this news, it looks theoretically > possible that jpackage.org could distribute the JDK directly instead of > requiring people to build their own RPM from .spec. I don't know if even that will be possible. The click-through license, the restriction on alternatives, and the requirement for "all or nothing" (while jpackage splits it up some) may all be killers. To me, this looks like yet another half-step from Sun to try to look good. They do something like that every year or so, without ever really accomplishing anything. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dwmw2 at infradead.org Wed May 17 21:46:22 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 17 May 2006 23:46:22 +0200 Subject: Do not BuildRequires: glibc-kernheaders In-Reply-To: <1147470120.18573.7.camel@metroid.rdu.redhat.com> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> Message-ID: <000101c679fb$56b39640$ba00000a@grecom.local> The glibc-kernheaders packages provides 'kernel-headers'. If you need to require a specific _version_, you should use that. But if you just need to require that it exists, you don't need to do anything -- the standard gcc development packages depend on it. If there's a file missing from /usr/include/linux or /usr/include/asm when you try to build, that's either a bug in the glibc-kernheaders package, or a bug in the package you're trying to build. If it's a kernel header you _should_ be using from userspace, assume the former and file a bug against glibc-kernheaders. If the latter, fix it not to include kernel headers. Do _NOT_ add 'BuildRequires: glibc-kernheaders' to any packages. That will break. Soon. -- dwmw2 -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From thuforuk at yahoo.co.uk Wed May 17 23:23:41 2006 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Thu, 18 May 2006 00:23:41 +0100 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <20060517222833.GA731374@hiwaay.net> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> <20060517222833.GA731374@hiwaay.net> Message-ID: <446BB07D.5090605@yahoo.co.uk> On 05/17/2006 11:28 PM, Chris Adams wrote: > Once upon a time, Jeff Spaleta said: >> On 5/17/06, Chris Adams wrote: >> -jef"not holding his breath"spaleta > > Given all the other issues, I don't think it really matters. The > conflict with GCJ and such is a much bigger issue; I don't see Fedora > dropping GCJ or the alternatives system that allows either GCJ or the > Sun JDK for development. According to this note by Simon Phipps that's not true: http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something#comment3 Quotation from the comment: "No, it's OK to distribute along with GCJ, GNU/Classpath and so on - that was one of the explicit intents of the new license as that was previously the chief obstacle to distribution with GNU/Linux." More details at http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something Regards, Dariusz Send instant messages to your online friends http://uk.messenger.yahoo.com From bojan at rexursive.com Thu May 18 00:01:06 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 18 May 2006 00:01:06 +0000 (UTC) Subject: Sun JRE or JDK to enter core, or at least extras? References: <446B8C2B.8050003@gmail.com> Message-ID: Jochen Wiedmann gmail.com> writes: > any comments on > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml? This a proprietary piece of software and it doesn't belong in FC/FE. In a sad twist of irony, the owners claim to be "inventors of open source". -- Bojan From toshio at tiki-lounge.com Thu May 18 00:14:47 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 17 May 2006 17:14:47 -0700 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446BB07D.5090605@yahoo.co.uk> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> <20060517222833.GA731374@hiwaay.net> <446BB07D.5090605@yahoo.co.uk> Message-ID: <1147911287.3154.28.camel@localhost> On Thu, 2006-05-18 at 00:23 +0100, Dariusz J. Garbowski wrote: > On 05/17/2006 11:28 PM, Chris Adams wrote: > > I don't think it really matters. The > > conflict with GCJ and such is a much bigger issue; I don't see Fedora > > dropping GCJ or the alternatives system that allows either GCJ or the > > Sun JDK for development. > > According to this note by Simon Phipps that's not true: > > http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something#comment3 > > Quotation from the comment: > > "No, it's OK to distribute along with GCJ, GNU/Classpath and so on - > that was one of the explicit intents of the new license as that was > previously the chief obstacle to distribution with GNU/Linux." > > More details at > http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something > Unfortunately there's a glaring disconnect between what the license says and what the Sun people think it says. The things the Sun people are saying and the FAQ says are encouraging but they are quite plainly at odds with the License. Since the license is legally binding whereas the FAQ and what the developers say is not, this new software license is not very helpful to Jpackage[1] or Debian[2]. When Sun responds to what JPackage and Debian's licensing issues with a better license we may see some progress. Also, no matter how you cut this license, it's not open source so the discussion definitely does not belong on fedora-devel (Fedora is committed to building from 100% open source software.) There are a variety of other distributions, repositories, or Sun linux-community-portal-sites which would be more appropriate for discussing the intent of the new license versus its actual content. [1] https://www.zarb.org/pipermail/jpackage-discuss/2006-May/thread.html#9914 [2] http://lists.debian.org/debian-legal/2006/05/threads.html#00064 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Thu May 18 00:16:00 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Thu, 18 May 2006 12:16:00 +1200 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446B9DED.2080101@redhat.com> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <446B9DED.2080101@redhat.com> Message-ID: <446BBCC0.8060609@knox.net.nz> Warren Togami wrote: > Do not sacrifice liberty for a little short-term convenience. +100 Well said. Michael From tjb at unh.edu Thu May 18 00:21:56 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 17 May 2006 20:21:56 -0400 Subject: Recent AIGLX Breakage? Message-ID: <1147911717.3434.9.camel@continuity> I had aiglx working fine on my laptop for quite a while now. I've got a ATI Technologies Inc Radeon R250 Lf [FireGL 9000] but within the last week, I've succumb to the everything-is-blue-with-metacity-compositing enabled bug. Anyone else had it working and then have it recently break? tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From jkeating at j2solutions.net Thu May 18 00:25:59 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 17 May 2006 20:25:59 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <446BA367.5000100@BitWagon.com> References: <1147889279.13113.22.camel@aglarond.local> <20060517214243.GC17312@neu.nirvana> <446BA367.5000100@BitWagon.com> Message-ID: <1147911959.14185.8.camel@ender> On Wed, 2006-05-17 at 15:27 -0700, John Reiser wrote: > $ grep ' pae ' < /proc/cpuinfo > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm > > So that machine has the necessary harware. If ' pae ' is missing, > then such a machine does not have good enough hardware. This is not entirely true. At least one laptop within Red Hat does NOT advertise PAE, but boots the kernel just fine (when the checking for pae in said file is disabled). So it would seem that there are chips out there that LIE about what they can do :/ -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thuforuk at yahoo.co.uk Thu May 18 00:29:28 2006 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Thu, 18 May 2006 01:29:28 +0100 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <1147911287.3154.28.camel@localhost> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> <20060517222833.GA731374@hiwaay.net> <446BB07D.5090605@yahoo.co.uk> <1147911287.3154.28.camel@localhost> Message-ID: <446BBFE8.7000009@yahoo.co.uk> On 05/18/2006 01:14 AM, Toshio Kuratomi wrote: > On Thu, 2006-05-18 at 00:23 +0100, Dariusz J. Garbowski wrote: >> >> More details at >> http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something >> > > Unfortunately there's a glaring disconnect between what the license says > and what the Sun people think it says. The things the Sun people are > saying and the FAQ says are encouraging but they are quite plainly at > odds with the License. Since the license is legally binding whereas the > FAQ and what the developers say is not, this new software license is not > very helpful to Jpackage[1] or Debian[2]. When Sun responds to what > JPackage and Debian's licensing issues with a better license we may see > some progress. Sadly... > Also, no matter how you cut this license, it's not open source so the > discussion definitely does not belong on fedora-devel (Fedora is > committed to building from 100% open source software.) There are a > variety of other distributions, repositories, or Sun > linux-community-portal-sites which would be more appropriate for > discussing the intent of the new license versus its actual content. Agreed. If anywhere, Sun Java as currently licensed does not belong to Core nor Extras. 3rd party repos perhaps if the licensing concerns are addressed. Regards, Dariusz > [1] > https://www.zarb.org/pipermail/jpackage-discuss/2006-May/thread.html#9914 > > [2] http://lists.debian.org/debian-legal/2006/05/threads.html#00064 > > -Toshio Send instant messages to your online friends http://uk.messenger.yahoo.com From johnp at redhat.com Thu May 18 00:35:11 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 17 May 2006 20:35:11 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <1147911717.3434.9.camel@continuity> References: <1147911717.3434.9.camel@continuity> Message-ID: <1147912511.27961.9.camel@localhost.localdomain> On Wed, 2006-05-17 at 20:21 -0400, Thomas J. Baker wrote: > I had aiglx working fine on my laptop for quite a while now. I've got a > ATI Technologies Inc Radeon R250 Lf [FireGL 9000] but within the last > week, I've succumb to the everything-is-blue-with-metacity-compositing > enabled bug. Anyone else had it working and then have it recently break? Ohh, I've seen this on my ATI mobility and I have a stacktrace from GDB sitting at work. I thought it was just my bad luck having a card that is busted with aiglx but it is nice to see that is is a regression. Can log into failsafe xterm mode, ssh in from another computer as your user and run these commands: export DISPLAY=:0 export XAUTHORITY=~/.Xauthority export METACITY_SYNC=1 gdb metacity gdb> run Metacity should crash at some point (if it doesn't try to grab the xterm window and move it around). After it crashes run this command in gdb: gdb> bt Open a bug and attach that output. Thanks. -- John (J5) Palmieri From sbonnevi at redhat.com Thu May 18 00:56:05 2006 From: sbonnevi at redhat.com (Steve Bonneville) Date: Wed, 17 May 2006 19:56:05 -0500 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060517223120.5A44D732DF@hormel.redhat.com> References: <20060517223120.5A44D732DF@hormel.redhat.com> Message-ID: <20060518005605.GC2755@sbonnevi-lt.rdu.redhat.com> "Antonio Vargas" wrote: > xen always needed p6 hardware (didnt run on k6-II for example), > and AFAIK p6 supports PAE always, so not any lose here i think Nope. "Banias" and at least early "Dothan" Pentium M and Celeron M processors don't have working PAE. I know some IBM ThinkPad T41 laptops will fall into this problem. I'm not sure if there are any AMD processors in the Athlon and later era that don't have PAE, but there may be. -- Steve From alan at redhat.com Thu May 18 01:31:10 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 17 May 2006 21:31:10 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060517223109.GF17312@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060517214243.GC17312@neu.nirvana> <446BA367.5000100@BitWagon.com> <20060517223109.GF17312@neu.nirvana> Message-ID: <20060518013110.GA31345@devserv.devel.redhat.com> On Thu, May 18, 2006 at 12:31:09AM +0200, Axel Thimm wrote: > > So that machine has the necessary harware. If ' pae ' is missing, > > then such a machine does not have good enough hardware. > > That already kills my 1 1/2 year old laptop :( And my laptop, and all of my other remaining x86-32 boxes which are VIA processor and where Xen would be most useful to aggregate them further. The question is how common such boxes are however. Alan From cmadams at hiwaay.net Thu May 18 01:38:51 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 17 May 2006 20:38:51 -0500 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <446BB07D.5090605@yahoo.co.uk> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060517214803.GF1164619@hiwaay.net> <604aa7910605171514h432e2524rafa6da3311bc11a@mail.gmail.com> <20060517222833.GA731374@hiwaay.net> <446BB07D.5090605@yahoo.co.uk> Message-ID: <20060518013851.GA544063@hiwaay.net> Once upon a time, Dariusz J. Garbowski said: > On 05/17/2006 11:28 PM, Chris Adams wrote: > >Given all the other issues, I don't think it really matters. The > >conflict with GCJ and such is a much bigger issue; I don't see Fedora > >dropping GCJ or the alternatives system that allows either GCJ or the > >Sun JDK for development. > > According to this note by Simon Phipps that's not true: > > http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something#comment3 > > Quotation from the comment: > > "No, it's OK to distribute along with GCJ, GNU/Classpath and so on - > that was one of the explicit intents of the new license as that was > previously the chief obstacle to distribution with GNU/Linux." Section 2 of the license says in part (including a couple of problem parts): Sun also grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and distribute the Software, directly or indirectly through your licensees, distributors, resellers, or OEMs, electronically or in physical form or pre-installed with your Operating System on a general purpose desktop computer or server, provided that: (b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System; (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; Section 2(b) says Sun's JDK (as released under this license) can only be used with Fedora to develop programs to run under Fedora. At best, the meaning can be extended to be used with Linux to develop programs to run under Linux. What happened to "run anywhere"? Even if they included the source under an otherwise Open Source license, that clause means it isn't very useful for Java development. Section 2(c) says it cannot be combined or distributed with other software of "same or similar functionality or APIs". There are no definitions, so that would tend to indicate it can't be distributed with any other Java implementation or any other software development tools of "similar functionality" (Mono/C#? Perl? Python?). IIRC (I'm not a Java developer) there is a Java to native code interface; you could not use the Sun JDK with a native library that implements similar functionality to a class in the JDK either. IANAL, but if that's not what Sun meant, they need to work on their license some more. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From arjan at fenrus.demon.nl Thu May 18 01:39:30 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 18 May 2006 03:39:30 +0200 Subject: Do not BuildRequires: glibc-kernheaders In-Reply-To: <000101c679fb$56b39640$ba00000a@grecom.local> References: <1147470120.18573.7.camel@metroid.rdu.redhat.com> <000101c679fb$56b39640$ba00000a@grecom.local> Message-ID: <1147916391.2956.0.camel@laptopd505.fenrus.org> On Wed, 2006-05-17 at 23:46 +0200, David Woodhouse wrote: > The glibc-kernheaders packages provides 'kernel-headers'. If you need to > require a specific _version_, you should use that. > > But if you just need to require that it exists, you don't need to do > anything -- the standard gcc development packages depend on it. > > If there's a file missing from /usr/include/linux or /usr/include/asm > when you try to build, that's either a bug in the glibc-kernheaders > package, or a bug in the package you're trying to build. If it's a > kernel header you _should_ be using from userspace, assume the former > and file a bug against glibc-kernheaders. If the latter, fix it not to > include kernel headers. > > Do _NOT_ add 'BuildRequires: glibc-kernheaders' to any packages. That > will break. Soon. you should be able to require the exact header file if you need something exotic ;) Requires: /usr/include/linux/silly.h like that.. and it'll pull in whatever package provides it.. From arjan at fenrus.demon.nl Thu May 18 01:41:06 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 18 May 2006 03:41:06 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <69304d110605171349o65d40cadn7d63fd869b341e83@mail.gmail.com> References: <1147889279.13113.22.camel@aglarond.local> <69304d110605171349o65d40cadn7d63fd869b341e83@mail.gmail.com> Message-ID: <1147916486.2956.2.camel@laptopd505.fenrus.org> > xen always needed p6 hardware (didnt run on k6-II for example), > and AFAIK p6 supports PAE always, so not any lose here i think you lose pentium M's. From davej at redhat.com Thu May 18 01:48:51 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 17 May 2006 21:48:51 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <69304d110605171349o65d40cadn7d63fd869b341e83@mail.gmail.com> References: <1147889279.13113.22.camel@aglarond.local> <69304d110605171349o65d40cadn7d63fd869b341e83@mail.gmail.com> Message-ID: <20060518014851.GA17408@redhat.com> On Wed, May 17, 2006 at 10:49:03PM +0200, Antonio Vargas wrote: > >2) Switch the 32-bit xen kernels to require PAE. For most "current" > >non-laptop hardware, this is a non-issue. It does mean that xen won't > >work a lot of earlier PentiumM laptops > > xen always needed p6 hardware (didnt run on k6-II for example), > and AFAIK p6 supports PAE always, so not any lose here i think Sadly, not the case.. Celerons, and some Pentium-M's (as Jeremy noted above) are P6 class, yet lack PAE. Dave -- http://www.codemonkey.org.uk From jwboyer at jdub.homelinux.org Thu May 18 01:53:49 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 17 May 2006 20:53:49 -0500 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1147916486.2956.2.camel@laptopd505.fenrus.org> References: <1147889279.13113.22.camel@aglarond.local> <69304d110605171349o65d40cadn7d63fd869b341e83@mail.gmail.com> <1147916486.2956.2.camel@laptopd505.fenrus.org> Message-ID: <1147917229.28211.6.camel@vader.jdub.homelinux.org> On Thu, 2006-05-18 at 03:41 +0200, Arjan van de Ven wrote: > > xen always needed p6 hardware (didnt run on k6-II for example), > > and AFAIK p6 supports PAE always, so not any lose here i think > > you lose pentium M's. Some of them. I have a Pentium M that has PAE. Though I just bought it about a month ago. josh From tjb at unh.edu Thu May 18 02:01:51 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 17 May 2006 22:01:51 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <1147912511.27961.9.camel@localhost.localdomain> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> Message-ID: <1147917712.3434.11.camel@continuity> On Wed, 2006-05-17 at 20:35 -0400, John (J5) Palmieri wrote: > On Wed, 2006-05-17 at 20:21 -0400, Thomas J. Baker wrote: > > I had aiglx working fine on my laptop for quite a while now. I've got a > > ATI Technologies Inc Radeon R250 Lf [FireGL 9000] but within the last > > week, I've succumb to the everything-is-blue-with-metacity-compositing > > enabled bug. Anyone else had it working and then have it recently break? > > Ohh, I've seen this on my ATI mobility and I have a stacktrace from GDB > sitting at work. I thought it was just my bad luck having a card that > is busted with aiglx but it is nice to see that is is a regression. Can > log into failsafe xterm mode, ssh in from another computer as your user > and run these commands: > > export DISPLAY=:0 > export XAUTHORITY=~/.Xauthority > export METACITY_SYNC=1 > gdb metacity > gdb> run > > Metacity should crash at some point (if it doesn't try to grab the xterm > window and move it around). After it crashes run this command in gdb: > > gdb> bt > > Open a bug and attach that output. Thanks. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192163 tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From davej at redhat.com Thu May 18 02:35:23 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 17 May 2006 22:35:23 -0400 Subject: [Fedora-xen] Re: Heads-up: Requiring PAE for running Xen In-Reply-To: <001501c67a20$12f6bca0$0301a8c0@china> References: <20060518014851.GA17408@redhat.com> <001501c67a20$12f6bca0$0301a8c0@china> Message-ID: <20060518023523.GB17408@redhat.com> On Wed, May 17, 2006 at 07:09:10PM -0700, Eyal Traitel wrote: > While I understand the development pain, I think it's important to note my > case - I currently use Xen in production service (for Wiki server) with an > old Dual PIII. I understand that this will imply that on this specific h/w I > will have to stay with the current kernel versions, right? They should have PAE, so you should be ok. Dave -- http://www.codemonkey.org.uk From walovaton at yahoo.com.mx Thu May 18 03:10:01 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Wed, 17 May 2006 22:10:01 -0500 Subject: FC5 and IBM x366 Video Problem In-Reply-To: <6.2.5.6.2.20060517043739.01e220c0@comcast.net> References: <6.2.5.6.2.20060517043739.01e220c0@comcast.net> Message-ID: <1147921802.4028.8.camel@athlon2000.localdomain> Hi, I have some IBM xSeries 445 at the office and it is recommended that you use the vesa driver instead of the ATI driver (with FC3). However I had the very same problem with FC5 and the kernel was crashing in the init procedure. Try removing some of the boot options so you can see the exact message (eg: rhgb and quiet). For me it crashed randomly at boot. -William El mi??, 17-05-2006 a las 04:43 -0700, Harry Smith escribi??: > I have been given a couple of IBM e-Series x 366 machines to use for > a project. I can install FC5 x86-64 with no problems. It detects a > ATI 7000 /7100 video card and on first boot everything seem fine. > > When I reboot, I am hitting the black screen of nothing. Are there > any problems with FC5 or ATI driver on the IBM x366 ? > > Thanks > Harry Smith > > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From nicolas.mailhot at laposte.net Thu May 18 08:35:45 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 18 May 2006 10:35:45 +0200 (CEST) Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <1147899371.12565.22.camel@cutter> References: <446B8C2B.8050003@gmail.com> <1147899371.12565.22.camel@cutter> Message-ID: <11836.192.54.193.51.1147941345.squirrel@rousalka.dyndns.org> Le Mer 17 mai 2006 22:56, seth vidal a ?crit : > On Wed, 2006-05-17 at 22:48 +0200, Jochen Wiedmann wrote: >> Hi, >> >> any comments on >> http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? >> I understand this as an indicator, that the Sun JDK and JRE should now >> be distributable via Fedora Core or Extras? If so, I would very much >> like to see this. >> > > it is not free software. > > fedora is about free software: > > http://fedoraproject.org/wiki/Overview#head-c12f7664badb48c91c2cf8547a450fcaed001de0 However it should be good enough for a sister project like jpackage. I'm not following jpackage nowadays but two years ago this would have been a welcome licensing change -- Nicolas Mailhot From skvidal at linux.duke.edu Thu May 18 11:24:32 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 18 May 2006 07:24:32 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <11836.192.54.193.51.1147941345.squirrel@rousalka.dyndns.org> References: <446B8C2B.8050003@gmail.com> <1147899371.12565.22.camel@cutter> <11836.192.54.193.51.1147941345.squirrel@rousalka.dyndns.org> Message-ID: <1147951472.1973.0.camel@cutter> On Thu, 2006-05-18 at 10:35 +0200, Nicolas Mailhot wrote: > Le Mer 17 mai 2006 22:56, seth vidal a ?crit : > > On Wed, 2006-05-17 at 22:48 +0200, Jochen Wiedmann wrote: > >> Hi, > >> > >> any comments on > >> http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > >> I understand this as an indicator, that the Sun JDK and JRE should now > >> be distributable via Fedora Core or Extras? If so, I would very much > >> like to see this. > >> > > > > it is not free software. > > > > fedora is about free software: > > > > http://fedoraproject.org/wiki/Overview#head-c12f7664badb48c91c2cf8547a450fcaed001de0 > > > However it should be good enough for a sister project like jpackage. > I'm not following jpackage nowadays but two years ago this would have been > a welcome licensing change > and what jpackage chooses to do is a bit off topic for this list. -sv From buildsys at redhat.com Thu May 18 15:21:48 2006 From: buildsys at redhat.com (Build System) Date: Thu, 18 May 2006 11:21:48 -0400 Subject: rawhide report: 20060518 changes Message-ID: <200605181521.k4IFLmPv008989@porkchop.devel.redhat.com> From jkeating at redhat.com Thu May 18 15:25:34 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 11:25:34 -0400 Subject: rawhide report: 20060518 changes In-Reply-To: <200605181521.k4IFLmPv008989@porkchop.devel.redhat.com> References: <200605181521.k4IFLmPv008989@porkchop.devel.redhat.com> Message-ID: <1147965934.14172.19.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-18 at 11:21 -0400, Build System wrote: Misfire. sorry for the noise. -- 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 buildsys at redhat.com Thu May 18 15:33:32 2006 From: buildsys at redhat.com (Build System) Date: Thu, 18 May 2006 11:33:32 -0400 Subject: rawhide report: 20060518 changes Message-ID: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> Updated Packages: anaconda-11.1.0.13-1 -------------------- * Wed May 17 2006 Jeremy Katz - 11.1.0.13-1 - Fix image building typo - Remove some dead code (clumens, dcantrel) - More thread fixing (dcantrel) - Fix rescue mode (clumens) - Fix upgrades (clumens) - Don't try to mount protected partitions on hd ugprades (clumens) - Hook copyExtraModules back up (clumens, #185344) - Don't modify the main fs for user/password info on --rootpath install - Fix kickstart bootloader install - Some fixes for live CD anthy-7716-1.fc6 ---------------- * Wed May 17 2006 Akira TAGOH - 7716-1 - New upstream snapshot release. dasher-4.1.0-1 -------------- * Wed May 17 2006 Matthias Clasen - 4.1.0-1 - Update to 4.1.0 dbus-0.61-5.2 ------------- * Wed May 17 2006 Karsten Hopp 0.61-5.2 - add buildrequires libICE-devel, libSM-devel, libcap-devel - change buildrequires form libX11 to libX11-devel ddd-3.3.11-7 ------------ * Wed May 17 2006 Karsten Hopp 3.3.11-7 - add buildrequires elfutils-libelf-devel dhcp-12:3.0.4-4 --------------- * Wed May 17 2006 Jason Vas Dias - 12:3.0.4-4 - Enable libdhcp4client build * Tue May 16 2006 Jason Vas Dias - 12:3.0.4-2 - Fix bug 191470: prevent dhcpd writing 8 byte dhcp-lease-time option in packets on 64-bit platforms * Sun May 14 2006 Jason Vas Dias - 12:3.0.4-2 - Add the libdhcp4client library package for use by the new libdhcp package, which enables dhclient to be invoked by programs in a single process from the library. The normal dhclient code is unmodified by this. dhcpv6-0.10-22 -------------- * Wed May 17 2006 Jason Vas Dias 0.10-22 - Thanks, Karsten. Now building with libdhcp6client enabled. * Wed May 17 2006 Karsten Hopp 0.10-21 - change buildrequires from openssl top openssl-devel so that the configure checks actually work * Sun May 14 2006 Jason Vas Dias - 0.10-20 - Produce the libdhcp6client library for invoking dhcp6c from within other programs. eel2-2.15.1-1 ------------- * Wed May 17 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 elinks-0.11.0-3 --------------- * Wed May 17 2006 Karsten Hopp 0.11.0-3 - add buildrequires bzip2-devel, expat-devel,libidn-devel epic-4:2.2-4 ------------ * Wed May 17 2006 Karsten Hopp 2.2-4 - add buildrequires openssl-devel ethereal-0.99.0-2 ----------------- * Wed May 17 2006 Karsten Hopp 0.99.0-2 - add buildrequires gnutls-devel evolution-2.7.2.1-1 ------------------- * Wed May 17 2006 Matthew Barnes - 2.7.2.1-1 - Update to 2.7.2.1 - Remove nss/nspr hunk from evolution-2.7.1-no-gnome-common.patch (fixed upstream). evolution-data-server-1.7.2-1 ----------------------------- * Wed May 17 2006 Matthew Barnes - 1.7.2 - Update to 1.7.2 - Remove evolution-data-server-1.7.1-nss_auto_detect.patch; in upstream now. evolution-webcal-2.7.1-1 ------------------------ * Wed May 17 2006 Matthew Barnes - 2.7.1-1 - Update to 2.7.1 * Mon May 15 2006 Matthew Barnes - 2.7.0-1 - Update to 2.7.0 fontconfig-2.3.95-3 ------------------- * Thu May 18 2006 Matthias Clasen - 2.3.95-3 = Apply a patch by David Turner to speed up cache generation freetype-2.1.10-6 ----------------- * Wed May 17 2006 Karsten Hopp 2.1.10-6 - add buildrequires libICE-devel, libSM-devel g-wrap-1.9.6-5 -------------- * Wed May 17 2006 Bill Nottingham 1.9.6-5 - rebuild against new guile gaim-1:1.5.0-19.fc6 ------------------- * Thu May 18 2006 Karsten Hopp 1.5.0-19.fc6 - bump release and rebuild * Wed May 17 2006 Karsten Hopp 1.5.0-18.fc6 - add some missing buildrequires: libICE-devel, libSM-devel libX11-devel, libXext-devel, libXScrnSaver-devel gdb-6.3.0.0-1.129.FC6 --------------------- * Wed May 17 2006 Alexandre Oliva - 6.3.0.0-1.129 - Add not-automatically-generated file to fopen64 patch (BZ 191948). gedit-1:2.15.2-1 ---------------- * Wed May 17 2006 Matthias Clasen 2.15.2-1 - Update to 2.15.2 glibc-kernheaders-3.0-34 ------------------------ * Thu May 18 2006 David Woodhouse 3.0-34 - Add fdreg.h (#191954) * Wed May 17 2006 David Woodhouse 3.0-33 - Add in_route.h (#192012) gnome-desktop-2.15.2-1 ---------------------- * Wed May 17 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 gnome-games-1:2.15.2-1 ---------------------- * Tue May 16 2006 Matthias Clasen - 1:2.15.2-1 - Update to 2.15.2 gnome-mag-0.12.5-1 ------------------ * Thu May 18 2006 Matthias Clasen 0.12.5-1 - Update to 0.12.5 gnome-screensaver-2.15.2-1 -------------------------- * Wed May 17 2006 Matthias Clasen 2.15.2-1 - Update to 2.15.2 gnome-speech-0.4.0-1 -------------------- * Wed May 17 2006 Matthias Clasen - 0.4.0-1 - Update to 0.4.0 gnome-system-monitor-2.14.3-2 ----------------------------- * Wed May 17 2006 Matthias Clasen 2.14.3-2 - Update to 2.14.3 gnome-vfs2-2.15.1-1 ------------------- * Wed May 17 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 guile-5:1.8.0-4 --------------- * Thu May 18 2006 Miroslav Lichvar - 5:1.8.0-4 - add gmp-devel to requires for devel package (#192107) - fix guile-config link (#191595) hal-0.5.7-9 ----------- * Wed May 17 2006 John (J5) Palmieri - 0.5.7-9 - Add patch that makes hald not stat nfs and autofs mounts kdeadmin-7:3.5.2-2 ------------------ * Wed May 17 2006 Than Ngo 7:3.5.2-2 - add support Fedora Core release 5 kdeutils-6:3.5.2-2 ------------------ * Tue May 16 2006 Than Ngo 6:3.5.2-2 - fix #192003, Missing BuildRequire on python-devel/libXtst-devel * Wed Apr 05 2006 Than Ngo 6:3.5.2-1 - update to 3.5.2 * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kernel-2.6.16-1.2206_FC6 ------------------------ * Wed May 17 2006 Dave Jones - 2.6.17rc4-git5 * Tue May 16 2006 Juan Quintela - rebase xen to cset 28078. libbtctl-0.6.0-6 ---------------- * Wed May 17 2006 Harald Hoyer 0.6.0-6 - added more build requirements (bug #191981) libwnck-2.15.2-1 ---------------- * Wed May 17 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 logrotate-3.7.4-1 ----------------- * Wed May 17 2006 Peter Vrabec 3.7.4-1 - add new "minsize" option (#173088) m17n-db-1.3.3-3 --------------- * Wed May 17 2006 Mayank Jain - Added following keymaps - as-inscript.mim - as-phonetic.mim - mr-inscript.mim - ta-tamil99.mim * Wed Mar 22 2006 Jens Petersen - fix language names in Indic .mim file headers (Naoto Takahashi) - add make-dist script to m17n-db-indic mc-1:4.6.1a-15 -------------- * Wed May 17 2006 Jindrich Novy 4.6.1a-15 - update from CVS - drop .fish-upload patch, applied upstream - sync .showfree patch * Fri Apr 28 2006 Jindrich Novy 4.6.1a-14 - don't reread panel contents while in panelized mode (#188438) * Thu Mar 30 2006 Jindrich Novy 4.6.1a-13 - comment fallback to use only dd in FISH upload patch - drop .promptfix patch so that prompt is displayed only once while in panels mcelog-1:0.7-1.19 ----------------- * Wed May 17 2006 Dave Jones - Update to upstream 0.7 - Change frequency to hourly instead of daily. mesa-6.5-6 ---------- * Wed May 17 2006 Mike A. Harris 6.5-6 - Add "BuildRequires: makedepend" for bug (#191967) * Tue Apr 11 2006 Kristian H??gsberg 6.5-5 - Bump for fc5 build. nautilus-2.15.1-1 ----------------- * Wed May 17 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 nautilus-cd-burner-2.15.2-1 --------------------------- * Wed May 17 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 neon-0.25.5-3 ------------- * Wed May 17 2006 Joe Orton 0.25.5-3 - rebuild * Mon Feb 27 2006 Joe Orton 0.25.5-2 - don't trim exported libraries (#182997) nmap-2:4.03-2 ------------- * Wed May 17 2006 Harald Hoyer 4.03-2 - added more build requirements (bug #191932) openswan-2.4.5-2 ---------------- * Wed May 17 2006 Harald Hoyer - 2.4.5-2 - fixed typo (bug #191930) php-5.1.4-3 ----------- * Mon May 08 2006 Joe Orton 5.1.4-3 - update to 5.1.4 planner-0.13-5 -------------- * Fri Mar 17 2006 Caolan McNamara - 0.13-5 - courtesy Stuart Clark bug fix for: Gantt bar height doesn't match treeview row height from bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=128983 - rh#191808# Extra BuildRequires, and fix eds enabling patch psmisc-22.2-1.1 --------------- * Wed May 17 2006 Karel Zak 22.2-1.1 - add BuildRequires: gettext-devel - sync with upstream python-ldap-0:2.2.0-2 --------------------- * Wed May 17 2006 Matthew Barnes - 2.2.0-2 - Put back the epoch line... happy beehive? * Mon May 15 2006 Matthew Barnes - 2.2.0-1 - Update to 2.2.0 - Update python-ldap-2.0.6-rpath.patch and rename it to python-ldap-2.2.0-dirs.patch. qt-1:3.3.6-5 ------------ * Tue May 16 2006 Than Ngo 1:3.3.6-5 - fix #191895, BR libXmu-devel - disable warnings if debug is off ruby-1.8.4-6.fc6 ---------------- * Wed May 17 2006 Akira TAGOH - 1.8.4-6 - ruby-deprecated-search-path.patch: added the deprecated installation paths to the search path for the backward compatibility. - added a Provides: ruby(abi) to ruby-libs. - ruby-1.8.4-64bit-pack.patch: backport patch from upstream to fix unpack("l") not working on 64bit arch and integer overflow on template "w". (#189350) - updated License tag to be more comfortable, and with a pointer to get more details, like Python package does. (#179933) - clean up. * Wed Apr 19 2006 Akira TAGOH - ruby-rubyprefix.patch: moved all arch-independent modules under /usr/lib/ruby and keep arch-dependent modules under /usr/lib64/ruby for 64bit archs. so 'rubylibdir', 'sitelibdir' and 'sitedir' in Config::CONFIG points to the kind of /usr/lib/ruby now. (#184199) s390utils-2:1.5.3-1 ------------------- * Wed May 17 2006 Phil Knirsch 2:1.5.3-1 - Made src_vipa build on current toolchain again * Tue May 16 2006 Phil Knirsch - Update to s390-tools-1.5.3 from IBM - Included vmconvert - Dropped obsolete asm patch sane-backends-1.0.17-10 ----------------------- * Wed May 17 2006 Nils Philippsen 1.0.17-10 - add pkg-config support, re-write sane-config to use pkg-config to avoid multilib problems with conflicting sane-config scripts scim-hangul-0.2.2-3.fc6 ----------------------- * Wed May 17 2006 Akira TAGOH - 0.2.2-3 - scim-hangul-0.2.2-ascii-mode.patch: applied to support the ASCII input mode in scim-hangul. (#185506) sound-juicer-2.15.2.1-1 ----------------------- * Wed May 17 2006 Matthias Clasen - 2.15.2.1-1 - Update to 2.15.2.1 totem-1.5.1-1 ------------- * Wed May 17 2006 Matthias Clasen - 1.5.1-1 - Update to 1.5.1 * Wed Apr 19 2006 Matthias Clasen - 1.4.0-3 - Add missing BuildRequires (#181304) vte-0.13.1-1 ------------ * Wed May 17 2006 Matthias Clasen 0.13.1-1 - Update to 0.13.1 xorg-x11-drv-mouse-1.1.0-2 -------------------------- * Wed May 17 2006 Kristian H??gsberg - 1.1.0-2 - Add missing build requires (#192047). yelp-2.15.2-1 ------------- * Wed May 17 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 appending i386 appending ppc64 appending x86_64 appending s390 appending ppc appending ia64 appending s390x Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-system-monitor - 2.14.3-2.i386 requires GConf Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-system-monitor - 2.14.3-2.ppc64 requires GConf hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-system-monitor - 2.14.3-2.x86_64 requires GConf Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-system-monitor - 2.14.3-2.s390 requires GConf hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for ppc ---------------------------------------------------------- gnome-system-monitor - 2.14.3-2.ppc requires GConf Broken deps for ia64 ---------------------------------------------------------- gnome-system-monitor - 2.14.3-2.ia64 requires GConf rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-system-monitor - 2.14.3-2.s390x requires GConf hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 From vandrove at vc.cvut.cz Thu May 18 15:39:57 2006 From: vandrove at vc.cvut.cz (Petr Vandrovec) Date: Thu, 18 May 2006 17:39:57 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060518005605.GC2755@sbonnevi-lt.rdu.redhat.com> References: <20060517223120.5A44D732DF@hormel.redhat.com> <20060518005605.GC2755@sbonnevi-lt.rdu.redhat.com> Message-ID: <446C954D.7050303@vc.cvut.cz> Steve Bonneville wrote: > "Antonio Vargas" wrote: > >>xen always needed p6 hardware (didnt run on k6-II for example), >>and AFAIK p6 supports PAE always, so not any lose here i think > > > Nope. "Banias" and at least early "Dothan" Pentium M and Celeron M > processors don't have working PAE. I know some IBM ThinkPad T41 Are you sure that they do not have working PAE? I believe they are just reporting that they do not have working PAE, but if you'll try to use it, it will work. > laptops will fall into this problem. I'm not sure if there are any > AMD processors in the Athlon and later era that don't have PAE, but > there may be. All (reasonable) AMD's processors have PAE. But as Alan said, it might be problem for VIA's processors. Petr From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 18 15:41:08 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 18 May 2006 17:41:08 +0200 Subject: rawhide report: 20060518 changes In-Reply-To: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> References: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> Message-ID: <20060518174108.37132527@python2> Build System wrote : [...] > yelp-2.15.2-1 > ------------- > * Wed May 17 2006 Matthias Clasen - 2.15.2-1 > - Update to 2.15.2 > > appending i386 > appending ppc64 > appending x86_64 > appending s390 > appending ppc > appending ia64 > appending s390x > Broken deps for i386 > ---------------------------------------------------------- [...] This looks somewhat unusual :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2202_FC6 Load : 0.54 0.60 0.59 From paul at all-the-johnsons.co.uk Thu May 18 15:47:52 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 18 May 2006 16:47:52 +0100 Subject: rawhide report: 20060518 changes In-Reply-To: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> References: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> Message-ID: <1147967272.12334.40.camel@T7.Linux> Hi, > kernel-2.6.16-1.2206_FC6 > GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 > cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 > dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 > gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 Given the disparity between the actual kernel released and the GFS/cman/dlm/gnbd-kernel reqs, two questions need to be asked. The first is does anyone using rawhide still use GFS/cman/dlm/gnbd-kernel and why is it so far behind? (could it not be better served being orphaned from core and added to extras?) TTFN Paul -- ich liebe Ashleigh, eins zwei drei ich liebe Ashleigh, auf meinem Knee zu h?pfen -------------- 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 jwboyer at jdub.homelinux.org Thu May 18 15:51:16 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 18 May 2006 10:51:16 -0500 Subject: rawhide report: 20060518 changes In-Reply-To: <1147967272.12334.40.camel@T7.Linux> References: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> <1147967272.12334.40.camel@T7.Linux> Message-ID: <20060518155116.GB11051@yoda.jdub.homelinux.org> On Thu, May 18, 2006 at 04:47:52PM +0100, Paul wrote: > Hi, > > > kernel-2.6.16-1.2206_FC6 > > > GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 > > cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 > > dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 > > gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 > > Given the disparity between the actual kernel released and the > GFS/cman/dlm/gnbd-kernel reqs, two questions need to be asked. The first > is does anyone using rawhide still use GFS/cman/dlm/gnbd-kernel and why > is it so far behind? (could it not be better served being orphaned from > core and added to extras?) Or at least use the Extras kmod stuff josh From alan at redhat.com Thu May 18 15:59:52 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 18 May 2006 11:59:52 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <446C954D.7050303@vc.cvut.cz> References: <20060517223120.5A44D732DF@hormel.redhat.com> <20060518005605.GC2755@sbonnevi-lt.rdu.redhat.com> <446C954D.7050303@vc.cvut.cz> Message-ID: <20060518155952.GD7819@devserv.devel.redhat.com> On Thu, May 18, 2006 at 05:39:57PM +0200, Petr Vandrovec wrote: > >Nope. "Banias" and at least early "Dothan" Pentium M and Celeron M > >processors don't have working PAE. I know some IBM ThinkPad T41 > > Are you sure that they do not have working PAE? I believe they are just > reporting that they do not have working PAE, but if you'll try to use it, > it will work. To what extent. Unless someone from Intel is going to put their hands up and say it works then we don't know it works. We've no idea if Intel pulled the PAE reporting because they found some horrible chip bug Alan From jkeating at redhat.com Thu May 18 16:04:47 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 May 2006 12:04:47 -0400 Subject: rawhide report: 20060518 changes In-Reply-To: <20060518174108.37132527@python2> References: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> <20060518174108.37132527@python2> Message-ID: <1147968287.14172.38.camel@dhcp83-49.boston.redhat.com> On Thu, 2006-05-18 at 17:41 +0200, Matthias Saou wrote: > > This looks somewhat unusual :-) Nothing to see here, move along please... (it was a bit of debugging that I forgot to take out for the final push out) -- 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 jwboyer at jdub.homelinux.org Thu May 18 18:23:10 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 18 May 2006 13:23:10 -0500 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060518155952.GD7819@devserv.devel.redhat.com> References: <20060517223120.5A44D732DF@hormel.redhat.com> <20060518005605.GC2755@sbonnevi-lt.rdu.redhat.com> <446C954D.7050303@vc.cvut.cz> <20060518155952.GD7819@devserv.devel.redhat.com> Message-ID: <20060518182310.GA12985@yoda.jdub.homelinux.org> On Thu, May 18, 2006 at 11:59:52AM -0400, Alan Cox wrote: > On Thu, May 18, 2006 at 05:39:57PM +0200, Petr Vandrovec wrote: > > >Nope. "Banias" and at least early "Dothan" Pentium M and Celeron M > > >processors don't have working PAE. I know some IBM ThinkPad T41 > > > > Are you sure that they do not have working PAE? I believe they are just > > reporting that they do not have working PAE, but if you'll try to use it, > > it will work. > > To what extent. Unless someone from Intel is going to put their hands up and > say it works then we don't know it works. We've no idea if Intel pulled the > PAE reporting because they found some horrible chip bug One that eats babies? This is rawhide... people should be used to it eating babies by now ;) josh From tibbs at math.uh.edu Thu May 18 19:36:35 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 18 May 2006 14:36:35 -0500 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <446C954D.7050303@vc.cvut.cz> (Petr Vandrovec's message of "Thu, 18 May 2006 17:39:57 +0200") References: <20060517223120.5A44D732DF@hormel.redhat.com> <20060518005605.GC2755@sbonnevi-lt.rdu.redhat.com> <446C954D.7050303@vc.cvut.cz> Message-ID: >>>>> "PV" == Petr Vandrovec writes: PV> All (reasonable) AMD's processors have PAE. But as Alan said, it PV> might be problem for VIA's processors. Petr The Nehemiah chips are i686 compatible and will do SMP but do not have PAE. (The Fedora i686 SMP kernel will crash immediately at boot but will run fine if compiled with HIGHMEM64G off.) - J< From che666 at gmail.com Thu May 18 19:39:25 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 18 May 2006 21:39:25 +0200 Subject: patch for reposync to have a real destdir... its still using repo.id as default Message-ID: patch for reposync to have a real destdir... its still using repo.id as default apply with: -p0 "no repo to setup" should also in my eyes have a different exit state than 0 if reposync is called the intention of the user is to sync a specific repo. exit 0 in my eyes means a repo is succesfully synced. if it cant setup a repo there should definitely be a different exit state. regards, Rudolf Kastl p.s. probably needs still some tweaking -------------- next part -------------- A non-text attachment was scrubbed... Name: newrpms-reposync-realdest.patch Type: text/x-patch Size: 1637 bytes Desc: not available URL: From che666 at gmail.com Thu May 18 21:33:08 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Thu, 18 May 2006 23:33:08 +0200 Subject: patch for reposync to have a real destdir... its still using repo.id as default In-Reply-To: References: Message-ID: 2006/5/18, Rudolf Kastl : > patch for reposync to have a real destdir... its still using repo.id as default > apply with: -p0 > > "no repo to setup" should also in my eyes have a different exit state than 0 > > if reposync is called the intention of the user is to sync a specific > repo. exit 0 in my eyes means a repo is succesfully synced. if it cant > setup a repo there should definitely be a different exit state. > > regards, > Rudolf Kastl > > p.s. probably needs still some tweaking > > this mail should have gone to the yum list... and actually the patch has to be applied with -R cause i was too tired and fscked up :) From rc040203 at freenet.de Fri May 19 14:23:55 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 May 2006 16:23:55 +0200 Subject: rpmbuild doesn't produce debuginfos Message-ID: <1148048635.882.10.camel@mccallum.corsepiu.local> Hi, I am facing a bizarre issue on rpmbuilding *some* rpms on FC5: rpmbuild doesn't build debuginfos, despite the package contains binaries[1]. Also, on packages exposing these symptoms, executables don't seem get stripped: $ rpmlint ~/src/rpms/RPMS/i386/xxx-0.0.2-0.fc5.i386.rpm ... W: xxx unstripped-binary-or-object /usr/bin/xyz Ralf [1] Yes, redhat-rpm-config is installed. From mattdm at mattdm.org Fri May 19 14:26:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 19 May 2006 10:26:09 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <1147900189.20963.45.camel@atlantis.mpeters.local> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> Message-ID: <20060519142609.GA13734@jadzia.bu.edu> On Wed, May 17, 2006 at 02:09:49PM -0700, Michael A. Peters wrote: > > any comments on > > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > > I understand this as an indicator, that the Sun JDK and JRE should now > > be distributable via Fedora Core or Extras? If so, I would very much > > like to see this. > This pretty much kills it: > 2c. ``you do not combine, configure or distribute the Software to run in > conjunction with any additional software that implements the same or > similar functionality or APIs as the Software'' The "it's not open source" kills it for Fedora. But for "non-free", I don't believe this is a problem. I think the people on the JPackage list who are concerned about this are misinterpreting -- remember, licenses are written in legalese, which is formed from English words but where the meaning of certain terms is determined by heaps of case law and precedent, not necessarily by the dictionary. My assumption, given that Sun people say that this clause does not prevent distribution of the JDK _alongside_ GCJ etc., is that people are reading the phrase "in conjunction with" more strongly than it should be. A more narrow reading indicates that you can't use the Sun JVM with GNU Classpath, but you can use and distribute them both _not_ in conjunction. But really, a lawyer needs to answer this question. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From caolanm at redhat.com Fri May 19 14:29:08 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 19 May 2006 15:29:08 +0100 Subject: rpmbuild doesn't produce debuginfos In-Reply-To: <1148048635.882.10.camel@mccallum.corsepiu.local> References: <1148048635.882.10.camel@mccallum.corsepiu.local> Message-ID: <1148048948.32128.30.camel@localhost.localdomain> On Fri, 2006-05-19 at 16:23 +0200, Ralf Corsepius wrote: > Hi, > > I am facing a bizarre issue on rpmbuilding *some* rpms on FC5: > > rpmbuild doesn't build debuginfos, despite the package contains > binaries[1]. > > Also, on packages exposing these symptoms, executables don't seem get > stripped: > $ rpmlint ~/src/rpms/RPMS/i386/xxx-0.0.2-0.fc5.i386.rpm > ... > W: xxx unstripped-binary-or-object /usr/bin/xyz The created binaries might not have permissions which allow them to be written by the rpmbuild-ing owner. C. From skvidal at linux.duke.edu Fri May 19 14:33:08 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 19 May 2006 10:33:08 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <20060519142609.GA13734@jadzia.bu.edu> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060519142609.GA13734@jadzia.bu.edu> Message-ID: <1148049188.9516.5.camel@cutter> On Fri, 2006-05-19 at 10:26 -0400, Matthew Miller wrote: > On Wed, May 17, 2006 at 02:09:49PM -0700, Michael A. Peters wrote: > > > any comments on > > > http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml ? > > > I understand this as an indicator, that the Sun JDK and JRE should now > > > be distributable via Fedora Core or Extras? If so, I would very much > > > like to see this. > > This pretty much kills it: > > 2c. ``you do not combine, configure or distribute the Software to run in > > conjunction with any additional software that implements the same or > > similar functionality or APIs as the Software'' > > The "it's not open source" kills it for Fedora. > > But for "non-free", I don't believe this is a problem. I think the people on > the JPackage list who are concerned about this are misinterpreting -- > remember, licenses are written in legalese, which is formed from English > words but where the meaning of certain terms is determined by heaps of case > law and precedent, not necessarily by the dictionary. > > My assumption, given that Sun people say that this clause does not prevent > distribution of the JDK _alongside_ GCJ etc., is that people are reading > the phrase "in conjunction with" more strongly than it should be. A more > narrow reading indicates that you can't use the Sun JVM with GNU Classpath, > but you can use and distribute them both _not_ in conjunction. > > But really, a lawyer needs to answer this question. > and no matter what it is off topic for this list. sun's java is not free software. It will NOT be in fedora provided that it continues to be closed-source - no matter how much they let us redistribute it. so we can stop discussing it. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 19 14:34:43 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 19 May 2006 16:34:43 +0200 Subject: rpmbuild doesn't produce debuginfos In-Reply-To: <1148048948.32128.30.camel@localhost.localdomain> References: <1148048635.882.10.camel@mccallum.corsepiu.local> <1148048948.32128.30.camel@localhost.localdomain> Message-ID: <20060519163443.256008c5@python2> Caolan McNamara wrote : > On Fri, 2006-05-19 at 16:23 +0200, Ralf Corsepius wrote: > > Hi, > > > > I am facing a bizarre issue on rpmbuilding *some* rpms on FC5: > > > > rpmbuild doesn't build debuginfos, despite the package contains > > binaries[1]. > > > > Also, on packages exposing these symptoms, executables don't seem get > > stripped: > > $ rpmlint ~/src/rpms/RPMS/i386/xxx-0.0.2-0.fc5.i386.rpm > > ... > > W: xxx unstripped-binary-or-object /usr/bin/xyz > > The created binaries might not have permissions which allow them to be > written by the rpmbuild-ing owner. ...or the binary might have had setuid or setgid bits set. Not sure why, but binaries don't get stripped properly in that case. No idea about the debuginfo packages not being created, though, since in my experience, even if there are no binaries in the package, you'll get one (although empty) as long as the package isn't explicitly "noarch". Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2202_FC6 Load : 1.35 1.27 1.19 From mattdm at mattdm.org Fri May 19 14:37:02 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 19 May 2006 10:37:02 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <1148049188.9516.5.camel@cutter> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060519142609.GA13734@jadzia.bu.edu> <1148049188.9516.5.camel@cutter> Message-ID: <20060519143702.GA14196@jadzia.bu.edu> On Fri, May 19, 2006 at 10:33:08AM -0400, seth vidal wrote: > and no matter what it is off topic for this list. > sun's java is not free software. It will NOT be in fedora provided that > it continues to be closed-source - no matter how much they let us > redistribute it. *nod* > so we can stop discussing it. Yes. I just want it to be very clear that _that_ is the showstopper, not some particular reading of the current license. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at linux.duke.edu Fri May 19 14:47:51 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 19 May 2006 10:47:51 -0400 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <20060519143702.GA14196@jadzia.bu.edu> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060519142609.GA13734@jadzia.bu.edu> <1148049188.9516.5.camel@cutter> <20060519143702.GA14196@jadzia.bu.edu> Message-ID: <1148050072.9516.8.camel@cutter> On Fri, 2006-05-19 at 10:37 -0400, Matthew Miller wrote: > On Fri, May 19, 2006 at 10:33:08AM -0400, seth vidal wrote: > > and no matter what it is off topic for this list. > > sun's java is not free software. It will NOT be in fedora provided that > > it continues to be closed-source - no matter how much they let us > > redistribute it. > > *nod* > > > so we can stop discussing it. > > Yes. I just want it to be very clear that _that_ is the showstopper, not > some particular reading of the current license. > And before someone can argue and complain that we're just being free software zealots I'd like to openly affirm that label. I am an free software zealot. If I have anything to do with it fedora will NEVER have non-free software in it. -sv From bernie at develer.com Fri May 19 15:46:21 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 19 May 2006 17:46:21 +0200 Subject: rawhide report: 20060518 changes In-Reply-To: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> References: <200605181533.k4IFXWxt011095@porkchop.devel.redhat.com> Message-ID: <446DE84D.2000804@develer.com> Build System wrote: > anaconda-11.1.0.13-1 > -------------------- > * Wed May 17 2006 Jeremy Katz - 11.1.0.13-1 > - Fix image building typo > - Remove some dead code (clumens, dcantrel) > - More thread fixing (dcantrel) > - Fix rescue mode (clumens) > - Fix upgrades (clumens) > - Don't try to mount protected partitions on hd ugprades (clumens) Due to this change, Anaconda dumps trace in PartedUtils.py:722 because anaconda.method.protectedPartitions() returns None, but the for loop wants a list. > - Hook copyExtraModules back up (clumens, #185344) > - Don't modify the main fs for user/password info on --rootpath install > - Fix kickstart bootloader install > - Some fixes for live CD -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From buildsys at redhat.com Fri May 19 16:26:21 2006 From: buildsys at redhat.com (Build System) Date: Fri, 19 May 2006 12:26:21 -0400 Subject: rawhide report: 20060519 changes Message-ID: <200605191626.k4JGQL4c004481@porkchop.devel.redhat.com> Updated Packages: anaconda-11.1.0.14-1 -------------------- * Thu May 18 2006 Jeremy Katz - 11.1.0.14-1 - Few more liveCD tweaks - And clean up the ppc64 tree a little - Enable ipv6 by default (pnasrat) - Fix a traceback in finding root part (clumens) * Wed May 17 2006 Jeremy Katz - 11.1.0.13-1 - Fix image building typo - Remove some dead code (clumens, dcantrel) - More thread fixing (dcantrel) - Fix rescue mode (clumens) - Fix upgrades (clumens) - Don't try to mount protected partitions on hd ugprades (clumens) - Hook copyExtraModules back up (clumens, #185344) - Don't modify the main fs for user/password info on --rootpath install - Fix kickstart bootloader install - Some fixes for live CD authconfig-5.2.5-1 ------------------ * Thu May 18 2006 Tomas Mraz - 5.2.5-1 - write ldap servers as URIs and not HOSTs (#191842) - fix a typo in --test output - updated summary, converted changelog to UTF-8 cups-1:1.2.0-5 -------------- * Fri May 19 2006 Tim Waugh 1:1.2.0-5 - Sync to svn5545. - Ship a driver directory. * Thu May 18 2006 Tim Waugh 1:1.2.0-4 - Disable back-channel data in the usb backend (STR #1705, bug #192034). - Fix for 'browsing stops on reload', STR #1670 (bug #191217). * Tue May 16 2006 Tim Waugh - Sync to svn5538. - Added 'restartlog' to initscript, for clearing out error_log. Useful for problem diagnosis. - Initscript no longer needs to check for printconf-backend. dasher-4.1.0-1 -------------- * Wed May 17 2006 Matthias Clasen - 4.1.0-1 - Update to 4.1.0 dhcpv6-0.10-24 -------------- * Fri May 19 2006 Jason Vas Dias 0.10-24 - build libdhcp6client with -soname dictd-1.9.15-7 -------------- * Thu May 18 2006 Karsten Hopp 1.9.15-7 - Buildrequires: libdbi-devel diskdumputils-1.3.6-5 --------------------- * Thu May 18 2006 David Woodhouse 1.3.6-5 - Use $RPM_OPT_FLAGS and %{_libdir} * Thu May 18 2006 Dave Anderson 1.3.6-4 - Added /sbin files that replaced the /usr/sbin versions, making them symbolic links. * Wed May 17 2006 Dave Woodhouse 1.3.6-3 - Remove glibc-kernheaders BR - Build on PPC - Don't use evolution-connector-2.7.2-1 --------------------------- * Wed May 17 2006 Matthew Barnes - 2.7.2-1 - Update to 2.7.2 - Update spec file to run the autotools itself after patching. - Remove evolution-exchange-2.7.1-fix_version.patch; fixed upstream. - Remove unused or obsolete patches: evolution-connector-2.0.2-domain-fix.patch evolution-connector-2.7.2-generated-autotool.patch ximian-connector-2.1.4-fix-convenience-libraries.patch ximian-connector-2.2.2-install-debug-utilities.patch ximian-connector-2.2.2-noinst-ltlibraries.patch - Add evolution-exchange-2.7.2-no_gnome_common.patch; removes GNOME_COMPILE_WARNINGS from configure.in. fontconfig-2.3.95-3 ------------------- * Thu May 18 2006 Matthias Clasen - 2.3.95-3 = Apply a patch by David Turner to speed up cache generation foomatic-3.0.2-35 ----------------- * Fri May 19 2006 Tim Waugh 3.0.2-35 - Define CUPS_PPDS for configure (bug #192375). * Fri Apr 21 2006 Tim Waugh - Updated db-engine to 3.0-20060421. freeglut-2.4.0-5 ---------------- * Fri May 19 2006 Mike A. Harris 2.4.0-5 - Added "BuildRequires: libXext-devel, libXxf86vm-devel" for (#192255) g-wrap-1.9.6-6 -------------- * Thu May 18 2006 Bill Nottingham 1.9.6-6 - rebuild against new guile, again * Wed May 17 2006 Bill Nottingham 1.9.6-5 - rebuild against new guile gaim-1:1.5.0-19.fc6 ------------------- * Thu May 18 2006 Karsten Hopp 1.5.0-19.fc6 - bump release and rebuild * Wed May 17 2006 Karsten Hopp 1.5.0-18.fc6 - add some missing buildrequires: libICE-devel, libSM-devel libX11-devel, libXext-devel, libXScrnSaver-devel gdm-1:2.15.3-1 -------------- * Wed May 17 2006 Matthias Clasen > - 1:2.15.3-1 - Update to 2.15.3 glibc-kernheaders-3.0-34 ------------------------ * Thu May 18 2006 David Woodhouse 3.0-34 - Add fdreg.h (#191954) gnome-mag-0.12.5-1 ------------------ * Thu May 18 2006 Matthias Clasen 0.12.5-1 - Update to 0.12.5 gnome-system-monitor-2.14.3-3 ----------------------------- * Thu May 18 2006 Bill Nottingham 2.14.3-3 - s/GConf/GConf2 gnucash-1.9.6-1 --------------- * Wed May 17 2006 Bill Nottingham - 1.9.6-1 - update to 1.9.6 gok-1.0.10-2 ------------ * Thu May 18 2006 Matthias Clasen - 1.0.10-2 - Update to 1.0.10 gphoto2-2.1.99-11 ----------------- * Thu May 18 2006 Radek Vok??l 2.1.99-11 - include docs on side, disable compiling them (bug in gtk-doc!?) guile-5:1.8.0-4 --------------- * Thu May 18 2006 Miroslav Lichvar - 5:1.8.0-4 - add gmp-devel to requires for devel package (#192107) - fix guile-config link (#191595) kdeutils-6:3.5.2-2 ------------------ * Tue May 16 2006 Than Ngo 6:3.5.2-2 - fix #192003, Missing BuildRequire on python-devel/libXtst-devel * Wed Apr 05 2006 Than Ngo 6:3.5.2-1 - update to 3.5.2 * Fri Feb 10 2006 Jesse Keating - 6:3.5.1-1.2 - bump again for double-long bug on ppc(64) kernel-2.6.16-1.2207_FC6 ------------------------ * Thu May 18 2006 Dave Jones - 2.6.17rc4-git6 * Wed May 17 2006 Dave Jones - 2.6.17rc4-git5 * Tue May 16 2006 Juan Quintela - rebase xen to cset 28078. libselinux-1.30.8-1 ------------------- * Thu May 18 2006 Dan Walsh 1.30.8-1 - More fixes for translation cache - Upgrade to latest from NSA * Added matchpathcon_fini() function to free memory allocated by matchpathcon_init(). * Wed May 17 2006 Dan Walsh 1.30.7-2 - Add simple cache to improve translation speed libsepol-1.12.11-1 ------------------ * Mon May 15 2006 Dan Walsh 1.12.11-1 - Upgrade to latest from NSA * Merged patch to initialize sym_val_to_name arrays from Kevin Carr. Reworked to use calloc in the first place, and converted some other malloc/memset pairs to calloc calls. m17n-db-1.3.3-3 --------------- * Wed May 17 2006 Mayank Jain - Added following keymaps - as-inscript.mim - as-phonetic.mim - mr-inscript.mim - ta-tamil99.mim * Wed Mar 22 2006 Jens Petersen - fix language names in Indic .mim file headers (Naoto Takahashi) - add make-dist script to m17n-db-indic metacity-2.15.3-2 ----------------- * Thu May 18 2006 Soren Sandmann 2.15.3-2 - Update libcm to 0.0.21 * Wed May 17 2006 Matthias Clasen 2.15.3-1 - Update to 2.15.3 mkinitrd-5.0.40-1 ----------------- * Thu May 18 2006 Jeremy Katz - 5.0.40-1 - fix multiple netdev handling (#192321) net-tools-1.60-71 ----------------- * Fri May 19 2006 Radek Vokal - 1.60-71 - BuildRequires: libselinux-devel (#191737) openoffice.org-1:2.0.3-1.1 -------------------------- * Wed May 17 2006 Caolan McNamara - 1:2.0.3-1.2 - 2.0.3 RC1 - rh#191689# well fine so!, anonymous EXEC mapping is verboten altogether, reimplement three UNO bridges arch with the double file mmap pattern - add openoffice.org-2.0.3.oooXXXXX.vcl.removemenukey.patch for rh#192172# * Mon May 15 2006 Caolan McNamara - 1:2.0.3-0.169.5 - rh#191689# re-add openoffice.org-2.0.3.oooXXXXX.selinux.bridges.patch the upstreamed replacement alloc/mprotect pattern still leaves writable executable mem * Mon May 15 2006 Caolan McNamara - 1:2.0.3-0.169.4 - ooo#65361# remove gengal.rdb - ooo#61767# remove oo_product.bmp - add workspace.vcl59.patch + openoffice.org-2.0.3.ooo65304.sn.vcl.patch merged into vcl59 - add openoffice.org-2.0.3.oooXXXXX.atkbroken.vcl.patch for rh#191621# + upstream atk version check doesn't seen to work pam-0.99.4.0-3 -------------- * Wed May 17 2006 Tomas Mraz 0.99.4.0-3 - use md5 implementation from pam_unix in pam_namespace - pam_namespace should call setexeccon only when selinux is enabled php-5.1.4-5 ----------- * Thu May 18 2006 Joe Orton 5.1.4-5 - provide mod_php (#187891) - provide php-cli (#192196) - use correct LDAP fix (#181518) - define _GNU_SOURCE in php_config.h and leave it defined - drop (circular) dependency on php-pear * Mon May 08 2006 Joe Orton 5.1.4-3 - update to 5.1.4 policycoreutils-1.30.9-3 ------------------------ * Mon May 15 2006 James Antill 1.30.9-3 - Add rhpl dependancy selinux-policy-2.2.41-1 ----------------------- * Thu May 18 2006 Dan Walsh 2.2.41-1 - allow hal to read boot_t files - Upgrade to upstream * Wed May 17 2006 Dan Walsh 2.2.40-2 - allow hal to read boot_t files sound-juicer-2.15.2.1-1 ----------------------- * Wed May 17 2006 Matthias Clasen - 2.15.2.1-1 - Update to 2.15.2.1 udev-092-1 ---------- * Thu May 18 2006 Harald Hoyer - 092-1 - version 092 - corrected some rules (bug #192210 #190927) vnc-4.1.2-0 ----------- * Thu May 18 2006 Jitka Kudrnacova 4.1.2-0 - update to version 4.1.2 * Wed May 10 2006 Jitka Kudrnacova 4.1.1-38 - fixed crash of Xnvc caused by a NULL pointer in interfaces (bug #187607) - This also fixes crash of Xvnc when vpnc is running (bug #187069) - don't build on ppc64 due to intermittent build problems xorg-x11-drv-v4l-0.1.1-2 ------------------------ * Fri May 19 2006 Mike A. Harris 0.1.1-2 - Added "BuildRequires: xorg-x11-proto-devel" for (#192386) Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 From bernie at develer.com Fri May 19 17:23:06 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 19 May 2006 19:23:06 +0200 Subject: rawhide report: 20060504 changes In-Reply-To: <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> Message-ID: <446DFEFA.3010308@develer.com> Jesse Keating wrote: > On Thu, 2006-05-04 at 15:38 -0400, Jesse Keating wrote: >>> rpm-4.4.2-22 >>> ------------ >>> * Wed May 03 2006 Jeremy Katz - 4.4.2-22 >>> - put in simple workaround for per-file deps with autoreq off (#190488) >>> while pnasrat works on a real fix >> So you're going to want to update rpm first, then proceed with the rest >> of the update, or else you're going to get bit on the glibc update with: >> >> rpmte.c:589: rpmteColorDS: Assertion 'ix < Count' failed. >> >> Welcome to rawhide (: > > Um, that should be rpm and rpm-libs. What if I keep hitting this very same assertion while installing glibc-2.4.90-7.x86_64.rpm after upgrading to rpm-4.4.2-24? I tried an rpm --rebuilddb, no luck. By the way, my rpmdb is still using Berkeley DB. Am I supposed to convert it to SQLite? -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rc040203 at freenet.de Fri May 19 17:39:51 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 May 2006 19:39:51 +0200 Subject: rpmbuild doesn't produce debuginfos In-Reply-To: <20060519163443.256008c5@python2> References: <1148048635.882.10.camel@mccallum.corsepiu.local> <1148048948.32128.30.camel@localhost.localdomain> <20060519163443.256008c5@python2> Message-ID: <1148060391.882.89.camel@mccallum.corsepiu.local> On Fri, 2006-05-19 at 16:34 +0200, Matthias Saou wrote: > Caolan McNamara wrote : > > > On Fri, 2006-05-19 at 16:23 +0200, Ralf Corsepius wrote: > > > Hi, > > > > > > I am facing a bizarre issue on rpmbuilding *some* rpms on FC5: > > > > > > rpmbuild doesn't build debuginfos, despite the package contains > > > binaries[1]. > > > > > > Also, on packages exposing these symptoms, executables don't seem get > > > stripped: > > > $ rpmlint ~/src/rpms/RPMS/i386/xxx-0.0.2-0.fc5.i386.rpm > > > ... > > > W: xxx unstripped-binary-or-object /usr/bin/xyz > > > > The created binaries might not have permissions which allow them to be > > written by the rpmbuild-ing owner. > ...or the binary might have had setuid or setgid bits set. #8() > Not sure why, > but binaries don't get stripped properly in that case. Not in the cases I trip over this issue. These are normal application, with nothing special about them. Actually, as it seems, the more trivial a package is, the more likely it seems to be hit by the problem. Even a package containing "hello world" and building in mock exposes this problem ;). > No idea about the debuginfo packages not being created, though, since in > my experience, even if there are no binaries in the package, you'll get > one (although empty) as long as the package isn't explicitly "noarch". I had wanted to send an example src.rpm of a package exposing the issue to this list, but the FESCo/RH God reigning this list has proven to insist on ridiculously unreasonable low limits on postings ... which had forced me to file this PR to ... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422 Ralf From toshio at tiki-lounge.com Fri May 19 18:01:24 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 19 May 2006 11:01:24 -0700 Subject: rpmbuild doesn't produce debuginfos In-Reply-To: <1148060391.882.89.camel@mccallum.corsepiu.local> References: <1148048635.882.10.camel@mccallum.corsepiu.local> <1148048948.32128.30.camel@localhost.localdomain> <20060519163443.256008c5@python2> <1148060391.882.89.camel@mccallum.corsepiu.local> Message-ID: <1148061684.3732.1.camel@localhost> On Fri, 2006-05-19 at 19:39 +0200, Ralf Corsepius wrote: > Not in the cases I trip over this issue. These are normal application, > with nothing special about them. Actually, as it seems, the more trivial > a package is, the more likely it seems to be hit by the problem. > > Even a package containing "hello world" and building in mock exposes > this problem ;). > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192422 For this particular package, adding an [empty] %build seems to get us generating debuginfo packages. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Fri May 19 18:35:00 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 19 May 2006 14:35:00 -0400 Subject: rawhide report: 20060504 changes In-Reply-To: <446DFEFA.3010308@develer.com> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> <446DFEFA.3010308@develer.com> Message-ID: <1148063700.2183.24.camel@ender> On Fri, 2006-05-19 at 19:23 +0200, Bernardo Innocenti wrote: > > What if I keep hitting this very same assertion while installing > glibc-2.4.90-7.x86_64.rpm after upgrading to rpm-4.4.2-24? Did you update rpm-libs too? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bernie at develer.com Fri May 19 19:39:35 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 19 May 2006 21:39:35 +0200 Subject: rawhide report: 20060504 changes In-Reply-To: <1148063700.2183.24.camel@ender> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> <446DFEFA.3010308@develer.com> <1148063700.2183.24.camel@ender> Message-ID: <446E1EF7.1070208@develer.com> Jesse Keating wrote: > On Fri, 2006-05-19 at 19:23 +0200, Bernardo Innocenti wrote: >> What if I keep hitting this very same assertion while installing >> glibc-2.4.90-7.x86_64.rpm after upgrading to rpm-4.4.2-24? > > Did you update rpm-libs too? Yeah: beetle:/pub/linux/distro/fedora-devel64# rpm -qa | grep ^rpm rpm-build-4.4.2-24.x86_64 rpm-libs-4.4.2-24.x86_64 rpm-devel-4.4.2-24.x86_64 rpm-4.4.2-24.x86_64 rpm-python-4.4.2-24.x86_64 beetle:/pub/linux/distro/fedora-devel64# rpm -U glibc-2.4.90-7.i686.rpm glibc-2.4.90-7.x86_64.rpm glibc-common-2.4.90-7.x86_64.rpm glibc-devel-2.4.90-7.i386.rpm glibc-devel-2.4.90-7.x86_64.rpm glibc-headers-2.4.90-7.x86_64.rpm glibc-kernheaders-3.0-34.x86_64.rpm glibc-utils-2.4.90-7.x86_64.rpm rpm: rpmte.c:589: rpmteColorDS: Assertion `ix < Count' failed. Aborted -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From pnasrat at redhat.com Fri May 19 19:54:20 2006 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 19 May 2006 15:54:20 -0400 Subject: rawhide report: 20060504 changes In-Reply-To: <446E1EF7.1070208@develer.com> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> <446DFEFA.3010308@develer.com> <1148063700.2183.24.camel@ender> <446E1EF7.1070208@develer.com> Message-ID: <1148068461.2650.39.camel@enki.eridu> On Fri, 2006-05-19 at 21:39 +0200, Bernardo Innocenti wrote: > > beetle:/pub/linux/distro/fedora-devel64# rpm -qa | grep ^rpm > rpm-build-4.4.2-24.x86_64 > rpm-libs-4.4.2-24.x86_64 > rpm-devel-4.4.2-24.x86_64 > rpm-4.4.2-24.x86_64 > rpm-python-4.4.2-24.x86_64 > beetle:/pub/linux/distro/fedora-devel64# rpm -U glibc-2.4.90-7.i686.rpm glibc-2.4.90-7.x86_64.rpm glibc-common-2.4.90-7.x86_64.rpm glibc-devel-2.4.90-7.i386.rpm glibc-devel-2.4.90-7.x86_64.rpm glibc-headers-2.4.90-7.x86_64.rpm glibc-kernheaders-3.0-34.x86_64.rpm glibc-utils-2.4.90-7.x86_64.rpm > rpm: rpmte.c:589: rpmteColorDS: Assertion `ix < Count' failed. See instructions in Comment #6 here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190972 Paul From bernie at develer.com Fri May 19 20:08:12 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 19 May 2006 22:08:12 +0200 Subject: rawhide report: 20060504 changes In-Reply-To: <1148068461.2650.39.camel@enki.eridu> References: <200605041920.k44JKddC004265@porkchop.devel.redhat.com> <1146771521.29889.22.camel@dhcp83-49.boston.redhat.com> <1146771943.29889.24.camel@dhcp83-49.boston.redhat.com> <446DFEFA.3010308@develer.com> <1148063700.2183.24.camel@ender> <446E1EF7.1070208@develer.com> <1148068461.2650.39.camel@enki.eridu> Message-ID: <446E25AC.6040609@develer.com> Paul Nasrat wrote: > On Fri, 2006-05-19 at 21:39 +0200, Bernardo Innocenti wrote: > >> beetle:/pub/linux/distro/fedora-devel64# rpm -qa | grep ^rpm >> rpm-build-4.4.2-24.x86_64 >> rpm-libs-4.4.2-24.x86_64 >> rpm-devel-4.4.2-24.x86_64 >> rpm-4.4.2-24.x86_64 >> rpm-python-4.4.2-24.x86_64 >> beetle:/pub/linux/distro/fedora-devel64# rpm -U glibc-2.4.90-7.i686.rpm glibc-2.4.90-7.x86_64.rpm glibc-common-2.4.90-7.x86_64.rpm glibc-devel-2.4.90-7.i386.rpm glibc-devel-2.4.90-7.x86_64.rpm glibc-headers-2.4.90-7.x86_64.rpm glibc-kernheaders-3.0-34.x86_64.rpm glibc-utils-2.4.90-7.x86_64.rpm >> rpm: rpmte.c:589: rpmteColorDS: Assertion `ix < Count' failed. > > See instructions in Comment #6 here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190972 Your suggestion fixed the problem, thanks! -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From mspevack at redhat.com Fri May 19 23:23:24 2006 From: mspevack at redhat.com (Max Spevack) Date: Fri, 19 May 2006 19:23:24 -0400 (EDT) Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <1148050072.9516.8.camel@cutter> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060519142609.GA13734@jadzia.bu.edu> <1148049188.9516.5.camel@cutter> <20060519143702.GA14196@jadzia.bu.edu> <1148050072.9516.8.camel@cutter> Message-ID: On Fri, 19 May 2006, seth vidal wrote: > If I have anything to do with it fedora will NEVER have non-free > software in it. Too bad you're not on the Fedora Board or anything. :-) -- Max Spevack + http://people.redhat.com/mspevack/ + gpg key -- http://people.redhat.com/mspevack/mspevack.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From Matt_Domsch at dell.com Sat May 20 03:34:08 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 19 May 2006 22:34:08 -0500 Subject: rawhide rebuild in mock status 2006-05-19 Message-ID: <20060520033408.GA27962@lists.us.dell.com> Rawhide-in-Mock Build Results for x86_64 Architecture Fri May 19 22:31:14 CDT 2006 Number failed to build: 208 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 180 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 56 ---------------------------------- cman-kernel compat-gcc-32 dlm-kernel eclipse elilo emacs gail gaim gcc gdk-pixbuf gdm gecko-sharp2 GFS-kernel gnbd-kernel gnome-media gnome-panel gnome-python2 gnome-python2-desktop gnome-python2-extras gnome-terminal grub gtk-doc hal-cups-utils hdparm HelixPlayer initscripts iptraf jakarta-commons-codec jakarta-commons-dbcp jakarta-commons-el jakarta-commons-pool jakarta-taglibs-standard java-1.4.2-gcj-compat kdeartwork kdebindings kdegames kdelibs kdemultimedia kdenetwork kdepim kdesdk kdevelop ldapjdk libgconf-java libglade-java libselinux libvte-java magma-plugins memtest86+ mx4j rgmanager struts syslinux system-config-netboot tomcat5 xen With bugs filed: 122 ---------------------------------- amanda ['191796 NEW'] arptables_jf ['191688 NEW'] arts ['192367 ASSIGNED'] at-spi ['192368 NEW'] beagle ['191664 NEW'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 NEW'] ekiga ['191597 NEW'] eog ['191666 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gcalctool ['191910 NEW'] gmime ['192116 CLOSED'] gnome-utils ['191757 NEW'] gnucash ['192008 CLOSED'] ImageMagick ['192036 NEW'] jsch ['191668 NEW'] kdebase ['192037 NEW'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] libbonoboui ['191728 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libsemanage ['191733 MODIFIED'] libwnck ['191756 NEW'] lvm2 ['191748 NEW'] mozilla ['191984 NEW'] nautilus ['191817 NEW'] nautilus-sendto ['191818 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] pango ['191958 NEW'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEW'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 NEW'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] startup-notification ['191877 NEW'] subversion ['191611 NEW'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vino ['191827 NEW'] vixie-cron ['191823 NEW'] vte ['192484 NEW'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 NEW'] xorg-x11-drv-digitaledge ['192316 NEW'] xorg-x11-drv-dmc ['192312 NEW'] xorg-x11-drv-dummy ['192304 NEW'] xorg-x11-drv-dynapro ['192300 NEW'] xorg-x11-drv-elo2300 ['192320 NEW'] xorg-x11-drv-elographics ['192318 NEW'] xorg-x11-drv-evdev ['192317 NEW'] xorg-x11-drv-fbdev ['192325 NEW'] xorg-x11-drv-fpit ['192324 NEW'] xorg-x11-drv-hyperpen ['192326 NEW'] xorg-x11-drv-i810 ['192334 NEW'] xorg-x11-drv-jamstudio ['192335 NEW'] xorg-x11-drv-joystick ['192336 NEW'] xorg-x11-drv-keyboard ['192337 NEW'] xorg-x11-drv-magellan ['192338 NEW'] xorg-x11-drv-magictouch ['192339 NEW'] xorg-x11-drv-mga ['192340 NEW'] xorg-x11-drv-microtouch ['192341 NEW'] xorg-x11-drv-mutouch ['192342 NEW'] xorg-x11-drv-nv ['192343 NEW'] xorg-x11-drv-palmax ['192346 NEW'] xorg-x11-drv-penmount ['192344 NEW'] xorg-x11-drv-s3 ['192347 NEW'] xorg-x11-drv-s3virge ['192348 NEW'] xorg-x11-drv-savage ['192349 NEW'] xorg-x11-drv-siliconmotion ['192350 NEW'] xorg-x11-drv-sis ['192351 NEW'] xorg-x11-drv-sisusb ['192352 NEW'] xorg-x11-drv-spaceorb ['192353 NEW'] xorg-x11-drv-summa ['192354 NEW'] xorg-x11-drv-tdfx ['192358 NEW'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 NEW'] xorg-x11-drv-ur98 ['192360 NEW'] xorg-x11-drv-vesa ['192359 NEW'] xorg-x11-drv-vga ['192168 NEW'] xorg-x11-drv-via ['192167 NEW'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 NEW'] xorg-x11-drv-void ['192045 NEW'] xorg-x11-drv-voodoo ['192042 NEW'] xorg-x11-fonts ['192038 NEW'] xorg-x11-resutils ['192040 NEW'] xorg-x11-server ['192021 NEW'] xorg-x11-server-utils ['191987 NEW'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ From michael at knox.net.nz Sat May 20 03:45:21 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sat, 20 May 2006 15:45:21 +1200 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <20060520033408.GA27962@lists.us.dell.com> References: <20060520033408.GA27962@lists.us.dell.com> Message-ID: <446E90D1.40407@knox.net.nz> Matt Domsch wrote: > compat-gcc-32 This does build in mock, ran it this morning. > struts > syslinux Bug have been file strust = bz#192489 syslinux = bz#192488 Michael From Matt_Domsch at dell.com Sat May 20 04:02:35 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 19 May 2006 23:02:35 -0500 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <446E90D1.40407@knox.net.nz> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> Message-ID: <20060520040235.GB27962@lists.us.dell.com> On Sat, May 20, 2006 at 03:45:21PM +1200, Michael J Knox wrote: > Matt Domsch wrote: > >compat-gcc-32 > > This does build in mock, ran it this morning. I've gotten this twice now: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-x86_64-core-compat-gcc-32-3.2.3-55.fc5.src.rpm/root resolvedep 'zlib-devel' 'flex' '/lib64/libc.so.6' 'dejagnu' '/usr/lib64/libc.so' '/lib/libc.so.6' 'binutils >= 2.16.91.0.5-1' 'gettext' 'bison' '/usr/lib/libc.so' 'glibc-devel >= 2.2.90-12' 'texinfo' No Package Found for /lib/libc.so.6 No Package Found for /usr/lib/libc.so -- 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 jkeating at redhat.com Sat May 20 06:12:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 20 May 2006 02:12:39 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <20060520040235.GB27962@lists.us.dell.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> Message-ID: <1148105559.12055.17.camel@ender> On Fri, 2006-05-19 at 23:02 -0500, Matt Domsch wrote: > No Package Found for /lib/libc.so.6 > No Package Found for /usr/lib/libc.so Mock config is not allowing the 32bit package to be installed. There needs to be a whitelist setup for gcc, glibc, and maybe something else which really needs the 32bit components to build the 64bit package. -- 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 buildsys at redhat.com Sat May 20 07:44:14 2006 From: buildsys at redhat.com (Build System) Date: Sat, 20 May 2006 03:44:14 -0400 Subject: rawhide report: 20060520 changes Message-ID: <200605200744.k4K7iEdi013580@porkchop.devel.redhat.com> Updated Packages: anaconda-11.1.0.16-1 -------------------- * Fri May 19 2006 David Cantrell - 11.1.0.16-1 - Added asix driver (pjones) - Fix i18n build * Fri May 19 2006 David Cantrell - 11.1.0.15-1 - Fix indendation error in handleRenderCallback() that caused hang - Use gobject.threads_init() model - Remove gtk.threads_enter()/gtk.threads_leave() wrappers - Disk and filesystem scanning fixes (clumens) dhcp-12:3.0.4-8 --------------- * Fri May 19 2006 Jason Vas Dias - 12:3.0.4-6 - Make libdhcp4client a versioned .so (BZ 192146) firstboot-1.4.9-1 ----------------- * Fri May 19 2006 Chris Lumens 1.4.9-1 - Make /etc/modprobe.conf reading more robust (#191819). - Don't try to call readHTML from anaconda's ICS. gnome-terminal-2.15.0-2 ----------------------- * Thu May 18 2006 Dan Williams - 2.15.0-2 - Revert gnome.org #336325 (fixes #338913 ??? Terminal resized when switching tabs) hal-0.5.7-10 ------------ * Fri May 19 2006 David Zeuthen - 0.5.7-10 - Make PCMCIA card readers work again (#185557) * Wed May 17 2006 John (J5) Palmieri - 0.5.7-9 - Add patch that makes hald not stat nfs and autofs mounts * Mon May 15 2006 John (J5) Palmieri - 0.5.7-8 - Patch from Brian Pepple Add BR for dbus-glib ipsec-tools-0.6.5-2 ------------------- * Tue Apr 18 2006 Dan Walsh - 0.6.5-2 - Fix patch to build MLS Stuff correctly jakarta-commons-el-0:1.0-5jpp_1fc --------------------------------- * Fri May 19 2006 Fernando Nasser - 0:1.0-5jpp_1fc - First build for FC6 * Fri May 19 2006 Fernando Nasser - 0:1.0-5jpp_0fc - Add gcj_support * Wed Apr 26 2006 Fernando Nasser - 0:1.0-5jpp - First JPP 1.7 build kdebase-6:3.5.2-10 ------------------ * Fri May 19 2006 Than Ngo 6:3.5.2-10 - fix #191049, KDE screensaver calls PAM incorrectly - fix 191306, Kde Help Center can't build an index libnotify-0.4.0-1 ----------------- * Fri May 19 2006 John (J5) Palmieri - 0.4.0-1 - Update to 0.4.0 parted-1.7.0-1 -------------- * Fri May 19 2006 David Cantrell - 1.7.0-1 - Upgraded to parted-1.7.0 pyparted-1.7.0-1 ---------------- * Fri May 19 2006 David Cantrell - 1.7.0-1 - Bump version to 1.7.0 and require parted >= 1.7.0 * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Nov 11 2005 Peter Jones - 1.6.10-1 - rebuild for new parted. - add debugging options for make so debuginfo isn't useless switchdesk-4.0.8-5 ------------------ * Fri May 19 2006 Than Ngo 4.0.8-5 - add French translation, thanks to Alain PORTAL Broken deps for ppc64 ---------------------------------------------------------- NetworkManager-gnome - 0.6.2-1.fc6.ppc64 requires libnotify.so.0()(64bit) avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.7.2.1-1.ppc64 requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-power-manager - 2.15.2-1.ppc64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ppc64 requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.9.4.1-2.ppc64 requires libnotify.so.0()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for ppc ---------------------------------------------------------- NetworkManager-gnome - 0.6.2-1.fc6.ppc requires libnotify.so.0 evolution - 2.7.2.1-1.ppc requires libnotify.so.0 gnome-power-manager - 2.15.2-1.ppc requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.ppc requires libnotify.so.0 rhythmbox - 0.9.4.1-2.ppc requires libnotify.so.0 Broken deps for ia64 ---------------------------------------------------------- NetworkManager-gnome - 0.6.2-1.fc6.ia64 requires libnotify.so.0()(64bit) evolution - 2.7.2.1-1.ia64 requires libnotify.so.0()(64bit) gnome-power-manager - 2.15.2-1.ia64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ia64 requires libnotify.so.0()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.4.1-2.ia64 requires libnotify.so.0()(64bit) Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390 requires libnotify.so.0 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-power-manager - 2.15.2-1.s390 requires libnotify.so.0 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390x requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-power-manager - 2.15.2-1.s390x requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU NetworkManager-gnome - 0.6.2-1.fc6.i386 requires libnotify.so.0 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.i386 requires libnotify.so.0 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.i386 requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.i386 requires libnotify.so.0 rhythmbox - 0.9.4.1-2.i386 requires libnotify.so.0 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU NetworkManager-gnome - 0.6.2-1.fc6.x86_64 requires libnotify.so.0()(64bit) cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.x86_64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.x86_64 requires libnotify.so.0()(64bit) rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) From kmaraas at broadpark.no Sat May 20 12:39:57 2006 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sat, 20 May 2006 14:39:57 +0200 Subject: gdm broken today? Message-ID: <1148128797.10150.0.camel@rivendell> I see prefdm respawning gdm-binary processes over and over here. Anyone else seeing this? Cheers Kjartan From sundaram at fedoraproject.org Sat May 20 12:45:30 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 20 May 2006 18:15:30 +0530 Subject: gdm broken today? In-Reply-To: <1148128797.10150.0.camel@rivendell> References: <1148128797.10150.0.camel@rivendell> Message-ID: <1148129130.4310.449.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-20 at 14:39 +0200, Kjartan Maraas wrote: > I see prefdm respawning gdm-binary processes over and over here. Anyone > else seeing this? check fedora-test list. Known issue. Rahul From Matt_Domsch at dell.com Sat May 20 13:17:54 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 20 May 2006 08:17:54 -0500 Subject: rawhide rebuild in mock status 2006-05-20 Message-ID: <20060520131754.GC27962@lists.us.dell.com> Rawhide-in-Mock Build Results for x86_64 Architecture Sat May 20 07:59:07 CDT 2006 Number failed to build: 208 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 180 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 14 ---------------------------------- cman-kernel compat-gcc-32 dlm-kernel eclipse elilo (this has a dep on gnu-efi which is ExclusiveArch ia64 right now) emacs gcc GFS-kernel gnbd-kernel libselinux magma-plugins memtest86+ rgmanager tomcat5 With bugs filed: 164 ---------------------------------- amanda ['191796 NEW'] arptables_jf ['191688 NEW'] arts ['192367 ASSIGNED'] at-spi ['192368 NEW'] beagle ['191664 NEW'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 NEW'] ekiga ['191597 NEW'] eog ['191666 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gail ['192492 NEW'] gaim ['192496 NEW'] gcalctool ['191910 NEW'] gdk-pixbuf ['192493 NEW'] gdm ['192494 NEW'] gecko-sharp2 ['192495 NEW'] gmime ['192116 CLOSED'] gnome-media ['192497 NEW'] gnome-panel ['192498 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 NEW'] gnome-python2-extras ['192501 NEW'] gnome-terminal ['192503 NEW'] gnome-utils ['191757 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] gtk-doc ['192505 NEW'] hal-cups-utils ['192507 NEW'] hdparm ['192508 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] initscripts ['192509 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdebindings ['192520 NEW'] kdegames ['192521 NEW'] kdelibs ['192522 NEW'] kdemultimedia ['192523 NEW'] kdenetwork ['192525 NEW'] kdepim ['192526 NEW'] kdesdk ['192527 NEW'] kdevelop ['192529 NEW'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonoboui ['191728 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libsemanage ['191733 MODIFIED'] libvte-java ['192533 NEW'] libwnck ['191756 NEW'] lvm2 ['191748 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus ['191817 NEW'] nautilus-sendto ['191818 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] pango ['191958 NEW'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEW'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 NEW'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] startup-notification ['191877 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 NEW'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vino ['191827 NEW'] vixie-cron ['191823 NEW'] vte ['192484 NEW'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 NEW'] xorg-x11-drv-digitaledge ['192316 NEW'] xorg-x11-drv-dmc ['192312 NEW'] xorg-x11-drv-dummy ['192304 NEW'] xorg-x11-drv-dynapro ['192300 NEW'] xorg-x11-drv-elo2300 ['192320 NEW'] xorg-x11-drv-elographics ['192318 NEW'] xorg-x11-drv-evdev ['192317 NEW'] xorg-x11-drv-fbdev ['192325 NEW'] xorg-x11-drv-fpit ['192324 NEW'] xorg-x11-drv-hyperpen ['192326 NEW'] xorg-x11-drv-i810 ['192334 NEW'] xorg-x11-drv-jamstudio ['192335 NEW'] xorg-x11-drv-joystick ['192336 NEW'] xorg-x11-drv-keyboard ['192337 NEW'] xorg-x11-drv-magellan ['192338 NEW'] xorg-x11-drv-magictouch ['192339 NEW'] xorg-x11-drv-mga ['192340 NEW'] xorg-x11-drv-microtouch ['192341 NEW'] xorg-x11-drv-mutouch ['192342 NEW'] xorg-x11-drv-nv ['192343 NEW'] xorg-x11-drv-palmax ['192346 NEW'] xorg-x11-drv-penmount ['192344 NEW'] xorg-x11-drv-s3 ['192347 NEW'] xorg-x11-drv-s3virge ['192348 NEW'] xorg-x11-drv-savage ['192349 NEW'] xorg-x11-drv-siliconmotion ['192350 NEW'] xorg-x11-drv-sis ['192351 NEW'] xorg-x11-drv-sisusb ['192352 NEW'] xorg-x11-drv-spaceorb ['192353 NEW'] xorg-x11-drv-summa ['192354 NEW'] xorg-x11-drv-tdfx ['192358 NEW'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 NEW'] xorg-x11-drv-ur98 ['192360 NEW'] xorg-x11-drv-vesa ['192359 NEW'] xorg-x11-drv-vga ['192168 NEW'] xorg-x11-drv-via ['192167 NEW'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 NEW'] xorg-x11-drv-void ['192045 NEW'] xorg-x11-drv-voodoo ['192042 NEW'] xorg-x11-fonts ['192038 NEW'] xorg-x11-resutils ['192040 NEW'] xorg-x11-server ['192021 NEW'] xorg-x11-server-utils ['191987 NEW'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ From Axel.Thimm at ATrpms.net Sat May 20 14:14:25 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 May 2006 16:14:25 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1147889279.13113.22.camel@aglarond.local> References: <1147889279.13113.22.camel@aglarond.local> Message-ID: <20060520141425.GD1924@neu.nirvana> On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > As we move forward with Xen enablement, there's a desire for > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > options for handling this are > 1) Another kernel. This is bad due to > a) we're running out of CD space already > b) keeping things matched up between the HV and the guest kernels > c) migration is worlds of pain with two types of kernels > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > non-laptop hardware, this is a non-issue. It does mean that xen won't > work a lot of earlier PentiumM laptops > 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of > RAM > 4) Make the PAE code handled at runtime. This is a pretty non-trivial > amount of work :) > > Given these, we're looking at going with #2 and thus only having Xen > work on PAE-capable hardware in the development tree. And we're > planning to try to execute this switchover the beginning of next week. > Note that this will not affect bare metal installs at all. > > Jeremy Judging from the feedback I would derive that o in later production environments usually hardware with PAE support will be used. o during development, though, people would like to test xen on their non-PAE hardware like their laptops. So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers. And maybe until then the runtime handling emerges out of the blue and solves all issues. It's that improbable that it has to happen ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Sat May 20 14:47:17 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 20 May 2006 09:47:17 -0500 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060520141425.GD1924@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> Message-ID: <1148136437.5542.5.camel@vader.jdub.homelinux.org> On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote: > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > As we move forward with Xen enablement, there's a desire for > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > options for handling this are > > 1) Another kernel. This is bad due to > > a) we're running out of CD space already > > b) keeping things matched up between the HV and the guest kernels > > c) migration is worlds of pain with two types of kernels > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > work a lot of earlier PentiumM laptops > > 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of > > RAM > > 4) Make the PAE code handled at runtime. This is a pretty non-trivial > > amount of work :) > > > > Given these, we're looking at going with #2 and thus only having Xen > > work on PAE-capable hardware in the development tree. And we're > > planning to try to execute this switchover the beginning of next week. > > Note that this will not affect bare metal installs at all. > > > > Jeremy > > Judging from the feedback I would derive that > > o in later production environments usually hardware with PAE support > will be used. > > o during development, though, people would like to test xen on their > non-PAE hardware like their laptops. > > So maybe rawhide should continue with both PAE and non-PAE kernels and > decide on dropping the non-PAE when a release is about to be cut? I don't think so. I think you missed the "worlds of pain" part about having two kernels. It also becomes a resource issue. I think option 1 is simply too much burden. So options 2 and 3 are left. It seems to come down to which is the "greater good". Which group is larger? The ones that don't have PAE hardware, or the ones that have machines with >= 4 gigs of RAM that are non-64bit. Personally, I think option 2 is fine. Of course, both my machines have PAE :). josh From Axel.Thimm at ATrpms.net Sat May 20 15:26:23 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 May 2006 17:26:23 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148136437.5542.5.camel@vader.jdub.homelinux.org> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148136437.5542.5.camel@vader.jdub.homelinux.org> Message-ID: <20060520152623.GH1924@neu.nirvana> On Sat, May 20, 2006 at 09:47:17AM -0500, Josh Boyer wrote: > On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote: > > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > > As we move forward with Xen enablement, there's a desire for > > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > > options for handling this are > > > 1) Another kernel. This is bad due to > > > a) we're running out of CD space already > > > b) keeping things matched up between the HV and the guest kernels > > > c) migration is worlds of pain with two types of kernels > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > > work a lot of earlier PentiumM laptops > > > 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of > > > RAM > > > 4) Make the PAE code handled at runtime. This is a pretty non-trivial > > > amount of work :) > > > > > > Given these, we're looking at going with #2 and thus only having Xen > > > work on PAE-capable hardware in the development tree. And we're > > > planning to try to execute this switchover the beginning of next week. > > > Note that this will not affect bare metal installs at all. > > > > > > Jeremy > > > > Judging from the feedback I would derive that > > > > o in later production environments usually hardware with PAE support > > will be used. > > > > o during development, though, people would like to test xen on their > > non-PAE hardware like their laptops. > > > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > decide on dropping the non-PAE when a release is about to be cut? > > I don't think so. I think you missed the "worlds of pain" part about > having two kernels. It also becomes a resource issue. Not within rawhide, or? > > I think option 1 is simply too much burden. So options 2 and 3 are > left. It seems to come down to which is the "greater good". Which > group is larger? The ones that don't have PAE hardware, or the ones > that have machines with >= 4 gigs of RAM that are non-64bit. > > Personally, I think option 2 is fine. Of course, both my machines have > PAE :). If personal bits matter, then I'd go for 3. I have no 32 bit machine with >= 4GB, but quite a few 64 bits ones. And the toy machines I would use to play with rawhide have no PAE. I guess whoever needs that much memory also needs something like x86_64' in-chip memory controller. (the only systems I've recently seen with large memories running on 32 bits were 64-bits platforms with Debian, due to Debian not supporting multilib ...) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sat May 20 15:40:20 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 20 May 2006 17:40:20 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060520141425.GD1924@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> Message-ID: <1148139621.2289.31.camel@localhost.localdomain> Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm: > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > As we move forward with Xen enablement, there's a desire for > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > options for handling this are > [...] > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > work a lot of earlier PentiumM laptops > [...] > > Given these, we're looking at going with #2 and thus only having Xen > > work on PAE-capable hardware in the development tree. And we're > > planning to try to execute this switchover the beginning of next week. > > Note that this will not affect bare metal installs at all. > [...] > So maybe rawhide should continue with both PAE and non-PAE kernels and > decide on dropping the non-PAE when a release is about to be cut? > Otherwise you will keep out a large amount of (admittedly casual) > testers. Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if - they are build with the same spec-file as the other kernels - they are build on the same build system in the same step as the other kernels - they are moved to the proper Extras repo in the same moment as the other kernels are pushed out There are some technical problems that probably would need to be solved before the above could be realized, but that should be possible if we really want to. CU thl -- Thorsten Leemhuis From Axel.Thimm at ATrpms.net Sat May 20 15:46:47 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 May 2006 17:46:47 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148139621.2289.31.camel@localhost.localdomain> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148139621.2289.31.camel@localhost.localdomain> Message-ID: <20060520154647.GJ1924@neu.nirvana> On Sat, May 20, 2006 at 05:40:20PM +0200, Thorsten Leemhuis wrote: > Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm: > > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > > As we move forward with Xen enablement, there's a desire for > > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > > options for handling this are > > [...] > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > > work a lot of earlier PentiumM laptops > > [...] > > > Given these, we're looking at going with #2 and thus only having Xen > > > work on PAE-capable hardware in the development tree. And we're > > > planning to try to execute this switchover the beginning of next week. > > > Note that this will not affect bare metal installs at all. > > [...] > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > decide on dropping the non-PAE when a release is about to be cut? > > Otherwise you will keep out a large amount of (admittedly casual) > > testers. > > Well, I was always against kernel's in Fedora Extras (and I still am, > [mostly]). But having a Xen non-PAE kernel in Extras sounds like the > proper solution for the above problem. But having kernels in Extras > would only be okay for me if > - they are build with the same spec-file as the other kernels > - they are build on the same build system in the same step as the other > kernels > - they are moved to the proper Extras repo in the same moment as the > other kernels are pushed out > > There are some technical problems that probably would need to be solved > before the above could be realized, but that should be possible if we > really want to. Basically you want src.rpms in Core, but a way to move subpackages from a "Core build" to Extras, correct? That only covers Jeremy's "no place on CD" point, what about migration and maintenance/security etc.? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jos at xos.nl Sat May 20 15:47:40 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 20 May 2006 17:47:40 +0200 Subject: [Fedora-xen] Heads-up: Requiring PAE for running Xen In-Reply-To: <1147889279.13113.22.camel@aglarond.local>; from katzj@redhat.com on Wed, May 17, 2006 at 02:07:59PM -0400 References: <1147889279.13113.22.camel@aglarond.local> Message-ID: <20060520174740.A19565@xos037.xos.nl> On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > non-laptop hardware, this is a non-issue. It does mean that xen won't > work a lot of earlier PentiumM laptops Will the kernel src.rpm stay supporting building non-PAE kernels (via changing some macro)? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Axel.Thimm at ATrpms.net Sat May 20 15:50:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 May 2006 17:50:28 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060520174740.A19565@xos037.xos.nl> References: <1147889279.13113.22.camel@aglarond.local> <20060520174740.A19565@xos037.xos.nl> Message-ID: <20060520155028.GK1924@neu.nirvana> On Sat, May 20, 2006 at 05:47:40PM +0200, Jos Vos wrote: > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > work a lot of earlier PentiumM laptops > > Will the kernel src.rpm stay supporting building non-PAE kernels (via > changing some macro)? That's doomed to break, reminds me of the switch to allow kernel-source(code) to build. Once it's off by default, noone will look anymore into it, and one day it will be removed as cruft (which it will have become ;). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cjb at mrao.cam.ac.uk Sat May 20 16:08:18 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Sat, 20 May 2006 12:08:18 -0400 Subject: gdm broken today? References: <1148128797.10150.0.camel@rivendell> Message-ID: <87ejyoadcd.fsf@mrao.cam.ac.uk> >> On Sat, 20 May 2006, Kjartan Maraas said: > I see prefdm respawning gdm-binary processes over and over > here. Anyone else seeing this? Yeah. I filed a bug for it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192464 -- Chris Ball From fedora at leemhuis.info Sat May 20 16:10:52 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 20 May 2006 18:10:52 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060520154647.GJ1924@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148139621.2289.31.camel@localhost.localdomain> <20060520154647.GJ1924@neu.nirvana> Message-ID: <1148141453.2289.35.camel@localhost.localdomain> Am Samstag, den 20.05.2006, 17:46 +0200 schrieb Axel Thimm: > On Sat, May 20, 2006 at 05:40:20PM +0200, Thorsten Leemhuis wrote: > > Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm: > > > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > > > As we move forward with Xen enablement, there's a desire for > > > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > > > options for handling this are > > > [...] > > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > > > work a lot of earlier PentiumM laptops > > > [...] > > > > Given these, we're looking at going with #2 and thus only having Xen > > > > work on PAE-capable hardware in the development tree. And we're > > > > planning to try to execute this switchover the beginning of next week. > > > > Note that this will not affect bare metal installs at all. > > > [...] > > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > > decide on dropping the non-PAE when a release is about to be cut? > > > Otherwise you will keep out a large amount of (admittedly casual) > > > testers. > > > > Well, I was always against kernel's in Fedora Extras (and I still am, > > [mostly]). But having a Xen non-PAE kernel in Extras sounds like the > > proper solution for the above problem. But having kernels in Extras > > would only be okay for me if > > - they are build with the same spec-file as the other kernels > > - they are build on the same build system in the same step as the other > > kernels > > - they are moved to the proper Extras repo in the same moment as the > > other kernels are pushed out > > > > There are some technical problems that probably would need to be solved > > before the above could be realized, but that should be possible if we > > really want to. > > Basically you want src.rpms in Core, but a way to move subpackages > from a "Core build" to Extras, correct? Yes. > That only covers Jeremy's "no place on CD" point, what about > migration and maintenance/security etc.? Build from the same specfile in the same step as the other (kernel-)packages, so maintenance/security is and should still be in the hands of the core maintainer. CU thl -- Thorsten Leemhuis From Axel.Thimm at ATrpms.net Sat May 20 16:30:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 May 2006 18:30:35 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148141453.2289.35.camel@localhost.localdomain> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148139621.2289.31.camel@localhost.localdomain> <20060520154647.GJ1924@neu.nirvana> <1148141453.2289.35.camel@localhost.localdomain> Message-ID: <20060520163035.GM1924@neu.nirvana> > > > > 1) Another kernel. This is bad due to > > > > a) we're running out of CD space already > > > > b) keeping things matched up between the HV and the guest kernels > > > > c) migration is worlds of pain with two types of kernels > > > Well, I was always against kernel's in Fedora Extras (and I > > > still am, [mostly]). But having a Xen non-PAE kernel in Extras > > > sounds like the proper solution for the above problem. But > > > having kernels in Extras would only be okay for me if > > Basically you want src.rpms in Core, but a way to move subpackages > > from a "Core build" to Extras, correct? > > Yes. > > > That only covers Jeremy's "no place on CD" point, what about > > migration and maintenance/security etc.? > > Build from the same specfile in the same step as the other > (kernel-)packages, so maintenance/security is and should still be in the > hands of the core maintainer. But that's what the xen fedorians want to avoid, maintaining HV and migration for several kernels. The CD space argument is only valid for the time when the next release is to be cut, so it isn't high priority right now. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael at knox.net.nz Sat May 20 19:46:03 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 21 May 2006 07:46:03 +1200 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148105559.12055.17.camel@ender> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> Message-ID: <446F71FB.2030408@knox.net.nz> Jesse Keating wrote: > On Fri, 2006-05-19 at 23:02 -0500, Matt Domsch wrote: >> No Package Found for /lib/libc.so.6 >> No Package Found for /usr/lib/libc.so > > Mock config is not allowing the 32bit package to be installed. There > needs to be a whitelist setup for gcc, glibc, and maybe something else > which really needs the 32bit components to build the 64bit package. Is there any point filing the buildrequires bug against compat-gcc in this case? Perhaps mock needs a "feature request" bug report. Michael From jkeating at j2solutions.net Sat May 20 19:58:48 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 20 May 2006 15:58:48 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <446F71FB.2030408@knox.net.nz> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> Message-ID: <1148155128.12055.25.camel@ender> On Sun, 2006-05-21 at 07:46 +1200, Michael J Knox wrote: > > Is there any point filing the buildrequires bug against compat-gcc in > this case? No. > Perhaps mock needs a "feature request" bug report. There is some discussion going on about this already. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael at knox.net.nz Sat May 20 20:07:34 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 21 May 2006 08:07:34 +1200 Subject: rawhide rebuild in mock status 2006-05-20 In-Reply-To: <20060520131754.GC27962@lists.us.dell.com> References: <20060520131754.GC27962@lists.us.dell.com> Message-ID: <446F7706.1030601@knox.net.nz> cman-kernel dlm-kernel gnbd-kernel GFS-kernel These 4 require specific kernel versions, so do these still need to have bugs filed? I think these 4 are more than just "BuildRequires" compat-gcc-32 Needs mock to allow 32bit packages to install for a build. emacs duplicate, the newer builds. gcc same as compat-gcc-32 magma-plugins has dependencies on cman/dlm kernels, which have broken dependencies. rgmanager duplicate, the newer builds. The remained have bugs filed against them now. Michael Matt Domsch wrote: > Rawhide-in-Mock Build Results for x86_64 Architecture Sat May 20 07:59:07 CDT 2006 > Number failed to build: 208 > Number expected to fail due to ExclusiveArch or ExcludeArch: 28 > Leaving: 180 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 14 > ---------------------------------- > cman-kernel > compat-gcc-32 > dlm-kernel > eclipse > elilo (this has a dep on gnu-efi which is ExclusiveArch ia64 right now) > emacs > gcc > GFS-kernel > gnbd-kernel > libselinux > magma-plugins > memtest86+ > rgmanager > tomcat5 > > With bugs filed: 164 > ---------------------------------- > amanda ['191796 NEW'] > arptables_jf ['191688 NEW'] > arts ['192367 ASSIGNED'] > at-spi ['192368 NEW'] > beagle ['191664 NEW'] > bsf ['192369 NEW'] > cairo-java ['192371 NEW'] > classpathx-jaf ['192372 ASSIGNED'] > control-center ['192233 NEW'] > device-mapper-multipath ['192242 NEW'] > e2fsprogs ['192247 NEW'] > eel2 ['191909 NEW'] > ekiga ['191597 NEW'] > eog ['191666 NEW'] > epiphany ['191665 NEW'] > frysk ['192256 NEW'] > gail ['192492 NEW'] > gaim ['192496 NEW'] > gcalctool ['191910 NEW'] > gdk-pixbuf ['192493 NEW'] > gdm ['192494 NEW'] > gecko-sharp2 ['192495 NEW'] > gmime ['192116 CLOSED'] > gnome-media ['192497 NEW'] > gnome-panel ['192498 NEW'] > gnome-python2 ['192499 NEW'] > gnome-python2-desktop ['192500 NEW'] > gnome-python2-extras ['192501 NEW'] > gnome-terminal ['192503 NEW'] > gnome-utils ['191757 NEW'] > gnucash ['192008 CLOSED'] > grub ['192504 NEW'] > gtk-doc ['192505 NEW'] > hal-cups-utils ['192507 NEW'] > hdparm ['192508 NEW'] > HelixPlayer ['192512 NEW'] > ImageMagick ['192036 NEW'] > initscripts ['192509 NEW'] > iptraf ['192510 NEW'] > jakarta-commons-codec ['192511 NEW'] > jakarta-commons-dbcp ['192515 NEW'] > jakarta-commons-el ['192514 NEW'] > jakarta-commons-pool ['192516 NEW'] > jakarta-taglibs-standard ['192517 NEW'] > java-1.4.2-gcj-compat ['192518 NEW'] > jsch ['191668 NEW'] > kdeartwork ['192519 NEW'] > kdebase ['192037 NEW'] > kdebindings ['192520 NEW'] > kdegames ['192521 NEW'] > kdelibs ['192522 NEW'] > kdemultimedia ['192523 NEW'] > kdenetwork ['192525 NEW'] > kdepim ['192526 NEW'] > kdesdk ['192527 NEW'] > kdevelop ['192529 NEW'] > kdewebdev ['191983 NEEDINFO_REPORTER'] > latex2html ['191762 NEW'] > ldapjdk ['192530 NEW'] > libbonoboui ['191728 NEW'] > libgconf-java ['192531 NEW'] > libglade-java ['192532 NEW'] > libnl ['191973 NEW'] > libnotify ['191731 NEW'] > libsemanage ['191733 MODIFIED'] > libvte-java ['192533 NEW'] > libwnck ['191756 NEW'] > lvm2 ['191748 NEW'] > mozilla ['191984 NEW'] > mx4j ['192534 NEW'] > nautilus ['191817 NEW'] > nautilus-sendto ['191818 NEW'] > nfs-utils ['191943 NEW'] > nfs-utils-lib ['191749 NEW'] > notify-daemon ['191810 NEW'] > opal ['191936 NEW'] > openhpi ['191935 NEW'] > pam ['191915 ASSIGNED'] > pango ['191958 NEW'] > perl-XML-Simple ['191911 NEW'] > psgml ['191902 NEW'] > psmisc ['191901 CLOSED'] > pydict ['191898 NEW'] > python-pyblock ['191866 NEW'] > pyxf86config ['191894 NEW'] > reiserfs-utils ['191889 NEW'] > rhythmbox ['191760 NEW'] > scim ['191886 ASSIGNED'] > sound-juicer ['182174 NEW'] > squashfs-tools ['191880 CLOSED'] > stardict ['191878 NEW'] > startup-notification ['191877 NEW'] > struts ['192489 NEW'] > subversion ['191611 NEW'] > syslinux ['192488 NEW'] > system-config-netboot ['192537 NEW'] > tetex ['191874 NEW'] > thunderbird ['191881 NEW'] > tomboy ['191833 NEW'] > tux ['191828 NEW'] > valgrind ['191820 NEW'] > vino ['191827 NEW'] > vixie-cron ['191823 NEW'] > vte ['192484 NEW'] > xdoclet ['192483 NEW'] > xen ['192539 NEW'] > xjavadoc ['192057 NEW'] > xorg-x11-apps ['191896 ASSIGNED'] > xorg-x11-drv-acecad ['191900 ASSIGNED'] > xorg-x11-drv-aiptek ['191903 ASSIGNED'] > xorg-x11-drv-calcomp ['191904 ASSIGNED'] > xorg-x11-drv-citron ['192292 NEW'] > xorg-x11-drv-digitaledge ['192316 NEW'] > xorg-x11-drv-dmc ['192312 NEW'] > xorg-x11-drv-dummy ['192304 NEW'] > xorg-x11-drv-dynapro ['192300 NEW'] > xorg-x11-drv-elo2300 ['192320 NEW'] > xorg-x11-drv-elographics ['192318 NEW'] > xorg-x11-drv-evdev ['192317 NEW'] > xorg-x11-drv-fbdev ['192325 NEW'] > xorg-x11-drv-fpit ['192324 NEW'] > xorg-x11-drv-hyperpen ['192326 NEW'] > xorg-x11-drv-i810 ['192334 NEW'] > xorg-x11-drv-jamstudio ['192335 NEW'] > xorg-x11-drv-joystick ['192336 NEW'] > xorg-x11-drv-keyboard ['192337 NEW'] > xorg-x11-drv-magellan ['192338 NEW'] > xorg-x11-drv-magictouch ['192339 NEW'] > xorg-x11-drv-mga ['192340 NEW'] > xorg-x11-drv-microtouch ['192341 NEW'] > xorg-x11-drv-mutouch ['192342 NEW'] > xorg-x11-drv-nv ['192343 NEW'] > xorg-x11-drv-palmax ['192346 NEW'] > xorg-x11-drv-penmount ['192344 NEW'] > xorg-x11-drv-s3 ['192347 NEW'] > xorg-x11-drv-s3virge ['192348 NEW'] > xorg-x11-drv-savage ['192349 NEW'] > xorg-x11-drv-siliconmotion ['192350 NEW'] > xorg-x11-drv-sis ['192351 NEW'] > xorg-x11-drv-sisusb ['192352 NEW'] > xorg-x11-drv-spaceorb ['192353 NEW'] > xorg-x11-drv-summa ['192354 NEW'] > xorg-x11-drv-tdfx ['192358 NEW'] > xorg-x11-drv-tek4957 ['192357 NEW'] > xorg-x11-drv-trident ['192356 NEW'] > xorg-x11-drv-ur98 ['192360 NEW'] > xorg-x11-drv-vesa ['192359 NEW'] > xorg-x11-drv-vga ['192168 NEW'] > xorg-x11-drv-via ['192167 NEW'] > xorg-x11-drv-vmmouse ['192047 CLOSED'] > xorg-x11-drv-vmware ['192046 NEW'] > xorg-x11-drv-void ['192045 NEW'] > xorg-x11-drv-voodoo ['192042 NEW'] > xorg-x11-fonts ['192038 NEW'] > xorg-x11-resutils ['192040 NEW'] > xorg-x11-server ['192021 NEW'] > xorg-x11-server-utils ['191987 NEW'] > xorg-x11-utils ['191966 ASSIGNED'] > xorg-x11-xdm ['191858 ASSIGNED'] > xorg-x11-xfs ['191856 ASSIGNED'] > xorg-x11-xfwp ['191813 ASSIGNED'] > xorg-x11-xsm ['191802 ASSIGNED'] > xscreensaver ['191769 NEW'] > zsh ['191647 NEW'] > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > From jwboyer at jdub.homelinux.org Sat May 20 20:58:17 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 20 May 2006 15:58:17 -0500 Subject: rawhide rebuild in mock status 2006-05-20 In-Reply-To: <446F7706.1030601@knox.net.nz> References: <20060520131754.GC27962@lists.us.dell.com> <446F7706.1030601@knox.net.nz> Message-ID: <1148158697.5542.7.camel@vader.jdub.homelinux.org> On Sun, 2006-05-21 at 08:07 +1200, Michael J Knox wrote: > cman-kernel > dlm-kernel > gnbd-kernel > GFS-kernel > > These 4 require specific kernel versions, so do these still need to have > bugs filed? I think these 4 are more than just "BuildRequires" They're kernel modules. If you want to file a bug against them, file one to have them start using the kmod stuff that is being used in Extras ;) josh From michael at knox.net.nz Sat May 20 21:00:04 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 21 May 2006 09:00:04 +1200 Subject: rawhide rebuild in mock status 2006-05-20 In-Reply-To: <1148158697.5542.7.camel@vader.jdub.homelinux.org> References: <20060520131754.GC27962@lists.us.dell.com> <446F7706.1030601@knox.net.nz> <1148158697.5542.7.camel@vader.jdub.homelinux.org> Message-ID: <446F8354.3000907@knox.net.nz> Josh Boyer wrote: > On Sun, 2006-05-21 at 08:07 +1200, Michael J Knox wrote: >> cman-kernel >> dlm-kernel >> gnbd-kernel >> GFS-kernel >> >> These 4 require specific kernel versions, so do these still need to have >> bugs filed? I think these 4 are more than just "BuildRequires" > > They're kernel modules. If you want to file a bug against them, file > one to have them start using the kmod stuff that is being used in > Extras ;) Ok, consider it done. Michael From thomas.canniot at laposte.net Sat May 20 22:07:54 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Sun, 21 May 2006 00:07:54 +0200 Subject: rawhide rebuild in mock status 2006-05-20 In-Reply-To: <446F8354.3000907@knox.net.nz> References: <20060520131754.GC27962@lists.us.dell.com> <446F7706.1030601@knox.net.nz> <1148158697.5542.7.camel@vader.jdub.homelinux.org> <446F8354.3000907@knox.net.nz> Message-ID: <1148162875.2753.14.camel@MrTomLinux.workstation> It's very difficult to make updates with yum thses times... I get errno 256 every 5 or 6 downloaded harders ... :/ When it's not this problem, it is a checksum error with the xml of the mirrors. Any explanation ? Le dimanche 21 mai 2006 ? 09:00 +1200, Michael J Knox a ?crit : > Josh Boyer wrote: > > On Sun, 2006-05-21 at 08:07 +1200, Michael J Knox wrote: > >> cman-kernel > >> dlm-kernel > >> gnbd-kernel > >> GFS-kernel > >> > >> These 4 require specific kernel versions, so do these still need to have > >> bugs filed? I think these 4 are more than just "BuildRequires" > > > > They're kernel modules. If you want to file a bug against them, file > > one to have them start using the kmod stuff that is being used in > > Extras ;) > > Ok, consider it done. > > Michael > -- Thomas Canniot http://www.fedoraproject.org/wiki/ThomasCanniot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From scottlove at verizon.net Sat May 20 22:49:16 2006 From: scottlove at verizon.net (SCOTT LOVE) Date: Sat, 20 May 2006 15:49:16 -0700 Subject: Fedora Kernel Sources Message-ID: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> I am trying to install the latest FC 5 sources to do some device driver work. I am following the instructions at http://fedora.redhat.com/docs/release-notes/fc5/#id2983562, but rpm -Uvh kernel-.src.rpm always returns unable to find specified version. For the version number I fill in the value returned from uname -r which is: 2.6.16-1.2111_FC5. Any thoughts on why this is not working to get the sources? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrsam at courier-mta.com Sat May 20 23:02:43 2006 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 20 May 2006 19:02:43 -0400 Subject: Fedora Kernel Sources References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> Message-ID: SCOTT LOVE writes: > I am trying to install the latest FC 5 sources to do some device driver > work.? I am following the instructions at > http://fedo > ra.redhat.com/docs/release-notes/fc5/#id2983562, but > > ? > > rpm -Uvh kernel-.src.rpm?? always returns unable to find > specified version.? For the version number I fill in the value returned > from uname ?r which is: > > ? > > 2.6.16-1.2111_FC5. > > ? > > Any thoughts on why this is not working to get the sources? Did you actually download this file, kernel-2.6.16-1.2111_FC5.src.rpm? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From skvidal at linux.duke.edu Sun May 21 03:31:28 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 20 May 2006 23:31:28 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148155128.12055.25.camel@ender> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> Message-ID: <1148182288.7089.7.camel@cutter> On Sat, 2006-05-20 at 15:58 -0400, Jesse Keating wrote: > On Sun, 2006-05-21 at 07:46 +1200, Michael J Knox wrote: > > > > Is there any point filing the buildrequires bug against compat-gcc in > > this case? > > No. > > > Perhaps mock needs a "feature request" bug report. > > There is some discussion going on about this already. > right now I'm mostly concerned with the idea that in order to build for x86_64 we have to first have i686 built. That sort of works against all the assumptions we've been making for a while. So far I've not heard an explanation for it it has simply been asserted that it must be so. -sv From zaitcev at redhat.com Sun May 21 03:44:38 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 20 May 2006 20:44:38 -0700 Subject: Fedora Kernel Sources In-Reply-To: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> Message-ID: <20060520204438.75cadc16.zaitcev@redhat.com> On Sat, 20 May 2006 15:49:16 -0700, "SCOTT LOVE" wrote: > I am trying to install the latest FC 5 sources to do some device driver > work. [...] I question the need to use Fedora kernel for "some" device driver work. Stock kernel always worked well for me. All my driver work for Fedora was done on Linus' kernel. What are you up to? -- Pete From mpeters at mac.com Sun May 21 04:48:49 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 20 May 2006 21:48:49 -0700 Subject: rawhide rebuild in mock status 2006-05-20 In-Reply-To: <1148158697.5542.7.camel@vader.jdub.homelinux.org> References: <20060520131754.GC27962@lists.us.dell.com> <446F7706.1030601@knox.net.nz> <1148158697.5542.7.camel@vader.jdub.homelinux.org> Message-ID: <1148186930.4296.6.camel@atlantis.mpeters.local> On Sat, 2006-05-20 at 15:58 -0500, Josh Boyer wrote: > On Sun, 2006-05-21 at 08:07 +1200, Michael J Knox wrote: > > cman-kernel > > dlm-kernel > > gnbd-kernel > > GFS-kernel > > > > These 4 require specific kernel versions, so do these still need to have > > bugs filed? I think these 4 are more than just "BuildRequires" > > They're kernel modules. If you want to file a bug against them, file > one to have them start using the kmod stuff that is being used in > Extras ;) That would require the kmod stuff in extras being moved to core, correct? From mharris at mharris.ca Sun May 21 05:16:27 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sun, 21 May 2006 01:16:27 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. Message-ID: <446FF7AB.30301@mharris.ca> Since the introduction of Keith Packard's Xft library to XFree86 years ago, and the second incarnation of Xft coupled with Keith's fontconfig, it seemed natural that at some point in the future, the majority of modern desktop applications being developed would move away from the legacy X Window system's "core fonts" system and use the far superior Xft/fontconfig system. However, since there are a large number of Xt, Xaw, and Motif based applications out there, as well as applications which use other less common toolkits - all of which use the core fonts system, it was obvious that we would need to provide core fonts compatibility in our OS products for the forseeable future. The simplest thing to do, was to just leave the existing system as it was, under the "if it ain't broke, don't fix it" principle, which is what I have pushed for since the Red Hat Linux days when we deprecated xfs and core fonts, reserving the future right to make changes if the need arose. For the last 3 Fedora Core releases, there has been a lot of increasing pressure both in the community, and internally, to reduce the reliance of Fedora Core on the core fonts system, and so this problem has been investigated each release to determine wether it was the right time to make any dramatic changes or not. While the migration from monolithic X.Org 6.8.x to X.Org 7.0 introduced quite a number of rather major changes in the way the X Window System is packaged, maintained and integrates into the OS, we managed to keep the core fonts system intact, and decided to keep xfs as the default solution for Fedora Core 5. Now that we have begun the Fedora Core 6 cycle, this problem domain is once again on the chopping block so to speak, and there is increasing pressure to reduce our dependency on the xfs font server and the legacy core fonts system. In particular, xfs and core fonts does not fit well into the One Laptop Per Child (OLPC) effort, or other Fedora derived embedded distributions. In these embedded systems, or reduced computing environments if you will, every megabyte of disk space and memory counts. Shedding megs of stuff out of the default OS installation is sure to reduce both the memory footprint and disk footprint of the OS installation, which is a net gain for these systems, and also for a lot of the userbase out there that do not use any applications which rely on core fonts. On the other hand, there are many applications included both in Fedora Core, and in Fedora Extras, which do rely on the core fonts system still, and are likely to rely on it for the forseeable future. There are also many 3rd party open source and commercial applications, as well as custom in-house applications that many users and/or companies rely on, and will want to keep working in new OS releases. As such, for the present time and forseeable future, we still need to provide core fonts support in the OS, however in the interest of moving forward, and reducing dependencies on legacy technology, we would like to make the xfs font server an optional part of OS installation, and change the default configuration of the X server to not require xfs. Additionally, the font packages would need to be changed to not have indirect dependencies on xfs (through a dependency on chkfontpath). Since this is a change which is likely to affect many users out there, I thought it was best to discuss this problem with the community right away, and get everyone involved in the problem solving and decision making process, in hopes that we can collectively come up with the best solution overall which balances the needs of all users, while at the same time keeping things as simple as we possibly can. Here is a bit of background on the OLPC issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192416 We look forward to hearing your constructive feedback and suggestions as to how best to attack this problem. Please respond to this thread on-list, and if you have any comments to add to the OLPC bug report above, please feel free to provide some constructive feedback there as well. Thanks in advance for your contributions. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From laroche at redhat.com Sun May 21 06:30:50 2006 From: laroche at redhat.com (Florian La Roche) Date: Sun, 21 May 2006 08:30:50 +0200 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148182288.7089.7.camel@cutter> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> Message-ID: <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> > right now I'm mostly concerned with the idea that in order to build for > x86_64 we have to first have i686 built. > > That sort of works against all the assumptions we've been making for a > while. > > So far I've not heard an explanation for it it has simply been asserted > that it must be so. This is not true for most packages, only very few need to have 32bit packages installed in the buildroot. We anyway build x86_64 and x86 packages on the same machine. Seth, what is your concern here? regards, Florian La Roche From michael at knox.net.nz Sun May 21 07:06:49 2006 From: michael at knox.net.nz (Michael J Knox) Date: Sun, 21 May 2006 19:06:49 +1200 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> Message-ID: <44701189.7040002@knox.net.nz> Florian La Roche wrote: >> right now I'm mostly concerned with the idea that in order to build for >> x86_64 we have to first have i686 built. >> >> That sort of works against all the assumptions we've been making for a >> while. >> >> So far I've not heard an explanation for it it has simply been asserted >> that it must be so. > > This is not true for most packages, only very few need to have > 32bit packages installed in the buildroot. > > We anyway build x86_64 and x86 packages on the same machine. > Seth, what is your concern here? The problem arises when you try to rebuild gcc with mock on x86_64. x86 versions are needed to rebuild for x86_64, if I am understanding this correctly..... This prevents gcc from being built with mock (in its current state/config)... From mock's root.log of gcc-4.1.0-17.src.rpm on x86_64: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-x86_64-core-gcc-4.1.0-17.src.rpm/root resolvedep 'zlib-devel' 'flex' '/usr/lib/libc.so' 'libgnat >= 3.1' 'dejagnu' '/usr/lib64/libc.so' 'libXt-devel' '/lib/libc.so.6' 'libart_lgpl-devel >= 2.1.0' 'gettext' 'gtk2-devel >= 2.4.0' 'glib2-devel >= 2.4.0' 'libXtst-devel' '/lib64/libc.so.6' 'bison' 'glibc-devel >= 2.3.90-2' 'binutils >= 2.16.91.0.3-1' 'gmp-devel >= 4.1.2-8' 'texinfo' 'gcc-gnat >= 3.1' 'alsa-lib-devel' No Package Found for /usr/lib/libc.so No Package Found for /lib/libc.so.6 I hope I am understanding this correctly :) Michael From david.jamison1 at ntlworld.com Sun May 21 07:13:52 2006 From: david.jamison1 at ntlworld.com (David) Date: Sun, 21 May 2006 08:13:52 +0100 Subject: Future Fedora Development Message-ID: <44701330.4030807@ntlworld.com> Hi Folks, Ive just joined this mailing list and I am in intending to get involved with the testing effort within the Feodra project. Just by way of introduction I am based in Belfast Ireland and I work as a software tester within a large software house working predominately on web-site testing with a chunk of interoperability and linkage testing thrown in. My question is probably way "off topic" but none the less I would be interested in hearing peoples comments. I tend to run older hardware because 1. Cost. 2. This older kit provides all the functionality I need at home as Im not big into gaming or heavy multimedia or the like 3. An element of "save the earth". There was an article in the paper yesterday that claims that MS Vista 's full range of tools would be available to less than 5% of all PC's in Britian (presumably this would extrapolate world wide) I was then reading over the thread on PAE and Zen and it occured to me that perhaps the same issue might rise with Fedora? I do fully realise that and OS needs to keep abreast of hardware developments but Im wondering if this has to be to the detriment of the folks like me who tend to run behind the times. Perhaps a solution would be to ask ANACONDA to identify hardware resources available on a box and then provide a suggested build of Fedora to be intstalled that will provide only the functionality the hardware is capable of running sucessfully? Cheers David From elitescripts2000 at yahoo.com Sun May 21 07:49:32 2006 From: elitescripts2000 at yahoo.com (Matt) Date: Sun, 21 May 2006 00:49:32 -0700 (PDT) Subject: Future Fedora Development In-Reply-To: <44701330.4030807@ntlworld.com> Message-ID: <20060521074932.45334.qmail@web31814.mail.mud.yahoo.com> Hi David, I work at Microsoft in the VISTA Firewall team. And I can tell you that VISTA requires about 512 megs, to run. ANd that is just to run the OS. Fedora being GUI as well will never need such requirements as M$ has a HUGE lead over 'Look and Feel' of a GUI based computer experience. THe main thing to worry about is to not worry about VISTA at all... since Vista WILL require computer hardware upgrades 100% guarenttee on that, most will not instantly jump at the idea of VISTA. Unless RAM and CPU along with video card excelleration cards come down in price to compete with Dell < $250 for a cedently powered computer. However, things are only getting FASTER and BIGGER. ( I.e. Hard drives, RAM and Video Memory is BIGGER... CPU, Memory, Bus and interface speeds are getting FASTER ). VISTA I believe is only following the trends in hardware... Microsoft and Open Source will always be Apples and Oranges and one should never compare the two. Its just like debating religion and philosophy... it is to no end. --- David wrote: > Hi Folks, > > Ive just joined this mailing list and I am in intending to get involved > with the testing effort within the Feodra project. Just by way of > introduction I am based in Belfast Ireland and I work as a software > tester within a large software house working predominately on web-site > testing with a chunk of interoperability and linkage testing thrown in. > > My question is probably way "off topic" but none the less I would be > interested in hearing peoples comments. > > I tend to run older hardware because > > 1. Cost. > 2. This older kit provides all the functionality I need at home as Im > not big into gaming or heavy multimedia or the like > 3. An element of "save the earth". > > There was an article in the paper yesterday that claims that MS Vista 's > full range of tools would be available to less than 5% of all PC's in > Britian (presumably this would extrapolate world wide) I was then > reading over the thread on PAE and Zen and it occured to me that perhaps > the same issue might rise with Fedora? > > I do fully realise that and OS needs to keep abreast of hardware > developments but Im wondering if this has to be to the detriment of the > folks like me who tend to run behind the times. > > Perhaps a solution would be to ask ANACONDA to identify hardware > resources available on a box and then provide a suggested build of > Fedora to be intstalled that will provide only the functionality the > hardware is capable of running sucessfully? > > Cheers > > David > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From buildsys at redhat.com Sun May 21 07:58:31 2006 From: buildsys at redhat.com (Build System) Date: Sun, 21 May 2006 03:58:31 -0400 Subject: rawhide report: 20060521 changes Message-ID: <200605210758.k4L7wVEi015410@porkchop.devel.redhat.com> Updated Packages: cups-1:1.2.0-6 -------------- * Sat May 20 2006 Tim Waugh 1:1.2.0-6 - Sync to svn5555. No longer need str1670 or str1705 patches. eel2-2.15.1-2 ------------- * Sun May 21 2006 Matthias Clasen - 2.15.1-2 - Add missing BuildRequires (#129292) eog-2.15.1-2 ------------ * Sat May 20 2006 Matthias Clasen - 2.15.1-2 - Add missing BuildRequires (#129025) gcalctool-5.8.13-2 ------------------ * Sun May 21 2006 Matthias Clasen 5.8.13-2 - Add missing BuildRequires (#191910) gnome-utils-1:2.15.0-2 ---------------------- * Sun May 21 2006 Matthias Clasen 2.15.0-2 - Add missing BuildRequires (#129097) gtkhtml2-2.11.0-1 ----------------- * Sat May 20 2006 Matthew Barnes - 2.11.0-1 - Update to 2.11.0 kernel-2.6.16-1.2208_FC6 ------------------------ * Sat May 20 2006 Dave Jones - 2.6.17rc4-git9 libbonoboui-2.14.0-2 -------------------- * Sun May 21 2006 Matthias Clasen 2.14.0-2 - Add missing BuildRequires (#129104) libwnck-2.15.2-2 ---------------- * Sat May 20 2006 Matthias Clasen - 2.15.2-2 - Fix missing BuildRequires (#129340) nautilus-2.15.1-2 ----------------- * Sun May 21 2006 Matthias Clasen - 2.15.1-2 - Add missing BuildRequires (#129184) * Wed May 17 2006 Matthias Clasen - 2.15.1-1 - Update to 2.15.1 * Fri May 12 2006 Matthias Clasen - 2.14.1-3 - Close the about dialog openoffice.org-1:2.0.3-2.1 -------------------------- * Fri May 19 2006 Caolan McNamara - 1:2.0.3-2.1 - 2.0.3 RC2 - drop rvpapi module - experimental new gtk print dialog * Thu May 18 2006 Caolan McNamara - 1:2.0.3-1.2 - 2.0.3 RC1 - rh#191689# well fine so!, anonymous EXEC mapping is verboten altogether, reimplement three UNO bridges arch with the double file mmap pattern - add openoffice.org-2.0.3.oooXXXXX.vcl.removemenukey.patch for rh#192172# * Mon May 15 2006 Caolan McNamara - 1:2.0.3-0.169.5 - rh#191689# re-add openoffice.org-2.0.3.oooXXXXX.selinux.bridges.patch the upstreamed replacement alloc/mprotect pattern still leaves writable executable mem pango-1.13.1-3 -------------- * Sun May 21 2006 Matthias Clasen - 1.13.1-3 - Add missing BuildRequires (#191958) policycoreutils-1.30.9-4 ------------------------ * Sat May 20 2006 Dan Walsh 1.30.9-4 - Fix exception in genhomedircon selinux-policy-2.2.42-1 ----------------------- * Thu May 18 2006 Dan Walsh 2.2.42-1 - Upgrade to upstream sound-juicer-2.15.2.1-2 ----------------------- * Sat May 20 2006 Matthias Clasen - 2.15.2.1-2 - Add missing BuildRequires (#182174) Broken deps for ppc64 ---------------------------------------------------------- NetworkManager-gnome - 0.6.2-1.fc6.ppc64 requires libnotify.so.0()(64bit) avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.7.2.1-1.ppc64 requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-power-manager - 2.15.2-1.ppc64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ppc64 requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.9.4.1-2.ppc64 requires libnotify.so.0()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU NetworkManager-gnome - 0.6.2-1.fc6.i386 requires libnotify.so.0 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.i386 requires libnotify.so.0 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.i386 requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.i386 requires libnotify.so.0 rhythmbox - 0.9.4.1-2.i386 requires libnotify.so.0 Broken deps for ppc ---------------------------------------------------------- NetworkManager-gnome - 0.6.2-1.fc6.ppc requires libnotify.so.0 evolution - 2.7.2.1-1.ppc requires libnotify.so.0 gnome-power-manager - 2.15.2-1.ppc requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.ppc requires libnotify.so.0 rhythmbox - 0.9.4.1-2.ppc requires libnotify.so.0 Broken deps for ia64 ---------------------------------------------------------- NetworkManager-gnome - 0.6.2-1.fc6.ia64 requires libnotify.so.0()(64bit) evolution - 2.7.2.1-1.ia64 requires libnotify.so.0()(64bit) gnome-power-manager - 2.15.2-1.ia64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ia64 requires libnotify.so.0()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.4.1-2.ia64 requires libnotify.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU NetworkManager-gnome - 0.6.2-1.fc6.x86_64 requires libnotify.so.0()(64bit) cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.x86_64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.x86_64 requires libnotify.so.0()(64bit) rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390 requires libnotify.so.0 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-power-manager - 2.15.2-1.s390 requires libnotify.so.0 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390x requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-power-manager - 2.15.2-1.s390x requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 From fedora at leemhuis.info Sun May 21 08:23:53 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 May 2006 10:23:53 +0200 Subject: rawhide rebuild in mock status 2006-05-20 In-Reply-To: <1148186930.4296.6.camel@atlantis.mpeters.local> References: <20060520131754.GC27962@lists.us.dell.com> <446F7706.1030601@knox.net.nz> <1148158697.5542.7.camel@vader.jdub.homelinux.org> <1148186930.4296.6.camel@atlantis.mpeters.local> Message-ID: <1148199833.2296.9.camel@localhost.localdomain> Am Samstag, den 20.05.2006, 21:48 -0700 schrieb Michael A. Peters: > On Sat, 2006-05-20 at 15:58 -0500, Josh Boyer wrote: > > On Sun, 2006-05-21 at 08:07 +1200, Michael J Knox wrote: > > > cman-kernel > > > dlm-kernel > > > gnbd-kernel > > > GFS-kernel > > > > > > These 4 require specific kernel versions, so do these still need to have > > > bugs filed? I think these 4 are more than just "BuildRequires" > > > > They're kernel modules. If you want to file a bug against them, file > > one to have them start using the kmod stuff that is being used in > > Extras ;) > > That would require the kmod stuff in extras being moved to core, > correct? That's the plan (for a long time already, but we didn't have enough time before FC5). See also: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20060504 [...] 19:02 < thl> | jeremy, warren, we should convert GFS and Co soon (at least before test1) [...] 19:03 < warren> | thl, agreed, I'll push the necessary people. [...] CU thl -- Thorsten Leemhuis From nicolas.mailhot at laposte.net Sun May 21 08:53:37 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 21 May 2006 10:53:37 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <446FF7AB.30301@mharris.ca> References: <446FF7AB.30301@mharris.ca> Message-ID: <1148201620.27847.6.camel@rousalka.dyndns.org> Le dimanche 21 mai 2006 ? 01:16 -0400, Mike A. Harris a ?crit : > However, since there are a large number of Xt, Xaw, and Motif > based applications out there, as well as applications which use > other less common toolkits - all of which use the core fonts > system, it was obvious that we would need to provide core fonts > compatibility in our OS products for the forseeable future. > > The simplest thing to do, was to just leave the existing system > as it was, under the "if it ain't broke, don't fix it" principle, > which is what I have pushed for since the Red Hat Linux days when > we deprecated xfs and core fonts, reserving the future right to > make changes if the need arose. Hi Mike, I can only approve phasing out core fonts one way or another. In fact I'm convinced the last strugglers will *never* move to fontconfig unless Red Hat / Fedora or another big distro exerts a bit of pressure (as was the case for the gcc, utf-8 and selinux migrations), so waiting so long for even making core fonts optional was in the end conterproductive (and OLPC is paying the price today). However I know it's a difficult decision to take, as the users of the bad citizen apps still relying on core fonts are certain to yell loudly near FC-6 release. Good luck, may the force be with you ;) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pemboa at gmail.com Sun May 21 09:08:26 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 21 May 2006 04:08:26 -0500 Subject: Fedora Kernel Sources In-Reply-To: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> Message-ID: <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> On 5/20/06, SCOTT LOVE wrote: > > > > > I am trying to install the latest FC 5 sources to do some device driver > work. I am following the instructions at > http://fedora.redhat.com/docs/release-notes/fc5/#id2983562, > but > > > > rpm -Uvh kernel-.src.rpm always returns unable to find specified > version. For the version number I fill in the value returned from uname ?r > which is: > > > > 2.6.16-1.2111_FC5. > > > > Any thoughts on why this is not working to get the sources? > > > > Scott > -- I am actually in exactly the same boat as you. People over at #fedora seemed reluctant to help, not sure why. I just gave up on using yum for this, and downloaded and installed it manually from here: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/SRPMS/kernel-2.6.16-1.2111_FC5.src.rpm -- To be updated... From tiemann at redhat.com Sun May 21 11:31:52 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Sun, 21 May 2006 07:31:52 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <446FF7AB.30301@mharris.ca> References: <446FF7AB.30301@mharris.ca> Message-ID: <1148211112.4022.5.camel@localhost.localdomain> On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: > In particular, xfs and core fonts does not fit well into the > One Laptop Per Child (OLPC) effort, or other Fedora derived > embedded distributions. In these embedded systems, or > reduced computing environments if you will, every megabyte > of disk space and memory counts. Shedding megs of stuff out > of the default OS installation is sure to reduce both the > memory footprint and disk footprint of the OS installation, > which is a net gain for these systems, and also for a lot > of the userbase out there that do not use any applications > which rely on core fonts. > > On the other hand, there are many applications included both > in Fedora Core, and in Fedora Extras, which do rely on the > core fonts system still, and are likely to rely on it for the > forseeable future. There are also many 3rd party open source > and commercial applications, as well as custom in-house > applications that many users and/or companies rely on, and > will want to keep working in new OS releases. Is it too late for this to be a major thrust of the Fedora Summer of Code projects? Even if it is, I think that such changes create a tremendous amount of opportunity for new folks to step into new leadership roles. I can imagine that at next years OSCON there will be a new crop of hackers who can proudly say "I cleaned up the font cruft in Project XYZ and now maintain its use of the new font system". I also think that given all the stuff that's been going on in Fedora in support of server-side computing, it makes good sense to give some major priority (which can mean major leeway) to client-side computing. M From alan at redhat.com Sun May 21 12:07:22 2006 From: alan at redhat.com (Alan Cox) Date: Sun, 21 May 2006 08:07:22 -0400 Subject: Future Fedora Development In-Reply-To: <44701330.4030807@ntlworld.com> References: <44701330.4030807@ntlworld.com> Message-ID: <20060521120722.GA12199@devserv.devel.redhat.com> On Sun, May 21, 2006 at 08:13:52AM +0100, David wrote: > Perhaps a solution would be to ask ANACONDA to identify hardware > resources available on a box and then provide a suggested build of > Fedora to be intstalled that will provide only the functionality the > hardware is capable of running sucessfully? That may actually be easier to do now in a way, however the stuff that makes the huge difference for small boxes (eg 128MB boxes) is in extras, so you would need to do a basic install then pull Xfce, Sylpheed, abiword from extras rather than gnome/evolution/openoffice. Alan From gauret at free.fr Sun May 21 12:25:23 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 21 May 2006 14:25:23 +0200 Subject: Future Fedora Development References: <44701330.4030807@ntlworld.com> <20060521120722.GA12199@devserv.devel.redhat.com> Message-ID: Alan Cox wrote: > That may actually be easier to do now in a way, however the stuff that > makes the huge difference for small boxes (eg 128MB boxes) is in extras, > so you would need to do a basic install then pull Xfce, Sylpheed, abiword > from extras rather than gnome/evolution/openoffice. Anaconda in FC6 will be able to pull packages directly from extras, right ? At least it's in http://fedoraproject.org/wiki/FC6Future So it might be easier than that, it could be just a matter of tayloring the comps.xml file. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From dwmw2 at infradead.org Sun May 21 12:44:06 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 21 May 2006 13:44:06 +0100 Subject: Fedora Kernel Sources In-Reply-To: <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> Message-ID: <1148215446.3875.275.camel@pmac.infradead.org> On Sun, 2006-05-21 at 04:08 -0500, Arthur Pemberton wrote: > I am actually in exactly the same boat as you. People over at #fedora > seemed reluctant to help, not sure why. Probably because you don't actually need the src.rpm. Install the kernel-devel package which matches your kernel and you'll be able to build modules the normal way; you don't need the full sources for that. -- dwmw2 From dimi at lattica.com Sun May 21 14:23:07 2006 From: dimi at lattica.com (Dimi Paun) Date: Sun, 21 May 2006 10:23:07 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <446FF7AB.30301@mharris.ca> References: <446FF7AB.30301@mharris.ca> Message-ID: <1148221387.1941.13.camel@dimi> On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: > On the other hand, there are many applications included both > in Fedora Core, and in Fedora Extras, which do rely on the > core fonts system still, and are likely to rely on it for the > forseeable future. Great to hear we're moving in this direction. I guess the obvious question is "what will break?". Once we have a clear idea what really depends on xfs (some packages, like wine, _can_ work with xfs if it's the only available option, or without), we can devise a plan of making xfs optional (moved to Extra along with all apps that depend on it?). Regardless, I'm sure such a list would help fix some apps. OSS community is rather good I find at this sort of focused cleanup efforts. -- Dimi Paun Lattica, Inc. From Matt_Domsch at dell.com Sun May 21 14:37:17 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 21 May 2006 09:37:17 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148221387.1941.13.camel@dimi> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> Message-ID: <20060521143717.GA9482@lists.us.dell.com> On Sun, May 21, 2006 at 10:23:07AM -0400, Dimi Paun wrote: > On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: > > On the other hand, there are many applications included both > > in Fedora Core, and in Fedora Extras, which do rely on the > > core fonts system still, and are likely to rely on it for the > > forseeable future. > > Great to hear we're moving in this direction. > > I guess the obvious question is "what will break?". Once we > have a clear idea what really depends on xfs (some packages, > like wine, _can_ work with xfs if it's the only available > option, or without), we can devise a plan of making xfs > optional (moved to Extra along with all apps that depend > on it?). > > Regardless, I'm sure such a list would help fix some apps. > OSS community is rather good I find at this sort of focused > cleanup efforts. +1. See how many BuildRequires are being fixed from a similar QA project. Blocker bug against apps that require xfs, and start tracking those. Thanks, Matt -- 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 mpeters at mac.com Sun May 21 15:38:41 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 21 May 2006 08:38:41 -0700 Subject: Future Fedora Development In-Reply-To: <44701330.4030807@ntlworld.com> References: <44701330.4030807@ntlworld.com> Message-ID: <1148225922.4296.8.camel@atlantis.mpeters.local> On Sun, 2006-05-21 at 08:13 +0100, David wrote: > > I tend to run older hardware because > > 1. Cost. > 2. This older kit provides all the functionality I need at home as Im > not big into gaming or heavy multimedia or the like > 3. An element of "save the earth". Take a look at RULE (Run Up2date Linux Esomething) It's a modified RH/Fedora installer designed specifically to work with older hardware. From mbarnes at redhat.com Sun May 21 16:13:11 2006 From: mbarnes at redhat.com (Matthew Barnes) Date: Sun, 21 May 2006 12:13:11 -0400 Subject: Fedora Kernel Sources In-Reply-To: <1148215446.3875.275.camel@pmac.infradead.org> References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> Message-ID: <1148227991.14242.11.camel@localhost.localdomain> On Sun, 2006-05-21 at 13:44 +0100, David Woodhouse wrote: > Install the kernel-devel package which matches your kernel and you'll be > able to build modules the normal way; you don't need the full sources > for that. On a related note, what ever happened to the kernel-smp and kernel-smp-devel packages? Matt From dcbw at redhat.com Sun May 21 16:56:39 2006 From: dcbw at redhat.com (Dan Williams) Date: Sun, 21 May 2006 12:56:39 -0400 Subject: Fedora Kernel Sources In-Reply-To: <1148227991.14242.11.camel@localhost.localdomain> References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> Message-ID: <1148230599.2473.2.camel@localhost.localdomain> On Sun, 2006-05-21 at 12:13 -0400, Matthew Barnes wrote: > On Sun, 2006-05-21 at 13:44 +0100, David Woodhouse wrote: > > Install the kernel-devel package which matches your kernel and you'll be > > able to build modules the normal way; you don't need the full sources > > for that. > > On a related note, what ever happened to the kernel-smp and > kernel-smp-devel packages? All rawhide kernels now have SMP turned on by default, even for UP machines. On my Latitude 610 (single PIII 1.2GHz) I get: [localhost ~]# uname -a Linux localhost.localdomain 2.6.16-1.2204_FC6 #1 SMP Tue May 16 14:44:33 EDT 2006 i686 i686 i386 GNU/Linux [localhost ~]# rpm -qv kernel kernel-2.6.16-1.2204_FC6 Dan From mbarnes at redhat.com Sun May 21 17:53:27 2006 From: mbarnes at redhat.com (Matthew Barnes) Date: Sun, 21 May 2006 13:53:27 -0400 Subject: Fedora Kernel Sources In-Reply-To: <1148230599.2473.2.camel@localhost.localdomain> References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> Message-ID: <1148234007.17953.4.camel@localhost.localdomain> On Sun, 2006-05-21 at 12:56 -0400, Dan Williams wrote: > All rawhide kernels now have SMP turned on by default, even for UP > machines. > > On my Latitude 610 (single PIII 1.2GHz) I get: > > [localhost ~]# uname -a > Linux localhost.localdomain 2.6.16-1.2204_FC6 #1 SMP Tue May 16 14:44:33 EDT 2006 i686 i686 i386 GNU/Linux > [localhost ~]# rpm -qv kernel > kernel-2.6.16-1.2204_FC6 Okay. I asked because I'm trying to compile VMware's 'vmmon' kernel module, but the vmware-config.pl script complains that the headers in kernel-devel are for a uniprocessor kernel. I don't know how to convince it otherwise. Matt From Matt_Domsch at dell.com Sun May 21 19:30:37 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 21 May 2006 14:30:37 -0500 Subject: rawhide rebuild in mock status 2006-05-21 Message-ID: <20060521193037.GA21217@lists.us.dell.com> Rawhide-in-Mock Build Results for x86_64 Architecture Sun May 21 13:02:57 CDT 2006 Number failed to build: 199 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 171 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 7 ---------------------------------- compat-gcc-32 elilo emacs gcc magma-plugins rgmanager (the above are all well understood; can someone nuke the old emacs and rgmanager srpms from the tree?) tomcat5 With bugs filed: 162 ---------------------------------- amanda ['191796 NEW'] arptables_jf ['191688 NEW'] arts ['192367 ASSIGNED'] at-spi ['192368 NEW'] beagle ['191664 NEW'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEW'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] eclipse ['192563 NEW'] ekiga ['191597 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gail ['192492 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gdm ['192494 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gmime ['192116 CLOSED'] gnbd-kernel ['192573 NEW'] gnome-media ['192497 NEW'] gnome-panel ['192498 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 NEW'] gnome-python2-extras ['192501 NEW'] gnome-terminal ['192503 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] gtk-doc ['192505 NEW'] hal-cups-utils ['192507 NEW'] hdparm ['192508 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] initscripts ['192509 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdebindings ['192520 NEW'] kdegames ['192521 NEW'] kdelibs ['192522 NEW'] kdemultimedia ['192523 NEW'] kdenetwork ['192525 NEW'] kdepim ['192526 NEW'] kdesdk ['192527 NEW'] kdevelop ['192529 NEW'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libselinux ['192562 NEW'] libsemanage ['191733 MODIFIED'] libvte-java ['192533 NEW'] lvm2 ['191748 NEW'] memtest86+ ['192561 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEW'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] startup-notification ['191877 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 NEW'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vino ['191827 NEW'] vixie-cron ['191823 NEW'] vte ['192484 NEW'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 NEW'] xorg-x11-drv-digitaledge ['192316 NEW'] xorg-x11-drv-dmc ['192312 NEW'] xorg-x11-drv-dummy ['192304 NEW'] xorg-x11-drv-dynapro ['192300 NEW'] xorg-x11-drv-elo2300 ['192320 NEW'] xorg-x11-drv-elographics ['192318 NEW'] xorg-x11-drv-evdev ['192317 NEW'] xorg-x11-drv-fbdev ['192325 NEW'] xorg-x11-drv-fpit ['192324 NEW'] xorg-x11-drv-hyperpen ['192326 NEW'] xorg-x11-drv-i810 ['192334 NEW'] xorg-x11-drv-jamstudio ['192335 NEW'] xorg-x11-drv-joystick ['192336 NEW'] xorg-x11-drv-keyboard ['192337 NEW'] xorg-x11-drv-magellan ['192338 NEW'] xorg-x11-drv-magictouch ['192339 NEW'] xorg-x11-drv-mga ['192340 NEW'] xorg-x11-drv-microtouch ['192341 NEW'] xorg-x11-drv-mutouch ['192342 NEW'] xorg-x11-drv-nv ['192343 NEW'] xorg-x11-drv-palmax ['192346 NEW'] xorg-x11-drv-penmount ['192344 NEW'] xorg-x11-drv-s3 ['192347 NEW'] xorg-x11-drv-s3virge ['192348 NEW'] xorg-x11-drv-savage ['192349 NEW'] xorg-x11-drv-siliconmotion ['192350 NEW'] xorg-x11-drv-sis ['192351 NEW'] xorg-x11-drv-sisusb ['192352 NEW'] xorg-x11-drv-spaceorb ['192353 NEW'] xorg-x11-drv-summa ['192354 NEW'] xorg-x11-drv-tdfx ['192358 NEW'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 NEW'] xorg-x11-drv-ur98 ['192360 NEW'] xorg-x11-drv-vesa ['192359 NEW'] xorg-x11-drv-vga ['192168 NEW'] xorg-x11-drv-via ['192167 NEW'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 NEW'] xorg-x11-drv-void ['192045 NEW'] xorg-x11-drv-voodoo ['192042 NEW'] xorg-x11-fonts ['192038 NEW'] xorg-x11-resutils ['192040 NEW'] xorg-x11-server ['192021 NEW'] xorg-x11-server-utils ['191987 NEW'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ From michael at knox.net.nz Sun May 21 19:36:20 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Mon, 22 May 2006 07:36:20 +1200 Subject: rawhide rebuild in mock status 2006-05-21 In-Reply-To: <20060521193037.GA21217@lists.us.dell.com> References: <20060521193037.GA21217@lists.us.dell.com> Message-ID: <4470C134.8090103@knox.net.nz> tomcat5 = bz#192565 Michael Matt Domsch wrote: > Rawhide-in-Mock Build Results for x86_64 Architecture Sun May 21 13:02:57 CDT 2006 > Number failed to build: 199 > Number expected to fail due to ExclusiveArch or ExcludeArch: 28 > Leaving: 171 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 7 > ---------------------------------- > compat-gcc-32 > elilo > emacs > gcc > magma-plugins > rgmanager > (the above are all well understood; can someone nuke the old emacs and > rgmanager srpms from the tree?) > tomcat5 > > With bugs filed: 162 > ---------------------------------- > amanda ['191796 NEW'] > arptables_jf ['191688 NEW'] > arts ['192367 ASSIGNED'] > at-spi ['192368 NEW'] > beagle ['191664 NEW'] > bsf ['192369 NEW'] > cairo-java ['192371 NEW'] > classpathx-jaf ['192372 ASSIGNED'] > cman-kernel ['192570 NEW'] > control-center ['192233 NEW'] > device-mapper-multipath ['192242 NEW'] > dlm-kernel ['192572 NEW'] > e2fsprogs ['192247 NEW'] > eclipse ['192563 NEW'] > ekiga ['191597 NEW'] > epiphany ['191665 NEW'] > frysk ['192256 NEW'] > gail ['192492 NEW'] > gaim ['192496 NEW'] > gdk-pixbuf ['192493 NEW'] > gdm ['192494 NEW'] > gecko-sharp2 ['192495 NEW'] > GFS-kernel ['192569 NEW'] > gmime ['192116 CLOSED'] > gnbd-kernel ['192573 NEW'] > gnome-media ['192497 NEW'] > gnome-panel ['192498 NEW'] > gnome-python2 ['192499 NEW'] > gnome-python2-desktop ['192500 NEW'] > gnome-python2-extras ['192501 NEW'] > gnome-terminal ['192503 NEW'] > gnucash ['192008 CLOSED'] > grub ['192504 NEW'] > gtk-doc ['192505 NEW'] > hal-cups-utils ['192507 NEW'] > hdparm ['192508 NEW'] > HelixPlayer ['192512 NEW'] > ImageMagick ['192036 NEW'] > initscripts ['192509 NEW'] > iptraf ['192510 NEW'] > jakarta-commons-codec ['192511 NEW'] > jakarta-commons-dbcp ['192515 NEW'] > jakarta-commons-el ['192514 NEW'] > jakarta-commons-pool ['192516 NEW'] > jakarta-taglibs-standard ['192517 NEW'] > java-1.4.2-gcj-compat ['192518 NEW'] > jsch ['191668 NEW'] > kdeartwork ['192519 NEW'] > kdebase ['192037 NEW'] > kdebindings ['192520 NEW'] > kdegames ['192521 NEW'] > kdelibs ['192522 NEW'] > kdemultimedia ['192523 NEW'] > kdenetwork ['192525 NEW'] > kdepim ['192526 NEW'] > kdesdk ['192527 NEW'] > kdevelop ['192529 NEW'] > kdewebdev ['191983 NEEDINFO_REPORTER'] > latex2html ['191762 NEW'] > ldapjdk ['192530 NEW'] > libgconf-java ['192531 NEW'] > libglade-java ['192532 NEW'] > libnl ['191973 NEW'] > libnotify ['191731 NEW'] > libselinux ['192562 NEW'] > libsemanage ['191733 MODIFIED'] > libvte-java ['192533 NEW'] > lvm2 ['191748 NEW'] > memtest86+ ['192561 NEW'] > mozilla ['191984 NEW'] > mx4j ['192534 NEW'] > nautilus-sendto ['191818 NEW'] > nfs-utils ['191943 NEW'] > nfs-utils-lib ['191749 NEW'] > notify-daemon ['191810 NEW'] > opal ['191936 NEW'] > openhpi ['191935 NEW'] > pam ['191915 ASSIGNED'] > perl-XML-Simple ['191911 NEW'] > psgml ['191902 NEW'] > psmisc ['191901 CLOSED'] > pydict ['191898 NEW'] > python-pyblock ['191866 NEW'] > pyxf86config ['191894 NEW'] > reiserfs-utils ['191889 NEW'] > rhythmbox ['191760 CLOSED'] > scim ['191886 ASSIGNED'] > squashfs-tools ['191880 CLOSED'] > stardict ['191878 NEW'] > startup-notification ['191877 NEW'] > struts ['192489 NEW'] > subversion ['191611 NEW'] > syslinux ['192488 NEW'] > system-config-netboot ['192537 NEW'] > tetex ['191874 NEW'] > thunderbird ['191881 NEW'] > tomboy ['191833 NEW'] > tux ['191828 NEW'] > valgrind ['191820 NEW'] > vino ['191827 NEW'] > vixie-cron ['191823 NEW'] > vte ['192484 NEW'] > xdoclet ['192483 NEW'] > xen ['192539 NEW'] > xjavadoc ['192057 NEW'] > xorg-x11-apps ['191896 ASSIGNED'] > xorg-x11-drv-acecad ['191900 ASSIGNED'] > xorg-x11-drv-aiptek ['191903 ASSIGNED'] > xorg-x11-drv-calcomp ['191904 ASSIGNED'] > xorg-x11-drv-citron ['192292 NEW'] > xorg-x11-drv-digitaledge ['192316 NEW'] > xorg-x11-drv-dmc ['192312 NEW'] > xorg-x11-drv-dummy ['192304 NEW'] > xorg-x11-drv-dynapro ['192300 NEW'] > xorg-x11-drv-elo2300 ['192320 NEW'] > xorg-x11-drv-elographics ['192318 NEW'] > xorg-x11-drv-evdev ['192317 NEW'] > xorg-x11-drv-fbdev ['192325 NEW'] > xorg-x11-drv-fpit ['192324 NEW'] > xorg-x11-drv-hyperpen ['192326 NEW'] > xorg-x11-drv-i810 ['192334 NEW'] > xorg-x11-drv-jamstudio ['192335 NEW'] > xorg-x11-drv-joystick ['192336 NEW'] > xorg-x11-drv-keyboard ['192337 NEW'] > xorg-x11-drv-magellan ['192338 NEW'] > xorg-x11-drv-magictouch ['192339 NEW'] > xorg-x11-drv-mga ['192340 NEW'] > xorg-x11-drv-microtouch ['192341 NEW'] > xorg-x11-drv-mutouch ['192342 NEW'] > xorg-x11-drv-nv ['192343 NEW'] > xorg-x11-drv-palmax ['192346 NEW'] > xorg-x11-drv-penmount ['192344 NEW'] > xorg-x11-drv-s3 ['192347 NEW'] > xorg-x11-drv-s3virge ['192348 NEW'] > xorg-x11-drv-savage ['192349 NEW'] > xorg-x11-drv-siliconmotion ['192350 NEW'] > xorg-x11-drv-sis ['192351 NEW'] > xorg-x11-drv-sisusb ['192352 NEW'] > xorg-x11-drv-spaceorb ['192353 NEW'] > xorg-x11-drv-summa ['192354 NEW'] > xorg-x11-drv-tdfx ['192358 NEW'] > xorg-x11-drv-tek4957 ['192357 NEW'] > xorg-x11-drv-trident ['192356 NEW'] > xorg-x11-drv-ur98 ['192360 NEW'] > xorg-x11-drv-vesa ['192359 NEW'] > xorg-x11-drv-vga ['192168 NEW'] > xorg-x11-drv-via ['192167 NEW'] > xorg-x11-drv-vmmouse ['192047 CLOSED'] > xorg-x11-drv-vmware ['192046 NEW'] > xorg-x11-drv-void ['192045 NEW'] > xorg-x11-drv-voodoo ['192042 NEW'] > xorg-x11-fonts ['192038 NEW'] > xorg-x11-resutils ['192040 NEW'] > xorg-x11-server ['192021 NEW'] > xorg-x11-server-utils ['191987 NEW'] > xorg-x11-utils ['191966 ASSIGNED'] > xorg-x11-xdm ['191858 ASSIGNED'] > xorg-x11-xfs ['191856 ASSIGNED'] > xorg-x11-xfwp ['191813 ASSIGNED'] > xorg-x11-xsm ['191802 ASSIGNED'] > xscreensaver ['191769 NEW'] > zsh ['191647 NEW'] > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ > From sdl.web at gmail.com Sun May 21 19:36:51 2006 From: sdl.web at gmail.com (Leon) Date: Sun, 21 May 2006 20:36:51 +0100 Subject: Fedora Kernel Sources References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> Message-ID: Dan Williams writes: > On Sun, 2006-05-21 at 12:13 -0400, Matthew Barnes wrote: >> On Sun, 2006-05-21 at 13:44 +0100, David Woodhouse wrote: >> > Install the kernel-devel package which matches your kernel and you'll be >> > able to build modules the normal way; you don't need the full sources >> > for that. >> >> On a related note, what ever happened to the kernel-smp and >> kernel-smp-devel packages? > > All rawhide kernels now have SMP turned on by default, even for UP > machines. Any benefit of this? > > On my Latitude 610 (single PIII 1.2GHz) I get: > > [localhost ~]# uname -a > Linux localhost.localdomain 2.6.16-1.2204_FC6 #1 SMP Tue May 16 14:44:33 EDT 2006 i686 i686 i386 GNU/Linux > [localhost ~]# rpm -qv kernel > kernel-2.6.16-1.2204_FC6 > > Dan -- Leon From davej at redhat.com Sun May 21 19:43:36 2006 From: davej at redhat.com (Dave Jones) Date: Sun, 21 May 2006 15:43:36 -0400 Subject: Fedora Kernel Sources In-Reply-To: References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> Message-ID: <20060521194336.GI8250@redhat.com> On Sun, May 21, 2006 at 08:36:51PM +0100, Leon wrote: > >> > Install the kernel-devel package which matches your kernel and you'll be > >> > able to build modules the normal way; you don't need the full sources > >> > for that. > >> > >> On a related note, what ever happened to the kernel-smp and > >> kernel-smp-devel packages? > > > > All rawhide kernels now have SMP turned on by default, even for UP > > machines. > > Any benefit of this? Takes up less space on CD / mirrors, quicker build times, negligable overhead. Right now it's an experiment, it may turn out to be a bad idea. We'll see how things look after FC6-test1 results come back. Dave -- http://www.codemonkey.org.uk From jacliburn at bellsouth.net Sun May 21 19:43:24 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 21 May 2006 14:43:24 -0500 Subject: Via Velocity minimum MTU size Message-ID: <1148240604.2329.9.camel@osprey.hogchain.net> I'm trying to set the MTU size on my Via Velocity 6122 Gbit adapter from the default of 1500 down to 1492, but I keep getting this error: [root at osprey ~]# ifconfig eth0 mtu 1492 SIOCSIFMTU: Invalid argument Turns out that via-velocity.h defines the minimum MTU at 1500 bytes. #define VELOCITY_MIN_MTU (1514-14) #define VELOCITY_MAX_MTU (9000) And via-velocity.c enforces the limit. if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) { VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n", vptr->dev->name); return -EINVAL; } This is an Abit AV8 motherboard with an Athlon64 3000+ cpu running 2.6.16-1.2111_FC5 x86_64. Can someone explain why the driver might constrain the NIC to a minimum MTU size of 1500? Thanks, Jay From davej at redhat.com Sun May 21 19:48:59 2006 From: davej at redhat.com (Dave Jones) Date: Sun, 21 May 2006 15:48:59 -0400 Subject: Via Velocity minimum MTU size In-Reply-To: <1148240604.2329.9.camel@osprey.hogchain.net> References: <1148240604.2329.9.camel@osprey.hogchain.net> Message-ID: <20060521194859.GK8250@redhat.com> On Sun, May 21, 2006 at 02:43:24PM -0500, Jay Cliburn wrote: > I'm trying to set the MTU size on my Via Velocity 6122 Gbit adapter from > the default of 1500 down to 1492, but I keep getting this error: > > [root at osprey ~]# ifconfig eth0 mtu 1492 > SIOCSIFMTU: Invalid argument > > Turns out that via-velocity.h defines the minimum MTU at 1500 bytes. > > #define VELOCITY_MIN_MTU (1514-14) > #define VELOCITY_MAX_MTU (9000) > > And via-velocity.c enforces the limit. > > if ((new_mtu < VELOCITY_MIN_MTU) || new_mtu > (VELOCITY_MAX_MTU)) { > VELOCITY_PRT(MSG_LEVEL_ERR, KERN_NOTICE "%s: Invalid MTU.\n", > vptr->dev->name); > return -EINVAL; > } > > This is an Abit AV8 motherboard with an Athlon64 3000+ cpu running > 2.6.16-1.2111_FC5 x86_64. > > Can someone explain why the driver might constrain the NIC to a minimum > MTU size of 1500? Asking the developers on netdev at vger.kernel.org is going to get you the answer faster than asking here. Dave -- http://www.codemonkey.org.uk From david.jamison1 at ntlworld.com Sun May 21 20:15:12 2006 From: david.jamison1 at ntlworld.com (David) Date: Sun, 21 May 2006 21:15:12 +0100 Subject: Future Fedora Development In-Reply-To: <1148225922.4296.8.camel@atlantis.mpeters.local> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> Message-ID: <4470CA50.8060000@ntlworld.com> > > > Thanks for all the comments. Just a few points and comments. 1. I would hasten to say that it was not my intent to directly compare Linux with Vista I was really just trying to say look this is the direction Vista is going in relation to hardware and my worry is that Fedora would go likewise where the opportunity not to do so exists. As a result of the Vista upgrade there should be another glut of cheap second hand hardware for me to run Linux on!!!!!!!! 2. Looking at the FC6 Future. I found the following Trim down core Packages that provide duplicate functionality in Fedora Core, or that aren't essential to a basic operating system, should move to Extras. Several ideas exist around this: * Main distro down to 1 or 2 discs - its growing too much * Main distro down to 1 disk + 1 disk gnome, 1 kde, one java, 1 other stuff * All stuff for personal install and the support for the most important languages (???) on the first two CDs. Big stuff like openoffice-lang-support for not that important langages only in extras? To me this is bang on message. My vote would be to have the initial install go either one of two ways. a. As previously mentioned design Anaconda to have hardware detection built in and install accordingly. I suppose the issue here might be achieving 100% detection of hardware. b. If it were possible move the main distro down to 1 disc per the second option above and then YUM everything else. This Im guessing presupposes users have access to a reasonably fast internet connection and some knowledge of thier requirements. Would a third route perhaps be a live-distro CD boot from that and pull requirements down via the internet? Cheers D From david.jamison1 at ntlworld.com Sun May 21 20:30:14 2006 From: david.jamison1 at ntlworld.com (David) Date: Sun, 21 May 2006 21:30:14 +0100 Subject: Future Fedora Development In-Reply-To: <1148225922.4296.8.camel@atlantis.mpeters.local> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> Message-ID: <4470CDD6.7040300@ntlworld.com> Michael A. Peters wrote: >On Sun, 2006-05-21 at 08:13 +0100, David wrote: > > > >>I tend to run older hardware because >> >>1. Cost. >>2. This older kit provides all the functionality I need at home as Im >>not big into gaming or heavy multimedia or the like >>3. An element of "save the earth". >> >> > >Take a look at RULE (Run Up2date Linux Esomething) >It's a modified RH/Fedora installer designed specifically to work with >older hardware. > > > I have used RULE in the past and come to think of it I seem to have dropped off thier mailing list when they moved servers. Totally coincdentally I tripped over the Pentium II box I had RULE running on so Ill try a reinstall with the Fedora Slinky. Incidentally the Slinky Detect and DAn: Distro Analyizer tool discussion on their site http://www.rule-project.org might be pertinent! Cheers D From nicolas.mailhot at laposte.net Sun May 21 20:39:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 21 May 2006 22:39:40 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060521143717.GA9482@lists.us.dell.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> Message-ID: <1148243982.8958.4.camel@rousalka.dyndns.org> Le dimanche 21 mai 2006 ? 09:37 -0500, Matt Domsch a ?crit : > On Sun, May 21, 2006 at 10:23:07AM -0400, Dimi Paun wrote: > > Regardless, I'm sure such a list would help fix some apps. > > OSS community is rather good I find at this sort of focused > > cleanup efforts. > > +1. See how many BuildRequires are being fixed from a similar QA > project. Blocker bug against apps that require xfs, and start > tracking those. To be fair Mike carefully avoided talking about RHEL, and the major offenders are in the entreprise space : - java apps (which do not run with gcj) : oracle tools... - motif apps - tcl/tk apps - gtk1 apps - etc In the pure FOSS world you have the emacsen but I think that's pretty much the only major FOSS apps not moved to fontconfig yet. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kloczek at zie.pg.gda.pl Sun May 21 21:00:45 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Sun, 21 May 2006 23:00:45 +0200 Subject: Future Fedora Development In-Reply-To: <4470CA50.8060000@ntlworld.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> Message-ID: <1148245245.21278.22.camel@kloczek01.pracownicy.zie> Dnia 21-05-2006, nie o godzinie 21:15 +0100, David napisa?(a): > > > > > > > Thanks for all the comments. Just a few points and comments. > > 1. I would hasten to say that it was not my intent to directly compare > Linux with Vista I was really just trying to say look this is the > direction Vista is going in relation to hardware and my worry is that > Fedora would go likewise where the opportunity not to do so exists. As > a result of the Vista upgrade there should be another glut of cheap > second hand hardware for me to run Linux on!!!!!!!! > > 2. Looking at the FC6 Future. I found the following > > Trim down core > > Packages that provide duplicate functionality in Fedora Core, or that > aren't essential to a basic operating system, should move to Extras. > > Several ideas exist around this: > > * > > Main distro down to 1 or 2 discs - its growing too much It will be good remove multiple implementation of: - term toolkit (lang, libtermcap and ncurses). Use only ncurses will fit all what is neccessary,. Patching all program for use libncursesw will allow remove distribute libncurses library (now are distributed libncurses and libncursesw) and move libncurses to kind compat-ncurses package. - multiple digests operation (openssl, gnutls, nss .. some programs are now linked with *all* avalaible implemntations 8-0 ), - multipme XML parsers. Now some programs are linked with more than one XML parser library. For example fontconfig now uses expat but can be on build stage compiled as using libxml2 .. but most GNOME programs uses libxml2. This is only few points from much more larger list. For example now in Fedora is avalaible libdbi but there is no other programs which uses this library .. except dictd which unondiotionaly if will find libdbi on autoconf level causes compile dbi dictd pliugin (anyone uses this ? one persone or more ?). Why this unused piece of was added to distributed packages list ? More .. why many packages do not have separated devel resources ? Why so many packages still have static libraries and .la files ? Why so many packages still build static libraries and and removes this on %install sttage if on %build can be added --disable-static to autoconf options ? kloczek From sdl.web at gmail.com Sun May 21 21:04:23 2006 From: sdl.web at gmail.com (Leon) Date: Sun, 21 May 2006 22:04:23 +0100 Subject: Fedora Kernel Sources References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> <20060521194336.GI8250@redhat.com> Message-ID: Dave Jones writes: > On Sun, May 21, 2006 at 08:36:51PM +0100, Leon wrote: > > > >> > Install the kernel-devel package which matches your kernel and you'll be > > >> > able to build modules the normal way; you don't need the full sources > > >> > for that. > > >> > > >> On a related note, what ever happened to the kernel-smp and > > >> kernel-smp-devel packages? > > > > > > All rawhide kernels now have SMP turned on by default, even for UP > > > machines. > > > > Any benefit of this? > > Takes up less space on CD / mirrors, quicker build times, negligable overhead. > Right now it's an experiment, it may turn out to be a bad idea. We'll see > how things look after FC6-test1 results come back. > > Dave > Would it compromise the performance of uni processor machines? -- Leon From arjan at fenrus.demon.nl Sun May 21 21:13:03 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 21 May 2006 23:13:03 +0200 Subject: Fedora Kernel Sources In-Reply-To: References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> <20060521194336.GI8250@redhat.com> Message-ID: <1148245983.3902.41.camel@laptopd505.fenrus.org> > Would it compromise the performance of uni processor machines? the actual smp-or-not.. not so much anymore now that the lock prefixes get patched out at runtime. If the kernel also has PAE enabled you pay a noticable 6% or so. But then that won't boot on many machines so I doubt that's the case. From zaitcev at redhat.com Sun May 21 21:17:47 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sun, 21 May 2006 14:17:47 -0700 Subject: Fedora Kernel Sources In-Reply-To: References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> <20060521194336.GI8250@redhat.com> Message-ID: <20060521141747.6a257fc5.zaitcev@redhat.com> On Sun, 21 May 2006 22:04:23 +0100, Leon wrote: > Would it compromise the performance of uni processor machines? We support SMP Alternatives now, so not so much anymore. It should not be measurable. -- Pete From vonbrand at inf.utfsm.cl Sun May 21 20:38:57 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 21 May 2006 16:38:57 -0400 Subject: Future Fedora Development In-Reply-To: Your message of "Sun, 21 May 2006 21:15:12 +0100." <4470CA50.8060000@ntlworld.com> Message-ID: <200605212039.k4LKcvrm015588@laptop11.inf.utfsm.cl> David wrote: > Thanks for all the comments. Just a few points and comments. [...] > To me this is bang on message. My vote would be to have the initial > install go either one of two ways. > > a. As previously mentioned design Anaconda to have hardware detection > built in and install accordingly. I suppose the issue here might be > achieving 100% detection of hardware. Would be nice. But then again, the people I know with "limited hardware" are just in for /very/ personalized installations (i.e., setting up a router, firewall, file server, print server, ...) > b. If it were possible move the main distro down to 1 disc per the > second option above and then YUM everything else. This Im guessing > presupposes users have access to a reasonably fast internet connection > and some knowledge of thier requirements. Most people around here don't have "reasonably fast internet connections"... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From dimi at lattica.com Sun May 21 21:32:31 2006 From: dimi at lattica.com (Dimi Paun) Date: Sun, 21 May 2006 17:32:31 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148243982.8958.4.camel@rousalka.dyndns.org> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> Message-ID: <1148247151.1941.15.camel@dimi> On Sun, 2006-05-21 at 22:39 +0200, Nicolas Mailhot wrote: > To be fair Mike carefully avoided talking about RHEL, and the major > offenders are in the entreprise space True, but it would still be quite good to know how affected Fedora would be. RHEL is a different bowl of wax :) -- Dimi Paun Lattica, Inc. From sdl.web at gmail.com Sun May 21 21:33:02 2006 From: sdl.web at gmail.com (Leon) Date: Sun, 21 May 2006 22:33:02 +0100 Subject: Fedora Kernel Sources References: <0IZL00J0Y622P4S5@vms044.mailsrvcs.net> <16de708d0605210208i7118c3a7j12ea3e2d708598b0@mail.gmail.com> <1148215446.3875.275.camel@pmac.infradead.org> <1148227991.14242.11.camel@localhost.localdomain> <1148230599.2473.2.camel@localhost.localdomain> <20060521194336.GI8250@redhat.com> Message-ID: Thank you for answering, Arjan and Pete. -- Leon From jakub at redhat.com Sun May 21 21:37:54 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Sun, 21 May 2006 17:37:54 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148182288.7089.7.camel@cutter> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> Message-ID: <20060521213754.GA30682@devserv.devel.redhat.com> On Sat, May 20, 2006 at 11:31:28PM -0400, seth vidal wrote: > right now I'm mostly concerned with the idea that in order to build for > x86_64 we have to first have i686 built. The dependency is that to build x86_64 gcc you need i[36]86 and x86_64 glibc{,-devel} (similarly for ppc that needs ppc{,64} glibc{,-devel}, ppc64 needs ppc{64,}, s390x needs s390{,x}). We want gcc to support both -m64 and -m32 on the arches where this is possible, and for multilib support both arches of glibc development are needed. Jakub From skvidal at linux.duke.edu Sun May 21 23:18:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 21 May 2006 19:18:36 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> Message-ID: <1148253516.7089.32.camel@cutter> On Sun, 2006-05-21 at 08:30 +0200, Florian La Roche wrote: > > right now I'm mostly concerned with the idea that in order to build for > > x86_64 we have to first have i686 built. > > > > That sort of works against all the assumptions we've been making for a > > while. > > > > So far I've not heard an explanation for it it has simply been asserted > > that it must be so. > > This is not true for most packages, only very few need to have > 32bit packages installed in the buildroot. > > We anyway build x86_64 and x86 packages on the same machine. > Seth, what is your concern here? That it feels wrong and klunky to have to have a working i686 distribution before we can have a working x86_64 distribution. I know it's not the goal of fedora but at some point I would hope we could just rid ourselves of i686 forever once x86_64 saturation is sufficiently complete. Anyway to fix the problem for the mock case in your mock.cfg make it look like this: [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 exclude=*.i386 *.486 *.586 *.i686 *.athlon includepkgs=glibc*.i686 *.x86_64 *.ia32e *.noarch that should allow for the specific packages you want. whomever is running against this error, please let me know if the above succeeds. thanks, -sv From skvidal at linux.duke.edu Sun May 21 23:21:59 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 21 May 2006 19:21:59 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148253516.7089.32.camel@cutter> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> <1148253516.7089.32.camel@cutter> Message-ID: <1148253719.7089.34.camel@cutter> On Sun, 2006-05-21 at 19:18 -0400, seth vidal wrote: > [main] > cachedir=/var/cache/yum > debuglevel=1 > reposdir=/dev/null > logfile=/var/log/yum.log > retries=20 > obsoletes=1 > gpgcheck=0 > assumeyes=1 > exclude=*.i386 *.486 *.586 *.i686 *.athlon > includepkgs=glibc*.i686 *.x86_64 *.ia32e *.noarch > whoops :) remove the 'exclude=' line, too. :) -sv From jacliburn at bellsouth.net Mon May 22 02:57:26 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 21 May 2006 21:57:26 -0500 Subject: Via Velocity minimum MTU size In-Reply-To: <20060521194859.GK8250@redhat.com> References: <1148240604.2329.9.camel@osprey.hogchain.net> <20060521194859.GK8250@redhat.com> Message-ID: <1148266646.2329.18.camel@osprey.hogchain.net> On Sun, 2006-05-21 at 15:48 -0400, Dave Jones wrote: > > Can someone explain why the driver might constrain the NIC to a minimum > > MTU size of 1500? > > Asking the developers on netdev at vger.kernel.org is going to get > you the answer faster than asking here. > > Dave Thanks Dave. Done. From Matt_Domsch at dell.com Mon May 22 03:06:58 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 21 May 2006 22:06:58 -0500 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148253719.7089.34.camel@cutter> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> <1148253516.7089.32.camel@cutter> <1148253719.7089.34.camel@cutter> Message-ID: <20060522030658.GB21217@lists.us.dell.com> On Sun, May 21, 2006 at 07:21:59PM -0400, seth vidal wrote: > On Sun, 2006-05-21 at 19:18 -0400, seth vidal wrote: > > > [main] > > cachedir=/var/cache/yum > > debuglevel=1 > > reposdir=/dev/null > > logfile=/var/log/yum.log > > retries=20 > > obsoletes=1 > > gpgcheck=0 > > assumeyes=1 > > exclude=*.i386 *.486 *.586 *.i686 *.athlon > > includepkgs=glibc*.i686 *.x86_64 *.ia32e *.noarch > > > > whoops :) > > remove the 'exclude=' line, too. :) yep. includepkgs=glibc*.i686 is what I did. It's the smallest change that lets them build. Well, almost, as gcc got stuck on something to do with Ada. But compat-gcc-32 built now. checking whether compiler driver understands Ada... no ... configure: error: The following requested languages could not be built: ada Recognised languages are: c,ada,c++,fortran,java,objc,obj-c++,treelang -- 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 nmiell at comcast.net Mon May 22 03:29:34 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sun, 21 May 2006 20:29:34 -0700 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <20060522030658.GB21217@lists.us.dell.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521063050.GA7251@dudweiler.stuttgart.redhat.com> <1148253516.7089.32.camel@cutter> <1148253719.7089.34.camel@cutter> <20060522030658.GB21217@lists.us.dell.com> Message-ID: <1148268574.21977.2.camel@entropy> On Sun, 2006-05-21 at 22:06 -0500, Matt Domsch wrote: > On Sun, May 21, 2006 at 07:21:59PM -0400, seth vidal wrote: > > On Sun, 2006-05-21 at 19:18 -0400, seth vidal wrote: > > > > > [main] > > > cachedir=/var/cache/yum > > > debuglevel=1 > > > reposdir=/dev/null > > > logfile=/var/log/yum.log > > > retries=20 > > > obsoletes=1 > > > gpgcheck=0 > > > assumeyes=1 > > > exclude=*.i386 *.486 *.586 *.i686 *.athlon > > > includepkgs=glibc*.i686 *.x86_64 *.ia32e *.noarch > > > > > > > whoops :) > > > > remove the 'exclude=' line, too. :) > > yep. > > includepkgs=glibc*.i686 > is what I did. It's the smallest change that lets them build. Well, > almost, as gcc got stuck on something to do with Ada. But > compat-gcc-32 built now. > > checking whether compiler driver understands Ada... no > ... > configure: error: > The following requested languages could not be built: ada > Recognised languages are: c,ada,c++,fortran,java,objc,obj-c++,treelang > This is probably exec-shield (still) being broken: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187853 (You can learn two things from this bug: a) beehive doesn't run on FC5 and b) nobody uses Ada for anything.) -- Nicholas Miell From scottlove at verizon.net Mon May 22 04:43:01 2006 From: scottlove at verizon.net (SCOTT LOVE) Date: Sun, 21 May 2006 21:43:01 -0700 Subject: Fedora Kernel Sources In-Reply-To: <1148215446.3875.275.camel@pmac.infradead.org> Message-ID: <0IZN00CD2H3BPBTM@vms040.mailsrvcs.net> Looks like I did not download the actual RPM first. I'll do that tomorrow. Thanks for everyone's help. -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of David Woodhouse Sent: Sunday, May 21, 2006 5:44 AM To: Development discussions related to Fedora Core Subject: Re: Fedora Kernel Sources On Sun, 2006-05-21 at 04:08 -0500, Arthur Pemberton wrote: > I am actually in exactly the same boat as you. People over at #fedora > seemed reluctant to help, not sure why. Probably because you don't actually need the src.rpm. Install the kernel-devel package which matches your kernel and you'll be able to build modules the normal way; you don't need the full sources for that. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From buildsys at redhat.com Mon May 22 07:24:25 2006 From: buildsys at redhat.com (Build System) Date: Mon, 22 May 2006 03:24:25 -0400 Subject: rawhide report: 20060522 changes Message-ID: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.7.0-0.cvs20060521 ---------------------------------- * Sun May 21 2006 Dan Williams - 0.7.0-0.cvs20050621 - Update to latest CVS - Drop special-case-madwifi.patch, since WEXT code is in madwifi-ng trunk now * Fri May 19 2006 Bill Nottingham - 0.6.2-3.fc6 - use the same 0.6.2 tarball as FC5, so we have the same VPN interface (did he fire ten args, or only nine?) * Thu Apr 27 2006 Jeremy Katz - 0.6.2-2.fc6 - use the hal device type instead of poking via ioctl so that wireless devices are properly detected even if the kill switch has been used glibc-2.4.90-9 -------------- * Sun May 21 2006 Jakub Jelinek 2.4.90-9 - update from CVS - big NIS+ changes * Fri May 19 2006 Jakub Jelinek 2.4.90-8 - update from CVS - fix nss_compat when SETENT_BATCH_READ=TRUE is in /etc/default/nss - fix RFC3484 precedence table for site-local and ULA addresses (#188364) - fix a sunrpc memory leak glibc-kernheaders-3.0-35 ------------------------ * Sun May 21 2006 David Woodhouse 3.0-35 - Fix asm-x86_64/mtrr.h to not attempt to include libraw1394-1.2.1-1.fc5 ---------------------- * Thu Apr 13 2006 Jarod Wilson - 1.2.1-1.fc5 - 1.2.1 linuxwacom-0:0.7.4_1-2 ---------------------- * Sun May 21 2006 Peter Jones 0:0.7.4_1-2 - fix the sysfs test equality syntax in the udev rule udev-092-2 ---------- * Sun May 21 2006 Peter Jones - 092-2 - Fix typo in pam-console rule Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.7.2.1-1.ppc64 requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 gnome-power-manager - 2.15.2-1.ppc64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ppc64 requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.9.4.1-2.ppc64 requires libnotify.so.0()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390 requires libnotify.so.0 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 gnome-power-manager - 2.15.2-1.s390 requires libnotify.so.0 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.i386 requires libnotify.so.0 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.i386 requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.i386 requires libnotify.so.0 rhythmbox - 0.9.4.1-2.i386 requires libnotify.so.0 Broken deps for ppc ---------------------------------------------------------- evolution - 2.7.2.1-1.ppc requires libnotify.so.0 gnome-power-manager - 2.15.2-1.ppc requires libnotify.so.0 gnome-volume-manager - 1.5.15-1.1.ppc requires libnotify.so.0 rhythmbox - 0.9.4.1-2.ppc requires libnotify.so.0 Broken deps for ia64 ---------------------------------------------------------- evolution - 2.7.2.1-1.ia64 requires libnotify.so.0()(64bit) gnome-power-manager - 2.15.2-1.ia64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.ia64 requires libnotify.so.0()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.4.1-2.ia64 requires libnotify.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU gnome-power-manager - 2.15.2-1.x86_64 requires libnotify.so.0()(64bit) gnome-volume-manager - 1.5.15-1.1.x86_64 requires libnotify.so.0()(64bit) rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390x requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 gnome-power-manager - 2.15.2-1.s390x requires libnotify.so.0()(64bit) hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 From mcdavey at mrao.cam.ac.uk Mon May 22 09:06:22 2006 From: mcdavey at mrao.cam.ac.uk (Matt Davey) Date: Mon, 22 May 2006 10:06:22 +0100 Subject: Via Velocity minimum MTU size In-Reply-To: <1148266646.2329.18.camel@osprey.hogchain.net> References: <1148240604.2329.9.camel@osprey.hogchain.net> <20060521194859.GK8250@redhat.com> <1148266646.2329.18.camel@osprey.hogchain.net> Message-ID: <1148288782.3891.99.camel@mistral.local.corvil.com> On Sun, 2006-05-21 at 21:57 -0500, Jay Cliburn wrote: > On Sun, 2006-05-21 at 15:48 -0400, Dave Jones wrote: > > > Can someone explain why the driver might constrain the NIC to a minimum > > > MTU size of 1500? > > > > Asking the developers on netdev at vger.kernel.org is going to get > > you the answer faster than asking here. There is a patch: http://bugme.osdl.org/show_bug.cgi?id=4001 Matt Matt Davey Do not seek to follow in the footsteps of the men of old; mcdavey at mrao.cam.ac.uk seek what they sought. -- Basho From davej at redhat.com Mon May 22 12:46:55 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 22 May 2006 08:46:55 -0400 Subject: Via Velocity minimum MTU size In-Reply-To: <1148288782.3891.99.camel@mistral.local.corvil.com> References: <1148240604.2329.9.camel@osprey.hogchain.net> <20060521194859.GK8250@redhat.com> <1148266646.2329.18.camel@osprey.hogchain.net> <1148288782.3891.99.camel@mistral.local.corvil.com> Message-ID: <20060522124655.GC3486@redhat.com> On Mon, May 22, 2006 at 10:06:22AM +0100, Matt Davey wrote: > On Sun, 2006-05-21 at 21:57 -0500, Jay Cliburn wrote: > > On Sun, 2006-05-21 at 15:48 -0400, Dave Jones wrote: > > > > Can someone explain why the driver might constrain the NIC to a minimum > > > > MTU size of 1500? > > > > > > Asking the developers on netdev at vger.kernel.org is going to get > > > you the answer faster than asking here. > > There is a patch: > http://bugme.osdl.org/show_bug.cgi?id=4001 I think this may be a separate issue. That last comment on 2006-03-01 mentions that it was included in mainline. The patch referenced in the other bug (http://bugzilla.kernel.org/show_bug.cgi?id=4380) does seem to be included in the kernel Jay was running (I just doublechecked the Fedora sources for that version). Dave -- http://www.codemonkey.org.uk From hendrik.wiese at siemens.com Mon May 22 13:49:39 2006 From: hendrik.wiese at siemens.com (Wiese, Hendrik) Date: Mon, 22 May 2006 15:49:39 +0200 Subject: AW: AW: Still much more than 350 sockets needed! Message-ID: So here I am again. Sorry for letting you wait. I figured out where the limit is reached. I wrote a small program that opens reusable UDP sockets (not TCP as I was told lately... please excuse this lack of essential information, I'm very sorry) in a 'forever'-loop and tries to send some dummy text over them. After about 28140 open sockets the program quits with the errormessage: sendto: resource temporarily unavailable So this is what our software does. But just after only 350 open UDP sockets. Does anybody know what it means and how we can break this limit? The machine where this fedora is running on is a Dual XEON 64bit system with 1gig of RAM. Hope this helps helping me finding a solution... ;) I'm sorry for forgetting some informations! thanks a lot for any kind of help! Regards, Hendrik W. From katzj at redhat.com Mon May 22 14:51:24 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 10:51:24 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060520141425.GD1924@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> Message-ID: <1148309484.1881.26.camel@orodruin.boston.redhat.com> On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote: > Judging from the feedback I would derive that > > o in later production environments usually hardware with PAE support > will be used. > > o during development, though, people would like to test xen on their > non-PAE hardware like their laptops. Basically. > So maybe rawhide should continue with both PAE and non-PAE kernels and > decide on dropping the non-PAE when a release is about to be cut? > Otherwise you will keep out a large amount of (admittedly casual) > testers. But this then requires doing all of the work to handle the case of both as well as breaking any sort of upgradeability. Plus, the testing will then largely end up on what's not shipped. Which isn't really what you want. Not to mention the last minute name switcheroo (which was quite nearly a disaster before FC5 :-) > And maybe until then the runtime handling emerges out of the blue and > solves all issues. It's that improbable that it has to happen ;) If we could only be so lucky... :) Jeremy From katzj at redhat.com Mon May 22 14:51:26 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 10:51:26 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060520152623.GH1924@neu.nirvana> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148136437.5542.5.camel@vader.jdub.homelinux.org> <20060520152623.GH1924@neu.nirvana> Message-ID: <1148309486.1881.27.camel@orodruin.boston.redhat.com> On Sat, 2006-05-20 at 17:26 +0200, Axel Thimm wrote: > On Sat, May 20, 2006 at 09:47:17AM -0500, Josh Boyer wrote: > > On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote: > > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > > decide on dropping the non-PAE when a release is about to be cut? > > > > I don't think so. I think you missed the "worlds of pain" part about > > having two kernels. It also becomes a resource issue. > > Not within rawhide, or? There's still just as much pain needed to do it just in the devel tree. The only thing that removes is the CD space burden/ > > I think option 1 is simply too much burden. So options 2 and 3 are > > left. It seems to come down to which is the "greater good". Which > > group is larger? The ones that don't have PAE hardware, or the ones > > that have machines with >= 4 gigs of RAM that are non-64bit. > > > > Personally, I think option 2 is fine. Of course, both my machines have > > PAE :). > > If personal bits matter, then I'd go for 3. I have no 32 bit machine > with >= 4GB, but quite a few 64 bits ones. And the toy machines I > would use to play with rawhide have no PAE. I guess whoever needs that > much memory also needs something like x86_64' in-chip memory > controller. > > (the only systems I've recently seen with large memories running on 32 > bits were 64-bits platforms with Debian, due to Debian not supporting > multilib ...) Sadly, many people continue to run 32-bit distros even on brand new hardware due to dependencies on "other stuff"[1] Jeremy [1] Think flash and the endless going on about that in 64bit browsers, or on the even more painful side there are things which require kernel modules :-/ From katzj at redhat.com Mon May 22 14:51:30 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 10:51:30 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148139621.2289.31.camel@localhost.localdomain> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148139621.2289.31.camel@localhost.localdomain> Message-ID: <1148309490.1881.28.camel@orodruin.boston.redhat.com> On Sat, 2006-05-20 at 17:40 +0200, Thorsten Leemhuis wrote: > Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm: > > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > > As we move forward with Xen enablement, there's a desire for > > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > > options for handling this are > > [...] > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > > work a lot of earlier PentiumM laptops > > [...] > > > Given these, we're looking at going with #2 and thus only having Xen > > > work on PAE-capable hardware in the development tree. And we're > > > planning to try to execute this switchover the beginning of next week. > > > Note that this will not affect bare metal installs at all. > > [...] > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > decide on dropping the non-PAE when a release is about to be cut? > > Otherwise you will keep out a large amount of (admittedly casual) > > testers. > > Well, I was always against kernel's in Fedora Extras (and I still am, > [mostly]). But having a Xen non-PAE kernel in Extras sounds like the > proper solution for the above problem. But having kernels in Extras > would only be okay for me if > - they are build with the same spec-file as the other kernels > - they are build on the same build system in the same step as the other > kernels > - they are moved to the proper Extras repo in the same moment as the > other kernels are pushed out This involves huge fundamental changes to the build infrastructure that I'm really not sure are worth doing > There are some technical problems that probably would need to be solved > before the above could be realized, but that should be possible if we > really want to. The other problem is the kernel binaries *have* to be with the installer, too -- otherwise, you can't install the guest as everything (HV + dom0 kernel + domU kernel) has to either be PAE or not. Mixing and matching can't happen :( Jeremy From katzj at redhat.com Mon May 22 14:54:46 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 10:54:46 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <20060521213754.GA30682@devserv.devel.redhat.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521213754.GA30682@devserv.devel.redhat.com> Message-ID: <1148309687.1881.31.camel@orodruin.boston.redhat.com> On Sun, 2006-05-21 at 17:37 -0400, Jakub Jelinek wrote: > On Sat, May 20, 2006 at 11:31:28PM -0400, seth vidal wrote: > > right now I'm mostly concerned with the idea that in order to build for > > x86_64 we have to first have i686 built. > > The dependency is that to build x86_64 gcc you need i[36]86 and x86_64 > glibc{,-devel} (similarly for ppc that needs ppc{,64} glibc{,-devel}, ppc64 > needs ppc{64,}, s390x needs s390{,x}). > We want gcc to support both -m64 and -m32 on the arches where this is > possible, and for multilib support both arches of glibc development are > needed. And for a few other low-level packages[1], the 32-bit glibc-devel is needed for building them as well on x86_64. Jeremy [1] Notably bootloaders (syslinux and grub) and memtest86+ as they're largely not actually 64-bit code, but we want to build them as x86_64 packages From katzj at redhat.com Mon May 22 14:56:01 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 10:56:01 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148182288.7089.7.camel@cutter> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> Message-ID: <1148309762.1881.34.camel@orodruin.boston.redhat.com> On Sat, 2006-05-20 at 23:31 -0400, seth vidal wrote: > On Sat, 2006-05-20 at 15:58 -0400, Jesse Keating wrote: > > On Sun, 2006-05-21 at 07:46 +1200, Michael J Knox wrote: > > > > > > Is there any point filing the buildrequires bug against compat-gcc in > > > this case? > > > > No. > > > > > Perhaps mock needs a "feature request" bug report. > > > > There is some discussion going on about this already. > > right now I'm mostly concerned with the idea that in order to build for > x86_64 we have to first have i686 built. You don't have to have all of i686 built, just some of it. Just instead of needing only 64-bit glibc to build gcc, you need 32-bit as well as the gcc build includes support for 32bit builds. Jeremy From jkeating at j2solutions.net Mon May 22 15:14:57 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 22 May 2006 11:14:57 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148309687.1881.31.camel@orodruin.boston.redhat.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521213754.GA30682@devserv.devel.redhat.com> <1148309687.1881.31.camel@orodruin.boston.redhat.com> Message-ID: <1148310897.337.4.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-22 at 10:54 -0400, Jeremy Katz wrote: > [1] Notably bootloaders (syslinux and grub) and memtest86+ as they're > largely not actually 64-bit code, but we want to build them as x86_64 > packages > Do we really want to build memtest86 as an x86_64 package instead of just bringing the 32bit package into the x86_64 install tree? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Mon May 22 15:11:57 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 22 May 2006 17:11:57 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148309490.1881.28.camel@orodruin.boston.redhat.com> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148139621.2289.31.camel@localhost.localdomain> <1148309490.1881.28.camel@orodruin.boston.redhat.com> Message-ID: <1148310717.2291.48.camel@localhost.localdomain> Am Montag, den 22.05.2006, 10:51 -0400 schrieb Jeremy Katz: > On Sat, 2006-05-20 at 17:40 +0200, Thorsten Leemhuis wrote: > > Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm: > > > On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote: > > > > As we move forward with Xen enablement, there's a desire for > > > > being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The > > > > options for handling this are > > > [...] > > > > 2) Switch the 32-bit xen kernels to require PAE. For most "current" > > > > non-laptop hardware, this is a non-issue. It does mean that xen won't > > > > work a lot of earlier PentiumM laptops > > > [...] > > > > Given these, we're looking at going with #2 and thus only having Xen > > > > work on PAE-capable hardware in the development tree. And we're > > > > planning to try to execute this switchover the beginning of next week. > > > > Note that this will not affect bare metal installs at all. > > > [...] > > > So maybe rawhide should continue with both PAE and non-PAE kernels and > > > decide on dropping the non-PAE when a release is about to be cut? > > > Otherwise you will keep out a large amount of (admittedly casual) > > > testers. > > > > Well, I was always against kernel's in Fedora Extras (and I still am, > > [mostly]). But having a Xen non-PAE kernel in Extras sounds like the > > proper solution for the above problem. But having kernels in Extras > > would only be okay for me if > > - they are build with the same spec-file as the other kernels > > - they are build on the same build system in the same step as the other > > kernels > > - they are moved to the proper Extras repo in the same moment as the > > other kernels are pushed out > > This involves huge fundamental changes to the build infrastructure that > I'm really not sure are worth doing Well, that could be nice for other aspects, too. E.g. moving some devel packages and/or not that important sub-packages/language packs/whatever to Extras sound like a good idea in my eyes in general (at least in the long term). > > There are some technical problems that probably would need to be solved > > before the above could be realized, but that should be possible if we > > really want to. > The other problem is the kernel binaries *have* to be with the > installer, too -- otherwise, you can't install the guest as everything > (HV + dom0 kernel + domU kernel) has to either be PAE or not. Mixing > and matching can't happen :( Okay, that's a good argument :-/ CU thl -- Thorsten Leemhuis From jkeating at j2solutions.net Mon May 22 15:16:56 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 22 May 2006 11:16:56 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148310717.2291.48.camel@localhost.localdomain> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148139621.2289.31.camel@localhost.localdomain> <1148309490.1881.28.camel@orodruin.boston.redhat.com> <1148310717.2291.48.camel@localhost.localdomain> Message-ID: <1148311016.337.6.camel@dhcp83-49.boston.redhat.com> On Mon, 2006-05-22 at 17:11 +0200, Thorsten Leemhuis wrote: > Well, that could be nice for other aspects, too. E.g. moving some devel > packages and/or not that important sub-packages/language packs/whatever > to Extras sound like a good idea in my eyes in general (at least in the > long term). > More easily accomplished by putting everything outside and building it out there. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Mon May 22 15:19:41 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 22 May 2006 11:19:41 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148309484.1881.26.camel@orodruin.boston.redhat.com> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> Message-ID: <20060522151941.GA28153@devserv.devel.redhat.com> On Mon, May 22, 2006 at 10:51:24AM -0400, Jeremy Katz wrote: > > o during development, though, people would like to test xen on their > > non-PAE hardware like their laptops. > > Basically. Once you get into the habit of having your "desktop" as a Xen guest you migrate between your desktop and laptop when you travel you'll stop seeing it as a devlopment tool, very fast.. From katzj at redhat.com Mon May 22 15:20:01 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 22 May 2006 11:20:01 -0400 Subject: rawhide rebuild in mock status 2006-05-19 In-Reply-To: <1148310897.337.4.camel@dhcp83-49.boston.redhat.com> References: <20060520033408.GA27962@lists.us.dell.com> <446E90D1.40407@knox.net.nz> <20060520040235.GB27962@lists.us.dell.com> <1148105559.12055.17.camel@ender> <446F71FB.2030408@knox.net.nz> <1148155128.12055.25.camel@ender> <1148182288.7089.7.camel@cutter> <20060521213754.GA30682@devserv.devel.redhat.com> <1148309687.1881.31.camel@orodruin.boston.redhat.com> <1148310897.337.4.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148311201.1881.47.camel@orodruin.boston.redhat.com> On Mon, 2006-05-22 at 11:14 -0400, Jesse Keating wrote: > On Mon, 2006-05-22 at 10:54 -0400, Jeremy Katz wrote: > > [1] Notably bootloaders (syslinux and grub) and memtest86+ as they're > > largely not actually 64-bit code, but we want to build them as x86_64 > > packages > > Do we really want to build memtest86 as an x86_64 package instead of > just bringing the 32bit package into the x86_64 install tree? Yes. Otherwise, we have to special case memtest86 in the compose process instead of being able to have the general rule of "pull in -devel packages, resolve deps" Jeremy From avi at argo.co.il Mon May 22 15:24:07 2006 From: avi at argo.co.il (Avi Kivity) Date: Mon, 22 May 2006 18:24:07 +0300 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060522151941.GA28153@devserv.devel.redhat.com> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> Message-ID: <4471D797.3030603@argo.co.il> Alan Cox wrote: > Once you get into the habit of having your "desktop" as a Xen guest you > migrate between your desktop and laptop when you travel you'll stop seeing it > as a devlopment tool, very fast.. > How do you migrate your storage? Even with gigabit ethernet, copying a 50GB virtual disk can take a long time. -- error compiling committee.c: too many arguments to function From dimi at lattica.com Mon May 22 15:31:43 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 22 May 2006 11:31:43 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <4471D797.3030603@argo.co.il> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> Message-ID: <1148311903.1941.19.camel@dimi> On Mon, 2006-05-22 at 18:24 +0300, Avi Kivity wrote: > How do you migrate your storage? You don't just copy it blindly, you can synch it differentially, via something like rsync for example. I'm sure you can do even better with a special filesystem that can track what changed since last synch. -- Dimi Paun Lattica, Inc. From avi at argo.co.il Mon May 22 15:39:24 2006 From: avi at argo.co.il (Avi Kivity) Date: Mon, 22 May 2006 18:39:24 +0300 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148311903.1941.19.camel@dimi> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> <1148311903.1941.19.camel@dimi> Message-ID: <4471DB2C.3020009@argo.co.il> Dimi Paun wrote: > On Mon, 2006-05-22 at 18:24 +0300, Avi Kivity wrote: > >> How do you migrate your storage? >> > > You don't just copy it blindly, you can synch it > differentially, via something like rsync for example. > I'm sure you can do even better with a special > filesystem that can track what changed since last > synch. > Well, you could have the desktop and laptop in a raid-1 over nbd with a write intent bitmap, so that only changed blocks are copied. Seems like everything is in place for that. -- error compiling committee.c: too many arguments to function From dimi at lattica.com Mon May 22 16:03:19 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 22 May 2006 12:03:19 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <4471DB2C.3020009@argo.co.il> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> <1148311903.1941.19.camel@dimi> <4471DB2C.3020009@argo.co.il> Message-ID: <1148313799.1941.28.camel@dimi> On Mon, 2006-05-22 at 18:39 +0300, Avi Kivity wrote: > Well, you could have the desktop and laptop in a raid-1 over nbd with > a write intent bitmap, so that only changed blocks are copied. Seems > like everything is in place for that. Yeah, that should work, but I wonder what you lose by doing it at such a low level. For one, you need to have two identical partitions on the laptop and desktop. Not a big deal I guess, but mildly inconvenient. Second, you give up a bit of performance by working on the block level, but this may be negligible. Third, you lose the semantics of what's being changed, and this may be a problem when you update both the laptop and the desktop. CODA has a disconnected operation mode, but I've never used it personally. -- Dimi Paun Lattica, Inc. From alan at redhat.com Mon May 22 16:29:35 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 22 May 2006 12:29:35 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <4471D797.3030603@argo.co.il> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> Message-ID: <20060522162935.GA22032@devserv.devel.redhat.com> On Mon, May 22, 2006 at 06:24:07PM +0300, Avi Kivity wrote: > Even with gigabit ethernet, copying a 50GB virtual disk can take a long > time. Rsync. From avi at argo.co.il Mon May 22 16:48:53 2006 From: avi at argo.co.il (Avi Kivity) Date: Mon, 22 May 2006 19:48:53 +0300 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060522162935.GA22032@devserv.devel.redhat.com> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> <20060522162935.GA22032@devserv.devel.redhat.com> Message-ID: <4471EB75.20607@argo.co.il> Alan Cox wrote: > On Mon, May 22, 2006 at 06:24:07PM +0300, Avi Kivity wrote: > >> Even with gigabit ethernet, copying a 50GB virtual disk can take a long >> time. >> > > Rsync. > Still have to read every byte on the disk. I doubt you'd get away with less than 20 minutes. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From alan at redhat.com Mon May 22 16:51:31 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 22 May 2006 12:51:31 -0400 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <4471EB75.20607@argo.co.il> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> <20060522162935.GA22032@devserv.devel.redhat.com> <4471EB75.20607@argo.co.il> Message-ID: <20060522165131.GD22032@devserv.devel.redhat.com> On Mon, May 22, 2006 at 07:48:53PM +0300, Avi Kivity wrote: > >Rsync. > > Still have to read every byte on the disk. I doubt you'd get away with > less than 20 minutes. That isn't a problem I find. It takes me a good hour to pack 8) From mharris at mharris.ca Mon May 22 17:33:49 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 22 May 2006 13:33:49 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148201620.27847.6.camel@rousalka.dyndns.org> References: <446FF7AB.30301@mharris.ca> <1148201620.27847.6.camel@rousalka.dyndns.org> Message-ID: <4471F5FD.9080504@mharris.ca> Nicolas Mailhot wrote: > I can only approve phasing out core fonts one way or another. Technically, I believe complete removal of all core font support would result in an X Window System implementation which is non-compliant I believe. The X Window System does not require a font server to be present as a separate standalone process however, so we can certainly phase out xfs. We (well, everyone out there actually) will probably have to provide core fonts support forever, or X11 conformant applications will just fail. Long term, what would be really nice, is if someone figured out a way to implement core fonts using fontconfig/Xft underneath so we have one font system, and it provides legacy compatibility to ancient applications that have not been updated to modern interfaces. That is something that would need to be spearheaded at the X.Org level rather than at a specific distribution however. > In fact I'm convinced the last strugglers will *never* move to > fontconfig unless Red Hat / Fedora or another big distro > exerts a bit of pressure (as was the case for the gcc, utf-8 > and selinux migrations), so waiting so long > for even making core fonts optional was in the end conterproductive (and > OLPC is paying the price today). Core fonts are non-optional. It is xfs that is optional, however there was no real world gains to disabling it by default before, but there was functionality loss without re-engineering the rest of the OS to provide the same level of core font support via the X server. As such, we stuck with using xfs under the "if it's not broke, don't try to fix it" principle. Now however, there are some real gains to be had, in particular for OLPC and/or other embedded distros, and so it seems that now is the time to address this. > However I know it's a difficult decision to take, as the users of the > bad citizen apps still relying on core fonts are certain to yell loudly > near FC-6 release. It's a _very_ difficult decision indeed IMHO. There are many applications that ship as part of the X Window System itself, as well as numerous apps that are part of Fedora Core and Extras, not to mention numerous 3rd party apps beyond that out there, all which use core fonts exclusively. I believe that there will be some problems created when this change happens, but such is the way of progress. ;o) Once the problems are more visible, we'll be in a better situation to try to address as many as we can prior to FC-6 hopefully. Thanks for the feedback. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon May 22 17:38:34 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 22 May 2006 13:38:34 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148211112.4022.5.camel@localhost.localdomain> References: <446FF7AB.30301@mharris.ca> <1148211112.4022.5.camel@localhost.localdomain> Message-ID: <4471F71A.90506@mharris.ca> Michael Tiemann wrote: >> In particular, xfs and core fonts does not fit well into the >> One Laptop Per Child (OLPC) effort, or other Fedora derived >> embedded distributions. In these embedded systems, or >> reduced computing environments if you will, every megabyte >> of disk space and memory counts. Shedding megs of stuff out >> of the default OS installation is sure to reduce both the >> memory footprint and disk footprint of the OS installation, >> which is a net gain for these systems, and also for a lot >> of the userbase out there that do not use any applications >> which rely on core fonts. >> >> On the other hand, there are many applications included both >> in Fedora Core, and in Fedora Extras, which do rely on the >> core fonts system still, and are likely to rely on it for the >> forseeable future. There are also many 3rd party open source >> and commercial applications, as well as custom in-house >> applications that many users and/or companies rely on, and >> will want to keep working in new OS releases. > > Is it too late for this to be a major thrust of the Fedora Summer of > Code projects? Even if it is, I think that such changes create a > tremendous amount of opportunity for new folks to step into new > leadership roles. I can imagine that at next years OSCON there will be > a new crop of hackers who can proudly say "I cleaned up the font cruft > in Project XYZ and now maintain its use of the new font system". > > I also think that given all the stuff that's been going on in Fedora in > support of server-side computing, it makes good sense to give some major > priority (which can mean major leeway) to client-side computing. I think it would be fantastic if someone were to tackle adding fontconfig/Xft support to the various toolkits out there that don't support it currently, and/or the various apps that use core fonts directly, or are otherwise directly affected by it. If someone is interested in organizing such a project of any size, it would be a great service to the community, reaching beyond Fedora even. Another possibility is simply converting individual applications that use Xaw/Xt/Motif/etc. to using GTK or Qt, or creating an alternative implementation of said application. We could then start replacing the non-(GTK/Qt) based apps with their modern equivalents once they're ready, and move the legacy versions into Fedora Extras (assuming someone in the community desperately wants to maintain them). Any takers? -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon May 22 17:43:03 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 22 May 2006 13:43:03 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148221387.1941.13.camel@dimi> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> Message-ID: <4471F827.3010804@mharris.ca> Dimi Paun wrote: > On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: >> On the other hand, there are many applications included both >> in Fedora Core, and in Fedora Extras, which do rely on the >> core fonts system still, and are likely to rely on it for the >> forseeable future. > > Great to hear we're moving in this direction. > > I guess the obvious question is "what will break?". Once we > have a clear idea what really depends on xfs (some packages, > like wine, _can_ work with xfs if it's the only available > option, or without), we can devise a plan of making xfs > optional (moved to Extra along with all apps that depend > on it?). No apps[1] require xfs. Lots of apps require "core fonts" support. We currently provide core fonts support via the xfs font server, however the X server is equally capable of serving fonts on its own without a separate font server. Aside from disabling xfs by default, what needs to change is exactly how we go from configuring core fonts using chkfontpath which twiddles the xfs config, to a setup that twiddles the X server config, which also works properly through OS upgrades via anaconda and also via yum. That's the tricky part. The second tricky part is that there are probably a number of people out there who enable TCP support in xfs, to run it over the network to serve fonts to multiple machines. If we switch to using the X server, everyone who intentionally wants to use xfs either in networked mode, or in local mode, will have to manually configure their font server. There are definitely some complexities to sort through. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Mon May 22 17:50:26 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 22 May 2006 13:50:26 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148247151.1941.15.camel@dimi> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> Message-ID: <4471F9E2.4070106@mharris.ca> Dimi Paun wrote: > On Sun, 2006-05-21 at 22:39 +0200, Nicolas Mailhot wrote: >> To be fair Mike carefully avoided talking about RHEL, and the major >> offenders are in the entreprise space > > True, but it would still be quite good to know how affected > Fedora would be. RHEL is a different bowl of wax :) RHEL and Fedora are from the same code base, so they're both equally affected or non-affected. What is different perhaps, is how people _use_ each OS. Whatever we change in Fedora, will end up becoming "the new way things work" in the next RHEL release. So whatever solution is decided upon will affect both Fedora Core 6 and RHEL-$next-generation users/customers equally. For the RHEL case, some customers may not be ready and/or willing to migrate their custom applications for years, and may stay using RHEL4 or RHEL3 for example, or even migrate to a non-RH OS. What business impact that may have is hard to say. It's possible the number of systems out there where this is a problem may be significantly small in the grand scheme of things. I'm not sure how that could be measured without just doing it and finding out after the fact. ;o) The same situation exists for Fedora, only there's no business factors to consider, but rather community-factors. If someone has an app, or apps that they expect to be able to use for years to come, and they have trouble with getting them running in FC6, they might stay with FC5 or switch distros or something - if they don't feel like configuring everything manually for themselves. The big puzzle IMHO, is: Just how many applications out there, and just how many users, will be affected by this, even in a small way? Hard to say, but we'll find out soon enough I suppose. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From notting at redhat.com Mon May 22 17:56:10 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 May 2006 13:56:10 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4471F9E2.4070106@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> Message-ID: <20060522175610.GA21839@devserv.devel.redhat.com> Mike A. Harris (mharris at mharris.ca) said: > For the RHEL case, some customers may not be ready and/or > willing to migrate their custom applications for years, > and may stay using RHEL4 or RHEL3 for example, or even > migrate to a non-RH OS. What business impact that may > have is hard to say. It's possible the number of systems > out there where this is a problem may be significantly > small in the grand scheme of things. I'm not sure how > that could be measured without just doing it and finding > out after the fact. ;o) I suspect the move to modular X and the repackaging under a different path is going to cause significant heartburn for third-party software vendors; they may have to change how their apps build, and it wouldn't be a big news flash if various apps have /usr/X11R6/... paths hardcoded into them for various reasions. At that point, changing core fonts is just one more thing... :) Bill From pbrobinson at gmail.com Mon May 22 18:02:00 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 22 May 2006 19:02:00 +0100 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4471F9E2.4070106@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> Message-ID: <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> > The same situation exists for Fedora, only there's no > business factors to consider, but rather community-factors. > If someone has an app, or apps that they expect to be > able to use for years to come, and they have trouble with > getting them running in FC6, they might stay with FC5 or > switch distros or something - if they don't feel like > configuring everything manually for themselves. > > The big puzzle IMHO, is: Just how many applications out > there, and just how many users, will be affected by this, > even in a small way? Also if they are affected is it just a matter of updating the application to deal with the new way or if commercial trying to convince the vendore that it's worth they're while. Could an app have the ability to support both? My guess would yes (maye with an --enable/disable combo?). If its just a matter of upgrading to version x I don't think it would be a major problem. Peter From mharris at mharris.ca Mon May 22 18:15:36 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 22 May 2006 14:15:36 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> Message-ID: <4471FFC8.4080503@mharris.ca> Peter Robinson wrote: >> The same situation exists for Fedora, only there's no >> business factors to consider, but rather community-factors. >> If someone has an app, or apps that they expect to be >> able to use for years to come, and they have trouble with >> getting them running in FC6, they might stay with FC5 or >> switch distros or something - if they don't feel like >> configuring everything manually for themselves. >> >> The big puzzle IMHO, is: Just how many applications out >> there, and just how many users, will be affected by this, >> even in a small way? > > Also if they are affected is it just a matter of updating the > application to deal with the new way The application and/or the toolkit it uses. > or if commercial trying to > convince the vendore that it's worth they're while. I don't think we need to do any convincing. It's entirely up to 3rd parties wether to update their applications to work with modern technological evolution or not. If they do, their apps will work on current and future generation OS products out there. If they do not, their products/solutions will remain stuck with dependencies on legacy technology. While that legacy technology will remain around for a long time, _using_ it may become more difficult however. I suspect that each particular application out there needs to be considered on a case by case basis, by the people who own and/or maintain each particular app/lib/whatever, as well as by the userbases of them. I doubt there will be a single formula. ;o) > Could an app have the ability to support both? My guess would > yes (maye with an --enable/disable combo?). There are many applications which already have compile time and/or runtime support of both font subsystems. "xterm" for example is compiled with both, and uses core fonts by default, but if you pass the right options to it at invocation it will use antialiased truetype fonts with Xft/fontconfig. Many other apps out there could do the same thing if someone were to write the code. I'm sure some will be easier to do than others, and some will be quite a lot of work, in particular if it requires updating an entire toolkit which hasn't been updated yet. What I'm actually a bit more curious about though, is just how many apps included with Fedora Core 6 will not work properly if core fonts has a limited default configuration out of the box. ;o) It'd be an interesting test for someone to disable xfs, and to configure the X server to have only the "misc" font dir as a configured font path in xorg.conf, and then see what all apps no longer work. Second to that, many apps will work, but will probably look hideous, as they'll have a far reduced set of fonts to use with such a configuration. It'd be interesting to see what apps totally break or otherwise become unuseable with such a setup. If anyone feels up to trying this, please post your results back to the list. TIA -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From nicolas.mailhot at laposte.net Mon May 22 18:18:12 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 22 May 2006 20:18:12 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4471F5FD.9080504@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148201620.27847.6.camel@rousalka.dyndns.org> <4471F5FD.9080504@mharris.ca> Message-ID: <1148321895.12709.3.camel@rousalka.dyndns.org> Le lundi 22 mai 2006 ? 13:33 -0400, Mike A. Harris a ?crit : > Nicolas Mailhot wrote: > > > I can only approve phasing out core fonts one way or another. > > Technically, I believe complete removal of all core font support > would result in an X Window System implementation which is > non-compliant I believe. Well, you know as well as me that this kind of thing can change once the number of users has shrunk drastically. > RHEL and Fedora are from the same code base, so they're > both equally affected or non-affected. What is different > perhaps, is how people _use_ each OS. > > Whatever we change in Fedora, will end up becoming "the > new way things work" in the next RHEL release. So whatever > solution is decided upon will affect both Fedora Core 6 > and RHEL-$next-generation users/customers equally. Methinks the fact we've just passed a FC -> RHEL sync point explains part of your timing Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mike at miketc.com Mon May 22 18:22:05 2006 From: mike at miketc.com (Mike Chambers) Date: Mon, 22 May 2006 13:22:05 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4471FFC8.4080503@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> Message-ID: <1148322125.5620.1.camel@scrappy.miketc.com> On Mon, 2006-05-22 at 14:15 -0400, Mike A. Harris wrote: > What I'm actually a bit more curious about though, is just > how many apps included with Fedora Core 6 will not work > properly if core fonts has a limited default configuration > out of the box. ;o) > > It'd be an interesting test for someone to disable xfs, and > to configure the X server to have only the "misc" font dir > as a configured font path in xorg.conf, and then see what > all apps no longer work. > > Second to that, many apps will work, but will probably look > hideous, as they'll have a far reduced set of fonts to use > with such a configuration. It'd be interesting to see what > apps totally break or otherwise become unuseable with such > a setup. > > If anyone feels up to trying this, please post your results > back to the list. Not sure if this is something I want to tackle or not (then again, I have reinstalled a few tiems and don't mind doing it again a time or two if need to), but I might be willing to give it a shot. You might need to guide me a little as what to do (or create a step by step guide on what to enable/disable so I/we do it correctly), so can make sure I/we are doing a good test. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you're not getting any!" From Axel.Thimm at ATrpms.net Mon May 22 18:00:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 22 May 2006 20:00:26 +0200 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <1148309486.1881.27.camel@orodruin.boston.redhat.com> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148136437.5542.5.camel@vader.jdub.homelinux.org> <20060520152623.GH1924@neu.nirvana> <1148309486.1881.27.camel@orodruin.boston.redhat.com> Message-ID: <20060522180026.GB28556@neu.nirvana> On Mon, May 22, 2006 at 10:51:26AM -0400, Jeremy Katz wrote: > On Sat, 2006-05-20 at 17:26 +0200, Axel Thimm wrote: > > On Sat, May 20, 2006 at 09:47:17AM -0500, Josh Boyer wrote: > > If personal bits matter, then I'd go for 3. I have no 32 bit machine > > with >= 4GB, but quite a few 64 bits ones. And the toy machines I > > would use to play with rawhide have no PAE. I guess whoever needs that > > much memory also needs something like x86_64' in-chip memory > > controller. > > > > (the only systems I've recently seen with large memories running on 32 > > bits were 64-bits platforms with Debian, due to Debian not supporting > > multilib ...) > > Sadly, many people continue to run 32-bit distros even on brand new > hardware due to dependencies on "other stuff"[1] > > Jeremy > > [1] Think flash and the endless going on about that in 64bit browsers, > or on the even more painful side there are things which require kernel > modules :-/ So it's Desktop x86_64 users vs us poor ia32-no-PAE laptops. ;) Anyway, I think you should pick what will make development for you easier/faster, which is probably more worth than any additional few random community testers. Maybe I'll get the chance to upgrade my laptop and then I'll make sure for the new one to be PAE-capable (unless this means too much $$$, but it sounded like any new laptop is supposed to have PAE). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mharris at mharris.ca Mon May 22 19:29:59 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 22 May 2006 15:29:59 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148322125.5620.1.camel@scrappy.miketc.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> Message-ID: <44721137.2010806@mharris.ca> Mike Chambers wrote: > On Mon, 2006-05-22 at 14:15 -0400, Mike A. Harris wrote: > >> What I'm actually a bit more curious about though, is just >> how many apps included with Fedora Core 6 will not work >> properly if core fonts has a limited default configuration >> out of the box. ;o) >> >> It'd be an interesting test for someone to disable xfs, and >> to configure the X server to have only the "misc" font dir >> as a configured font path in xorg.conf, and then see what >> all apps no longer work. >> >> Second to that, many apps will work, but will probably look >> hideous, as they'll have a far reduced set of fonts to use >> with such a configuration. It'd be interesting to see what >> apps totally break or otherwise become unuseable with such >> a setup. >> >> If anyone feels up to trying this, please post your results >> back to the list. > > Not sure if this is something I want to tackle or not (then again, I > have reinstalled a few tiems and don't mind doing it again a time or two > if need to), but I might be willing to give it a shot. You might need > to guide me a little as what to do (or create a step by step guide on > what to enable/disable so I/we do it correctly), so can make sure I/we > are doing a good test. - Run ntsysv (or equivalent) and disable the xfs service from starting at boot time. - Run "service xfs stop" to shut down xfs - Edit xorg.conf and comment out the unix:/7100 font path. Add a FontPath that points to the "misc" font directory. - Start the X server. It should start correctly as long as you have properly configured the misc font path, as it will then still be able to find "fixed" and "cursor". You may or may not have errors or application failures during your desktop's startup, depending on wether you're using GNOME, KDE, or some other setup. If your setup uses apps that use core fonts, they may or may not start depending on how picky they are about finding specific fonts. Once your desktop is started, open a terminal and run various non-GNOME, non-GTK2, non-KDE, non-Qt applications. For example, run Xt, Xaw, Motif, and other such apps, and see if they work properly, or if they fail miserably. If any apps fail and report an error about a missing font or other font related problem, make note of it. Summarize testing results to the list. That's about it. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From icon at fedoraproject.org Mon May 22 19:42:48 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 22 May 2006 15:42:48 -0400 Subject: Any work done Mactel-wise? Message-ID: Hi, all: Just being my curious self (who's been stuck with an increasingly annoying OS X on his Mactel Mini) -- I know that there has been lots of commotion about supporting Fedora on Mactels. Has there been much work done in that regard? Are we any closer to a workable Mactel rawhide? Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From yaneti at declera.com Mon May 22 20:23:35 2006 From: yaneti at declera.com (Yanko Kaneti) Date: Mon, 22 May 2006 23:23:35 +0300 Subject: rpms/libpng/devel libpng.spec,1.28,1.29 (Re-add static libraries) In-Reply-To: <200605221946.k4MJkMVr007161@cvs.devel.redhat.com> References: <200605221946.k4MJkMVr007161@cvs.devel.redhat.com> Message-ID: <1148329416.22597.16.camel@indigo.declera.com> Hi, Would you add a brief rationale in the specfile about this exception? A comment with a reference to a bug report or something else... It would help if in the future the reason is no longer present and the exception can be removed. After all, for obvious security reasons, fedora should not be encouraging static linking of image handling libraries. Thanks. Yanko On Mon, 2006-05-22 at 15:46 -0400, fedora-cvs-commits at redhat.com wrote: > Author: mclasen > > Update of /cvs/dist/rpms/libpng/devel > In directory cvs.devel.redhat.com:/tmp/cvs-serv2918 > > Modified Files: > libpng.spec > Log Message: > Re-add static libraries > > > > Index: libpng.spec > =================================================================== > RCS file: /cvs/dist/rpms/libpng/devel/libpng.spec,v > retrieving revision 1.28 > retrieving revision 1.29 > diff -u -r1.28 -r1.29 > --- libpng.spec 4 May 2006 13:39:29 -0000 1.28 > +++ libpng.spec 22 May 2006 19:46:20 -0000 1.29 > @@ -1,7 +1,7 @@ > Summary: A library of functions for manipulating PNG image format files. > Name: libpng > Version: 1.2.10 > -Release: 1 > +Release: 2 > License: OSI certified > Group: System Environment/Libraries > Source: ftp://swrinde.nde.swri.edu/pub/png/src/libpng-%{version}.tar.bz2 > @@ -48,8 +48,8 @@ > %install > rm -rf $RPM_BUILD_ROOT > %makeinstall > -rm -rf $RPM_BUILD_ROOT%{_libdir}/libpng.{a,la} > -rm -rf $RPM_BUILD_ROOT%{_libdir}/libpng12.{a,la} > +rm -rf $RPM_BUILD_ROOT%{_libdir}/libpng.la > +rm -rf $RPM_BUILD_ROOT%{_libdir}/libpng12.la > > %post -p /sbin/ldconfig > > @@ -66,6 +66,7 @@ > %{_bindir}/* > %{_includedir}/* > %{_libdir}/libpng*.so > +%{_libdir}/libpng*.a > %{_libdir}/pkgconfig/* > %{_mandir}/man3/* > > @@ -73,6 +74,9 @@ > rm -rf $RPM_BUILD_ROOT > > %changelog > +* Mon May 22 2006 Matthias Clasen - 2:1.2.10-2 > +- Re-add static libraries > + > * Thu May 4 2006 Matthias Clasen - 2:1.2.10-1 > - Update to 1.2.10 > - Drop static libraries > From jacliburn at bellsouth.net Tue May 23 00:51:59 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Mon, 22 May 2006 19:51:59 -0500 Subject: Via Velocity minimum MTU size In-Reply-To: <20060522124655.GC3486@redhat.com> References: <1148240604.2329.9.camel@osprey.hogchain.net> <20060521194859.GK8250@redhat.com> <1148266646.2329.18.camel@osprey.hogchain.net> <1148288782.3891.99.camel@mistral.local.corvil.com> <20060522124655.GC3486@redhat.com> Message-ID: <1148345519.3000.13.camel@osprey.hogchain.net> On Mon, 2006-05-22 at 08:46 -0400, Dave Jones wrote: > On Mon, May 22, 2006 at 10:06:22AM +0100, Matt Davey wrote: > > On Sun, 2006-05-21 at 21:57 -0500, Jay Cliburn wrote: > > > On Sun, 2006-05-21 at 15:48 -0400, Dave Jones wrote: > > > > > Can someone explain why the driver might constrain the NIC to a minimum > > > > > MTU size of 1500? > > > > > > > > Asking the developers on netdev at vger.kernel.org is going to get > > > > you the answer faster than asking here. > > > > There is a patch: > > http://bugme.osdl.org/show_bug.cgi?id=4001 > > I think this may be a separate issue. > > That last comment on 2006-03-01 mentions that it was included in mainline. > The patch referenced in the other bug (http://bugzilla.kernel.org/show_bug.cgi?id=4380) > does seem to be included in the kernel Jay was running (I just doublechecked > the Fedora sources for that version). There appear to be two issues in the referenced bug: (1) VELOCITY_MIN_MTU is hardcoded at 1500 bytes in via-velocity.h, and (2) An earlier version of the via-velocity driver couldn't handle on-the-fly MTU changes. Number (2) was resolved with a patch. Number (1) was not. I intend to submit a patch to kernel.org, but first, can someone confirm that the proper way to alter MTU size is: ifconfig mtu service network restart I can't get it to work unless I bounce the network service after making the MTU change. I just need to know if that's normal. Thanks, Jay From jacliburn at bellsouth.net Tue May 23 01:34:34 2006 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Mon, 22 May 2006 20:34:34 -0500 Subject: Via Velocity minimum MTU size In-Reply-To: <1148345519.3000.13.camel@osprey.hogchain.net> References: <1148240604.2329.9.camel@osprey.hogchain.net> <20060521194859.GK8250@redhat.com> <1148266646.2329.18.camel@osprey.hogchain.net> <1148288782.3891.99.camel@mistral.local.corvil.com> <20060522124655.GC3486@redhat.com> <1148345519.3000.13.camel@osprey.hogchain.net> Message-ID: <1148348075.3000.20.camel@osprey.hogchain.net> On Mon, 2006-05-22 at 19:51 -0500, Jay Cliburn wrote: > can someone confirm that the proper way to alter MTU size is: > > ifconfig mtu > service network restart > > I can't get it to work unless I bounce the network service after making > the MTU change. I just need to know if that's normal. Apologies for responding to my own post, but just to clarify, "ifconfig eth0 mtu xxx" indeed changes mtu to xxx as displayed by the "ifconfig eth0" command, but ICMP pings to anywhere are unresponsive until after I bounce the network service. That's what I need to confirm as either correct or aberrant behavior. Thanks. From mike at miketc.com Tue May 23 01:40:34 2006 From: mike at miketc.com (Mike Chambers) Date: Mon, 22 May 2006 20:40:34 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44721137.2010806@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> Message-ID: <1148348434.22689.1.camel@scrappy.miketc.com> On Mon, 2006-05-22 at 15:29 -0400, Mike A. Harris wrote: > - Run ntsysv (or equivalent) and disable the xfs service from > starting at boot time. > > - Run "service xfs stop" to shut down xfs > > - Edit xorg.conf and comment out the unix:/7100 font path. > Add a FontPath that points to the "misc" font directory. > > - Start the X server. It should start correctly as long as you > have properly configured the misc font path, as it will then > still be able to find "fixed" and "cursor". I will see about giving this a shot tomorrow after work (around noon/one 'ish CST) and see what happens. Stay tuned, -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you're not getting any!" From buildsys at redhat.com Tue May 23 07:33:45 2006 From: buildsys at redhat.com (Build System) Date: Tue, 23 May 2006 03:33:45 -0400 Subject: rawhide report: 20060523 changes Message-ID: <200605230733.k4N7Xj6j024604@porkchop.devel.redhat.com> Updated Packages: SDL-1.2.10-1 ------------ * Mon May 22 2006 Thomas Woerner 1.2.10-1 - new version 1.2.10 - dropped the following patches because they are not needed anymore: ppc_modes, gcc4, yuv_mmx_gcc4 and no_exec_stack - new pagesize patch (drop PAGE_SIZE, use sysconf(_SC_PAGESIZE) instead) adjtimex-1.20-2 --------------- * Mon May 22 2006 Miroslav Lichvar 1.20-2 - fix segfault when parsing -s option amanda-2.5.0-3 -------------- * Mon May 22 2006 Jesse Keating 2.5.0-3 - Fix BuildReqs at-spi-1.7.7-7 -------------- * Mon May 22 2006 Matthias Clasen - 1.7.7-7 - Make it build in mock beagle-0.2.6-3 -------------- * Wed May 17 2006 Brian Pepple - 0.2.6-3 - Add BR for python-devel, libXt-devel, & pygtk2-devel. bison-2.2-1 ----------- * Mon May 22 2006 Roland McGrath - 2.2-1 - New upstream version 2.2 coreutils-5.96-2 ---------------- * Mon May 22 2006 Tim Waugh 5.96-2 - 5.96. No longer need proc patch. * Fri May 19 2006 Tim Waugh - Fixed pr properly in multibyte locales (bug #192381). cups-1:1.2.1-2 -------------- * Mon May 22 2006 Tim Waugh 1:1.2.1-2 - 1.2.1. - Another STR #1705 fix (bug #192034). - Fixed devel package multilib conflict (bug #192664). * Mon May 22 2006 Tim Waugh 1:1.2.0-7 - Sync to svn5568. No longer need rpath patch. - Added a 'conflicts:' for kdelibs to prevent bug #192548. cyrus-sasl-2.1.22-1 ------------------- * Mon May 22 2006 Nalin Dahyabhai 2.1.22-1 - update to 2.1.22, adding pluginviewer to %{_sbindir} desktop-printing-0.19-7.2 ------------------------- * Mon May 22 2006 Karsten Hopp 0.19-7.2 - add buildrequires openssl-devel dictd-1.9.15-8 -------------- * Mon May 22 2006 Karsten Hopp 1.9.15-8 - buildrequires zlib-devel ekiga-2.0.1-3 ------------- * Mon May 22 2006 Jesse Keating - 2.0.1-3 - Fix BuildRequires and Requires(post), Requires(postun) * Wed Mar 15 2006 Daniel Veillard - 2.0.1-2 - run 'ekiga-config-tool --install-schemas' in %post, c.f. #178929 * Tue Mar 14 2006 Daniel Veillard - 2.0.1-1 - last minute bug rerelease 2.0.1 eog-2.15.2-1 ------------ * Mon May 22 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 evince-0.5.3-1 -------------- * Mon May 22 2006 Kristian H??gsberg 0.5.3-1 - Bump poppler_version to 0.5.2. - Package icons and add %post and %postun script to update icon cache. * Wed May 17 2006 Matthias Clasen - 0.5.3-1 - Update to 0.5.3 foomatic-3.0.2-36 ----------------- * Mon May 22 2006 Karsten Hopp 3.0.2-36 - add buildrequires ghostscript-devel so that /usr/lib/cups/driver/foomatic gets built gail-1.8.11-2 ------------- * Mon May 22 2006 Matthias Clasen - 1.8.11-2 - Make it build in mock gdm-1:2.15.3-2 -------------- * Mon May 22 2006 Matthias Clasen - 1:2.15.3-2 - Add missing BuildRequires (#192494) * Wed May 17 2006 Matthias Clasen - 1:2.15.3-1 - Update to 2.15.3 * Wed May 10 2006 Matthias Clasen - 1:2.15.0-1 - Update to 2.15.0 giflib-4.1.3-7 -------------- * Mon May 22 2006 Karsten Hopp 4.1.3-7 - buildrequires libICE-devel, libSM-devel gimp-print-4.2.7-17 ------------------- * Mon May 22 2006 Karsten Hopp 4.2.7-17 - buildrequires openssl-devel, otherwise it'll link with gnutls gkrellm-2.2.9-3 --------------- * Mon May 22 2006 Karsten Hopp 2.2.9-3 - fix libdir patch gnome-media-2.14.0-3 -------------------- * Mon May 22 2006 Matthias Clasen - 2.14.0-3 - disable scrollkeeper gnome-panel-2.14.1-4 -------------------- * Mon May 22 2006 Matthias Clasen - 2.14.1-4 - Make it build in mock * Fri May 12 2006 Matthias Clasen - 2.14.1-3 - Close the about dialog gnome-power-manager-2.15.2-2 ---------------------------- * Mon May 22 2006 Matthias Clasen - 2.15.2-2 - Rebuild gnome-terminal-2.15.1-1 ----------------------- * Mon May 22 2006 Matthias Clasen 2.15.1-1 - Update to 2.15.1 gnome-volume-manager-1.5.15-1.2 ------------------------------- * Mon May 22 2006 Radek Vok??l 1.5.15-1.2 - rebuilt against new libnotify gstreamer-0.10.6-1 ------------------ * Mon May 22 2006 Matthias Clasen - 0.10.6-1 - Update to 0.10.6 * Tue Feb 14 2006 Rik van Riel - 0.10-3-3 - Obsolete gstreamer-plugins (#181296) * Mon Feb 13 2006 Christopher Aillon - 0.10.3-2 - Rebuild gstreamer-plugins-base-0.10.7-1 ------------------------------- * Mon May 22 2006 Matthias Clasen 0.10.7-1 - Update to 0.10.7 * Wed Mar 01 2006 Karsten Hopp 0.10.3-3 - really add BuildRequires: cdparanoia-devel (#179034) * Mon Feb 20 2006 John (J5) Palmieri - 0.10.3-2 - Obsolete gstreamer-plugins (Bug #182098) gthumb-2.7.7-2 -------------- * Mon May 22 2006 Matthias Clasen - 2.7.7-2 - Update to 2.7.7 gtk-doc-1.6-3 ------------- * Mon May 22 2006 Matthias Clasen 1.6-3 - Make it build in mock hdparm-6.6-1 ------------ * Mon May 22 2006 Karsten Hopp 6.3-3 - remove obsolute include patch - disable idestruct patch, rebuild * Fri Feb 10 2006 Jesse Keating - 6.3-2.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 6.3-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes kdelibs-6:3.5.2-6 ----------------- * Mon May 22 2006 Than Ngo 6:3.5.2-6 - fix #192585, kdeprint writes incorrect cupsd.conf * Thu May 18 2006 Than Ngo 6:3.5.2-5 - use a versioned Obsoletes for kdelibs-docs krb5-1.4.3-7 ------------ * Mon May 22 2006 Nalin Dahyabhai 1.4.3-7 - further munge krb5-config so that 'libdir=/usr/lib' is given even on 64-bit architectures, to avoid multilib conflicts; other changes will conspire to strip out the -L flag which uses this, so it should be harmless (#192692) kudzu-1.2.36-1 -------------- * Mon May 22 2006 Bill Nottingham - 1.2.36-1 - add asix to usb whitelisting code * Mon May 08 2006 Bill Nottingham - 1.2.35-1 - fix a module_upgrade segfault (#190938) libchewing-0.3.0-1.2.1 ---------------------- * Mon May 22 2006 Darshan Santani - New source tarball added. - Rebuild. * Thu May 18 2006 Jens Petersen - configure with --disable-static - exclude INSTALL from docs libgnomeprint22-2.12.1-5 ------------------------ * Mon May 22 2006 Matthias Clasen - 2.12.1-5 - Add missing BuildRequires libpng-2:1.2.10-2 ----------------- * Mon May 22 2006 Matthias Clasen - 2:1.2.10-2 - Re-add static libraries * Thu May 04 2006 Matthias Clasen - 2:1.2.10-1 - Update to 1.2.10 - Drop static libraries * Fri Feb 10 2006 Jesse Keating - 2:1.2.8-2.2.1 - bump again for double-long bug on ppc(64) libsemanage-1.6.7-3 ------------------- * Mon May 15 2006 Dan Walsh - 1.6.7-3 - Spec file cleanup from n0dalus+redhat at gmail.com * Mon May 15 2006 Dan Walsh - 1.6.7-2 - Add /usr/include/semanage to spec file lvm2-2.02.06-1.1 ---------------- * Mon May 22 2006 Alasdair Kergon - 2.02.06-1.1 - Reinstate archs now build system is back. - BuildRequires libsepol-devel. nautilus-sendto-0.5-1 --------------------- * Mon May 22 2006 Alexander Larsson 0.5-1 - Update to 0.5 - Add libgnomeui-devel buildreq poppler-0.5.2-1 --------------- * Mon May 22 2006 Kristian H??gsberg 0.5.2-1 - Update to 0.5.2. postgresql-8.1.4-1 ------------------ * Mon May 22 2006 Tom Lane 8.1.4-1 - Update to PostgreSQL 8.1.4 (includes fixes for CVE-2006-2313, CVE-2006-2314; see bug #192173) - Update to PyGreSQL 3.8 - Suppress noise from chcon, per bug #187744 prelink-0.3.7-1 --------------- * Mon May 22 2006 Jakub Jelinek 0.3.7-1 - in -q mode, recheck the canonicalized filename to avoid overwriting symlinks with regular files (#145983, #188062) - allow prelinking of binaries with .tbss section slang-2.0.6-1 ------------- * Mon May 22 2006 Miroslav Lichvar - 2.0.6-1 - update to slang-2.0.6 - move .so.2 link to main package - don't package static library and utf8 link - remove requires for libtool and libtermcap - rearrange doc files (#191583) startup-notification-0.8-4 -------------------------- * Mon May 22 2006 Matthias Clasen - 0.8-4 - Add missing BuildRequires - Don't install static libraries tomboy-0.3.5-4 -------------- * Mon May 22 2006 Matthias Clasen - 0.3.5-4 - Add missing BuildRequires vino-2.13.5-3 ------------- * Mon May 22 2006 Matthias Clasen - 2.13.5-3 - Add missing BuildRequires xchat-1:2.6.0-5 --------------- * Mon May 22 2006 Jesse Keating - 1:2.6.0-5 - Adding missing buildreq (bz:191577, thanks Paul F.) Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.7.2.1-1.ppc64 requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.9.4.1-2.ppc64 requires libnotify.so.0()(64bit) scim-chewing - 0.2.1-6.ppc64 requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.i686 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.i686 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.i386 requires libnotify.so.0 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.i686 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires kernel-smp = 0:2.6.16-1.2096_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.26.i686 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.i686 requires /lib/modules/2.6.16-1.2096_FC5xenU rhythmbox - 0.9.4.1-2.i386 requires libnotify.so.0 scim-chewing - 0.2.1-6.i386 requires libchewing.so.2 Broken deps for ia64 ---------------------------------------------------------- evolution - 2.7.2.1-1.ia64 requires libnotify.so.0()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.4.1-2.ia64 requires libnotify.so.0()(64bit) scim-chewing - 0.2.1-6.ia64 requires libchewing.so.2()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 GFS-kernel - 2.6.15.1-5.FC5.20.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.20.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 cman-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 dlm-kernel - 2.6.15.1-0.FC5.17.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.17.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5 gnbd-kernel - 2.6.15-5.FC5.26.x86_64 requires kernel = 0:2.6.16-1.2096_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.26.x86_64 requires kernel-xen0 = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires kernel-xenU = 0:2.6.16-1.2096_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.26.x86_64 requires /lib/modules/2.6.16-1.2096_FC5xenU rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) scim-chewing - 0.2.1-6.x86_64 requires libchewing.so.2()(64bit) Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390 requires libnotify.so.0 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 scim-chewing - 0.2.1-6.s390 requires libchewing.so.2 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for ppc ---------------------------------------------------------- evolution - 2.7.2.1-1.ppc requires libnotify.so.0 rhythmbox - 0.9.4.1-2.ppc requires libnotify.so.0 scim-chewing - 0.2.1-6.ppc requires libchewing.so.2 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 evolution - 2.7.2.1-1.s390x requires libnotify.so.0()(64bit) geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) scim-chewing - 0.2.1-6.s390x requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 23 09:00:01 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 23 May 2006 11:00:01 +0200 Subject: Resource sharing for two users logged in locally simultaneously Message-ID: <20060523110001.6a62775e@python2> Hi, Here's the one big feature I'd like to have in Fedora for my current needs : The possibility to have everything "just work" when more than one user is logged into X (from gdm). The need : Me and my girlfriend share the same PC at home for various things, and we both have our own users in order to keep settings separate (mainly useful for WM settings, program preferences, UI language). We don't have the habit of logging out since we never know which one of us will be the next to use the computer, so... the easiest is to have two gdm screens and let us both log in, especially since gdm allows that to be trivially configured! The problem : On FC4, changing /etc/security/console.perms* files in order to have group write access on various devices, for a group we both belonged to, worked out quite well. Sound was then OK, CDs/DVDs too... quite alright. On FC5, things got more complicated and I still wasn't able to get everything working as on FC4. For USB drives for instance, now that hotplug and udev seem to handle that, they get mounted, but although both users can see them, only one has write access to it, and it seems to be randomly one or the other. I wasn't even able to find how to change/fix that... So what I'd like would be for development to try and "clean up" the way console permissions are handled since it seems to be going in all directions currently, simplify everything and take into account at least these two common cases : - Some devices should always be writable by a given group. Useful for instance when logging in through ssh to remotely play music, which requires write access to the sound devices. - Some devices should always be available to all users logged in locally (the case I described above). Is this possible, would it be hard to do? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2208_FC6 Load : 2.08 2.03 1.82 From Axel.Thimm at ATrpms.net Tue May 23 10:54:41 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 May 2006 12:54:41 +0200 Subject: Back to 6 month schedule? Message-ID: <20060523105441.GA5224@neu.nirvana> Hi, I just checked with the schedule for FC6 in the wiki. I thought FC was targetting 9 months cycles, and FC6 looks like a 6 month cycle. Just curious what the targeted general schedule is, what FC6's concrete schedule is (e.g. if the general schedule is 9 month, why go 6 months for FC6?), and closely related to this, what the relationship RHEL5 to FC5/FC6 will be. My guess is that having an FC6 shortly before RHEL5 may be nice for checking some post-FC5 items that will have made it into RHEL5 (for instance xen and storage/cluster/gfs improvements). Is that the master plan? BTW in case it sounds like I would mind either way, I don't. ;) Maybe this has been discussed here before, but then I missed it when searching for "schedule" and "month" in subject lines. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Tue May 23 11:03:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 12:03:30 +0100 Subject: Back to 6 month schedule? In-Reply-To: <20060523105441.GA5224@neu.nirvana> References: <20060523105441.GA5224@neu.nirvana> Message-ID: <4472EC02.5000706@city-fan.org> Axel Thimm wrote: > Hi, > > I just checked with the schedule for FC6 in the wiki. I thought FC was > targetting 9 months cycles, and FC6 looks like a 6 month cycle. > > Just curious what the targeted general schedule is, what FC6's > concrete schedule is (e.g. if the general schedule is 9 month, why go > 6 months for FC6?), and closely related to this, what the relationship > RHEL5 to FC5/FC6 will be. > > My guess is that having an FC6 shortly before RHEL5 may be nice for > checking some post-FC5 items that will have made it into RHEL5 (for > instance xen and storage/cluster/gfs improvements). Is that the master > plan? > > BTW in case it sounds like I would mind either way, I don't. ;) > > Maybe this has been discussed here before, but then I missed it when > searching for "schedule" and "month" in subject lines. I thought the 9 months for FC5 was always a one-off in order to get the necessary installer infrastructure work done, and the plan was always for 6-monthly releases in general. Paul. From Axel.Thimm at ATrpms.net Tue May 23 11:14:07 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 23 May 2006 13:14:07 +0200 Subject: Back to 6 month schedule? In-Reply-To: <4472EC02.5000706@city-fan.org> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> Message-ID: <20060523111407.GB5829@neu.nirvana> On Tue, May 23, 2006 at 12:03:30PM +0100, Paul Howarth wrote: > Axel Thimm wrote: > >I just checked with the schedule for FC6 in the wiki. I thought FC > >was targetting 9 months cycles, and FC6 looks like a 6 month cycle. > > > >Just curious what the targeted general schedule is, what FC6's > >concrete schedule is (e.g. if the general schedule is 9 month, why > >go 6 months for FC6?), and closely related to this, what the > >relationship RHEL5 to FC5/FC6 will be. > > > >My guess is that having an FC6 shortly before RHEL5 may be nice for > >checking some post-FC5 items that will have made it into RHEL5 (for > >instance xen and storage/cluster/gfs improvements). Is that the > >master plan? > > > >BTW in case it sounds like I would mind either way, I don't. ;) > > > >Maybe this has been discussed here before, but then I missed it > >when searching for "schedule" and "month" in subject lines. > > I thought the 9 months for FC5 was always a one-off in order to get > the necessary installer infrastructure work done, and the plan was > always for 6-monthly releases in general. I remember at the beginning of the FC5 cycle some developers that raised concerns against the 3 months development + 3 months bug fixing, and pleaded for a 6+3 model, e.g. effectively doubling the development efforts per cycle, while the total cycle extends for only 50%. It also later went through the press that Fedora was going 9 months instead of 6 months, so I assumed it had been set in stone as such. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue May 23 11:24:19 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 May 2006 13:24:19 +0200 Subject: Back to 6 month schedule? In-Reply-To: <4472EC02.5000706@city-fan.org> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> Message-ID: <1148383459.20933.82.camel@thl.ct.heise.de> Am Dienstag, den 23.05.2006, 12:03 +0100 schrieb Paul Howarth: > Axel Thimm wrote: > > Hi, > > > > I just checked with the schedule for FC6 in the wiki. I thought FC was > > targetting 9 months cycles, and FC6 looks like a 6 month cycle. > > > > Just curious what the targeted general schedule is, what FC6's > > concrete schedule is (e.g. if the general schedule is 9 month, why go > > 6 months for FC6?), and closely related to this, what the relationship > > RHEL5 to FC5/FC6 will be. > > > > My guess is that having an FC6 shortly before RHEL5 may be nice for > > checking some post-FC5 items that will have made it into RHEL5 (for > > instance xen and storage/cluster/gfs improvements). Is that the master > > plan? > > > > BTW in case it sounds like I would mind either way, I don't. ;) > > > > Maybe this has been discussed here before, but then I missed it when > > searching for "schedule" and "month" in subject lines. > > I thought the 9 months for FC5 was always a one-off in order to get the > necessary installer infrastructure work done, and the plan was always > for 6-monthly releases in general. That my impression, too. But the back-an-forth with FC4, FC5 and FC6 seems to have confused a lot of people afaics -- we IMHO should try to avoid that in the future. That's why I'd prefer if we could have a long term planing with a fixed six month release interval. E.g. always release one week after each Gnome-Release (that would be sencond half or march and september). If there are reasons that force a slip then delay the release of "n" by one, two or three weeks (or even more), but that should not effect the schedule of release "n+1". Just my 2 cent. CU thl From jkeating at redhat.com Tue May 23 11:47:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 07:47:50 -0400 Subject: Back to 6 month schedule? In-Reply-To: <20060523105441.GA5224@neu.nirvana> References: <20060523105441.GA5224@neu.nirvana> Message-ID: <1148384870.3819.11.camel@ender> On Tue, 2006-05-23 at 12:54 +0200, Axel Thimm wrote: > Just curious what the targeted general schedule is, what FC6's > concrete schedule is (e.g. if the general schedule is 9 month, why go > 6 months for FC6?), and closely related to this, what the relationship > RHEL5 to FC5/FC6 will be. FC5's 9(10, 11) month schedule was an experiment in adjusting the schedule to see if it helped in our release. While it did allow for some larger changes to make it through, it multiplied the amount of little changes at the same time. It created a very bad situation for those of us trying to do any kind of QA on the distro before it went out the door. For all those involved, we felt that the 9 month schedule hurt more than it helped and we're back to the tried and true 6 month schedule, with slips here and there (hopefully not). Sorry for the confusion. -- 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 skvidal at linux.duke.edu Tue May 23 11:54:59 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 23 May 2006 07:54:59 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148384870.3819.11.camel@ender> References: <20060523105441.GA5224@neu.nirvana> <1148384870.3819.11.camel@ender> Message-ID: <1148385299.5212.3.camel@cutter> On Tue, 2006-05-23 at 07:47 -0400, Jesse Keating wrote: > FC5's 9(10, 11) month schedule was an experiment in adjusting the > schedule to see if it helped in our release. While it did allow for > some larger changes to make it through, it multiplied the amount of > little changes at the same time. It created a very bad situation for > those of us trying to do any kind of QA on the distro before it went out > the door. For all those involved, we felt that the 9 month schedule > hurt more than it helped and we're back to the tried and true 6 month > schedule, with slips here and there (hopefully not). Not all of us involved. I quite liked the 9 month schedule. -sv From jkeating at redhat.com Tue May 23 11:57:23 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 07:57:23 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148385299.5212.3.camel@cutter> References: <20060523105441.GA5224@neu.nirvana> <1148384870.3819.11.camel@ender> <1148385299.5212.3.camel@cutter> Message-ID: <1148385443.3819.16.camel@ender> On Tue, 2006-05-23 at 07:54 -0400, seth vidal wrote: > > Not all of us involved. > > I quite liked the 9 month schedule. Open mouth, insert foot. I didn't mean to say all involved, that was supposed to be 'most' or even 'some'. In reality, it did NOT turn into 6 months of changes and 3 months of fixes, it turned into 8~9 months of changes and a couple hectic weeks of trying to fix crap. Hence the slips and the delays and whatnot. Maybe if we had been more draconic about development freezes and freezes in general it would have ended up different. But alas we weren't and thus we had a TON more changed crap at the end of it all to try and polish up and get out. Even if we did stop at 6 months, this would mean that for all intensive purposes we're releasing 3 month old software into our 'early adopters' community. That wouldn't fly much either (; -- 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 mharris at mharris.ca Tue May 23 11:24:40 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 23 May 2006 07:24:40 -0400 Subject: Back to 6 month schedule? In-Reply-To: <20060523111407.GB5829@neu.nirvana> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <20060523111407.GB5829@neu.nirvana> Message-ID: <4472F0F8.4010300@mharris.ca> Axel Thimm wrote: > On Tue, May 23, 2006 at 12:03:30PM +0100, Paul Howarth wrote: >> Axel Thimm wrote: >>> I just checked with the schedule for FC6 in the wiki. I thought FC >>> was targetting 9 months cycles, and FC6 looks like a 6 month cycle. >>> >>> Just curious what the targeted general schedule is, what FC6's >>> concrete schedule is (e.g. if the general schedule is 9 month, why >>> go 6 months for FC6?), and closely related to this, what the >>> relationship RHEL5 to FC5/FC6 will be. >>> >>> My guess is that having an FC6 shortly before RHEL5 may be nice for >>> checking some post-FC5 items that will have made it into RHEL5 (for >>> instance xen and storage/cluster/gfs improvements). Is that the >>> master plan? >>> >>> BTW in case it sounds like I would mind either way, I don't. ;) >>> >>> Maybe this has been discussed here before, but then I missed it >>> when searching for "schedule" and "month" in subject lines. >> I thought the 9 months for FC5 was always a one-off in order to get >> the necessary installer infrastructure work done, and the plan was >> always for 6-monthly releases in general. > > I remember at the beginning of the FC5 cycle some developers that > raised concerns against the 3 months development + 3 months bug > fixing, and pleaded for a 6+3 model, e.g. effectively doubling the > development efforts per cycle, while the total cycle extends for only > 50%. > > It also later went through the press that Fedora was going 9 months > instead of 6 months, so I assumed it had been set in stone as such. :) Fedora has always had a variable 6 month development cycle, meaning that it is 6 months, but we may reduce or extend it if necessary to meet certain goals for a particular release. To the best of my knowledge this has not changed in any way. Fedora Core 5 was extended to 9 months under this policy, to meet certain goals for the release. There was indeed a lot of discussion on the mailing lists from various Red Hat engineers, community developers and others expressing their opinions on various hypothetical advantages and disadvantages of making the base development cycle longer or shorter, and opinions varied quite widely as to what the best thing to do might be. That is no surprise really, because there is no "best" situation which is "best" for every single person. Making the cycle shorter, would be "best" for some people in theory, and making it longer would make it "best" for others out there. While there was much discussion and opining about this, to the best of my knowledge it was just that, and there have been no policy changes to the length of the Fedora development cycle. We're still on a 6 month variable cycle, which may be reduced or extended to meet particular design/development goals for a particular release. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From seanlkml at sympatico.ca Tue May 23 12:56:50 2006 From: seanlkml at sympatico.ca (Sean) Date: Tue, 23 May 2006 08:56:50 -0400 Subject: Is yum fix coming? Message-ID: Hi folks, Been ignoring these errors for a couple of months because I saw a few messages go by saying this was a known problem that was being worked on. However, it's getting a bit annoying having to run yum 15 or 20 times to complete an update. It errors out with different messages each time, but usually they're of the form: http://download.fedoraproject.org/pub/fedora/linux/core/development/i386/Fedora/RPMS/SDL-1.2.10-1.i386.rpm: [Errno 14] HTTP Error 404: Date: Tue, 23 May 2006 12:54:09 GMT Server: Apache/2.0.46 (Red Hat) Content-Length: 378 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Error: failure: Fedora/RPMS/SDL-1.2.10-1.i386.rpm from development: [Errno 256] No more mirrors to try. This is with yum 2.6.1-1. Is there relief on the way for this issue? Sean From selinux at gmail.com Tue May 23 13:07:04 2006 From: selinux at gmail.com (Tom London) Date: Tue, 23 May 2006 06:07:04 -0700 Subject: Is yum fix coming? In-Reply-To: References: Message-ID: <4c4ba1530605230607p4a7be6e8pead0d50695e48d1b@mail.gmail.com> On 5/23/06, Sean wrote: > Hi folks, > > Been ignoring these errors for a couple of months because I saw a few > messages go by saying this was a known problem that was being worked on. > > However, it's getting a bit annoying having to run yum 15 or 20 times > to complete an update. It errors out with different messages each time, > but usually they're of the form: > > http://download.fedoraproject.org/pub/fedora/linux/core/development/i386/Fedora/RPMS/SDL-1.2.10-1.i386.rpm: [Errno 14] HTTP Error 404: Date: Tue, 23 May 2006 12:54:09 GMT > Server: Apache/2.0.46 (Red Hat) > Content-Length: 378 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > Trying other mirror. > Error: failure: Fedora/RPMS/SDL-1.2.10-1.i386.rpm from development: [Errno 256] No more mirrors to try. > > > This is with yum 2.6.1-1. Is there relief on the way for this issue? > > Sean > I had this problem too, but it seemed that changes to /etc/yum.repos.d/*.repo did not 'take'. Check /etc/yum.repos.d for *.rpmnew versions of your repo files. 'Installing' the new ones fixed this problem for me (e.g., mv fedora-development.repo fedora-development.old; mv fedora-development.repo.rpmnew fedora-development.repo). tom -- Tom London From seanlkml at sympatico.ca Tue May 23 13:24:49 2006 From: seanlkml at sympatico.ca (Sean) Date: Tue, 23 May 2006 09:24:49 -0400 Subject: Is yum fix coming? In-Reply-To: <4c4ba1530605230607p4a7be6e8pead0d50695e48d1b@mail.gmail.com> References: <4c4ba1530605230607p4a7be6e8pead0d50695e48d1b@mail.gmail.com> Message-ID: On Tue, 23 May 2006 06:07:04 -0700 "Tom London" wrote: > I had this problem too, but it seemed that changes to > /etc/yum.repos.d/*.repo did not 'take'. > > Check /etc/yum.repos.d for *.rpmnew versions of your repo files. > > 'Installing' the new ones fixed this problem for me (e.g., mv > fedora-development.repo fedora-development.old; mv > fedora-development.repo.rpmnew fedora-development.repo). > Thanks Tom, seems to have done the trick. Sean From david at lovesunix.net Tue May 23 13:33:20 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 23 May 2006 15:33:20 +0200 Subject: rawhide report: 20060523 changes In-Reply-To: <200605230733.k4N7Xj6j024604@porkchop.devel.redhat.com> References: <200605230733.k4N7Xj6j024604@porkchop.devel.redhat.com> Message-ID: <1148391200.29013.5.camel@localhost.localdomain> > evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) > rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) I can't help to notice that these have been broken for a few days, is a fix forthcoming? - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From avi at argo.co.il Tue May 23 13:47:21 2006 From: avi at argo.co.il (Avi Kivity) Date: Tue, 23 May 2006 16:47:21 +0300 Subject: Heads-up: Requiring PAE for running Xen In-Reply-To: <20060522165131.GD22032@devserv.devel.redhat.com> References: <1147889279.13113.22.camel@aglarond.local> <20060520141425.GD1924@neu.nirvana> <1148309484.1881.26.camel@orodruin.boston.redhat.com> <20060522151941.GA28153@devserv.devel.redhat.com> <4471D797.3030603@argo.co.il> <20060522162935.GA22032@devserv.devel.redhat.com> <4471EB75.20607@argo.co.il> <20060522165131.GD22032@devserv.devel.redhat.com> Message-ID: <44731269.70906@argo.co.il> Alan Cox wrote: > On Mon, May 22, 2006 at 07:48:53PM +0300, Avi Kivity wrote: > >>> Rsync. >>> >> Still have to read every byte on the disk. I doubt you'd get away with >> less than 20 minutes. >> > > That isn't a problem I find. It takes me a good hour to pack 8) > Actually rsync is slower than copying. Rsync has to read and write the entire image on the target, while a copy only needs to write it. Rsync is excellent when network bandwidth is low, but with GbE, network bandwidth exceeds disk bandwidth. -- error compiling committee.c: too many arguments to function From saugart at mazunetworks.com Tue May 23 13:57:14 2006 From: saugart at mazunetworks.com (Steven Augart) Date: Tue, 23 May 2006 09:57:14 -0400 Subject: question about creation of updated DVD iso In-Reply-To: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> Message-ID: <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> On Tue, 2006-05-16 at 18:26 +0200, Gianluca Cecchi wrote: > I have read instructions at > http://fedoranews.org/contributors/gene_czarcinski/update_distro/ > I have basically one question: how to update the vmlinuz and > initrd.img files to put under isolinux directory of CD/DVD, so that > the installation kernel is the 2111 one and not the default 2054? > Do I have to compile the kernel source rpm with any specific target? > I remember in rh el 3 I was able to use a specific config file for the > installation kernel... > but it seems it is not here in Fedora. > Is it the i586 one? And what about the initrd.img file generation? Dear Gianluca, These are all really good questions. I assume you'd like to do this with FC 5, since I think 2054 was the default for FC 5. We've had some discussion on anaconda-devel-list about how to build modified installation CD images. A guy named Dan Carpenter has posted some scripts that have helped, and I personally managed to use his scripts (well, a variant of them, for which I posted the URL to the list -- you can look at this month's archives) to build an FC 5 installation CD that had my own packages on it and my own version of Anaconda. This required rebuilding the initrd. However, I did not replace the kernel. (The motivation here was that FC 5's Anaconda has a bug in it that crashes when it tries to find the CD drive on an IBM Blade Center, if the Kickstart file is on CD. Although I fixed the bug and posted the URL for the patches, it would be a lot less work, in most cases, just to work around it by reading the Kickstart file off of a floppy disk.) However, even though the scripts rebuild the initrd, I was using the kernel that came with the initrd. I believe that the kernel builds for the initrd and installer CD are identical to the stock kernel that ships with FC 5 and is installed. So using the stock one from the RPM should be safe. If you want to recompile the kernel for some reason, then the .config file from that kernel is probably pretty safe too. I know that Hans K. Rosbach (at http://fedora.isphuset.no/ ) has rebuilt the Fedora Core 4 installation CD set, with updated RPM packages, including an updated installation kernel. He calls it "Unofficial FC 4.2". I'm certainly curious to know how he rebuilt the initrd for FC 4 with the updated installer kernel; I myself failed to do it. Here's the story, in case you find it helpful to know about a path that didn't work for me: I've been putting together an installation CD for us to use here at Mazu Networks to install on our Mazu Profiler security appliance (a hardware box that we sell). We want a single CD that has bundled on it the Kickstart file we use and all of the packages we want to install. After I got the FC 5 version working (by fixing Anaconda, as I mentioned above), we made a technical decision to base the current release of the product on FC 4. The problem here is that the distributed FC 4 installer comes with kernel version 2.6.11-1.1369_FC4. 2.6.11 has a bug in the keyboard driver which causes a kernel panic when booting on the IBM Blade Center. 2.6.16 doesn't have it. So, before I discovered Hans Rosbach's kernel, I attempted the following sequence: * Got the new kernel. Unpacked it with the help of rpm2cpio. * Copied the first CD over to hard drive (write-able media). Let's say to the directory CD/ . * unpack the initrd on the CD: mkdir initrd; cd initrd; gzip -d -c < ../initrd.img | cpio -d -i * Unpacked the modules.cgz file on the CD (same format as the initrd) * Replaced the modules in it with matching ones from the new kernel, including having an appropriately-named subdirectory containing the modules. (This doesn't work for the MPT SCSI driver, which now needs three different kernel mods to work together, where it used to have two, but that's probably not relevant for you. Anyway, what I'm talking about didn't work.) * Repacked modules.cgz. Put it in the same place as the old one in my initrd subdirectory. * Repacked initrd: cd initrd; find . -print | cpio -o -c | gzip -9 -c>../initrd-new.img * cp initrd-new.img CD/isolinux/initrd.img * cp new-kernel/boot/vmlinuz CD/isolinux/vmlinuz * Reburned the CD with: mkisofs \ -o $ISO_DEST -r \ -b isolinux/isolinux.bin -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ CD/ Anyway, doing this led to a kernel panic: VFS: Unable to mount root FS on unknown-block(9, 1) And the stack trace is: panic => mount_block_root => sys_mknod => initrd_load => prepare_namespace => sys_access => init So, I obviously got something wrong there, but have no idea what it was. Just wanted to save you some time by telling you what doesn't work. As someone else on the list has mentioned, there are scripts available in the Anaconda distribution in the "scripts" directory. They are undocumented and I think it would take a lot of trial-and-error and study to learn to use them, but you might have to. If you do, please write up your experience and post it. Good luck! -- Steven Augart Mazu Networks Cambridge, Massachusetts, USA From mbarnes at redhat.com Tue May 23 14:03:24 2006 From: mbarnes at redhat.com (Matthew Barnes) Date: Tue, 23 May 2006 10:03:24 -0400 Subject: rawhide report: 20060523 changes In-Reply-To: <1148391200.29013.5.camel@localhost.localdomain> References: <200605230733.k4N7Xj6j024604@porkchop.devel.redhat.com> <1148391200.29013.5.camel@localhost.localdomain> Message-ID: <1148393004.4698.0.camel@mbarnes.boston.redhat.com> On Tue, 2006-05-23 at 15:33 +0200, David Nielsen wrote: > > evolution - 2.7.2.1-1.x86_64 requires libnotify.so.0()(64bit) > > rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) > > I can't help to notice that these have been broken for a few days, is a > fix forthcoming? For evolution, yes, I'm working on it now. Sorry about the delay. Matt From billcrawford1970 at gmail.com Tue May 23 14:25:24 2006 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 23 May 2006 15:25:24 +0100 Subject: Sun JRE or JDK to enter core, or at least extras? In-Reply-To: <20060519142609.GA13734@jadzia.bu.edu> References: <446B8C2B.8050003@gmail.com> <1147900189.20963.45.camel@atlantis.mpeters.local> <20060519142609.GA13734@jadzia.bu.edu> Message-ID: <200605231525.25590.billcrawford1970@googlemail.com> Le Vendredi 19 Mai 2006 15:26, Matthew Miller a ?crit?: > My assumption, given that Sun people say that this clause does not prevent > distribution of the JDK _alongside_ GCJ etc., is that people are reading > the phrase "in conjunction with" more strongly than it should be. A more > narrow reading indicates that you can't use the Sun JVM with GNU Classpath, > but you can use and distribute them both _not_ in conjunction. "in conjunction with" != "alongside" .. it really does mean "joined with" rather than just accompanying. But: > But really, a lawyer needs to answer this question. Yes. > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> From dimi at lattica.com Tue May 23 14:17:45 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 23 May 2006 10:17:45 -0400 (EDT) Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <20060523110001.6a62775e@python2> References: <20060523110001.6a62775e@python2> Message-ID: <35308.207.35.222.39.1148393865.squirrel@lattica.com> On Tue, May 23, 2006 5:00 am, Matthias Saou wrote: > easiest is to have two gdm screens and let us both log in, especially > since gdm allows that to be trivially configured! How did you get that setup, BTW? I've found this: http://www.faqs.org/docs/lnag/lnag_xwindows.html#2nd_GUI_login_prompt Is this the method you use? -- Dimi Paun Lattica, Inc. From galibert at pobox.com Tue May 23 14:42:17 2006 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 23 May 2006 16:42:17 +0200 Subject: question about creation of updated DVD iso In-Reply-To: <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> Message-ID: <20060523144217.GB45392@dspnet.fr.eu.org> I've managed to make a script to create a boot.img with an updated kernel. It's horribly hacky in places, but hey, it works. The filesystem setup needed is a directory with as subdirectories: - boot: The contents of boot.iso, i.e. one isolinux directory with boot.cat, etc. - initrd: The contents of the initrd (gzip -dc initrd.img | cpio -id --no-absolute-filenames) - configs: A directory with: - kernel-2.6.16-1.2111_FC5.x86_64.rpm (or another one, just not a xen one I think) - defmods.txt which is attached and comes from the anaconda-runtime scripts and Mk.1 eyeball - isolinux.cfg if you want to change it, otherwise remove the cp from the script - ks.cfg if you want to add it, otehrwise remove the cp from the script, you'll need an "ks=cdrom:/isolinux/ks.cfg" in the append of isolinux.cfg to use it automatically Also you need gen_initramfs_list.sh and gen_init_cpio from the linux kernel sources somewhere (in the script they're in ../..). Then you run mkiso, and hopefully you'll get a beautiful newboot.iso you can use for a nfs install. It's probably reasonably easy to extent to a dvd iso regeneration. OG. -------------- next part -------------- #!/bin/sh a=`cat initrd/etc/arch` rm -rf new mkdir new rsync -a initrd new rsync -a boot new mkdir new/kernel (cd new/kernel; rpm2cpio ../../configs/kernel*.rpm | cpio -id --no-absolute-filenames) v=`ls new/kernel/lib/modules` mkdir new/modules.1 new/modules.2 find new/kernel/lib/modules -name '*.ko' |xargs -iz mv z new/modules.1 touch new/modlist.txt for f in `cat configs/defmods.txt`; do echo $f >> new/modlist.txt; done for f in `egrep -v '^Version' new/initrd/modules/module-info |egrep -v '^ '`; do echo $f >> new/modlist.txt; done for f in `cat new/modlist.txt | sort -u`; do mv new/modules.1/$f.ko new/modules.2 done echo 'dir /'$v' 700 0 0' > new/modcpio.txt echo 'dir /'$v'/'$a' 700 0 0' >> new/modcpio.txt ../../gen_initramfs_list.sh new/modules.2 | sed 's%file /%file '$v'/'$a'/%' >> new/modcpio.txt ../../gen_init_cpio new/modcpio.txt | gzip --best > new/initrd/modules/modules.cgz cp new/kernel/boot/vmlinuz-$v new/boot/isolinux/vmlinuz cp configs/isolinux.cfg configs/ks.cfg new/boot/isolinux/. ../../gen_initramfs_list.sh new/initrd > new/cpiolist.txt ../../gen_init_cpio new/cpiolist.txt | gzip --best > new/boot/isolinux/initrd.img mkisofs -o newboot.iso \ -b isolinux/isolinux.bin -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ new/boot #cdrecord dev=/dev/hdc blank=fast gracetime=0 -nofix -v -sao -eject newboot.iso -------------- next part -------------- fat vfat nfs sunrpc lockd floppy cramfs loop edd pcspkr squashfs ohci-hcd uhci-hcd ehci-hcd hid mousedev usb-storage sd_mod sr_mod ub ieee1394 ohci1394 sbp2 ide-cd sr_mod sg st sd_mod scsi_mod iscsi_tcp fat msdos vfat ext3 reiserfs jfs xfs dm-mod dm-zero dm-snapshot dm-mirror md raid0 raid1 raid5 raid6 vga16fb yenta_socket i82365 tcic pcmcia 8390 atmel crc-ccitt exportfs hermes hostap i2o_core ieee80211_crypt jbd libata megaraid_mm mii mptscsih nfs_acl orinoco qla2xxx qlogicfas408 scsi_transport_fc scsi_transport_iscsi scsi_transport_sas scsi_transport_spi sungem_phy vgastate xor From mpeters at mac.com Tue May 23 14:58:12 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 23 May 2006 07:58:12 -0700 Subject: Back to 6 month schedule? In-Reply-To: <1148383459.20933.82.camel@thl.ct.heise.de> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> Message-ID: <1148396293.16995.11.camel@atlantis.mpeters.local> On Tue, 2006-05-23 at 13:24 +0200, Thorsten Leemhuis wrote: > E.g. always > release one week after each Gnome-Release ++ From jspaleta at gmail.com Tue May 23 15:04:29 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 May 2006 11:04:29 -0400 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <20060523110001.6a62775e@python2> References: <20060523110001.6a62775e@python2> Message-ID: <604aa7910605230804s1cfbf164x7454cd6fc10a0767@mail.gmail.com> On 5/23/06, Matthias Saou > Is this possible, would it be hard to do? I believe that the work on the PolicyKit layer of the HAL/DBUS stack is meant to address some of the easy user switching functionality issues. -jef From jkeating at redhat.com Tue May 23 15:13:48 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 11:13:48 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148383459.20933.82.camel@thl.ct.heise.de> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> Message-ID: <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 13:24 +0200, Thorsten Leemhuis wrote: > E.g. always > release one week after each Gnome-Release This is extremely distasteful from a rel-eng and QA perspective. We have to have our bits done about a week before we can release to the world, so you're asking us to take what Gnome Upstream releases and in the same day add them to the distro, spin a release, and send it out to the world. That has 'eat my babies' written all over it. Case in point FC5 release. We had to scramble to get the latest gnome released packages in, and many of them did not go in just because 'too many changes to be comfortable with this'. Ideally we'd be reaching test2 right around the time Gnome makes their release. That lines up with a feature freeze and gets those fresh bits out into the hands of the testers to give us a list of stuff to fix for Test3 and the resulting release. -- 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 Tue May 23 15:10:05 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 23 May 2006 17:10:05 +0200 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <35308.207.35.222.39.1148393865.squirrel@lattica.com> References: <20060523110001.6a62775e@python2> <35308.207.35.222.39.1148393865.squirrel@lattica.com> Message-ID: <20060523171005.289e4be0@python2> Dimi Paun wrote : > On Tue, May 23, 2006 5:00 am, Matthias Saou wrote: > > easiest is to have two gdm screens and let us both log in, especially > > since gdm allows that to be trivially configured! > > How did you get that setup, BTW? I've found this: > http://www.faqs.org/docs/lnag/lnag_xwindows.html#2nd_GUI_login_prompt > Is this the method you use? Yup. It's not as user friendly as if the same login screen could be used by multiple users, then have some kind of "switch login to other active session" in some menu, but it wasn't that hard to teach my girlfriend to switch between Alt+Ctrl+F7 and Alt+Ctrl+F8 to find her desktop. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2208_FC6 Load : 2.06 2.23 2.24 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 23 15:12:42 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 23 May 2006 17:12:42 +0200 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <604aa7910605230804s1cfbf164x7454cd6fc10a0767@mail.gmail.com> References: <20060523110001.6a62775e@python2> <604aa7910605230804s1cfbf164x7454cd6fc10a0767@mail.gmail.com> Message-ID: <20060523171242.440c385b@python2> Jeff Spaleta wrote : > On 5/23/06, Matthias Saou > > Is this possible, would it be hard to do? > > I believe that the work on the PolicyKit layer of the HAL/DBUS stack > is meant to address some of the easy user switching functionality > issues. Got any more information about this? Seems like the bit I'm missing alright. Still this doesn't really address the issue of now having to edit console.perms, udev rules and this hal/dbus stuff in order to set device permissions to be correct in all possible cases. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2208_FC6 Load : 2.38 2.40 2.31 From ajackson at redhat.com Tue May 23 14:22:36 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 23 May 2006 10:22:36 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4471F827.3010804@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> Message-ID: <44731AAC.3030909@redhat.com> Mike A. Harris wrote: > Dimi Paun wrote: >> On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: >>> On the other hand, there are many applications included both >>> in Fedora Core, and in Fedora Extras, which do rely on the >>> core fonts system still, and are likely to rely on it for the >>> forseeable future. >> >> Great to hear we're moving in this direction. >> I guess the obvious question is "what will break?". Once we >> have a clear idea what really depends on xfs (some packages, like >> wine, _can_ work with xfs if it's the only available option, or >> without), we can devise a plan of making xfs optional (moved to Extra >> along with all apps that depend on it?). > > No apps[1] require xfs. Lots of apps require "core fonts" > support. We currently provide core fonts support via the > xfs font server, however the X server is equally capable > of serving fonts on its own without a separate font server. I assume the [1] here was meant to point to a footnote about various very-low-level tools that do know how to explicitly talk to font servers. It's not a large list: fslsfonts, fstobdf, mkcfm, showfont, and xfsinfo from the Xorg app collection, and probably zero outside of that. I'm of the opinion that leaving xfs enabled isn't really a big deal even in RHEL, and that the correct fix is to fix the X server to use fontconfig once and for all, rather than expose users to a needless configuration change. I don't see the intermediate steps as being worthwhile targets on their own. - ajax From dimi at lattica.com Tue May 23 15:28:46 2006 From: dimi at lattica.com (Dimi Paun) Date: Tue, 23 May 2006 11:28:46 -0400 (EDT) Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <20060523171005.289e4be0@python2> References: <20060523110001.6a62775e@python2> <35308.207.35.222.39.1148393865.squirrel@lattica.com> <20060523171005.289e4be0@python2> Message-ID: <41769.207.35.222.39.1148398126.squirrel@lattica.com> On Tue, May 23, 2006 11:10 am, Matthias Saou wrote: > Yup. It's not as user friendly as if the same login screen could be > used by multiple users, then have some kind of "switch login to other > active session" in some menu, but it wasn't that hard to teach my > girlfriend to switch between Alt+Ctrl+F7 and Alt+Ctrl+F8 to find her > desktop. Yeah, but it would be nice to have that available in the GUI. Is anyone working on such a feature? I haven't used Windows in many years, but from what I've seen on a box running XP, it has this feature already... -- Dimi Paun Lattica, Inc. From dakingun at gmail.com Tue May 23 15:38:15 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Tue, 23 May 2006 11:38:15 -0400 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <41769.207.35.222.39.1148398126.squirrel@lattica.com> References: <20060523110001.6a62775e@python2> <35308.207.35.222.39.1148393865.squirrel@lattica.com> <20060523171005.289e4be0@python2> <41769.207.35.222.39.1148398126.squirrel@lattica.com> Message-ID: On 5/23/06, Dimi Paun wrote: > > On Tue, May 23, 2006 11:10 am, Matthias Saou wrote: > > Yup. It's not as user friendly as if the same login screen could be > > used by multiple users, then have some kind of "switch login to other > > active session" in some menu, but it wasn't that hard to teach my > > girlfriend to switch between Alt+Ctrl+F7 and Alt+Ctrl+F8 to find her > > desktop. > > Yeah, but it would be nice to have that available in the GUI. > Is anyone working on such a feature? I haven't used Windows > in many years, but from what I've seen on a box running XP, > it has this feature already... > Something like Gnome's FUSA, http://ignore-your.tv/fusa/ ? Deji From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 23 15:44:49 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 23 May 2006 17:44:49 +0200 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: References: <20060523110001.6a62775e@python2> <35308.207.35.222.39.1148393865.squirrel@lattica.com> <20060523171005.289e4be0@python2> <41769.207.35.222.39.1148398126.squirrel@lattica.com> Message-ID: <20060523174449.7ea4dbb3@python2> Deji Akingunola wrote : > On 5/23/06, Dimi Paun wrote: > > > > On Tue, May 23, 2006 11:10 am, Matthias Saou wrote: > > > Yup. It's not as user friendly as if the same login screen could be > > > used by multiple users, then have some kind of "switch login to other > > > active session" in some menu, but it wasn't that hard to teach my > > > girlfriend to switch between Alt+Ctrl+F7 and Alt+Ctrl+F8 to find her > > > desktop. > > > > Yeah, but it would be nice to have that available in the GUI. > > Is anyone working on such a feature? I haven't used Windows > > in many years, but from what I've seen on a box running XP, > > it has this feature already... > > Something like Gnome's FUSA, http://ignore-your.tv/fusa/ ? Exactly! I'll be looking deeper into that one for sure, thanks for the link. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2208_FC6 Load : 2.71 2.55 2.32 From katzj at redhat.com Tue May 23 15:47:28 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 23 May 2006 11:47:28 -0400 Subject: question about creation of updated DVD iso In-Reply-To: <20060523144217.GB45392@dspnet.fr.eu.org> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <20060523144217.GB45392@dspnet.fr.eu.org> Message-ID: <1148399249.392.7.camel@orodruin.boston.redhat.com> On Tue, 2006-05-23 at 16:42 +0200, Olivier Galibert wrote: > - initrd: The contents of the initrd (gzip -dc initrd.img | cpio -id --no-absolute-filenames) [snip] > Also you need gen_initramfs_list.sh and gen_init_cpio from the linux > kernel sources somewhere (in the script they're in ../..). Ermm, you do realize that there's a script in anaconda (scripts/upd-kernel) that will take a new kernel and explode everything that needs to go into the initrd? Jeremy From fedora at leemhuis.info Tue May 23 16:02:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 May 2006 18:02:28 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148400149.2297.2.camel@localhost.localdomain> Am Dienstag, den 23.05.2006, 11:13 -0400 schrieb Jesse Keating: > On Tue, 2006-05-23 at 13:24 +0200, Thorsten Leemhuis wrote: > > E.g. always > > release one week after each Gnome-Release > > This is extremely distasteful from a rel-eng and QA perspective. We > have to have our bits done about a week before we can release to the > world, so you're asking us to take what Gnome Upstream releases and in > the same day add them to the distro, spin a release, and send it out to > the world. That has 'eat my babies' written all over it. Case in point > FC5 release. We had to scramble to get the latest gnome released > packages in, and many of them did not go in just because 'too many > changes to be comfortable with this'. Ideally we'd be reaching test2 > right around the time Gnome makes their release. That lines up with a > feature freeze and gets those fresh bits out into the hands of the > testers to give us a list of stuff to fix for Test3 and the resulting > release. Then make it four weeks after Gnome. Or Two. Or Six -- I don't care. But I really would like a long-term plan where I know: okay, FC10 will be out in the beginning on October 2008. CU thl -- Thorsten Leemhuis From Matt_Domsch at dell.com Tue May 23 16:10:04 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 May 2006 11:10:04 -0500 Subject: rawhide rebuild in mock status 2006-05-23 Message-ID: <20060523161003.GA18290@lists.us.dell.com> Great progress! I'm now building i386 as well as x86_64. Can someone with the right powers kill off the old copies of emacs and rgmanager SRPMS in rawhide? I'm also starting to keep track of how long each build takes in mock. For each package, there's a new 'time.log' file. OpenOffice.org is the longest presently at 288 minutes (on x86_64; it doesn't build on i386 right now...) Rawhide-in-Mock Build Results for x86_64 Architecture Tue May 23 09:04:07 CDT 2006 Number failed to build: 182 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 154 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 7 ---------------------------------- SDL elilo emacs gcc magma-plugins memtest86+ rgmanager With bugs filed: 146 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] control-center ['192233 NEW'] device-mapper-multipath ['192242 ASSIGNED'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] eclipse ['192563 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gmime ['192116 CLOSED'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 NEW'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] hal-cups-utils ['192507 NEW'] initscripts ['192509 CLOSED'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdebindings ['192520 CLOSED'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libselinux ['192562 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEW'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 NEW'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 NEW'] xorg-x11-drv-digitaledge ['192316 NEW'] xorg-x11-drv-dmc ['192312 NEW'] xorg-x11-drv-dummy ['192304 NEW'] xorg-x11-drv-dynapro ['192300 NEW'] xorg-x11-drv-elo2300 ['192320 NEW'] xorg-x11-drv-elographics ['192318 NEW'] xorg-x11-drv-evdev ['192317 NEW'] xorg-x11-drv-fbdev ['192325 NEW'] xorg-x11-drv-fpit ['192324 NEW'] xorg-x11-drv-hyperpen ['192326 NEW'] xorg-x11-drv-i810 ['192334 NEW'] xorg-x11-drv-jamstudio ['192335 NEW'] xorg-x11-drv-joystick ['192336 NEW'] xorg-x11-drv-keyboard ['192337 NEW'] xorg-x11-drv-magellan ['192338 NEW'] xorg-x11-drv-magictouch ['192339 NEW'] xorg-x11-drv-mga ['192340 NEW'] xorg-x11-drv-microtouch ['192341 NEW'] xorg-x11-drv-mutouch ['192342 NEW'] xorg-x11-drv-nv ['192343 NEW'] xorg-x11-drv-palmax ['192346 NEW'] xorg-x11-drv-penmount ['192344 NEW'] xorg-x11-drv-s3 ['192347 NEW'] xorg-x11-drv-s3virge ['192348 NEW'] xorg-x11-drv-savage ['192349 NEW'] xorg-x11-drv-siliconmotion ['192350 NEW'] xorg-x11-drv-sis ['192351 NEW'] xorg-x11-drv-sisusb ['192352 NEW'] xorg-x11-drv-spaceorb ['192353 NEW'] xorg-x11-drv-summa ['192354 NEW'] xorg-x11-drv-tdfx ['192358 NEW'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 NEW'] xorg-x11-drv-ur98 ['192360 NEW'] xorg-x11-drv-vesa ['192359 NEW'] xorg-x11-drv-vga ['192168 NEW'] xorg-x11-drv-via ['192167 NEW'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 NEW'] xorg-x11-drv-void ['192045 NEW'] xorg-x11-drv-voodoo ['192042 NEW'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 NEW'] xorg-x11-server ['192021 NEW'] xorg-x11-server-utils ['191987 NEW'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Rawhide-in-Mock Build Results for i386 Architecture Tue May 23 10:57:25 CDT 2006 Number failed to build: 192 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 181 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 23 ---------------------------------- SDL dhcpv6 eclipse-bugzilla eclipse-cdt eclipse-changelog eclipse-pydev emacs evolution evolution-sharp firefox gnu-efi gpart libpfm ltrace magma-plugins openoffice.org perl pfmon rgmanager rhpl rpm sg3_utils tog-pegasus With bugs filed: 157 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] control-center ['192233 NEW'] crash ['191719 CLOSED'] device-mapper-multipath ['192242 ASSIGNED'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] eclipse ['192563 NEW'] epiphany ['191665 NEW'] evolution-connector ['192251 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gmime ['192116 CLOSED'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 NEW'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] hal-cups-utils ['192507 NEW'] initscripts ['192509 CLOSED'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdebindings ['192520 CLOSED'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnotify ['191731 NEW'] libselinux ['192562 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEW'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 NEW'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-glint ['192365 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-tseng ['192385 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server ['192021 CLOSED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ From jspaleta at gmail.com Tue May 23 16:08:50 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 May 2006 12:08:50 -0400 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <20060523171005.289e4be0@python2> References: <20060523110001.6a62775e@python2> <35308.207.35.222.39.1148393865.squirrel@lattica.com> <20060523171005.289e4be0@python2> Message-ID: <604aa7910605230908n39c14578u3ece467e46217bfa@mail.gmail.com> On 5/23/06, Matthias Saou > Yup. It's not as user friendly as if the same login screen could be > used by multiple users, then have some kind of "switch login to other > active session" in some menu, but it wasn't that hard to teach my > girlfriend to switch between Alt+Ctrl+F7 and Alt+Ctrl+F8 to find her > desktop. fast user switching is actually available in gnome 2.14 via gdm-flexiserver and is exposable in the screensaver and as a menu entry via a compile time options. The menu entry and the screensaver support are delibrately turned off in Fedora exactly because all the peices to make dealing with device permission policy are not there yet (ie PolicyKit). Skim http://www.gnome.org/start/2.14/notes/en/rnusers.html -jef"gdmflexiserver -n is my favorite command ever"spaleta From jamatos at fc.up.pt Tue May 23 16:22:46 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Tue, 23 May 2006 17:22:46 +0100 Subject: Back to 6 month schedule? In-Reply-To: <1148400149.2297.2.camel@localhost.localdomain> References: <20060523105441.GA5224@neu.nirvana> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> Message-ID: <200605231722.46695.jamatos@fc.up.pt> On Tuesday 23 May 2006 17:02, Thorsten Leemhuis wrote: > Then make it four weeks after Gnome. Or Two. Or Six -- I don't care. But > I really would like a long-term plan where I know: okay, FC10 will be > out in the beginning on October 2008. I intend to reply before that if Fedora adopted such release schedule I would be even more happier to be a kde user. ;-) Not only that but it makes us dependent on an external entity. What if gnome developer decide (rightly IMO) that they need more time to release 3.0, do we change the schedule then? Should we re-sync after? That is crazy. :-) > CU > thl -- Jos? Ab?lio From jspaleta at gmail.com Tue May 23 15:59:49 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 May 2006 11:59:49 -0400 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <20060523171242.440c385b@python2> References: <20060523110001.6a62775e@python2> <604aa7910605230804s1cfbf164x7454cd6fc10a0767@mail.gmail.com> <20060523171242.440c385b@python2> Message-ID: <604aa7910605230859tf088ef1p7d4710b86b537c33@mail.gmail.com> On 5/23/06, Matthias Saou > Got any more information about this? Seems like the bit I'm missing > alright. I believe its a topic of discussion in HAL's upstream development list. Or cruise davidz's blog entries about the bright shiny future of tomorrow where glossy desktop UI is exposed for managing per-user/system-default policy via the PolicyKit. > > Still this doesn't really address the issue of now having to edit > console.perms, udev rules and this hal/dbus stuff in order to set > device permissions to be correct in all possible cases. No.. there is no 'good' solution 'now'. I think what you are missing on your fc5 setup is edits to the hal policy. If you want non-default mounting options for devices that have mountpoints dynamically created at mount time by hal, you'll have to dig down into the xml spagetti that is hal policy. edit the udev rules for the default permissions block devices when the devices are noticed by udev edit the pam.console rules to shortcircuit the console user switching magic. edit fstab and create mountpoints for 'static' mounts that you need to write by hand edit the hal policy to deal with permissions associated with 'dynamically' created mount points in /media/. Remember the mountpoints for hal controlled storage devices are now created at mount time in FC5 not at device insertion time, and no more fstab entries for those devices all the mount options are encoded as hal policy. ... profit -jef From david at lovesunix.net Tue May 23 16:53:03 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 23 May 2006 18:53:03 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148403183.29013.19.camel@localhost.localdomain> tir, 23 05 2006 kl. 11:13 -0400, skrev Jesse Keating: > On Tue, 2006-05-23 at 13:24 +0200, Thorsten Leemhuis wrote: > > E.g. always > > release one week after each Gnome-Release > > This is extremely distasteful from a rel-eng and QA perspective. We > have to have our bits done about a week before we can release to the > world, so you're asking us to take what Gnome Upstream releases and in > the same day add them to the distro, spin a release, and send it out to > the world. That has 'eat my babies' written all over it. Case in point > FC5 release. We had to scramble to get the latest gnome released > packages in, and many of them did not go in just because 'too many > changes to be comfortable with this'. Ideally we'd be reaching test2 > right around the time Gnome makes their release. That lines up with a > feature freeze and gets those fresh bits out into the hands of the > testers to give us a list of stuff to fix for Test3 and the resulting > release. Aren't you disregarding the fact that GNOME also has a release cycle that enforces a strict bugfix only period, meaning the risk we face having shipped every test release in Development of the famous baby eating syndrome is incredibly low. But it would still be nice to have plenty of time between the GNOME and FC releases - It would give us the option to ship the follow up GNOME 2.x.1/2 release which is normally better translated and has more bugs fixed. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From cjb at mrao.cam.ac.uk Tue May 23 17:15:31 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Tue, 23 May 2006 13:15:31 -0400 Subject: Back to 6 month schedule? References: <20060523105441.GA5224@neu.nirvana> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> <200605231722.46695.jamatos@fc.up.pt> Message-ID: <87wtcc8xxo.fsf@mrao.cam.ac.uk> >> On Tue, 23 May 2006 17:22:46, Jose' Matos said: > Not only that but it makes us dependent on an external > entity. What if gnome developer decide (rightly IMO) that they need > more time to release 3.0, do we change the schedule then? > Should we re-sync after? > That is crazy. :-) I'm not pushing for either schedule, but some points (mostly from FUDCon) on why using a six-month schedule is not "crazy", and in fact seems to be becoming de facto: * GNOME does it, as mentioned. * Xorg does it. * OpenOffice does it. * GCC is on a yearly cycle, so we'd pick up a new release roughly every second time. * The farther our releases are out of sync with these, the more work we have to do. * The lesson learnt from FC5 was that it hurts more than it helps us to have more than six months for a release. As for getting GNOME packages the day before a release, no-one's proposing that. GNOME 2.16's scheduled for release on September 6th, our current schedule is to release on September 20th. Moreover, GNOME's feature freezes line up with ours; it's not like there'll be dramatically new code appearing while we're getting ready to push, just fixes to the packages we'll have already been testing in Rawhide for months. I think GNOME has a well-deserved reputation for not screwing up freezes and release dates. Ubuntu also uses six month GNOME-tied releases (though their last one overran, so they'll make Edgy tighter to catch back up). - Chris. -- Chris Ball From skvidal at linux.duke.edu Tue May 23 17:23:32 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 23 May 2006 13:23:32 -0400 Subject: Back to 6 month schedule? In-Reply-To: <87wtcc8xxo.fsf@mrao.cam.ac.uk> References: <20060523105441.GA5224@neu.nirvana> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> <200605231722.46695.jamatos@fc.up.pt> <87wtcc8xxo.fsf@mrao.cam.ac.uk> Message-ID: <1148405012.6325.21.camel@cutter> On Tue, 2006-05-23 at 13:15 -0400, Chris Ball wrote: > >> On Tue, 23 May 2006 17:22:46, Jose' Matos said: > I'm not pushing for either schedule, but some points (mostly from > FUDCon) on why using a six-month schedule is not "crazy", and in > fact seems to be becoming de facto: > > * GNOME does it, as mentioned. > * Xorg does it. > * OpenOffice does it. > * GCC is on a yearly cycle, so we'd pick up a new release roughly > every second time. > * The farther our releases are out of sync with these, the more > work we have to do. > * The lesson learnt from FC5 was that it hurts more than it > helps us to have more than six months for a release. the lesson learnt only by those people INSIDE red hat. it was not a universally acknowledged lesson - it just made life difficult for folks inside the fenceline. I'll live with a 6 month schedule but let's not revise history overly-much, okay? -sv From jkeating at redhat.com Tue May 23 17:24:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 13:24:03 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148403183.29013.19.camel@localhost.localdomain> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148403183.29013.19.camel@localhost.localdomain> Message-ID: <1148405043.10695.9.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 18:53 +0200, David Nielsen wrote: > Aren't you disregarding the fact that GNOME also has a release cycle > that enforces a strict bugfix only period, meaning the risk we face > having shipped every test release in Development of the famous baby > eating syndrome is incredibly low. But not low enough. There are parts of the gnome release that seem to not follow this. Large changes in the last tarball including FEATURE changes hit us with this last gnome release. Remember things that didn't make the release and were held out for later test updates. Even still it was a hellish couple of days for our gnome folks to chew through the 'minimal' changes. I was not comfortable at ALL with this process. > But it would still be nice to have plenty of time between the GNOME and > FC releases - It would give us the option to ship the follow up GNOME > 2.x.1/2 release which is normally better translated and has more bugs > fixed. So we move the problem from N to N+1 ? (; -- 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 Tue May 23 17:25:01 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 13:25:01 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148400149.2297.2.camel@localhost.localdomain> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> Message-ID: <1148405101.10695.11.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 18:02 +0200, Thorsten Leemhuis wrote: > > Then make it four weeks after Gnome. Or Two. Or Six -- I don't care. But > I really would like a long-term plan where I know: okay, FC10 will be > out in the beginning on October 2008. We are not an Enterprise distribution, we need flexibility to do the things we need to do to better the distribution. Some changes take longer to implement than others. Being tied down to a strict 3 year plan (or longer) does not fit well with what we need. -- 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 Tue May 23 17:28:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 13:28:51 -0400 Subject: Back to 6 month schedule? In-Reply-To: <87wtcc8xxo.fsf@mrao.cam.ac.uk> References: <20060523105441.GA5224@neu.nirvana> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> <200605231722.46695.jamatos@fc.up.pt> <87wtcc8xxo.fsf@mrao.cam.ac.uk> Message-ID: <1148405331.10695.15.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 13:15 -0400, Chris Ball wrote: > As for getting GNOME packages the day before a release, no-one's > proposing that. GNOME 2.16's scheduled for release on September 6th, > our current schedule is to release on September 20th. Moreover, > GNOME's feature freezes line up with ours; it's not like there'll be > dramatically new code appearing while we're getting ready to push, > just fixes to the packages we'll have already been testing in Rawhide > for months. I think GNOME has a well-deserved reputation for not > screwing up freezes and release dates. Our final devel freeze is the 12th. Our Feature freeze is July 5th. The last gnome release DID FEATURE CHANGES in the final tarballs. This hurts. -- 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 galibert at pobox.com Tue May 23 17:35:04 2006 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 23 May 2006 19:35:04 +0200 Subject: question about creation of updated DVD iso In-Reply-To: <1148399249.392.7.camel@orodruin.boston.redhat.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <20060523144217.GB45392@dspnet.fr.eu.org> <1148399249.392.7.camel@orodruin.boston.redhat.com> Message-ID: <20060523173504.GA72558@dspnet.fr.eu.org> On Tue, May 23, 2006 at 11:47:28AM -0400, Jeremy Katz wrote: > On Tue, 2006-05-23 at 16:42 +0200, Olivier Galibert wrote: > > - initrd: The contents of the initrd (gzip -dc initrd.img | cpio -id --no-absolute-filenames) > [snip] > > Also you need gen_initramfs_list.sh and gen_init_cpio from the linux > > kernel sources somewhere (in the script they're in ../..). > > Ermm, you do realize that there's a script in anaconda > (scripts/upd-kernel) that will take a new kernel and explode everything > that needs to go into the initrd? No, I didn't. It would have been nice to have it installed with anaconda, that would have given me a chance to find it. OG. From david at lovesunix.net Tue May 23 17:35:23 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 23 May 2006 19:35:23 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148405043.10695.9.camel@dhcp83-49.boston.redhat.com> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148403183.29013.19.camel@localhost.localdomain> <1148405043.10695.9.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148405723.29013.25.camel@localhost.localdomain> tir, 23 05 2006 kl. 13:24 -0400, skrev Jesse Keating: > So we move the problem from N to N+1 ? (; I'm probably not the right person to speak about release stability, I run Development as my desktop and have done so since basically FC1. I guess that means my eating habits include cuddly innocent babies. Pass the salt please. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jkeating at j2solutions.net Tue May 23 17:39:34 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 23 May 2006 13:39:34 -0400 Subject: question about creation of updated DVD iso In-Reply-To: <20060523173504.GA72558@dspnet.fr.eu.org> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <20060523144217.GB45392@dspnet.fr.eu.org> <1148399249.392.7.camel@orodruin.boston.redhat.com> <20060523173504.GA72558@dspnet.fr.eu.org> Message-ID: <1148405974.10695.16.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 19:35 +0200, Olivier Galibert wrote: > No, I didn't. It would have been nice to have it installed with > anaconda, that would have given me a chance to find it. anaconda-runtime -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Lam at Lam.pl Tue May 23 17:41:29 2006 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 23 May 2006 19:41:29 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148403183.29013.19.camel@localhost.localdomain> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148403183.29013.19.camel@localhost.localdomain> Message-ID: <1148406089.2738.15.camel@pensja.lam.pl> Dnia 23-05-2006, wto o godzinie 18:53 +0200, David Nielsen napisa?(a): > But it would still be nice to have plenty of time between the GNOME and > FC releases - It would give us the option to ship the follow up GNOME > 2.x.1/2 release which is normally better translated and has more bugs > fixed. If not us, who's going to report bugs back to them, then? After FC5 release I saw _only_ FC5 users posting on GNOME's bugzilla about bugs I've seen. In less than a month we got many updates, one of them incorporated a patch made by myself on my fresh FC5. I'm not an every day Fedora or GNOME developer, but the open-source model worked this time. Who knows, maybe the 2.14.1 release would have the bug still there without FC5 being so bleeding-edge? If you're so scared of testing the x.y.0 releases, just wait a month from next Fedora Core release for the updates to appear, then use it happily :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From katzj at redhat.com Tue May 23 17:41:40 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 23 May 2006 13:41:40 -0400 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523161003.GA18290@lists.us.dell.com> References: <20060523161003.GA18290@lists.us.dell.com> Message-ID: <1148406101.392.13.camel@orodruin.boston.redhat.com> On Tue, 2006-05-23 at 11:10 -0500, Matt Domsch wrote: > Great progress! I'm now building i386 as well as x86_64. > Can someone with the right powers kill off the old copies of emacs and > rgmanager SRPMS in rawhide? SRPMs are kept for all binary RPMs -- this probably means that there are older versions of emacs/rgmanager for _an_ arch because of an ExcludeArch somewhere. Jeremy From jkeating at redhat.com Tue May 23 17:49:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 13:49:12 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148406089.2738.15.camel@pensja.lam.pl> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148403183.29013.19.camel@localhost.localdomain> <1148406089.2738.15.camel@pensja.lam.pl> Message-ID: <1148406552.10695.18.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 19:41 +0200, Leszek Matok wrote: > If not us, who's going to report bugs back to them, then? After FC5 > release I saw _only_ FC5 users posting on GNOME's bugzilla about bugs > I've seen. In less than a month we got many updates, one of them > incorporated a patch made by myself on my fresh FC5. I'm not an every > day Fedora or GNOME developer, but the open-source model worked this > time. Who knows, maybe the 2.14.1 release would have the bug still there > without FC5 being so bleeding-edge? If you're so scared of testing the > x.y.0 releases, just wait a month from next Fedora Core release for the > updates to appear, then use it happily :) Or adjust the schedule so that this type of pain can happen in the Test releases so that we don't inflict broken packages on unsuspecting users. I really don't like the idea of 'Oh, that's final release, don't use it for another couple of weeks...' -- 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 paul at city-fan.org Tue May 23 17:52:22 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 23 May 2006 18:52:22 +0100 Subject: question about creation of updated DVD iso In-Reply-To: <1148405974.10695.16.camel@dhcp83-49.boston.redhat.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <20060523144217.GB45392@dspnet.fr.eu.org> <1148399249.392.7.camel@orodruin.boston.redhat.com> <20060523173504.GA72558@dspnet.fr.eu.org> <1148405974.10695.16.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148406743.5228.82.camel@laurel.intra.city-fan.org> On Tue, 2006-05-23 at 13:39 -0400, Jesse Keating wrote: > On Tue, 2006-05-23 at 19:35 +0200, Olivier Galibert wrote: > > No, I didn't. It would have been nice to have it installed with > > anaconda, that would have given me a chance to find it. > > anaconda-runtime Doesn't seem to be there either: $ rpm -ql anaconda-runtime | grep upd /usr/lib/anaconda-runtime/upd-instroot No upd-kernel script present. Is there a HOWTO for this somewhere? People wanting to try the installer with an updated kernel come by fedora-list every now and again. Paul. From fedora at leemhuis.info Tue May 23 17:53:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 May 2006 19:53:03 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148405101.10695.11.camel@dhcp83-49.boston.redhat.com> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> <1148405101.10695.11.camel@dhcp83-49.boston.redhat.com> Message-ID: <1148406783.2317.35.camel@localhost.localdomain> Am Dienstag, den 23.05.2006, 13:25 -0400 schrieb Jesse Keating: > On Tue, 2006-05-23 at 18:02 +0200, Thorsten Leemhuis wrote: > > Then make it four weeks after Gnome. Or Two. Or Six -- I don't care. But > > I really would like a long-term plan where I know: okay, FC10 will be > > out in the beginning on October 2008. > We are not an Enterprise distribution, we need flexibility to do the > things we need to do to better the distribution. But we are working on a distribution that is the base for an Enterprise distribution that ships every 18 month afaik. So a strict six months release schedule also a benefit for Red Hat afaics. > Some changes take > longer to implement than others. Being tied down to a strict 3 year > plan (or longer) does not fit well with what we need. Things can be changed if necessary. CU thl -- Thorsten Leemhuis From gianluca.cecchi at gmail.com Tue May 23 17:53:06 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 23 May 2006 19:53:06 +0200 Subject: question about creation of updated DVD iso In-Reply-To: <20060523144217.GB45392@dspnet.fr.eu.org> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <20060523144217.GB45392@dspnet.fr.eu.org> Message-ID: <561c252c0605231053j37371cdbq9d61ad18d98aae7@mail.gmail.com> Actually, using http://fedoranews.org/contributors/gene_czarcinski/update_distro/ hints, integrated with Remi Collet answer on this thread (update of vmlinuz/initrd install files: It's the "buildinstall" job) and taking things at http://www.users.on.net/~rgarth/weblog/fedora/patch_cd.autumn (Simone Caronni comments in particular for pkgorder and buildinstall options) allowed me to create an updated DVD iso (up to 16/5 + unofficial 2118 kernels) in a very simple way. I was able to install without any problem (x86 arch): only a pair of dependency problems in install.log about pilot-link and another package, probably related to mirror not completely updated when I downloaded rpm updates to master the iso... The choice and filter inside the RPMS dir was made manually ;-( I didn't have time to check the scripts referred in the latest link and other sources. I'm going to repeat with the offical 2122 kernel and see. One probably important thing is that the whole process of creating the updated iso was done on an FC5 system, updated at the same level the future iso would have been. Or at least with latest packages for programs used: anaconda anaconda-runtime busybox-anaconda The main need for an updated kernel in DVD iso is in the case you have an hw component not or not well supported in 2054/original kernel (my case problem with sata drivers) and instead supported in an updated version. And also for consistency and coherency of the bundle itself. Thanks to all for the moment. Gianluca From david at lovesunix.net Tue May 23 17:53:06 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 23 May 2006 19:53:06 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148406089.2738.15.camel@pensja.lam.pl> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148403183.29013.19.camel@localhost.localdomain> <1148406089.2738.15.camel@pensja.lam.pl> Message-ID: <1148406786.29013.30.camel@localhost.localdomain> tir, 23 05 2006 kl. 19:41 +0200, skrev Leszek Matok: > If not us, who's going to report bugs back to them, then? After FC5 > release I saw _only_ FC5 users posting on GNOME's bugzilla about bugs > I've seen. In less than a month we got many updates, one of them > incorporated a patch made by myself on my fresh FC5. I'm not an every > day Fedora or GNOME developer, but the open-source model worked this > time. Who knows, maybe the 2.14.1 release would have the bug still there > without FC5 being so bleeding-edge? If you're so scared of testing the > x.y.0 releases, just wait a month from next Fedora Core release for the > updates to appear, then use it happily :) I haven't run a stable release of any OS in years, I like bugreporting - everyone needs a hobby right? My main reason for pushing for going with a follow up release of GNOME is that I'm a translator and I've seen serious time issues on the team I'm on to catch up with all the work for the point zero release - however for the follow up releases nearly all active teams reach a level we could call supported (+90% translated and reviewed). Speaking of which, it would be really nice if the Fedora translations where exposed in a similar low entry level fasion as is done on l10n-status.gnome.org. - David *babies hate me* Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jkeating at redhat.com Tue May 23 17:59:20 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 May 2006 13:59:20 -0400 Subject: Back to 6 month schedule? In-Reply-To: <1148406783.2317.35.camel@localhost.localdomain> References: <20060523105441.GA5224@neu.nirvana> <4472EC02.5000706@city-fan.org> <1148383459.20933.82.camel@thl.ct.heise.de> <1148397228.10695.5.camel@dhcp83-49.boston.redhat.com> <1148400149.2297.2.camel@localhost.localdomain> <1148405101.10695.11.camel@dhcp83-49.boston.redhat.com> <1148406783.2317.35.camel@localhost.localdomain> Message-ID: <1148407160.10695.20.camel@dhcp83-49.boston.redhat.com> On Tue, 2006-05-23 at 19:53 +0200, Thorsten Leemhuis wrote: > But we are working on a distribution that is the base for an Enterprise > distribution that ships every 18 month afaik. So a strict six months > release schedule also a benefit for Red Hat afaics. > > > Some changes take > > longer to implement than others. Being tied down to a strict 3 year > > plan (or longer) does not fit well with what we need. > > Things can be changed if necessary. > So uh, which do you want? A strict inflexible schedule, or a flexible schedule where things can be changed if necessary? -- 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 overholt at redhat.com Tue May 23 18:27:21 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 23 May 2006 14:27:21 -0400 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523161003.GA18290@lists.us.dell.com> References: <20060523161003.GA18290@lists.us.dell.com> Message-ID: <20060523182721.GA32643@redhat.com> Hi, * Matt Domsch [2006-05-23 12:10]: > eclipse ['192563 NEW'] I fixed this in CVS when you posted your initial findings. Can you try again when you get a chance? Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Tue May 23 18:34:31 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 May 2006 13:34:31 -0500 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523182721.GA32643@redhat.com> References: <20060523161003.GA18290@lists.us.dell.com> <20060523182721.GA32643@redhat.com> Message-ID: <20060523183430.GA23524@lists.us.dell.com> On Tue, May 23, 2006 at 02:27:21PM -0400, Andrew Overholt wrote: > Hi, > > * Matt Domsch [2006-05-23 12:10]: > > eclipse ['192563 NEW'] > > I fixed this in CVS when you posted your initial findings. Can you try > again when you get a chance? It hasn't made it into rawhide yet I think. -rw-r--r-- 3 rhmirror rhmirror 61462552 Mar 7 21:08 eclipse-3.1.2-1jpp_13fc.src.rpm http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/eclipse-3.1.2-1jpp_13fc.src.rpm/result/root.log build on 19 May still reports: No Package Found for mozilla-devel = 37:1.7.12 No Package Found for mozilla = 37:1.7.12 When it gets pushed into rawhide, yes, it'll get rebuilt. :-) Thanks, Matt -- 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 overholt at redhat.com Tue May 23 18:38:17 2006 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 23 May 2006 14:38:17 -0400 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523183430.GA23524@lists.us.dell.com> References: <20060523161003.GA18290@lists.us.dell.com> <20060523182721.GA32643@redhat.com> <20060523183430.GA23524@lists.us.dell.com> Message-ID: <20060523183817.GB32643@redhat.com> * Matt Domsch [2006-05-23 14:34]: > On Tue, May 23, 2006 at 02:27:21PM -0400, Andrew Overholt wrote: > > Hi, > > > > * Matt Domsch [2006-05-23 12:10]: > > > eclipse ['192563 NEW'] > > > > I fixed this in CVS when you posted your initial findings. Can you try > > again when you get a chance? > > It hasn't made it into rawhide yet I think. I didn't know it had to be re-built into rawhide for it to take hold. Sorry, I should have realized you were re-building the SRPMs and not from CVS :) I'll get a build pushed soon. Thanks, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Tue May 23 18:51:30 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 May 2006 13:51:30 -0500 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523183817.GB32643@redhat.com> References: <20060523161003.GA18290@lists.us.dell.com> <20060523182721.GA32643@redhat.com> <20060523183430.GA23524@lists.us.dell.com> <20060523183817.GB32643@redhat.com> Message-ID: <20060523185130.GB23524@lists.us.dell.com> On Tue, May 23, 2006 at 02:38:17PM -0400, Andrew Overholt wrote: > * Matt Domsch [2006-05-23 14:34]: > > On Tue, May 23, 2006 at 02:27:21PM -0400, Andrew Overholt wrote: > > > Hi, > > > > > > * Matt Domsch [2006-05-23 12:10]: > > > > eclipse ['192563 NEW'] > > > > > > I fixed this in CVS when you posted your initial findings. Can you try > > > again when you get a chance? > > > > It hasn't made it into rawhide yet I think. > > I didn't know it had to be re-built into rawhide for it to take hold. > Sorry, I should have realized you were re-building the SRPMs and not from > CVS :) I'll get a build pushed soon. no problem, that's probably true of most of these that are marked CLOSED but are still broken for me (i386 list here): beagle ['191664 CLOSED'] crash ['191719 CLOSED'] gmime ['192116 CLOSED'] gnucash ['192008 CLOSED'] initscripts ['192509 CLOSED'] kdebindings ['192520 CLOSED'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] planner ['191808 CLOSED'] psmisc ['191901 CLOSED'] rhythmbox ['191760 CLOSED'] squashfs-tools ['191880 CLOSED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-server ['192021 CLOSED'] Core Maintainers: after committing fixes for the BuildRequires blocker bugs, please make sure it gets built and pushed to rawhide. I'm not building from Red Hat's internal (or external) CVS. Thanks, Matt -- 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 michael at knox.net.nz Tue May 23 19:42:16 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Wed, 24 May 2006 07:42:16 +1200 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523185130.GB23524@lists.us.dell.com> References: <20060523161003.GA18290@lists.us.dell.com> <20060523182721.GA32643@redhat.com> <20060523183430.GA23524@lists.us.dell.com> <20060523183817.GB32643@redhat.com> <20060523185130.GB23524@lists.us.dell.com> Message-ID: <44736598.3070305@knox.net.nz> Matt Domsch wrote: > On Tue, May 23, 2006 at 02:38:17PM -0400, Andrew Overholt wrote: > >>* Matt Domsch [2006-05-23 14:34]: >> >>>On Tue, May 23, 2006 at 02:27:21PM -0400, Andrew Overholt wrote: >>> >>>>Hi, >>>> >>>>* Matt Domsch [2006-05-23 12:10]: >>>> >>>>>eclipse ['192563 NEW'] >>>> >>>>I fixed this in CVS when you posted your initial findings. Can you try >>>>again when you get a chance? >>> >>>It hasn't made it into rawhide yet I think. >> >>I didn't know it had to be re-built into rawhide for it to take hold. >>Sorry, I should have realized you were re-building the SRPMs and not from >>CVS :) I'll get a build pushed soon. > > > no problem, that's probably true of most of these that are marked > CLOSED but are still broken for me (i386 list here): > > beagle ['191664 CLOSED'] > crash ['191719 CLOSED'] > gmime ['192116 CLOSED'] > gnucash ['192008 CLOSED'] > initscripts ['192509 CLOSED'] > kdebindings ['192520 CLOSED'] > kdegames ['192521 CLOSED'] > kdelibs ['192522 CLOSED'] > kdemultimedia ['192523 CLOSED'] > kdenetwork ['192525 CLOSED'] > kdepim ['192526 CLOSED'] > kdesdk ['192527 CLOSED'] > kdevelop ['192529 CLOSED'] > planner ['191808 CLOSED'] > psmisc ['191901 CLOSED'] > rhythmbox ['191760 CLOSED'] > squashfs-tools ['191880 CLOSED'] > xorg-x11-drv-vmmouse ['192047 CLOSED'] > xorg-x11-server ['192021 CLOSED'] > > Core Maintainers: after committing fixes for the BuildRequires blocker > bugs, please make sure it gets built and pushed to rawhide. I'm not > building from Red Hat's internal (or external) CVS. +1 I am happy to be a "gopher" and run around and follow things up, so just ask for it to be checked in the next rawhide push and it shal be done :) Michael From mike at miketc.com Tue May 23 19:46:27 2006 From: mike at miketc.com (Mike Chambers) Date: Tue, 23 May 2006 14:46:27 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44721137.2010806@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> Message-ID: <1148413587.15801.4.camel@scrappy.miketc.com> On Mon, 2006-05-22 at 15:29 -0400, Mike A. Harris wrote: > - Run ntsysv (or equivalent) and disable the xfs service from > starting at boot time. > > - Run "service xfs stop" to shut down xfs > > - Edit xorg.conf and comment out the unix:/7100 font path. > Add a FontPath that points to the "misc" font directory. > > - Start the X server. It should start correctly as long as you > have properly configured the misc font path, as it will then > still be able to find "fixed" and "cursor". So far so good for the test run. Disabled xfs from starting, and changed unix/:7100 (err, commented it out) and added /usr/share/fonts/misc as the FontPatch in xorg.conf. Rebooted and all is well so far. > You may or may not have errors or application failures during > your desktop's startup, depending on wether you're using GNOME, > KDE, or some other setup. If your setup uses apps that use > core fonts, they may or may not start depending on how picky > they are about finding specific fonts. gdm started up OK (thought it might hicup like it has been doing this last week or so). Gnome also started up OK, and no errors as of yet. Evolution and Firefox both seem to run just fine up to this point. And so far all the programs that are set to run on login (like weather, network-status, sound, clock, gaim). Anyway, basic gnome desktop and startup programs seem be working just fine. > Once your desktop is started, open a terminal and run various > non-GNOME, non-GTK2, non-KDE, non-Qt applications. For example, > run Xt, Xaw, Motif, and other such apps, and see if they work > properly, or if they fail miserably. If any apps fail and > report an error about a missing font or other font related > problem, make note of it. Not sure what runs on the systems above, so might need to give a few hints on what to test. Mplayer does seem to work if that is one of them. As does K3b. More to come later as I can test more. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you're not getting any!" From mpeters at mac.com Tue May 23 19:59:48 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 23 May 2006 12:59:48 -0700 Subject: rawhide rebuild in mock status 2006-05-23 In-Reply-To: <20060523161003.GA18290@lists.us.dell.com> References: <20060523161003.GA18290@lists.us.dell.com> Message-ID: <1148414388.16995.15.camel@atlantis.mpeters.local> On Tue, 2006-05-23 at 11:10 -0500, Matt Domsch wrote: > tetex ['191874 NEW'] I don't know if the tetex maintainer wants to do anything about this for FC6 or not, but upstream tetex just announced that tetex is dead, no new versions will be birthed. So it looks like maybe efforts should be put into packaging texlive rather than fixing tetex for mock. Just my opinion. From mike at miketc.com Tue May 23 22:12:05 2006 From: mike at miketc.com (Mike Chambers) Date: Tue, 23 May 2006 17:12:05 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44721137.2010806@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> Message-ID: <1148422325.15474.6.camel@scrappy.miketc.com> On Mon, 2006-05-22 at 15:29 -0400, Mike A. Harris wrote: > Once your desktop is started, open a terminal and run various > non-GNOME, non-GTK2, non-KDE, non-Qt applications. For example, > run Xt, Xaw, Motif, and other such apps, and see if they work > properly, or if they fail miserably. If any apps fail and > report an error about a missing font or other font related > problem, make note of it. nedit works fine but has this below when started... [mike at scrappy ~]$ nedit xorg.conf nedit: the current locale is utf8 (en_US.UTF-8) nedit: changed locale to non-utf8 (en_US) Cannot convert string "-*-helvetica-medium-r-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct Cannot convert string "-*-helvetica-bold-r-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct Cannot convert string "-*-helvetica-medium-o-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct Cannot convert string "-*-courier-medium-r-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct Cannot convert string "-*-courier-bold-r-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct Cannot convert string "-*-courier-medium-o-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct And emacs does NOT work. The menu is readable and the icon shapes are fine, but the wording is just boxes. Also the letters in the files themselves when trying to edit with emacs is just boxes. [mike at scrappy ~]$ emacs Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct Warning: Cannot convert string "-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1" to type FontStruct Evolution, firefox, epiphany, xchat, gnome-terminal all seem to work, as well as most of the other gnome/desktop apps in a general workstation install. Will have to see about testing some more. If anyone has some major apps that are of general use they want me to try with this setup, let me know and will give it a whirl. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless you're not getting any!" From nicolas.mailhot at laposte.net Tue May 23 22:15:44 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 24 May 2006 00:15:44 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44731AAC.3030909@redhat.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> Message-ID: <1148422547.25336.13.camel@rousalka.dyndns.org> Le mardi 23 mai 2006 ? 10:22 -0400, Adam Jackson a ?crit : > I'm of the opinion that leaving xfs enabled isn't really a big deal Unfortunately, as every single FCxT1 release shows, leaving xfs enabled means various users will have their X server fail mysteriously because of problems locating "fixed". Notwithstanding the fact that they probably do not have a single main app needing "fixed" anymore. Core font system is not "just working" and "low impact". Every once in a while it manages to remind everyone it's still lurking under the X server. As long as the current system is unchanged it will stay one of the X server main points of failure. +1 to reduce its perimeter in FC to something minimalistic, lightweight and robust. Even if it means reducing its functionnalities to the bare minimum required by the spec. Let the apps which didn't bother with fontconfig migration bear the weight of core font management, if they really want to keep it alive forever. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From david at fubar.dk Tue May 23 22:46:35 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 23 May 2006 18:46:35 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <446FF7AB.30301@mharris.ca> References: <446FF7AB.30301@mharris.ca> Message-ID: <1148424395.4474.3.camel@daxter.boston.redhat.com> On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: > In particular, xfs and core fonts does not fit well into the > One Laptop Per Child (OLPC) effort, or other Fedora derived > embedded distributions. In these embedded systems, or > reduced computing environments if you will, every megabyte > of disk space and memory counts. Shedding megs of stuff out > of the default OS installation is sure to reduce both the > memory footprint and disk footprint of the OS installation, > which is a net gain for these systems, and also for a lot > of the userbase out there that do not use any applications > which rely on core fonts. Just to be perfectly clear: All we are asking right now from OLPC is to cut a few Requires here and there such that our RPM transaction (that include xorg-x11-server-Xorg) doesn't pull in xorg-x11-xfs. This will not break new installs nor upgrades of Fedora - for new installs, just make sure that the comps.xml files include xorg-x11-xfs in addition to xorg-x11-server-Xorg. I second that it would be nice to get rid of xfs entirely but we're not really asking that much right now. David From pemboa at gmail.com Wed May 24 00:27:56 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 23 May 2006 19:27:56 -0500 Subject: Slightly-OT: How are the Google SOC reviews going? Message-ID: <16de708d0605231727n1be7712fh7ebab09738223f91@mail.gmail.com> To the mentors, I have applied to the Fedora Project, and my application has been in the ranking stage with otherwise no observable changes, save for a timestamp update. Is there anything I can possible do to catalyse the process? Please advise. Arthur Pemberton -- To be updated... From cjb at mrao.cam.ac.uk Wed May 24 00:38:21 2006 From: cjb at mrao.cam.ac.uk (Chris Ball) Date: Tue, 23 May 2006 20:38:21 -0400 Subject: Slightly-OT: How are the Google SOC reviews going? References: <16de708d0605231727n1be7712fh7ebab09738223f91@mail.gmail.com> Message-ID: <87odxo8dfm.fsf@mrao.cam.ac.uk> >> On Tue, 23 May 2006, Arthur Pemberton said: > To the mentors, I have applied to the Fedora Project, and my > application has been in the ranking stage with otherwise no > observable changes, save for a timestamp update. The accepted proposals have been given to Google, who expected to announce them today but it might actually be tomorrow 'cause they have to contact everyone who had a proposal accepted by more than one organisation and find out which they want to work for, and then contact the organisation that wasn't chosen and confirm which project they want to use as a replacement. So, expect to see the final list of accepted proposals on Google's site in the next day. - Chris, who's a GNOME SoC admin but not a Fedora one, but presumes everything he just said is still applicable. -- Chris Ball From pmatilai at laiskiainen.org Wed May 24 07:13:14 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 24 May 2006 00:13:14 -0700 (PDT) Subject: Back to 6 month schedule? In-Reply-To: <1148385443.3819.16.camel@ender> References: <20060523105441.GA5224@neu.nirvana> <1148384870.3819.11.camel@ender> <1148385299.5212.3.camel@cutter> <1148385443.3819.16.camel@ender> Message-ID: On Tue, 23 May 2006, Jesse Keating wrote: > On Tue, 2006-05-23 at 07:54 -0400, seth vidal wrote: >> >> Not all of us involved. >> >> I quite liked the 9 month schedule. > > > Open mouth, insert foot. I didn't mean to say all involved, that was > supposed to be 'most' or even 'some'. > > In reality, it did NOT turn into 6 months of changes and 3 months of > fixes, it turned into 8~9 months of changes and a couple hectic weeks of > trying to fix crap. Hence the slips and the delays and whatnot. > > Maybe if we had been more draconic about development freezes and freezes > in general it would have ended up different. But alas we weren't and > thus we had a TON more changed crap at the end of it all to try and > polish up and get out. > > Even if we did stop at 6 months, this would mean that for all intensive > purposes we're releasing 3 month old software into our 'early adopters' > community. That wouldn't fly much either (; If development freezes were honored (3 months development, 3 months bugfixing) you'd be shipping that "ancient" 3 month old software anyway. And no, I don't actually want *that* tight devel freezes, but in FC5 case the last minute Mono rush-in was BAD. Who cares (at least I dont) if new leafnode packages are added late in the game but as the shoe-thingy affected Gnome... - Panu - From bernie at develer.com Wed May 24 07:18:05 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 24 May 2006 09:18:05 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4471FFC8.4080503@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> Message-ID: <447408AD.3090706@develer.com> Mike A. Harris wrote: > It'd be an interesting test for someone to disable xfs, and > to configure the X server to have only the "misc" font dir > as a configured font path in xorg.conf, and then see what > all apps no longer work. I've been running my X server with xfs disabled for over one year, but I've added back core fonts in my xorg.conf. This seems to be a good compromise that would keep all legacy toolkits happy for a few more years. IIRC, delegating font rendering to xfs was just a workaround to avoid hanging X for too long while loading fonts with lots of glyphs (e.g. kanji fonts). Today, this is largely useless because: - Very few apps use the core fonts - most of them are not even localized or unable to use non-western fonts - Today's CPUs are much faster - Unless I've misunderstood something, X should now be able to load and render single character glyphs at a time. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Wed May 24 07:41:50 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 24 May 2006 09:41:50 +0200 Subject: rawhide report: 20060522 changes In-Reply-To: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> Message-ID: <44740E3E.9070001@develer.com> Build System wrote: > glibc-2.4.90-9 > -------------- > * Sun May 21 2006 Jakub Jelinek 2.4.90-9 > - update from CVS > - big NIS+ changes Maybe I'm just ignorant about the field, but is any RedHat/Fedora user still using NIS+ instead of LDAP in corporate environments? I wonder whether NIS, NIS+, Hesiod and DB support in glibc could be dropped altogether to reduce the size of Core and simplify dependencies. Maybe those NSS modules could just be splitted out and moved to Extras? -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From skvidal at linux.duke.edu Wed May 24 07:49:45 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 24 May 2006 03:49:45 -0400 Subject: rawhide report: 20060522 changes In-Reply-To: <44740E3E.9070001@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> Message-ID: <1148456985.19927.33.camel@cutter> On Wed, 2006-05-24 at 09:41 +0200, Bernardo Innocenti wrote: > Build System wrote: > > > glibc-2.4.90-9 > > -------------- > > * Sun May 21 2006 Jakub Jelinek 2.4.90-9 > > - update from CVS > > - big NIS+ changes > > Maybe I'm just ignorant about the field, but is any RedHat/Fedora > user still using NIS+ instead of LDAP in corporate environments? > > I wonder whether NIS, NIS+, Hesiod and DB support in glibc could > be dropped altogether to reduce the size of Core and simplify > dependencies. > dropping nis would be a serious problem for a lot of folks, including myself. For simple multi-machine nss nis is still, by far, the simplest to setup and maintain. -sv From buildsys at redhat.com Wed May 24 07:54:01 2006 From: buildsys at redhat.com (Build System) Date: Wed, 24 May 2006 03:54:01 -0400 Subject: rawhide report: 20060524 changes Message-ID: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.15.1-5.FC5.22 ---------------------------- anaconda-11.1.0.19-1 -------------------- * Tue May 23 2006 Chris Lumens 11.1.0.19-1 - Fix unicode stubs (pjones). - Fix libdir on ppc64 (katzj). * Tue May 23 2006 Chris Lumens 11.1.0.18-1 - Add slang-devel build requirement. * Tue May 23 2006 Chris Lumens 11.1.0.17-1 - Display full package name in log (pnasrat, #189308). - Add flags for multipath (pjones). - Allow protected partitions to be mounted (#105722). - Fix pkgorder traceback. apr-1.2.7-7 ----------- * Tue May 23 2006 Joe Orton 1.2.7-7 - fix another multilib conflict (#192659) * Tue May 16 2006 Joe Orton 1.2.7-6 - BR e2fsprogs-devel for libuuid * Mon May 08 2006 Joe Orton 1.2.7-4 - use multilib parallel-installation wrapper hack for apr.h cairo-java-1.0.3-1 ------------------ * Tue May 23 2006 Ben Konrath - 1.0.3-1 - Add -X to src zip and ensure Config.java has the same mod time across platforms - needed for multilib. checkpolicy-1.30.5-1 -------------------- * Tue May 23 2006 Dan Walsh - 1.30.5-1 - Latest upgrade from NSA * Merged compiler cleanup patch from Karl MacMillan. * Merged fix warnings patch from Karl MacMillan. cman-kernel-2.6.15.1-0.FC5.21 ----------------------------- dcraw-0.0.20060521-1 -------------------- * Tue May 23 2006 Nils Philippsen - 0.0.20060521-1 - program and manpage version of 2006-05-21 - use %optflags - change license tag to GPL - use lcms dlm-kernel-2.6.15.1-0.FC5.19 ---------------------------- eclipse-1:3.1.2-1jpp_14fc ------------------------- * Mon May 15 2006 Andrew Overholt 3.1.2-1jpp_14fc - Bump mozilla requirement to match rawhide. * Tue Mar 07 2006 Andrew Overholt 3.1.2-1jpp_13fc - One more small help fix (include tomcatwrapper.jar o.e.tomcat manifest). * Fri Mar 03 2006 Andrew Overholt 3.1.2-1jpp_12fc - Only build with a native ecj on x86{,_64} eclipse-changelog-1:2.0.4_fc-2 ------------------------------ * Tue May 23 2006 Igor Foox 2.0.4_fc-2 - Building for rawhide. * Tue May 23 2006 Igor Foox 2.0.4_fc-1 - Update to version 2.0.3, by fixes by Kyu Lee (rh#168682). * Thu Mar 30 2006 Igor Foox 2.0.2_fc-1 - Update to version 2.0.2, bug fixes by Tom Tromey. evolution-2.7.2.1-3 ------------------- * Tue May 23 2006 Matthew Barnes 2.7.2.1-3 - Port evolution-2.7.1-notification-cleanups.patch to new libnotify API. - Require libnotify >= 0.4. * Fri May 19 2006 Matthew Barnes - 2.7.2.1-2 - Require specific versions of GNU Autotools packages for building. - Add evolution-2.7.2-preedit-gnome.bz-264485.patch (Mayank Jain). - Various spec file cleanups. - Pick up new libnotify. fribidi-0.10.7-3 ---------------- * Tue May 23 2006 Caolan McNamara 0.10.7-3 - rh#192669# clearly I didn't actually get around to basing fribidi-config of pkg-config output gdm-1:2.15.3-3 -------------- * Tue May 23 2006 Ray Strode - 1:2.15.3-3 - Support xdm -nodaemon option (bug 192461) glib-java-0.2.4-3 ----------------- * Thu May 18 2006 Ben Konrath - 0.2.4-3 - Ensure Config.java has the same mod time accross rebuilds (needed for multilib). glib2-2.11.1-2 -------------- * Mon May 22 2006 Matthias Clasen - 2.11.1-2 - Move glib to /lib gmime-2.2.1-1 ------------- * Tue May 23 2006 Alexander Larsson - 2.2.1-1 - Update to 2.2.1 - Fix multilib -devel conflict by using pkg-config in gmime-config (#192675) * Tue Feb 28 2006 Karsten Hopp 2.1.19-4 - BuildRequires: gtk-sharp2 on mono archs only gnbd-kernel-2.6.15-5.FC5.28 --------------------------- initscripts-8.34-1 ------------------ * Tue May 23 2006 Bill Nottingham 8.34-1 - link glib2 dynamically now that it's in /lib, conflict with older versions - handle cups specially when cleaning /var (#189168) - remove ifdown-aliases () - ifup-ipsec: fix key handling when only one of AH or ESP is used (#166257, ) - IPv6 updates, including RFC 3041 support () - routing fixes, add METRIC support for default routes (#124045, ) - fix handling of mount points with white space (#186713, ) kdebase-6:3.5.2-11 ------------------ * Tue May 23 2006 Than Ngo 6:3.5.2-11 - apply upstream patches to fix several bugs in konsole, and fix #192832, konsole crashes on kde logout kdebindings-3.5.2-2 ------------------- * Tue May 23 2006 Than Ngo 3.5.2-2 - fix build problem with ruby kernel-2.6.16-1.2211_FC6 ------------------------ * Tue May 23 2006 Dave Jones - 2.6.17rc4-git11 * Mon May 22 2006 Dave Jones - 2.6.17rc4-git10 libIDL-0.8.6-3 -------------- * Tue May 23 2006 Matthias Clasen - 0.8.6-3 - Fix multilib conflicts libcroco-0.6.1-2 ---------------- * Tue May 23 2006 Matthias Clasen - 0.6.1-2 - Make config script a pkg-config wrapper to fix multilib conflict libgconf-java-2.12.1.0.20060301.rh1-1 ------------------------------------- * Tue May 23 2006 Ben Konrath - 2.12.1.0.20060301.rh1-1 - Add -X to src zip and ensure Config.java has the same mod time across platforms - needed for multilib. libglade-java-2.12.3-1 ---------------------- * Tue May 23 2006 Ben Konrath - 2.12.3-1 - Add -X to src zip and ensure Config.java has the same mod time across platforms - needed for multilib. libgnome-java-2.12.2-1 ---------------------- * Tue May 23 2006 Ben Konrath - 2.12.2-1 - Add -X to src zip and ensure Config.java has the same mod time across platforms - needed for multilib. libgnomecanvas-2.14.0-2 ----------------------- * Tue May 23 2006 Matthias Clasen - 2.14.0-2 - Fix multilib conflicts - Don't ship .la files - Some spec file cleanups libgsf-1.14.1-3 --------------- * Tue May 23 2006 Caolan McNamara 1.14.1-3 - rh#192707# disable rebuilding of gtk-doc so as to allow multi-arch devel libgtk-java-2.8.4-3 ------------------- * Tue May 23 2006 Ben Konrath - 2.8.4-3 - Add -X to src zip and ensure Config.java has the same mod time across platforms - needed for multilib. libpng-2:1.2.10-4 ----------------- * Tue May 23 2006 Matthias Clasen - 2:1.2.10-4 - fix multilib conflicts * Mon May 22 2006 Matthias Clasen - 2:1.2.10-3 - Add a comment about the need to keep static libraries * Mon May 22 2006 Matthias Clasen - 2:1.2.10-2 - Re-add static libraries libselinux-1.30.10-2 -------------------- * Tue May 23 2006 Dan Walsh 1.30.10-2 - Add BuildRequires for swig * Tue May 23 2006 Dan Walsh 1.30.10-1 - Upgrade to latest from NSA * Merged simple setrans client cache from Dan Walsh. Merged avcstat patch from Russell Coker. * Modified selinux_mkload_policy() to also set /selinux/compat_net appropriately for the loaded policy. libsepol-1.12.12-1 ------------------ * Tue May 23 2006 Dan Walsh 1.12.12-1 - Upgrade to latest from NSA * Added sepol_policydb_compat_net() interface for testing whether a policy requires the compatibility support for network checks to be enabled in the kernel. libvte-java-0.11.11.0.20060301.rh1-3 ------------------------------------ * Tue May 23 2006 Ben Konrath - 0.11.11.0.20060301.rh1-3 - Add -X to src zip and ensure Config.java has the same mod time across platforms - needed for multilib. make-1:3.81-1 ------------- * Tue May 23 2006 Petr Machata - 1:3.81-1 - Upstream 3.81: - Contains several backwards incompatible changes. See NEWS inside the source package to find out more. - memory patch and error reporting patch were ported to this version. * Wed Mar 15 2006 Petr Machata 1:3.80-11 - Applied (five years old) patch from Jonathan Kamens to allow make to handle several pattern-specific variables (#52962). The patch was changed so that it forces make to process pattern specific variables in the same order as they appear in file. (Upstream make behaves this way, too.) This is change from old make behavior, which processed the variables in reverse order. In case you used only x=a assignments, this had the effect of using the first pattern specific variable that matched. For x+=a this just doesn't work, and it produces absolutely nonintuitive results. - (It would be great if make's target-specific variables were handled the same way as pattern-specific ones, just without the pattern component. However current handling is documented and considered a feature.) net-snmp-5.3.1.pre2-1 --------------------- * Tue May 23 2006 Radek Vokal 5.3.1.pre2-1 - update to 5.3.1.pre2 - fix multilib issues (#192736) On system with /usr/lib64 use net-snmp-config64 and net-snmp-config64.h openoffice.org-1:2.0.3-3.1 -------------------------- * Tue May 23 2006 Caolan McNamara - 1:2.0.3-3.1 - 2.0.3 RC3 - rh#191650# add openoffice.org-2.0.2.oooXXXXX.vcl.honourcairofont.patch - rh#192588# don't use the cairo canvas by default pciutils-2.2.3-1 ---------------- * Tue May 23 2006 Harald Hoyer 2.2.3-1 - version 2.2.3 - multilib patch (bug #192743) * Thu Feb 23 2006 Harald Hoyer 2.2.1-2 - added update-pciids shell script and manpage (bz #178582) policycoreutils-1.30.10-1 ------------------------- * Wed May 24 2006 Dan Walsh 1.30.10-1 - Update to upstream * Merged patch with updates to audit2allow, secon, genhomedircon, and semanage from Dan Walsh. pykickstart-0.29-1 ------------------ * Tue May 23 2006 Chris Lumens 0.29-1 - Add multipath command, handlers, and data objects (pjones). - Rename --ports to --port in writer. setools-2.4-2 ------------- * Tue May 23 2006 Dan Walsh 2.4-2 - Remove sqlite include directory slang-2.0.6-2 ------------- * Tue May 23 2006 Peter Jones - 2.0.6-2 - put static lib back; it is required by anaconda sudo-1.6.8p12-5 --------------- * Tue May 23 2006 Karel Zak 1.6.8p12-5 - add LDAP support (#170848) tn5250-0.17.3-3 --------------- * Tue May 23 2006 Karsten Hopp 0.17.3-3 - don't check for sizeof(long), the result isn't used anywhere and causes problems with multilib installs xorg-x11-drv-apm-1.1.1-2 ------------------------ * Tue May 23 2006 Adam Jackson 1.1.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-ark-0.6.0-2 ------------------------ * Tue May 23 2006 Adam Jackson 0.6.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-ati-6.6.0-3 ------------------------ * Tue May 23 2006 Adam Jackson 6.6.0-3 - Rebuild for 7.1 ABI fix. * Tue Apr 11 2006 Kristian H??gsberg 6.6.0-2 - Bump for fc5-bling build. xorg-x11-drv-chips-1.1.1-2 -------------------------- * Tue May 23 2006 Adam Jackson 1.1.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-cyrix-1.1.0-2 -------------------------- * Tue May 23 2006 Adam Jackson 1.1.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-dummy-0.2.0-2 -------------------------- * Tue May 23 2006 Adam Jackson 0.2.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-glint-1.1.1-2 -------------------------- * Tue May 23 2006 Adam Jackson 1.1.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-i128-1.2.0-2 ------------------------- * Tue May 23 2006 Adam Jackson 1.2.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-i740-1.1.0-2 ------------------------- * Tue May 23 2006 Adam Jackson 1.1.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-i810-1.6.0-3 ------------------------- * Tue May 23 2006 Adam Jackson 1.6.0-3 - Rebuild for 7.1 ABI fix. * Tue Apr 11 2006 Kristian H??gsberg 1.6.0-2 - Bump for fc5-bling build. xorg-x11-drv-mga-1.4.1-2 ------------------------ * Sun Apr 09 2006 Adam Jackson 1.4.1-2 - Update to 1.4.1 from 7.1RC1. * Fri Feb 10 2006 Jesse Keating - 1.2.1.3-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 1.2.1.3-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-drv-neomagic-1.1.1-2 ----------------------------- * Tue May 23 2006 Adam Jackson 1.1.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-nsc-2.8.1-2 ------------------------ * Tue May 23 2006 Adam Jackson 2.8.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-nv-1.1.1-3 ----------------------- * Tue May 23 2006 Adam Jackson 1.1.1-3 - Rebuild for 7.1 ABI fix. xorg-x11-drv-rendition-4.1.0-2 ------------------------------ * Tue May 23 2006 Adam Jackson 4.1.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-s3-0.4.1-2 ----------------------- * Tue May 23 2006 Adam Jackson 0.4.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-s3virge-1.9.1-2 ---------------------------- * Tue May 23 2006 Adam Jackson 1.9.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-savage-2.1.1-2 --------------------------- * Tue May 23 2006 Adam Jackson 2.1.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-siliconmotion-1.4.1-2 ---------------------------------- * Tue May 23 2006 Adam Jackson 1.4.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-sis-0.9.1-2 ------------------------ * Tue May 23 2006 Adam Jackson 0.9.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-sisusb-0.8.1-2 --------------------------- * Tue May 23 2006 Adam Jackson 0.8.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-tdfx-1.2.1-2 ------------------------- * Tue May 23 2006 Adam Jackson 1.2.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-trident-1.2.1-2 ---------------------------- * Tue May 23 2006 Adam Jackson 1.2.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-tseng-1.1.0-2 -------------------------- * Tue May 23 2006 Adam Jackson 1.1.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-v4l-0.1.1-3 ------------------------ * Tue May 23 2006 Adam Jackson 0.1.1-3 - Rebuild for 7.1 ABI fix. xorg-x11-drv-vga-4.1.0-2 ------------------------ * Tue May 23 2006 Adam Jackson 4.1.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-via-0.2.1-2 ------------------------ * Tue May 23 2006 Adam Jackson 0.2.1-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-vmware-10.13.0-2 ----------------------------- * Tue May 23 2006 Adam Jackson 10.13.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-drv-voodoo-1.1.0-2 --------------------------- * Tue May 23 2006 Adam Jackson 1.1.0-2 - Rebuild for 7.1 ABI fix. xorg-x11-server-1.1.0-1 ----------------------- * Tue May 23 2006 Adam Jackson 1.1.0-1 - Xorg 7.1 final. * Tue May 23 2006 Mike A. Harris 1.0.99.903-2 - Disable dependency on xorg-x11-drivers package, for OLPC. (#191781) - Add "BuildRequires: freetype-devel >= 2.1.10" for bug (#192021) * Fri May 12 2006 Adam Jackson 1.0.99.903-1 - Update to 7.1RC3, plus experimental fix for fdo bug #6827. Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 beagle - 0.2.6-3.s390 requires mono(gmime-sharp) = 0:2.1.0.0 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 scim-chewing - 0.2.1-6.s390 requires libchewing.so.2 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 systemtap - 0.5.5-2.s390 requires kernel >= 0:2.6.9-11 tomboy - 0.3.5-4.s390 requires mono(gmime-sharp) = 0:2.1.0.0 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 beagle - 0.2.6-3.s390x requires mono(gmime-sharp) = 0:2.1.0.0 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) scim-chewing - 0.2.1-6.s390x requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 systemtap - 0.5.5-2.s390x requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.9.4.1-2.ppc64 requires libnotify.so.0()(64bit) scim-chewing - 0.2.1-6.ppc64 requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU beagle - 0.2.6-3.i386 requires mono(gmime-sharp) = 0:2.1.0.0 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU rhythmbox - 0.9.4.1-2.i386 requires libnotify.so.0 scim-chewing - 0.2.1-6.i386 requires libchewing.so.2 tomboy - 0.3.5-4.i386 requires mono(gmime-sharp) = 0:2.1.0.0 Broken deps for ia64 ---------------------------------------------------------- beagle - 0.2.6-3.ia64 requires mono(gmime-sharp) = 0:2.1.0.0 rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.4.1-2.ia64 requires libnotify.so.0()(64bit) scim-chewing - 0.2.1-6.ia64 requires libchewing.so.2()(64bit) tomboy - 0.3.5-4.ia64 requires mono(gmime-sharp) = 0:2.1.0.0 Broken deps for ppc ---------------------------------------------------------- beagle - 0.2.6-3.ppc requires mono(gmime-sharp) = 0:2.1.0.0 rhythmbox - 0.9.4.1-2.ppc requires libnotify.so.0 scim-chewing - 0.2.1-6.ppc requires libchewing.so.2 tomboy - 0.3.5-4.ppc requires mono(gmime-sharp) = 0:2.1.0.0 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU beagle - 0.2.6-3.x86_64 requires mono(gmime-sharp) = 0:2.1.0.0 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU rhythmbox - 0.9.4.1-2.x86_64 requires libnotify.so.0()(64bit) scim-chewing - 0.2.1-6.x86_64 requires libchewing.so.2()(64bit) tomboy - 0.3.5-4.x86_64 requires mono(gmime-sharp) = 0:2.1.0.0 From bernie at develer.com Wed May 24 08:00:26 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 24 May 2006 10:00:26 +0200 Subject: Future Fedora Development In-Reply-To: <1148245245.21278.22.camel@kloczek01.pracownicy.zie> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> Message-ID: <4474129A.5050201@develer.com> Tomasz K?oczko wrote: > It will be good remove multiple implementation of: > - term toolkit (lang, libtermcap and ncurses). Use only ncurses will fit > all what is neccessary,. Patching all program for use libncursesw will > allow remove distribute libncurses library (now are distributed > libncurses and libncursesw) and move libncurses to kind > compat-ncurses package. I also want to see libtermcap die, but then libncurses and its terminfo database would have to move from /usr to / to support applications such as vim. Maybe all the exotic terminals could remain in /usr/share/terminfo while the root partition would only have minimal support for the most common ones (linux, vt100, xterm, etc). > - multiple digests operation (openssl, gnutls, nss .. some programs are > now linked with *all* avalaible implemntations 8-0 ), Yeah, I agree. OpenSSL seems to be the most comprehensive, but its licence stinks and this is why gnutls was written in the first place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, there's no reason to keep gnutls any more. OpenSSL also tends to break its ABI very often and this is very annoying when upgrading to a new version of Fedora. I'd ditch that one too if wasn't used by so many packages. > - multipme XML parsers. Now some programs are linked with more than > one XML parser library. For example fontconfig now uses expat but can > be on build stage compiled as using libxml2 .. but most GNOME programs > uses libxml2. I used libxml2 once and I really don't like its API (very error prone, like glib). libexpat looks much better, has no other dependencies and it's very small, but it doesn't have an equivalent of libxslt and xsltproc. > This is only few points from much more larger list. > For example now in Fedora is avalaible libdbi but there is no other > programs which uses this library .. except dictd which unondiotionaly if > will find libdbi on autoconf level causes compile dbi dictd pliugin > (anyone uses this ? one persone or more ?). Why this unused piece of > was added to distributed packages list ? > > More .. why many packages do not have separated devel resources ? Why so > many packages still have static libraries and .la files ? Why so many > packages still build static libraries and and removes this on %install > sttage if on %build can be added --disable-static to autoconf options ? I 100% agree with you here. Fedora could use a good diet. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Wed May 24 08:13:52 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 24 May 2006 10:13:52 +0200 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <1148456985.19927.33.camel@cutter> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> Message-ID: <447415C0.8030300@develer.com> seth vidal wrote: > For simple multi-machine nss nis is still, by far, the simplest to setup > and maintain. LDAP sure isn't an easy beast to configure and run, expecially if you need TLS and replication. But this is largely a distribution issue: the default configuration in Fedora does not come close to what would be needed to setup an LDAP authentication server. And there are no system-config-* tools for newbies to use. I've had similar experience with other Linux distributions. Linux is now the only OS that doesn't provide out of the box authentication and directory services for corporate environments. Windows got there six years ago with ActiveDirectory and MacOSX does it beautifully with NetInfo and its nice OpenLDAP integration. As an administrator, I'm particularly embarassed to show my customers the tools I use to run their UNIX accounts and Samba domain controller. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From sundaram at fedoraproject.org Wed May 24 08:17:07 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 May 2006 13:47:07 +0530 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <447415C0.8030300@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> Message-ID: <1148458627.4310.567.camel@sundaram.pnq.redhat.com> On Wed, 2006-05-24 at 10:13 +0200, Bernardo Innocenti wrote: > seth vidal wrote: > > > For simple multi-machine nss nis is still, by far, the simplest to setup > > and maintain. > > LDAP sure isn't an easy beast to configure and run, expecially > if you need TLS and replication. > > But this is largely a distribution issue: the default configuration > in Fedora does not come close to what would be needed to setup an > LDAP authentication server. And there are no system-config-* tools > for newbies to use. I've had similar experience with other Linux > distributions. > > Linux is now the only OS that doesn't provide out of the box > authentication and directory services for corporate environments. > Windows got there six years ago with ActiveDirectory and MacOSX > does it beautifully with NetInfo and its nice OpenLDAP integration. > > As an administrator, I'm particularly embarassed to show my > customers the tools I use to run their UNIX accounts and > Samba domain controller. You might get involved and help write such tools. That would replace embarrassment with pride. Rahul From pemboa at gmail.com Wed May 24 08:39:20 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 May 2006 03:39:20 -0500 Subject: Future Fedora Development In-Reply-To: <44701330.4030807@ntlworld.com> References: <44701330.4030807@ntlworld.com> Message-ID: <16de708d0605240139n2e4b281bk85bb85683b500b1b@mail.gmail.com> On 5/21/06, David wrote: > Hi Folks, > > Ive just joined this mailing list and I am in intending to get involved > with the testing effort within the Feodra project. Just by way of > introduction I am based in Belfast Ireland [ snip ] No kidding, I am from Belfast, Dominica. [ snip ] > 1. Cost. No doubt there. > 2. This older kit provides all the functionality I need at home as Im > not big into gaming or heavy multimedia or the like True, but lower values from `time make foo` never hurt > 3. An element of "save the earth". Understandable, but I would assume that older hardware is also less energy efficient. > [ snip ] Perhaps a solution would be to ask ANACONDA to identify hardware > resources available on a box and then provide a suggested build of > Fedora to be intstalled that will provide only the functionality the > hardware is capable of running sucessfully? I would love to see Anaconda much more intelligent. The only reason that I am not more vocal about it is that I am not yet in a position to fix it, so why complain. But still Anaconda should be able to make interface, and installation decisions based on at least the following metrics, with the intention of making the entire experience more pleasureable. - Hardware power (CPU speed, primary storage capacity, etc. ) - Experience level of human installer - Choice of desktop environment - Type (if any) of internet connection - Status of human installer during installation (at machine, away from machine, etc.) It would also be cool to have the option to simply plug in a USB drive which contained a supported file system and a file with core version agnostic data which allowed Anaconda to know what the user likes (typically installs) and have the rest automated from there. But that might be a wee bit over the top. > > Cheers > > David > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- To be updated... From che666 at gmail.com Wed May 24 09:02:02 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 24 May 2006 11:02:02 +0200 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <1148458627.4310.567.camel@sundaram.pnq.redhat.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> Message-ID: 2006/5/24, Rahul Sundaram : > On Wed, 2006-05-24 at 10:13 +0200, Bernardo Innocenti wrote: > > seth vidal wrote: > > > > > For simple multi-machine nss nis is still, by far, the simplest to setup > > > and maintain. > > > > LDAP sure isn't an easy beast to configure and run, expecially > > if you need TLS and replication. > > > > But this is largely a distribution issue: the default configuration > > in Fedora does not come close to what would be needed to setup an > > LDAP authentication server. And there are no system-config-* tools > > for newbies to use. I've had similar experience with other Linux > > distributions. > > > > Linux is now the only OS that doesn't provide out of the box > > authentication and directory services for corporate environments. > > Windows got there six years ago with ActiveDirectory and MacOSX > > does it beautifully with NetInfo and its nice OpenLDAP integration. > > > > As an administrator, I'm particularly embarassed to show my > > customers the tools I use to run their UNIX accounts and > > Samba domain controller. > > You might get involved and help write such tools. That would replace > embarrassment with pride. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > i second that a tool that makes it "intuitive" to setup ldap authentication and later maybe even "single sign on" possible would make a nice enhancement for fedora. regards, Rudolf Kastl p.s. id maybe help with python hacking there once a project is set up. From hk at isphuset.no Wed May 24 09:06:19 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Wed, 24 May 2006 11:06:19 +0200 Subject: question about creation of updated DVD iso In-Reply-To: <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> Message-ID: <1148461579.19549.57.camel@linux> On Tue, 2006-05-23 at 09:57 -0400, Steven Augart wrote: *snip* > (The motivation here was that FC 5's Anaconda has a bug in it that > crashes when it tries to find the CD drive on an IBM Blade Center, if > the Kickstart file is on CD. Although I fixed the bug and posted the > URL for the patches, it would be a lot less work, in most cases, just to > work around it by reading the Kickstart file off of a floppy disk.) This is exactly what a respin would fix =) > However, even though the scripts rebuild the initrd, I was using the > kernel that came with the initrd. I believe that the kernel builds for > the initrd and installer CD are identical to the stock kernel that ships > with FC 5 and is installed. So using the stock one from the RPM should > be safe. If you want to recompile the kernel for some reason, then > the .config file from that kernel is probably pretty safe too. > > I know that Hans K. Rosbach (at http://fedora.isphuset.no/ ) has rebuilt > the Fedora Core 4 installation CD set, with updated RPM packages, > including an updated installation kernel. He calls it "Unofficial FC > 4.2". I'm certainly curious to know how he rebuilt the initrd for FC 4 > with the updated installer kernel; I myself failed to do it. http://fedora.isphuset.no/howididit.txt I haven't commented it a lot, but together with the comments from the howto I derived it from it should be enough to get you going. > Here's the > story, in case you find it helpful to know about a path that didn't work > for me: > > I've been putting together an installation CD for us to use here at Mazu > Networks to install on our Mazu Profiler security appliance (a hardware > box that we sell). We want a single CD that has bundled on it the > Kickstart file we use and all of the packages we want to install. After > I got the FC 5 version working (by fixing Anaconda, as I mentioned > above), we made a technical decision to base the current release of the > product on FC 4. > > The problem here is that the distributed FC 4 installer comes with > kernel version 2.6.11-1.1369_FC4. 2.6.11 has a bug in the keyboard > driver which causes a kernel panic when booting on the IBM Blade Center. > 2.6.16 doesn't have it. So, before I discovered Hans Rosbach's kernel, *snip* Actually my respins contain the official kernel RPM updates, so nothing should differ from a normal install + updates. But I am glad to see that I have helped some people. I am considering making respins for FC5 aswell, but with the lack of cooperation from fedora or community members it's currently on hold. -HK From sundaram at fedoraproject.org Wed May 24 09:12:31 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 May 2006 14:42:31 +0530 Subject: question about creation of updated DVD iso In-Reply-To: <1148461579.19549.57.camel@linux> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <1148461579.19549.57.camel@linux> Message-ID: <1148461951.4310.570.camel@sundaram.pnq.redhat.com> On Wed, 2006-05-24 at 11:06 +0200, Hans Kristian Rosbach wrote: > But I am glad to see that I have helped some people. > > I am considering making respins for FC5 aswell, but with the lack of > cooperation from fedora or community members it's currently on hold. There is both actually. Fedora Unity project seems to be already producing respins. https://www.redhat.com/archives/fedora-advisory-board/2006- May/msg00186.html https://www.redhat.com/archives/fedora-advisory-board/2006- May/msg00251.html Rahul From hk at isphuset.no Wed May 24 09:45:03 2006 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Wed, 24 May 2006 11:45:03 +0200 Subject: question about creation of updated DVD iso In-Reply-To: <1148461951.4310.570.camel@sundaram.pnq.redhat.com> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <1148461579.19549.57.camel@linux> <1148461951.4310.570.camel@sundaram.pnq.redhat.com> Message-ID: <1148463903.19549.74.camel@linux> On Wed, 2006-05-24 at 14:42 +0530, Rahul Sundaram wrote: > On Wed, 2006-05-24 at 11:06 +0200, Hans Kristian Rosbach wrote: > > > But I am glad to see that I have helped some people. > > > > I am considering making respins for FC5 aswell, but with the lack of > > cooperation from fedora or community members it's currently on hold. > > There is both actually. Fedora Unity project seems to be already > producing respins. > > https://www.redhat.com/archives/fedora-advisory-board/2006- > May/msg00186.html > https://www.redhat.com/archives/fedora-advisory-board/2006- > May/msg00251.html Yes, so they claim. However I have not been able to locate much info about these isos. I also don't know whether they use the official FC5 anaconda rpm (with its bugs) or their own rebuild of it. And if it is a "private" rebuild, I just don't like the idea as it raises a lot of concerns. Oh, and I'll have to correct my previous statement. I met a lot of cooperation from Rahul, and I am very thankful for that. Unfortunately we could not resolve the problems (see previous threads) by ourself. I will most likely make private respins for use in-house, just like what we had planned the FC4 ones to be. We have a pretty strict policy about knowing the origins and details of packages. -HK From che666 at gmail.com Wed May 24 10:14:39 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 24 May 2006 12:14:39 +0200 Subject: Back to 6 month schedule? In-Reply-To: <1148384870.3819.11.camel@ender> References: <20060523105441.GA5224@neu.nirvana> <1148384870.3819.11.camel@ender> Message-ID: 2006/5/23, Jesse Keating : > On Tue, 2006-05-23 at 12:54 +0200, Axel Thimm wrote: > > Just curious what the targeted general schedule is, what FC6's > > concrete schedule is (e.g. if the general schedule is 9 month, why go > > 6 months for FC6?), and closely related to this, what the relationship > > RHEL5 to FC5/FC6 will be. > > FC5's 9(10, 11) month schedule was an experiment in adjusting the > schedule to see if it helped in our release. While it did allow for > some larger changes to make it through, it multiplied the amount of > little changes at the same time. It created a very bad situation for > those of us trying to do any kind of QA on the distro before it went out > the door. For all those involved, we felt that the 9 month schedule > hurt more than it helped and we're back to the tried and true 6 month > schedule, with slips here and there (hopefully not). > > Sorry for the confusion. > > -- > Jesse Keating > Release Engineer: Fedora > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBEcvZm4v2HLvE71NURAlcGAJ4mgNB7n2Z8t9S0q4fkMtBH4VDaCQCfU9O0 > ssY1dr9GZAVYIFM0DxXe6ZI= > =cmkJ > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > just like with any other project: release early, release often :)) From billcrawford1970 at gmail.com Wed May 24 11:33:31 2006 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 24 May 2006 12:33:31 +0100 Subject: Future Fedora Development In-Reply-To: <16de708d0605240139n2e4b281bk85bb85683b500b1b@mail.gmail.com> References: <44701330.4030807@ntlworld.com> <16de708d0605240139n2e4b281bk85bb85683b500b1b@mail.gmail.com> Message-ID: <200605241233.31667.billcrawford1970@googlemail.com> Le Mercredi 24 Mai 2006 09:39, Arthur Pemberton a ?crit?: > Understandable, but I would assume that older hardware is also less > energy efficient. While this may be true, the overall power consumption of "modern" kit while in use is much higher than older machines, so for something that sees a lot of use, the "efficiency" issue is a bit of a red herring. > > Cheers > > > > David The Other Bill. From alan at redhat.com Wed May 24 11:37:18 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 24 May 2006 07:37:18 -0400 Subject: Future Fedora Development In-Reply-To: <4474129A.5050201@develer.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> Message-ID: <20060524113718.GA16163@devserv.devel.redhat.com> On Wed, May 24, 2006 at 10:00:26AM +0200, Bernardo Innocenti wrote: > Yeah, I agree. OpenSSL seems to be the most comprehensive, but > its licence stinks and this is why gnutls was written in the first > place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, > there's no reason to keep gnutls any more. GNUtls is needed for GPL programs using SSL. From kloczek at zie.pg.gda.pl Wed May 24 13:21:16 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 15:21:16 +0200 Subject: Future Fedora Development In-Reply-To: <4474129A.5050201@develer.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> Message-ID: <1148476876.8621.43.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 10:00 +0200, Bernardo Innocenti napisa?(a): > Tomasz K?oczko wrote: > > > It will be good remove multiple implementation of: > > - term toolkit (lang, libtermcap and ncurses). Use only ncurses will fit > > all what is neccessary,. Patching all program for use libncursesw will > > allow remove distribute libncurses library (now are distributed > > libncurses and libncursesw) and move libncurses to kind > > compat-ncurses package. > > I also want to see libtermcap die, but then libncurses and its > terminfo database would have to move from /usr to / to support > applications such as vim. > > Maybe all the exotic terminals could remain in /usr/share/terminfo > while the root partition would only have minimal support for the > most common ones (linux, vt100, xterm, etc). Best will be generate ncurses with --with-termlib and move only libterm to /%{_lib}. This library can bring some most offen used teminals definition and all other shoud be moved for example to compat-terminfo package. > > - multiple digests operation (openssl, gnutls, nss .. some programs are > > now linked with *all* avalaible implemntations 8-0 ), > > Yeah, I agree. OpenSSL seems to be the most comprehensive, but > its licence stinks and this is why gnutls was written in the first > place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, > there's no reason to keep gnutls any more. > > OpenSSL also tends to break its ABI very often and this is very > annoying when upgrading to a new version of Fedora. I'd ditch > that one too if wasn't used by so many packages. I can't understand this situation. It is sick .. Seems now strict license compliance is used only in libsoup and all other cases current using gnutls for example in cups can be switched between openssl and gnutls. All this cases (current using gnutls) this very small subset of all using SSL in distro. If in all other cases seems noone cares why now some "for make this betetter" someone (temporary ?) decide for "make this wors" ? Next ideology ? For me preparing distribution it dominion of practise .. not ideology :> If now is possible freely distribute Fedora and other distros with openssl without lawyers actions why this is moved to ideology groud ? Openssl not only have most offen used SLL suport. It also makes possible using some hardware SSL accelerators. Now nss and gnutls even do not have this on TODO lists .. > - multipme XML parsers. Now some programs are linked with more than > > one XML parser library. For example fontconfig now uses expat but can > > be on build stage compiled as using libxml2 .. but most GNOME programs > > uses libxml2. > > I used libxml2 once and I really don't like its API (very error prone, > like glib). > > libexpat looks much better, has no other dependencies and it's very > small, but it doesn't have an equivalent of libxslt and xsltproc. Look at some benchmarking materials. libxml2 is faster than expat. Also make some programs two the same class libraries dependent makes them additionaly slower. > > This is only few points from much more larger list. > > For example now in Fedora is avalaible libdbi but there is no other > > programs which uses this library .. except dictd which unondiotionaly if > > will find libdbi on autoconf level causes compile dbi dictd pliugin > > (anyone uses this ? one persone or more ?). Why this unused piece of > > was added to distributed packages list ? > > > > More .. why many packages do not have separated devel resources ? Why so > > many packages still have static libraries and .la files ? Why so many > > packages still build static libraries and and removes this on %install > > sttage if on %build can be added --disable-static to autoconf options ? > > I 100% agree with you here. Fedora could use a good diet. This thread ("Future Fedora Development") is for me formed on some "wishes" level completly not understendable on development level. Instead defining this in this way better will be take some real study on how technically this must be gained. For example it will be good to show which resources are most offen used, which sometimes and which completly not used (shooting .. now more than 30% current files are from this class). After this will be possible describe how to stip down amount of distributed resources. On current Fedora I see few hundriets MBs which can be removed without hurting any functionality. Examples: - not installing doubled documentations (some packages provides the same documentation texts in more than one form), - remove all Changelog files (if anyone want to move to datailed list of changes better is review this in SVN/CVS repo), - remove all automake copy INSTALL files from %doc, - instead distributing hudriets copies of GPL and simillar common licenses better will be make licenses package which will provide all this texts in roff man pages (distribute license text as %doc will be allowed only if it is not common license), - remove most of .la (only fiew are neccessaruy if program/DSO uses libltdl) and all static libraries and also drop all static linking (now initrd formed from neccessary shared libraries and dynamically linked utilities can be smaller than formed from statically linked tools). kloczek From sundaram at fedoraproject.org Wed May 24 13:44:39 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 May 2006 19:14:39 +0530 Subject: Future Fedora Development In-Reply-To: <1148476876.8621.43.camel@kloczek01.pracownicy.zie> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <1148476876.8621.43.camel@kloczek01.pracownicy.zie> Message-ID: <1148478279.4310.575.camel@sundaram.pnq.redhat.com> On Wed, 2006-05-24 at 15:21 +0200, Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 10:00 +0200, Bernardo Innocenti > napisa?(a): > > Tomasz K?oczko wrote: > > > > > It will be good remove multiple implementation of: > > > - term toolkit (lang, libtermcap and ncurses). Use only ncurses will fit > > > all what is neccessary,. Patching all program for use libncursesw will > > > allow remove distribute libncurses library (now are distributed > > > libncurses and libncursesw) and move libncurses to kind > > > compat-ncurses package. > > > > I also want to see libtermcap die, but then libncurses and its > > terminfo database would have to move from /usr to / to support > > applications such as vim. > > > > Maybe all the exotic terminals could remain in /usr/share/terminfo > > while the root partition would only have minimal support for the > > most common ones (linux, vt100, xterm, etc). > > Best will be generate ncurses with --with-termlib and move only libterm > to /%{_lib}. This library can bring some most offen used teminals > definition and all other shoud be moved for example to compat-terminfo > package. > > > > - multiple digests operation (openssl, gnutls, nss .. some programs are > > > now linked with *all* avalaible implemntations 8-0 ), > > > > Yeah, I agree. OpenSSL seems to be the most comprehensive, but > > its licence stinks and this is why gnutls was written in the first > > place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, > > there's no reason to keep gnutls any more. > > > > OpenSSL also tends to break its ABI very often and this is very > > annoying when upgrading to a new version of Fedora. I'd ditch > > that one too if wasn't used by so many packages. > > I can't understand this situation. It is sick .. > Seems now strict license compliance is used only in libsoup and all > other cases current using gnutls for example in cups can be switched > between openssl and gnutls. > All this cases (current using gnutls) this very small subset of all > using SSL in distro. If in all other cases seems noone cares why now > some "for make this betetter" someone (temporary ?) decide for "make > this wors" ? Next ideology ? > For me preparing distribution it dominion of practise .. not ideology :> Are you claiming that its ok to violate licenses as long as the other end doesnt have lawyers? If its a license violation, it should be fixed. Period. Rahul From kloczek at zie.pg.gda.pl Wed May 24 14:29:17 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 16:29:17 +0200 Subject: Future Fedora Development In-Reply-To: <1148478279.4310.575.camel@sundaram.pnq.redhat.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <1148476876.8621.43.camel@kloczek01.pracownicy.zie> <1148478279.4310.575.camel@sundaram.pnq.redhat.com> Message-ID: <1148480958.15113.12.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 19:14 +0530, Rahul Sundaram napisa?(a): [..] > Are you claiming that its ok to violate licenses as long as the other > end doesnt have lawyers? If its a license violation, it should be fixed. > Period. No. I'm claiming only: *if* [1] now openssl violate licenses and moving only few from hundriets projects to gnutls changes nothing on this area but changes distribution (makes them worse) on technical level. [1] word *if* is importand in this case because openssl is distributed under Apache-style license (BSD license derivat). If openssl breaks anything on this area probably apache braks this too. Also look on: http://www.openssl.org/support/faq.html#LEGAL For me moving to gnutls hang only on "Some GPL software copyright holders claim that you infringe on their rights". So question in this case is: are this people are lawyers or not and anyone must care on this or not ? kloczek From bernie at develer.com Wed May 24 14:57:04 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 24 May 2006 16:57:04 +0200 Subject: Future Fedora Development In-Reply-To: <20060524113718.GA16163@devserv.devel.redhat.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> Message-ID: <44747440.8070101@develer.com> Alan Cox wrote: > On Wed, May 24, 2006 at 10:00:26AM +0200, Bernardo Innocenti wrote: >> Yeah, I agree. OpenSSL seems to be the most comprehensive, but >> its licence stinks and this is why gnutls was written in the first >> place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, >> there's no reason to keep gnutls any more. > > GNUtls is needed for GPL programs using SSL. What's wrong with GPL programs using the Mozilla implementation? Last time I checked NSS was totally GPL compatible. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From alan at redhat.com Wed May 24 15:04:59 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 24 May 2006 11:04:59 -0400 Subject: Future Fedora Development In-Reply-To: <44747440.8070101@develer.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> Message-ID: <20060524150459.GA28005@devserv.devel.redhat.com> On Wed, May 24, 2006 at 04:57:04PM +0200, Bernardo Innocenti wrote: > >GNUtls is needed for GPL programs using SSL. > > What's wrong with GPL programs using the Mozilla implementation? > Last time I checked NSS was totally GPL compatible. Nothing at all, just the openssl one is problematic From cmadams at hiwaay.net Wed May 24 15:08:05 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 May 2006 10:08:05 -0500 Subject: Future Fedora Development In-Reply-To: <44747440.8070101@develer.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> Message-ID: <20060524150805.GC1186624@hiwaay.net> Once upon a time, Bernardo Innocenti said: > What's wrong with GPL programs using the Mozilla implementation? > Last time I checked NSS was totally GPL compatible. mozilla-nss requires mozilla-nspr. libnss3.so also pulls in libpthread.so. Those are pretty heavy requirements for SSL. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From smooge at gmail.com Wed May 24 15:13:39 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 24 May 2006 09:13:39 -0600 Subject: rawhide report: 20060522 changes In-Reply-To: <44740E3E.9070001@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> Message-ID: <80d7e4090605240813w7240e476q168bef7b398f6b1a@mail.gmail.com> On 5/24/06, Bernardo Innocenti wrote: > Build System wrote: > > > glibc-2.4.90-9 > > -------------- > > * Sun May 21 2006 Jakub Jelinek 2.4.90-9 > > - update from CVS > > - big NIS+ changes > > Maybe I'm just ignorant about the field, but is any RedHat/Fedora > user still using NIS+ instead of LDAP in corporate environments? > > I wonder whether NIS, NIS+, Hesiod and DB support in glibc could > be dropped altogether to reduce the size of Core and simplify > dependencies. > > Maybe those NSS modules could just be splitted out and moved > to Extras? Sadly, NIS is still a product of choice for a lot of environments (as ugly and insecure as it is). I dont think I have ever seen a NIS+ environment at any of the organizations I have worked at.. but that was mainly due to the 'closed' nature of it. The main reason for NIS to be used is that it really only takes 2-3 files, a couple of little edits, and poof you have it working. I am just starting to look at Fedora Directory Server and it looks like it will take a LOT more work than that to get it working (or even getting a small LDAP service that would duplicate the 3 things most people use NIS for: user accounts, centralized passwords, and email aliases) -- Stephen J Smoogen. CSIRT/Linux System Administrator From felipe.alfaro at gmail.com Wed May 24 15:30:55 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Wed, 24 May 2006 17:30:55 +0200 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <447415C0.8030300@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> Message-ID: <6f6293f10605240830w4f3bb136mb2750cdad8efcfda@mail.gmail.com> > LDAP sure isn't an easy beast to configure and run, expecially > if you need TLS and replication. Fedora Directory Server is relatively easy to set up, configure and mantain, and has a nice Java administration console. From jkeating at j2solutions.net Wed May 24 15:33:28 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 24 May 2006 11:33:28 -0400 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <6f6293f10605240830w4f3bb136mb2750cdad8efcfda@mail.gmail.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <6f6293f10605240830w4f3bb136mb2750cdad8efcfda@mail.gmail.com> Message-ID: <1148484808.2372.14.camel@ender> On Wed, 2006-05-24 at 17:30 +0200, Felipe Alfaro Solana wrote: > has a nice Java administration console. Sorry, I just can't agree with 'nice' and 'java' being used in conjunction. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kloczek at zie.pg.gda.pl Wed May 24 16:00:20 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 18:00:20 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> Message-ID: <1148486420.15113.24.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): [..] > fribidi-0.10.7-3 > ---------------- > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > - rh#192669# clearly I didn't actually get around to basing fribidi-config > of pkg-config output Instead fixing all -config scripts better will be remove them all and move all lib detections to use pkgconfig. This allow strip down entrophy on this area instead enlarging .. > glib2-2.11.1-2 > -------------- > * Mon May 22 2006 Matthias Clasen - 2.11.1-2 > - Move glib to /lib Why ? IIRC last /%{_lib}, /sbin and /bin binary which was requires glib (pam_console) was rewrited week or two ago for not use libglib. What more requires this on boot stage ? > xorg-x11-drv-apm-1.1.1-2 > ------------------------ > * Tue May 23 2006 Adam Jackson 1.1.1-2 > - Rebuild for 7.1 ABI fix. Why on all this this kind changes was not added neccessary BuildRequire rule ? kloczek From dlutter at redhat.com Wed May 24 16:01:32 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 24 May 2006 09:01:32 -0700 Subject: new project: fedora-mirror In-Reply-To: References: Message-ID: <1148486492.31059.2.camel@currant.watzmann.net> On Wed, 2006-05-10 at 21:56 +0200, Rudolf Kastl wrote: > Heres the info: > http://fedoraproject.org/wiki/Projects/fedora-mirror Have you looked at yam ? I am wondering if what you are doing could be folded into yam. I've been using yam quite happily to maintain a local mirror for myself. David From mclasen at redhat.com Wed May 24 16:03:13 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 May 2006 12:03:13 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148486420.15113.24.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> Message-ID: <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> On Wed, 2006-05-24 at 18:00 +0200, Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > [..] > > fribidi-0.10.7-3 > > ---------------- > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > of pkg-config output > > Instead fixing all -config scripts better will be remove them all > and move all lib detections to use pkgconfig. > This allow strip down entrophy on this area instead enlarging .. Thats a huge amount of work. Good luck with that. > > glib2-2.11.1-2 > > -------------- > > * Mon May 22 2006 Matthias Clasen - 2.11.1-2 > > - Move glib to /lib > > Why ? > IIRC last /%{_lib}, /sbin and /bin binary which was requires glib > (pam_console) was rewrited week or two ago for not use libglib. > What more requires this on boot stage ? initscripts From jkeating at j2solutions.net Wed May 24 16:03:18 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 24 May 2006 12:03:18 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148486420.15113.24.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> Message-ID: <1148486598.2372.18.camel@ender> On Wed, 2006-05-24 at 18:00 +0200, Tomasz K?oczko wrote: > > Why on all this this kind changes was not added neccessary > BuildRequire > rule ? It was a scripted rebuild of all the packages. Another X maintainer is working on the BuildRequires fixes. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Wed May 24 16:11:07 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 24 May 2006 12:11:07 -0400 Subject: new project: fedora-mirror In-Reply-To: <1148486492.31059.2.camel@currant.watzmann.net> References: <1148486492.31059.2.camel@currant.watzmann.net> Message-ID: <1148487068.2940.23.camel@cutter> On Wed, 2006-05-24 at 09:01 -0700, David Lutterkort wrote: > On Wed, 2006-05-10 at 21:56 +0200, Rudolf Kastl wrote: > > Heres the info: > > http://fedoraproject.org/wiki/Projects/fedora-mirror > > Have you looked at yam ? I am wondering if what you are doing could be > folded into yam. I've been using yam quite happily to maintain a local > mirror for myself. I've always thought yam reaches way too far in what it does. The point of fedora-mirror is just to make it easier for non-mirrors to easily mirror the distro. yam does some neat things but it's just too much. less code is good :) -sv From docs-list at fedoralinks.org Wed May 24 16:07:55 2006 From: docs-list at fedoralinks.org (Robert 'Bob' Jensen) Date: Wed, 24 May 2006 11:07:55 -0500 Subject: question about creation of updated DVD iso In-Reply-To: <1148463903.19549.74.camel@linux> References: <561c252c0605160926n3f7db9f5r6b3347b363f9d51a@mail.gmail.com> <1148392634.25908.29.camel@saugart-t41.mazunetworks.com> <1148461579.19549.57.camel@linux> <1148461951.4310.570.camel@sundaram.pnq.redhat.com> <1148463903.19549.74.camel@linux> Message-ID: <447484DB.9030200@fedoralinks.org> Hans Kristian Rosbach wrote: > > Yes, so they claim. However I have not been able to locate > much info about these isos. > > I also don't know whether they use the official FC5 anaconda rpm > (with its bugs) or their own rebuild of it. And if it is a "private" > rebuild, I just don't like the idea as it raises a lot of concerns. > > Oh, and I'll have to correct my previous statement. I met a lot > of cooperation from Rahul, and I am very thankful for that. > Unfortunately we could not resolve the problems (see previous threads) > by ourself. > > > I will most likely make private respins for use in-house, just like > what we had planned the FC4 ones to be. We have a pretty strict > policy about knowing the origins and details of packages. > > -HK > Hans, Yes right now our re-spins are *private* until testing can be completed. We are using a slightly modified testing matrix that was used by Release Engineering to make sure the ISOs are of a quality that deserves the Fedora name. If you are interested in contributing to our effort feel free to contact me. -- Robert 'Bob' Jensen * * http://fedoraproject.org/wiki/BobJensen gpg fingerprint: F9F4 7243 4243 0043 2C45 97AF E8A4 C3AE 42EB 0BC6 Fedora Docs Projects FDSCo http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Wed May 24 16:15:05 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 12:15:05 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148486420.15113.24.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> Message-ID: <20060524161505.GE22172@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > [..] > > fribidi-0.10.7-3 > > ---------------- > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > of pkg-config output > > Instead fixing all -config scripts better will be remove them all > and move all lib detections to use pkgconfig. > This allow strip down entrophy on this area instead enlarging .. That would require patching all *upstream* users of library to change their configury, which could involve redoing all of their auto* files. It's not a 'small' amount of work. Bill From david at lovesunix.net Wed May 24 16:16:11 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 24 May 2006 18:16:11 +0200 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <1148484808.2372.14.camel@ender> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <6f6293f10605240830w4f3bb136mb2750cdad8efcfda@mail.gmail.com> <1148484808.2372.14.camel@ender> Message-ID: <1148487371.2581.3.camel@localhost.localdomain> ons, 24 05 2006 kl. 11:33 -0400, skrev Jesse Keating: > On Wed, 2006-05-24 at 17:30 +0200, Felipe Alfaro Solana wrote: > > has a nice Java administration console. > > Sorry, I just can't agree with 'nice' and 'java' being used in > conjunction. Quoted for truth. I have yet to see a Java application which didn't redefine the term ugly in a new and hidious way. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From rc040203 at freenet.de Wed May 24 16:24:12 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 24 May 2006 18:24:12 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524161505.GE22172@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> Message-ID: <1148487853.882.377.camel@mccallum.corsepiu.local> On Wed, 2006-05-24 at 12:15 -0400, Bill Nottingham wrote: > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > [..] > > > fribidi-0.10.7-3 > > > ---------------- > > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > > of pkg-config output > > > > Instead fixing all -config scripts better will be remove them all > > and move all lib detections to use pkgconfig. > > This allow strip down entrophy on this area instead enlarging .. > > That would require patching all *upstream* users of library > to change their configury, which could involve redoing all of their > auto* files. It's not a 'small' amount of work. In many cases, it's trivial to add pkgconfig files (if upstream doesn't) and to rewrite -config scripts as wrappers to pkgconfig. Whether this makes sense and has a long term perspective, are different matters. Ralf From notting at redhat.com Wed May 24 16:28:27 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 12:28:27 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148487853.882.377.camel@mccallum.corsepiu.local> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148487853.882.377.camel@mccallum.corsepiu.local> Message-ID: <20060524162827.GG22172@nostromo.devel.redhat.com> Ralf Corsepius (rc040203 at freenet.de) said: > > > Instead fixing all -config scripts better will be remove them all > > > and move all lib detections to use pkgconfig. > > > This allow strip down entrophy on this area instead enlarging .. > > > > That would require patching all *upstream* users of library > > to change their configury, which could involve redoing all of their > > auto* files. It's not a 'small' amount of work. > In many cases, it's trivial to add pkgconfig files (if upstream doesn't) > and to rewrite -config scripts as wrappers to pkgconfig. > > Whether this makes sense and has a long term perspective, are different > matters. Exactly, that's what this change was. Tomasz was suggesting just removing the foo-config scripts. Bill From kloczek at zie.pg.gda.pl Wed May 24 16:31:20 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 18:31:20 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> Message-ID: <1148488280.15113.28.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 12:03 -0400, Matthias Clasen napisa?(a): > On Wed, 2006-05-24 at 18:00 +0200, Tomasz K?oczko wrote: > > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > [..] > > > fribidi-0.10.7-3 > > > ---------------- > > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > > of pkg-config output > > > > Instead fixing all -config scripts better will be remove them all > > and move all lib detections to use pkgconfig. > > This allow strip down entrophy on this area instead enlarging .. > > Thats a huge amount of work. Good luck with that. Probably not so big because now in most cases is used pkgconfig. It must be ten or less packages (simillar number to now neccessary -config fix). > > > glib2-2.11.1-2 > > > -------------- > > > * Mon May 22 2006 Matthias Clasen - 2.11.1-2 > > > - Move glib to /lib > > > > Why ? > > IIRC last /%{_lib}, /sbin and /bin binary which was requires glib > > (pam_console) was rewrited week or two ago for not use libglib. > > What more requires this on boot stage ? > > initscripts Where ? $ rpm -q --qf "[%{REQUIRENAME}\n]" initscripts | grep lib libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) rpmlib(CompressedFileNames) rpmlib(PayloadFilesHavePrefix) kloczek From notting at redhat.com Wed May 24 16:37:52 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 12:37:52 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148488280.15113.28.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> Message-ID: <20060524163752.GK22172@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > > > glib2-2.11.1-2 > > > > -------------- > > > > * Mon May 22 2006 Matthias Clasen - 2.11.1-2 > > > > - Move glib to /lib > > > > > > Why ? > > > IIRC last /%{_lib}, /sbin and /bin binary which was requires glib > > > (pam_console) was rewrited week or two ago for not use libglib. > > > What more requires this on boot stage ? > > > > initscripts > > Where ? > > $ rpm -q --qf "[%{REQUIRENAME}\n]" initscripts | grep lib > libc.so.6()(64bit) > libc.so.6(GLIBC_2.2.5)(64bit) > libc.so.6(GLIBC_2.3)(64bit) > libc.so.6(GLIBC_2.3.4)(64bit) > libc.so.6(GLIBC_2.4)(64bit) > rpmlib(CompressedFileNames) > rpmlib(PayloadFilesHavePrefix) It was linked statically. Static glib libs went away, so.... Bill From kloczek at zie.pg.gda.pl Wed May 24 16:41:36 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 18:41:36 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524161505.GE22172@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> Message-ID: <1148488896.15113.33.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 12:15 -0400, Bill Nottingham napisa?(a): > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > [..] > > > fribidi-0.10.7-3 > > > ---------------- > > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > > of pkg-config output > > > > Instead fixing all -config scripts better will be remove them all > > and move all lib detections to use pkgconfig. > > This allow strip down entrophy on this area instead enlarging .. > > That would require patching all *upstream* users of library > to change their configury, which could involve redoing all of their > auto* files. It's not a 'small' amount of work. And what is so problematic in make this as "this feacture will be disscontinued in FC6 ?" Again: on strict distribution packages set amout of work is compareable but just introduced way allow continue to grow entrophy .. probably this way will create in future more cases for fixing. Why not cut this now ? kloczek From txtoth at gmail.com Wed May 24 16:42:51 2006 From: txtoth at gmail.com (Xavier Toth) Date: Wed, 24 May 2006 11:42:51 -0500 Subject: Fwd: kernel 'make rpm', kadischi and kernel version disconnect In-Reply-To: References: <1147536530.3217.9.camel@laptopd505.fenrus.org> Message-ID: I built a livecd that boots and runs from a src rpm (lspp.27) but I had to hack lib/functions.py get_kernel_version() so that it didn't append the release number to the kernel. Maybe Kadischi could check for the directory with the release number and if it doesn't find it check for a directory without the release number since it happens that the kernel 'make rpm' doesn't use the release number. On 5/13/06, Xavier Toth wrote: > Yes, I'm using a fedora src.rpm but the build contains a script named mkspec > which the build uses to generate kernel.spec. > > > On 5/13/06, Arjan van de Ven < arjan at fenrus.demon.nl> wrote: > > On Sat, 2006-05-13 at 14:20 +0000, Xavier Toth wrote: > > > I'm hoping someone on this list will have some thoughts related to > > > this problem. > > > > > > I assume you build this rpm using the fedora src.rpm and specfile? > > Because if not then you really should... ;) > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > From rc040203 at freenet.de Wed May 24 16:43:58 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 24 May 2006 18:43:58 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524162827.GG22172@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148487853.882.377.camel@mccallum.corsepiu.local> <20060524162827.GG22172@nostromo.devel.redhat.com> Message-ID: <1148489039.882.380.camel@mccallum.corsepiu.local> On Wed, 2006-05-24 at 12:28 -0400, Bill Nottingham wrote: > Ralf Corsepius (rc040203 at freenet.de) said: > > > > Instead fixing all -config scripts better will be remove them all > > > > and move all lib detections to use pkgconfig. > > > > This allow strip down entrophy on this area instead enlarging .. > > > > > > That would require patching all *upstream* users of library > > > to change their configury, which could involve redoing all of their > > > auto* files. It's not a 'small' amount of work. > > In many cases, it's trivial to add pkgconfig files (if upstream doesn't) > > and to rewrite -config scripts as wrappers to pkgconfig. > > > > Whether this makes sense and has a long term perspective, are different > > matters. > > Exactly, that's what this change was. Tomasz was suggesting just > removing the foo-config scripts. OK, of cause, the latter is not an option unless upstream doesn't. Ralf From kloczek at zie.pg.gda.pl Wed May 24 16:47:09 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 18:47:09 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148487853.882.377.camel@mccallum.corsepiu.local> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148487853.882.377.camel@mccallum.corsepiu.local> Message-ID: <1148489229.15113.39.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 18:24 +0200, Ralf Corsepius napisa?(a): > On Wed, 2006-05-24 at 12:15 -0400, Bill Nottingham wrote: > > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > > [..] > > > > fribidi-0.10.7-3 > > > > ---------------- > > > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > > > of pkg-config output > > > > > > Instead fixing all -config scripts better will be remove them all > > > and move all lib detections to use pkgconfig. > > > This allow strip down entrophy on this area instead enlarging .. > > > > That would require patching all *upstream* users of library > > to change their configury, which could involve redoing all of their > > auto* files. It's not a 'small' amount of work. > In many cases, it's trivial to add pkgconfig files (if upstream doesn't) > and to rewrite -config scripts as wrappers to pkgconfig. > > Whether this makes sense and has a long term perspective, are different > matters. IMO not because after introducing this all packages which provides -config scripts must additionaly depents on pkgconfig tool .. look this next set of things which enlarges enthropy. Now pkgconfig dependency is build stage (BuildRequires). After this it will change it to install some *-devel packages stage. kloczek From notting at redhat.com Wed May 24 16:44:50 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 12:44:50 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148488896.15113.33.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> Message-ID: <20060524164450.GL22172@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > And what is so problematic in make this as "this feacture will be > disscontinued in FC6 ?" > Again: on strict distribution packages set amout of work is compareable > but just introduced way allow continue to grow entrophy .. probably this > way will create in future more cases for fixing. > Why not cut this now ? Because you're nuts. :) Seriously, you will then have reports from lots of users - "this software doesn't build on Fedora! Fedora sucks, I'm using Ubuntu." Upstream maintainers who don't care about these things will just pile on, saying "Why use Fedora? This is just like gcc-2.96 all over again." If we want to have the foo-config scripts warn, sure. Possibly even patch our own Core & Extras packages. But randomly breaking third-party software so it won't build isn't really practical. Bill From rc040203 at freenet.de Wed May 24 16:48:47 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 24 May 2006 18:48:47 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148488896.15113.33.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> Message-ID: <1148489327.882.384.camel@mccallum.corsepiu.local> On Wed, 2006-05-24 at 18:41 +0200, Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 12:15 -0400, Bill Nottingham napisa?(a): > > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > > [..] > > > > fribidi-0.10.7-3 > > > > ---------------- > > > > * Tue May 23 2006 Caolan McNamara 0.10.7-3 > > > > - rh#192669# clearly I didn't actually get around to basing fribidi-config > > > > of pkg-config output > > > > > > Instead fixing all -config scripts better will be remove them all > > > and move all lib detections to use pkgconfig. > > > This allow strip down entrophy on this area instead enlarging .. > > > > That would require patching all *upstream* users of library > > to change their configury, which could involve redoing all of their > > auto* files. It's not a 'small' amount of work. > > And what is so problematic in make this as "this feacture will be > disscontinued in FC6 ?" It would mean implementing a Fedora proprietary breakage of package's API - This can't be in Fedora's interest. Ralf From kloczek at zie.pg.gda.pl Wed May 24 16:55:03 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 18:55:03 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524163752.GK22172@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> Message-ID: <1148489703.15113.48.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 12:37 -0400, Bill Nottingham napisa?(a): [..] > It was linked statically. Static glib libs went away, so.... OK. Next round .. why have (literaly) *one* binary (ppp-watch) which uses now shared libglib must affect glib ? Is not better rewrite this tool for not use glib ? or what so big performs ppp-watch where using glib is neccessary ? is it realy so hard rewrite this for not use glib ? kloczek PS. remember: fixing some bad things by introduce some way less ass pain way is *most* worse way of development :> Better is rest this kind things in current form and add them to TODO list. From mclasen at redhat.com Wed May 24 16:57:17 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 May 2006 12:57:17 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148489703.15113.48.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> Message-ID: <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> On Wed, 2006-05-24 at 18:55 +0200, Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 12:37 -0400, Bill Nottingham napisa?(a): > [..] > > It was linked statically. Static glib libs went away, so.... > > OK. Next round .. why have (literaly) *one* binary (ppp-watch) which > uses now shared libglib must affect glib ? > Is not better rewrite this tool for not use glib ? or what so big > performs ppp-watch where using glib is neccessary ? is it realy so hard > rewrite this for not use glib ? > > kloczek > PS. remember: fixing some bad things by introduce some way less ass pain > way is *most* worse way of development :> > Better is rest this kind things in current form and add them to TODO > list. > What problem do you have with glib in /lib ? From notting at redhat.com Wed May 24 16:56:48 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 12:56:48 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148489703.15113.48.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> Message-ID: <20060524165648.GA25102@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > Dnia 24-05-2006, ?ro o godzinie 12:37 -0400, Bill Nottingham napisa?(a): > [..] > > It was linked statically. Static glib libs went away, so.... > > OK. Next round .. why have (literaly) *one* binary (ppp-watch) which > uses now shared libglib must affect glib ? > Is not better rewrite this tool for not use glib ? or what so big > performs ppp-watch where using glib is neccessary ? is it realy so hard > rewrite this for not use glib ? How does glib in /lib change things in a bad way? (Realistically, by having it shared in PAM, etc., it saves memory....) This also enables using other things earlier in the boot process, such as d-bus, hal, NM, etc. Bill From ajackson at redhat.com Wed May 24 15:56:56 2006 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 24 May 2006 11:56:56 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148486598.2372.18.camel@ender> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486598.2372.18.camel@ender> Message-ID: <44748248.1030409@redhat.com> Jesse Keating wrote: > On Wed, 2006-05-24 at 18:00 +0200, Tomasz K?oczko wrote: >> Why on all this this kind changes was not added neccessary >> BuildRequire >> rule ? > > It was a scripted rebuild of all the packages. Another X maintainer is > working on the BuildRequires fixes. Technically it should be a full Requires too, the 1.0.99.90x packages have broken ABIs. Clearly I just neglected to do it. I'll hit this in the next day or so. - ajax From tmraz at redhat.com Wed May 24 16:58:49 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 24 May 2006 18:58:49 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148486420.15113.24.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> Message-ID: <1148489929.9552.9.camel@perun.kabelta.loc> On Wed, 2006-05-24 at 18:00 +0200, Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > glib2-2.11.1-2 > > -------------- > > * Mon May 22 2006 Matthias Clasen - 2.11.1-2 > > - Move glib to /lib > > Why ? > IIRC last /%{_lib}, /sbin and /bin binary which was requires glib > (pam_console) was rewrited week or two ago for not use libglib. > What more requires this on boot stage ? Heh I could save a little amount of work if I knew that. -- Tomas Mraz From mclasen at redhat.com Wed May 24 17:01:09 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 May 2006 13:01:09 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148489929.9552.9.camel@perun.kabelta.loc> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148489929.9552.9.camel@perun.kabelta.loc> Message-ID: <1148490069.13737.6.camel@dhcp83-64.boston.redhat.com> On Wed, 2006-05-24 at 18:58 +0200, Tomas Mraz wrote: > On Wed, 2006-05-24 at 18:00 +0200, Tomasz K?oczko wrote: > > Dnia 24-05-2006, ?ro o godzinie 03:54 -0400, Build System napisa?(a): > > > > glib2-2.11.1-2 > > > -------------- > > > * Mon May 22 2006 Matthias Clasen - 2.11.1-2 > > > - Move glib to /lib > > > > Why ? > > IIRC last /%{_lib}, /sbin and /bin binary which was requires glib > > (pam_console) was rewrited week or two ago for not use libglib. > > What more requires this on boot stage ? > > Heh I could save a little amount of work if I knew that. Yes, thats my fault. Sorry about that... From kloczek at zie.pg.gda.pl Wed May 24 17:02:07 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 19:02:07 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524164450.GL22172@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> Message-ID: <1148490127.15113.56.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 12:44 -0400, Bill Nottingham napisa?(a): > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > And what is so problematic in make this as "this feacture will be > > disscontinued in FC6 ?" > > Again: on strict distribution packages set amout of work is compareable > > but just introduced way allow continue to grow entrophy .. probably this > > way will create in future more cases for fixing. > > Why not cut this now ? > > Because you're nuts. :) > > Seriously, you will then have reports from lots of users - > "this software doesn't build on Fedora! Fedora sucks, I'm using > Ubuntu." Upstream maintainers who don't care about these things > will just pile on, saying "Why use Fedora? This is just like > gcc-2.96 all over again." write patch for remove -config script -> introduce this in distro resources and in the same moment submit this to package maintainer with some technical argumentation "why it will good remove this" (one reason we know .. it is bad multilib behavior) for include this in main source tree. > If we want to have the foo-config scripts warn, sure. Possibly > even patch our own Core & Extras packages. But randomly breaking > third-party software so it won't build isn't really practical. I'm start from fribidi. OK. Lets look on some facts. Where it library is used ? abiword ? (in all other cases applications are using fibidi embeded in pango) huh .. where in this case is *real* problem ? kloczek From mclasen at redhat.com Wed May 24 17:14:19 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 May 2006 13:14:19 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148490127.15113.56.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> Message-ID: <1148490859.13737.8.camel@dhcp83-64.boston.redhat.com> On Wed, 2006-05-24 at 19:02 +0200, Tomasz K?oczko wrote: > I'm start from fribidi. OK. Lets look on some facts. Where it library is > used ? abiword ? (in all other cases applications are using fibidi > embeded in pango) huh .. where in this case is *real* problem ? I think thats the question you have to answer... From kloczek at zie.pg.gda.pl Wed May 24 17:18:47 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 19:18:47 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> Message-ID: <1148491127.15113.71.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 12:57 -0400, Matthias Clasen napisa?(a): > On Wed, 2006-05-24 at 18:55 +0200, Tomasz K?oczko wrote: > > Dnia 24-05-2006, ?ro o godzinie 12:37 -0400, Bill Nottingham napisa?(a): > > [..] > > > It was linked statically. Static glib libs went away, so.... > > > > OK. Next round .. why have (literaly) *one* binary (ppp-watch) which > > uses now shared libglib must affect glib ? > > Is not better rewrite this tool for not use glib ? or what so big > > performs ppp-watch where using glib is neccessary ? is it realy so hard > > rewrite this for not use glib ? > > > > kloczek > > PS. remember: fixing some bad things by introduce some way less ass pain > > way is *most* worse way of development :> > > Better is rest this kind things in current form and add them to TODO > > list. > > > > What problem do you have with glib in /lib ? OK .. let me allow use your way of thinking: why not move more libraries from %{_libdir} to /%{_lib} ? :) A: because it enlarges minimal boot image (if you do not know RH/Fedora are used *directly* in many embeded systems aplyances). Correct way of decide case like this is using some siple logic technics like by make some sentence false and prove then or not. In this case .. can you prove "moving glib to %{_lib} is correct" ? Sorry but personaly I don't see real reasons for enlarge minimal boot image. Maybe you .. (?) kloczek From kloczek at zie.pg.gda.pl Wed May 24 17:27:40 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 19:27:40 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148490859.13737.8.camel@dhcp83-64.boston.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> <1148490859.13737.8.camel@dhcp83-64.boston.redhat.com> Message-ID: <1148491660.15113.78.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 13:14 -0400, Matthias Clasen napisa?(a): > On Wed, 2006-05-24 at 19:02 +0200, Tomasz K?oczko wrote: > > > I'm start from fribidi. OK. Lets look on some facts. Where it library is > > used ? abiword ? (in all other cases applications are using fibidi > > embeded in pango) huh .. where in this case is *real* problem ? > > I think thats the question you have to answer... Of course .. I just check abiword source tree for find how fribidi is detected. In abi/ac-helpers/abi-fribidi.m4 you can find line: PKG_CHECK_MODULES(FRIBIDI,[fribidi >= 0.10.4],[ In case libIDL or any other GNOME realated if anything still uses -config scripts fix for use directly pkgconfig probably will be very welcome by maitainers. All this (probably only few) cases cant be easy cached if -config scripts sill will be provided. kloczek From law at redhat.com Wed May 24 17:26:18 2006 From: law at redhat.com (Jeffrey A Law) Date: Wed, 24 May 2006 11:26:18 -0600 Subject: rawhide report: 20060524 changes In-Reply-To: <1148491127.15113.71.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> <1148491127.15113.71.camel@kloczek01.pracownicy.zie> Message-ID: <1148491578.21041.673.camel@fuel98> On Wed, 2006-05-24 at 19:18 +0200, Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 12:57 -0400, Matthias Clasen napisa?(a): > > On Wed, 2006-05-24 at 18:55 +0200, Tomasz K?oczko wrote: > > > Dnia 24-05-2006, ?ro o godzinie 12:37 -0400, Bill Nottingham napisa?(a): > > > [..] > > > > It was linked statically. Static glib libs went away, so.... > > > > > > OK. Next round .. why have (literaly) *one* binary (ppp-watch) which > > > uses now shared libglib must affect glib ? > > > Is not better rewrite this tool for not use glib ? or what so big > > > performs ppp-watch where using glib is neccessary ? is it realy so hard > > > rewrite this for not use glib ? > > > > > > kloczek > > > PS. remember: fixing some bad things by introduce some way less ass pain > > > way is *most* worse way of development :> > > > Better is rest this kind things in current form and add them to TODO > > > list. > > > > > > > What problem do you have with glib in /lib ? > > OK .. let me allow use your way of thinking: why not move more libraries > from %{_libdir} to /%{_lib} ? :) > A: because it enlarges minimal boot image (if you do not know RH/Fedora > are used *directly* in many embeded systems aplyances). > > Correct way of decide case like this is using some siple logic technics > like by make some sentence false and prove then or not. In this case .. > can you prove "moving glib to %{_lib} is correct" ? > Sorry but personaly I don't see real reasons for enlarge minimal boot > image. Maybe you .. (?) It seems to me that for these embedded systems that you probably don't want glib, NetworkManager, etc at all. So you just don't include them in your image in any way shape or form. Thus it doesn't matter if it's in /lib or /usr/lib. jeff From mclasen at redhat.com Wed May 24 17:35:33 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 May 2006 13:35:33 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148491127.15113.71.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> <1148491127.15113.71.camel@kloczek01.pracownicy.zie> Message-ID: <1148492133.13737.10.camel@dhcp83-64.boston.redhat.com> On Wed, 2006-05-24 at 19:18 +0200, Tomasz K?oczko wrote: > OK .. let me allow use your way of thinking: why not move more libraries > from %{_libdir} to /%{_lib} ? :) > A: because it enlarges minimal boot image (if you do not know RH/Fedora > are used *directly* in many embeded systems aplyances). > > Correct way of decide case like this is using some siple logic technics > like by make some sentence false and prove then or not. In this case .. > can you prove "moving glib to %{_lib} is correct" ? > Sorry but personaly I don't see real reasons for enlarge minimal boot > image. Maybe you .. (?) See, glib was already there...just statically linked. From j.w.r.degoede at hhs.nl Wed May 24 17:41:10 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 24 May 2006 19:41:10 +0200 Subject: Future Fedora Development In-Reply-To: <20060524150805.GC1186624@hiwaay.net> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> <20060524150805.GC1186624@hiwaay.net> Message-ID: <44749AB6.4010107@hhs.nl> Chris Adams wrote: > Once upon a time, Bernardo Innocenti said: >> What's wrong with GPL programs using the Mozilla implementation? >> Last time I checked NSS was totally GPL compatible. > > mozilla-nss requires mozilla-nspr. libnss3.so also pulls in > libpthread.so. Those are pretty heavy requirements for SSL. Erm, won't atleast libpthread be installed and probably also memory resident (remember they are Shared Objects) on almost any real world setup? Regards, Hans From kloczek at zie.pg.gda.pl Wed May 24 17:43:53 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 19:43:53 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <1148491578.21041.673.camel@fuel98> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> <1148491127.15113.71.camel@kloczek01.pracownicy.zie> <1148491578.21041.673.camel@fuel98> Message-ID: <1148492633.15113.91.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 11:26 -0600, Jeffrey A Law napisa?(a): [..] > It seems to me that for these embedded systems that you probably > don't want glib, NetworkManager, etc at all. In this case you can't remove some components without breaking some dependencies. Again .. we are not talk about "some system" instalation but about strict/minimal boot image. Please use this fact and continue if you still can .. kloczek From nicolas.mailhot at laposte.net Wed May 24 17:52:07 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 24 May 2006 19:52:07 +0200 Subject: Future Fedora Development In-Reply-To: <200605241233.31667.billcrawford1970@googlemail.com> References: <44701330.4030807@ntlworld.com> <16de708d0605240139n2e4b281bk85bb85683b500b1b@mail.gmail.com> <200605241233.31667.billcrawford1970@googlemail.com> Message-ID: <1148493130.28814.1.camel@rousalka.dyndns.org> Le mercredi 24 mai 2006 ? 12:33 +0100, Bill Crawford a ?crit : > Le Mercredi 24 Mai 2006 09:39, Arthur Pemberton a ?crit : > > > Understandable, but I would assume that older hardware is also less > > energy efficient. > > While this may be true, the overall power consumption of "modern" kit while > in use is much higher than older machines, so for something that sees a lot > of use, the "efficiency" issue is a bit of a red herring. Actually if you take a two-three year old P4 system and compare it to a new amd64 system I doubt the P4 system will win the consumption comparison. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From j.w.r.degoede at hhs.nl Wed May 24 18:05:39 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 24 May 2006 20:05:39 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44721137.2010806@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> Message-ID: <4474A073.6070904@hhs.nl> Mike A. Harris wrote: > - Run ntsysv (or equivalent) and disable the xfs service from > starting at boot time. > > - Run "service xfs stop" to shut down xfs > > - Edit xorg.conf and comment out the unix:/7100 font path. > Add a FontPath that points to the "misc" font directory. > > - Start the X server. It should start correctly as long as you > have properly configured the misc font path, as it will then > still be able to find "fixed" and "cursor". > > I've done this and I've just hit my first bug, should we file these in BZ starting with some kinda disclaimer that we did the above? Anyways "display" from ImageMagick no longer works, which is kinda PITA, since I'm trying to view some .rgb files and more modern tools try to read them as wmf which they are not and unsurprisingly thus fail. Doing a "xset fp+ /usr/share/X11/fonts/75dpi" unsurprisingly fixes the issue. I believe quite a few of the other trouble reports sofar where about helvetica too, maybe we should move helvetica to misc (ugly hack, but still) ? Regards, Hans From notting at redhat.com Wed May 24 18:26:07 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 14:26:07 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148491127.15113.71.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> <1148491127.15113.71.camel@kloczek01.pracownicy.zie> Message-ID: <20060524182607.GA25483@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > Correct way of decide case like this is using some siple logic technics > like by make some sentence false and prove then or not. In this case .. > can you prove "moving glib to %{_lib} is correct" ? > Sorry but personaly I don't see real reasons for enlarge minimal boot > image. Maybe you .. (?) Because, since it was linked statically into 5 or 6 things before, it may well be decreasing the size? Bill From che666 at gmail.com Wed May 24 18:29:24 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 24 May 2006 20:29:24 +0200 Subject: new project: fedora-mirror In-Reply-To: <1148487068.2940.23.camel@cutter> References: <1148486492.31059.2.camel@currant.watzmann.net> <1148487068.2940.23.camel@cutter> Message-ID: 2006/5/24, seth vidal : > On Wed, 2006-05-24 at 09:01 -0700, David Lutterkort wrote: > > On Wed, 2006-05-10 at 21:56 +0200, Rudolf Kastl wrote: > > > Heres the info: > > > http://fedoraproject.org/wiki/Projects/fedora-mirror > > > > Have you looked at yam ? I am wondering if what you are doing could be > > folded into yam. I've been using yam quite happily to maintain a local > > mirror for myself. > > I've always thought yam reaches way too far in what it does. The point > of fedora-mirror is just to make it easier for non-mirrors to easily > mirror the distro. > > yam does some neat things but it's just too much. > > less code is good :) > > -sv thats exactly my goal... less code and one tool for one single goal. also its using the reposync backend of skvidal already in core. actually the code online on the site is not the latest build. the next update will probably already fix 90% of the todo list yet mentioned. regards, Rudolf Kastl > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From notting at redhat.com Wed May 24 18:29:09 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 14:29:09 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148490127.15113.56.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> Message-ID: <20060524182909.GB25483@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > Seriously, you will then have reports from lots of users - > > "this software doesn't build on Fedora! Fedora sucks, I'm using > > Ubuntu." Upstream maintainers who don't care about these things > > will just pile on, saying "Why use Fedora? This is just like > > gcc-2.96 all over again." > > write patch for remove -config script -> introduce this in distro > resources and in the same moment submit this to package maintainer > with some technical argumentation "why it will good remove this" (one > reason we know .. it is bad multilib behavior) for include this in main > source tree. That doesn't help those packages' users, which is the whole point. > > If we want to have the foo-config scripts warn, sure. Possibly > > even patch our own Core & Extras packages. But randomly breaking > > third-party software so it won't build isn't really practical. > > I'm start from fribidi. OK. Lets look on some facts. Where it library is > used ? abiword ? (in all other cases applications are using fibidi > embeded in pango) huh .. where in this case is *real* problem ? All other cases? Do you know the extent of all fribidi using software that exists (not just Core/Extras)? Bill From kloczek at zie.pg.gda.pl Wed May 24 18:41:54 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 20:41:54 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524182909.GB25483@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> <20060524182909.GB25483@nostromo.devel.redhat.com> Message-ID: <1148496114.15113.100.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 14:29 -0400, Bill Nottingham napisa?(a): [..] > > > If we want to have the foo-config scripts warn, sure. Possibly > > > even patch our own Core & Extras packages. But randomly breaking > > > third-party software so it won't build isn't really practical. > > > > I'm start from fribidi. OK. Lets look on some facts. Where it library is > > used ? abiword ? (in all other cases applications are using fibidi > > embeded in pango) huh .. where in this case is *real* problem ? > > All other cases? Do you know the extent of all fribidi using > software that exists (not just Core/Extras)? One in core: wordtrans. One in extras: abiword. In case abiword for detecting is used pkgconfig. In case wordtrans there is no detections. BTW wordtrans: instead useless fixing fribidi-config better will be help fixing wordtrans for not use fribidi (by use pango). kloczek From kloczek at zie.pg.gda.pl Wed May 24 18:43:51 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 20:43:51 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524182607.GA25483@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> <1148491127.15113.71.camel@kloczek01.pracownicy.zie> <20060524182607.GA25483@nostromo.devel.redhat.com> Message-ID: <1148496231.15113.102.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 14:26 -0400, Bill Nottingham napisa?(a): > Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > > Correct way of decide case like this is using some siple logic technics > > like by make some sentence false and prove then or not. In this case .. > > can you prove "moving glib to %{_lib} is correct" ? > > Sorry but personaly I don't see real reasons for enlarge minimal boot > > image. Maybe you .. (?) > > Because, since it was linked statically into 5 or 6 things before, > it may well be decreasing the size? Sorry but I see only increase .. boot image. kloczek From rdieter at math.unl.edu Wed May 24 18:44:36 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 24 May 2006 13:44:36 -0500 Subject: rawhide report: 20060524 changes References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <1148486593.13737.2.camel@dhcp83-64.boston.redhat.com> <1148488280.15113.28.camel@kloczek01.pracownicy.zie> <20060524163752.GK22172@nostromo.devel.redhat.com> <1148489703.15113.48.camel@kloczek01.pracownicy.zie> <1148489837.13737.4.camel@dhcp83-64.boston.redhat.com> <1148491127.15113.71.camel@kloczek01.pracownicy.zie> <20060524182607.GA25483@nostromo.devel.redhat.com> <1148496231.15113.102.camel@kloczek01.pracownicy.zie> Message-ID: Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 14:26 -0400, Bill Nottingham napisa?(a): >> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: >> > Correct way of decide case like this is using some siple logic technics >> > like by make some sentence false and prove then or not. In this case .. >> > can you prove "moving glib to %{_lib} is correct" ? >> > Sorry but personaly I don't see real reasons for enlarge minimal boot >> > image. Maybe you .. (?) >> >> Because, since it was linked statically into 5 or 6 things before, >> it may well be decreasing the size? > > Sorry but I see only increase .. boot image. And I'm sure you have the #'s to back up your assertion? -- Rex From notting at redhat.com Wed May 24 18:46:53 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 May 2006 14:46:53 -0400 Subject: rawhide report: 20060524 changes In-Reply-To: <1148496114.15113.100.camel@kloczek01.pracownicy.zie> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> <20060524182909.GB25483@nostromo.devel.redhat.com> <1148496114.15113.100.camel@kloczek01.pracownicy.zie> Message-ID: <20060524184653.GA25823@nostromo.devel.redhat.com> Tomasz K?oczko (kloczek at zie.pg.gda.pl) said: > Dnia 24-05-2006, ?ro o godzinie 14:29 -0400, Bill Nottingham napisa?(a): > [..] > > > > If we want to have the foo-config scripts warn, sure. Possibly > > > > even patch our own Core & Extras packages. But randomly breaking > > > > third-party software so it won't build isn't really practical. > > > > > > I'm start from fribidi. OK. Lets look on some facts. Where it library is > > > used ? abiword ? (in all other cases applications are using fibidi > > > embeded in pango) huh .. where in this case is *real* problem ? > > > > All other cases? Do you know the extent of all fribidi using > > software that exists (not just Core/Extras)? > > One in core: wordtrans. One in extras: abiword. > In case abiword for detecting is used pkgconfig. > In case wordtrans there is no detections. > BTW wordtrans: instead useless fixing fribidi-config better will be help > fixing wordtrans for not use fribidi (by use pango). No offense, but you missed the point. It's not about core and extras. It's about the entire universe of software who autoconfed against m4 files that call -config. We can't fix the stuff we can't ship; all we can do by changing this is break them. Bill From rdieter at math.unl.edu Wed May 24 18:46:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 24 May 2006 13:46:04 -0500 Subject: rawhide report: 20060524 changes References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> <20060524182909.GB25483@nostromo.devel.redhat.com> <1148496114.15113.100.camel@kloczek01.pracownicy.zie> Message-ID: Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 14:29 -0400, Bill Nottingham napisa?(a): > [..] >> > > If we want to have the foo-config scripts warn, sure. Possibly >> > > even patch our own Core & Extras packages. But randomly breaking >> > > third-party software so it won't build isn't really practical. >> > >> > I'm start from fribidi. OK. Lets look on some facts. Where it library >> > is used ? abiword ? (in all other cases applications are using fibidi >> > embeded in pango) huh .. where in this case is *real* problem ? >> >> All other cases? Do you know the extent of all fribidi using >> software that exists (not just Core/Extras)? > > One in core: wordtrans. One in extras: abiword. You know what? It doesn't matter. Get upstream to drop foo-config, and so will Fedora. It's as easy as that. -- Rex From linux_4ever at yahoo.com Wed May 24 18:51:01 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 24 May 2006 11:51:01 -0700 (PDT) Subject: Future Fedora Development In-Reply-To: <4474129A.5050201@develer.com> Message-ID: <20060524185101.82743.qmail@web51502.mail.yahoo.com> >> - multiple digests operation (openssl, gnutls, nss .. some programs are >> now linked with *all* avalaible implemntations 8-0 ), > >Yeah, I agree. OpenSSL seems to be the most comprehensive, but >its licence stinks and this is why gnutls was written in the first >place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, >there's no reason to keep gnutls any more. We need to try to streamline the number of SSL implementations for another reason, FIPS 140-2 certifications. I think that FIPS 200 will be applicable next year which pulls in the requirement of all crypto being certified. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sundaram at fedoraproject.org Wed May 24 18:54:38 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 May 2006 00:24:38 +0530 Subject: Future Fedora Development In-Reply-To: <20060524185101.82743.qmail@web51502.mail.yahoo.com> References: <20060524185101.82743.qmail@web51502.mail.yahoo.com> Message-ID: <1148496878.4310.600.camel@sundaram.pnq.redhat.com> On Wed, 2006-05-24 at 11:51 -0700, Steve G wrote: > >> - multiple digests operation (openssl, gnutls, nss .. some programs are > >> now linked with *all* avalaible implemntations 8-0 ), > > > >Yeah, I agree. OpenSSL seems to be the most comprehensive, but > >its licence stinks and this is why gnutls was written in the first > >place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, > >there's no reason to keep gnutls any more. > > We need to try to streamline the number of SSL implementations for another > reason, FIPS 140-2 certifications. I think that FIPS 200 will be applicable next > year which pulls in the requirement of all crypto being certified. > > -Steve Which SSL implementation do you plan to standardize on? Has any potential licensing conflicts with OpenSSL and GPL programs been discussed? Rahul From smooge at gmail.com Wed May 24 18:59:45 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 24 May 2006 12:59:45 -0600 Subject: Future Fedora Development In-Reply-To: <20060524185101.82743.qmail@web51502.mail.yahoo.com> References: <4474129A.5050201@develer.com> <20060524185101.82743.qmail@web51502.mail.yahoo.com> Message-ID: <80d7e4090605241159j581eba80l3d99b6e34086bf6@mail.gmail.com> On 5/24/06, Steve G wrote: > > >> - multiple digests operation (openssl, gnutls, nss .. some programs are > >> now linked with *all* avalaible implemntations 8-0 ), > > > >Yeah, I agree. OpenSSL seems to be the most comprehensive, but > >its licence stinks and this is why gnutls was written in the first > >place. Now that Mozilla adopted the triple MPL/GPL/LGPL license, > >there's no reason to keep gnutls any more. > > We need to try to streamline the number of SSL implementations for another > reason, FIPS 140-2 certifications. I think that FIPS 200 will be applicable next > year which pulls in the requirement of all crypto being certified. > Actually depending on the part of the US Goverment that needs FIPS-200 certification now (or at least say that we need a 180 day exception to get FIPS140-2 certifications) -- Stephen J Smoogen. CSIRT/Linux System Administrator From kloczek at zie.pg.gda.pl Wed May 24 19:03:40 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 24 May 2006 21:03:40 +0200 Subject: rawhide report: 20060524 changes In-Reply-To: <20060524184653.GA25823@nostromo.devel.redhat.com> References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> <20060524182909.GB25483@nostromo.devel.redhat.com> <1148496114.15113.100.camel@kloczek01.pracownicy.zie> <20060524184653.GA25823@nostromo.devel.redhat.com> Message-ID: <1148497420.15113.110.camel@kloczek01.pracownicy.zie> Dnia 24-05-2006, ?ro o godzinie 14:46 -0400, Bill Nottingham napisa?(a): [..] > No offense, but you missed the point. It's not about core and extras. > It's about the entire universe of software who autoconfed against m4 > files that call -config. We can't fix the stuff we can't ship; > all we can do by changing this is break them. You cant fix word so don't try fix this. Try fix only distribution resources and nothing more and anything other changes will be result of this. So introducing on distribution level some RightWay(tm) fixes is *very importand* .. much more importand than saving few developers ases who still want use this -config scripts. kloczek From linux_4ever at yahoo.com Wed May 24 19:09:29 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 24 May 2006 12:09:29 -0700 (PDT) Subject: Future Fedora Development In-Reply-To: <1148496878.4310.600.camel@sundaram.pnq.redhat.com> Message-ID: <20060524190929.18483.qmail@web51515.mail.yahoo.com> >Which SSL implementation do you plan to standardize on? Its still too early to make that decision. On the one hand, OpenSSL has been through a source code certification for 0.9.7. We are past that and into the newer code (0.9.8) - which has to be re-certified. OSSI is interested in doing another cert with more recent code and with a smaller subset of software. That would be a step forward, I think. AFAICT, gnutls hasn't been through FIPS 140-2. I think mozilla-nss has, though. >Has any potential licensing conflicts with OpenSSL and GPL programs been >discussed? Not yet - but licenses are to be respected. We are still gaging how big the elephant is. I think we have to start with the definition of crypto and trace all packages that implement their own and patch them to use standard libraries if equivalent. This will likely take some time. If in the mean time some consolidation was done by the fedora project, that would help make the elephant smaller. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rdieter at math.unl.edu Wed May 24 19:17:19 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 24 May 2006 14:17:19 -0500 Subject: rawhide report: 20060524 changes References: <200605240754.k4O7s1pt001182@porkchop.devel.redhat.com> <1148486420.15113.24.camel@kloczek01.pracownicy.zie> <20060524161505.GE22172@nostromo.devel.redhat.com> <1148488896.15113.33.camel@kloczek01.pracownicy.zie> <20060524164450.GL22172@nostromo.devel.redhat.com> <1148490127.15113.56.camel@kloczek01.pracownicy.zie> <20060524182909.GB25483@nostromo.devel.redhat.com> <1148496114.15113.100.camel@kloczek01.pracownicy.zie> <20060524184653.GA25823@nostromo.devel.redhat.com> <1148497420.15113.110.camel@kloczek01.pracownicy.zie> Message-ID: Tomasz K?oczko wrote: > Dnia 24-05-2006, ?ro o godzinie 14:46 -0400, Bill Nottingham napisa?(a): > [..] >> No offense, but you missed the point. It's not about core and extras. >> It's about the entire universe of software who autoconfed against m4 >> files that call -config. We can't fix the stuff we can't ship; >> all we can do by changing this is break them. > > You cant fix word so don't try fix this. > Try fix only distribution resources and nothing more and anything other > changes will be result of this. So introducing on distribution level > some RightWay(tm) fixes is *very importand* But what exactly is being fixed (by making your suggested incompatible change)? I fail to see the importance that you seem to be placing on this. -- Rex From pertusus at free.fr Wed May 24 22:35:13 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 May 2006 00:35:13 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148422325.15474.6.camel@scrappy.miketc.com> References: <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> Message-ID: <20060524223513.GA920@free.fr> Hello, > Cannot convert string > "-*-helvetica-medium-r-normal-*-*-120-*-*-*-iso8859-1" to type > FontStruct I don't have the error message when I run nedit (I am on FC5), but the font used is a very big font and the result is rather ugly. I also have tried gv and there is the same issue (no error message, big font that looks ugly). All the other apps I tried were fine (xfig, xfce, kxterm, xmgrace, ppracer, xine, xpdf, xdvi, paraview, gnuplot X11 driver). I tried them because they depend on libXt, libXpm or libXaw. -- Pat From mharris at mharris.ca Wed May 24 23:33:22 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 24 May 2006 19:33:22 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148422325.15474.6.camel@scrappy.miketc.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> Message-ID: <4474ED42.2010106@mharris.ca> Mike Chambers wrote: > On Mon, 2006-05-22 at 15:29 -0400, Mike A. Harris wrote: > >> Once your desktop is started, open a terminal and run various >> non-GNOME, non-GTK2, non-KDE, non-Qt applications. For example, >> run Xt, Xaw, Motif, and other such apps, and see if they work >> properly, or if they fail miserably. If any apps fail and >> report an error about a missing font or other font related >> problem, make note of it. > > nedit works fine but has this below when started... > > [mike at scrappy ~]$ nedit xorg.conf > nedit: the current locale is utf8 (en_US.UTF-8) > nedit: changed locale to non-utf8 (en_US) > Cannot convert string > "-*-helvetica-medium-r-normal-*-*-120-*-*-*-iso8859-1" to type > FontStruct > Cannot convert string > "-*-helvetica-bold-r-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct > Cannot convert string > "-*-helvetica-medium-o-normal-*-*-120-*-*-*-iso8859-1" to type > FontStruct > Cannot convert string > "-*-courier-medium-r-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct > Cannot convert string "-*-courier-bold-r-normal-*-*-120-*-*-*-iso8859-1" > to type FontStruct > Cannot convert string > "-*-courier-medium-o-normal-*-*-120-*-*-*-iso8859-1" to type FontStruct That indicates that nedit uses core fonts, and is trying to use helvetica, which is not configured in the core fonts system. If nedit still works, it is probably falling back to another font. > And emacs does NOT work. The menu is readable and the icon shapes are > fine, but the wording is just boxes. Also the letters in the files > themselves when trying to edit with emacs is just boxes. I figured emacs would be the killer. ;) > [mike at scrappy ~]$ emacs > Warning: Cannot convert string > "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct > Warning: Cannot convert string > "-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1" to type FontStruct > > Evolution, firefox, epiphany, xchat, gnome-terminal all seem to work, as > well as most of the other gnome/desktop apps in a general workstation > install. Will have to see about testing some more. All GNOME/KDE apps which use GTK2, will work because they are not using core fonts, they're using fontconfig/Xft2. They're expected to work fine. It is the Xaw/Xt/Motif and other apps that are expected to be using core fonts, which might fail or look ugly. I think if enough people perform the test you've just done, and run _all_ of the applications that they use on a day to day basis, and indicate which ones fail miserably, or otherwise look horrible, the list of "missing fonts" that we need to add back to a default core fonts configuration for the system to work out of the box without major hassles will grow to essentially become what we have right now, or at least be large enough to be the same thing more or less. I'm wondering if it might be a better idea to simply replace the xfs dependency in the X server packaging with a virtual: Requires: fixed-font Requires: cursor-font And make a separate package containing those for OLPC. Then OLPC installs needn't depend on xfs, but Fedora and RHEL can simply continue to use it by default. It would require changing some of the font rpms still of course though, as they invoke chkfontpath currently, which has a dep on xfs. But OLPC has stated that they do not want any of the core fonts font packages installed, so we would only have to modify the font rpms that are intended to be installed on OLPC systems, to no longer configure themselves to integrate into the xfs configuration. I think that'd be a reasonable approach at least in theory. Feedback appreciated. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Wed May 24 23:53:21 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 24 May 2006 19:53:21 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <447408AD.3090706@develer.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> Message-ID: <4474F1F1.10805@mharris.ca> Bernardo Innocenti wrote: > Mike A. Harris wrote: > >> It'd be an interesting test for someone to disable xfs, and >> to configure the X server to have only the "misc" font dir >> as a configured font path in xorg.conf, and then see what >> all apps no longer work. > > I've been running my X server with xfs disabled for over one > year, but I've added back core fonts in my xorg.conf. > > This seems to be a good compromise that would keep all legacy > toolkits happy for a few more years. If the core fonts are properly configured in the X server config, then I'd more or less agree. To do that effectively though, would require changing the way fonts are installed and configured, or to simply require users to manually configure the fontpaths they desire (which is a bit ugly IMHO). > IIRC, delegating font rendering to xfs was just a workaround > to avoid hanging X for too long while loading fonts with lots > of glyphs (e.g. kanji fonts). That was more or less one of the primary reasons, however several people for years now claim that it is no longer a real issue. > Today, this is largely useless because: > > - Very few apps use the core fonts I'm not so sure that is true. I'd like to see a definition of "very few" really. Every app ever written for the X Window system which has not been ported to Xft/fontconfig, or to GTK/Qt stack that is fontconfig/Xft enabled uses core fonts still. Since I have posted this thread, it has surfaced that emacs, nedit, mplayer all use core fonts. I can't guess how many users use nedit, but emacs and mplayer have a massive userbase. There are likely to be a large number of applications out there which are very highly popular still, which still rely on core fonts. So ignoring core fonts, or making it a total 3rd class citizen that causes user pain is IMHO not viable. Any changes we make, must leave the common general case usage scenario still a useable system IMHO, or we will receive nothing but harsh words from the community, and perhaps even a wake of users ditching our distribution for one that their apps work with out of the box. > - most of them are not even localized or unable to use non-western fonts > - Today's CPUs are much faster > - Unless I've misunderstood something, X should now be able > to load and render single character glyphs at a time. The reasons that xfs was decided upon a long time ago may or may not be relevent today. The main reason xfs continues to be used in Fedora/RHEL in 2006 is because of the "if it is not broken, don't fix it" principle. The core fonts system "just works" with our current xfs setup. Font rpms drop into place and configure themselves to work with xfs simply, and users generally do not need to do any hand editing of config files or other futzing around. Every time someone has previously proposed to get rid of xfs, it has been suggested in a way that hinted that we can simply disable xfs from being started by default, and core fonts magically continues to work for everyone without any further engineering effort. In reality, if we are to not use xfs by default, and still have core fonts remain to be useable out of the box without user intervention, we need to change every single font package which currently configures itself to integrate into the core fonts system with chkfontpath. chkfontpath in theory could be rewritten to configure the X server, which would work for fresh OS installs, but would more or less totally break on OS upgrades, or yum upgrades that migrate from one OS release to the next. If we are to migrate the OS from using xfs by default to using the X server directly by default for core fonts, then we need to clearly determine what level of compatibility we require, and determine every single part of the OS which will need to be updated to work with the new way of doing things properly. In the past, all of this effort has been determined to be a lot of work to allocate resources to, to remove a dependency on xfs, but to otherwise give no new functionality. In other words, to spend some unknown amount of manpower to engineer a solution that hopefully results in giving us the same level of functionality for core font using apps as we have right now already if we do nothing. ;o) So, what I'm trying to determine right now is - if we do decide to do this, what actual work needs to be done, so we can scope out how much resources need to be committed to doing it, or alternatively to find an alternative solution to the OLPC problem. The one alternative that has come up, is to remove the xfs dep from the X server packaging, and replace it with a virtual dep on the required core fonts, then add the virtual provides to the xfs package, and also to a new package that just provides fixed+cursor for OLPC. Another alternative, is to build the fixed+cursor fonts into the X server binary, and not have any external dependency, thereby making any further core fonts optional, either provided by xfs, or by manual configuration. Feedback/thoughts/etc. appreciated! Thanks guys! -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Thu May 25 00:00:13 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 24 May 2006 20:00:13 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44731AAC.3030909@redhat.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> Message-ID: <4474F38D.9010308@mharris.ca> Adam Jackson wrote: > Mike A. Harris wrote: >> Dimi Paun wrote: >>> On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: >>>> On the other hand, there are many applications included both >>>> in Fedora Core, and in Fedora Extras, which do rely on the >>>> core fonts system still, and are likely to rely on it for the >>>> forseeable future. >>> >>> Great to hear we're moving in this direction. >>> I guess the obvious question is "what will break?". Once we >>> have a clear idea what really depends on xfs (some packages, like >>> wine, _can_ work with xfs if it's the only available option, or >>> without), we can devise a plan of making xfs optional (moved to Extra >>> along with all apps that depend on it?). >> >> No apps[1] require xfs. Lots of apps require "core fonts" >> support. We currently provide core fonts support via the >> xfs font server, however the X server is equally capable >> of serving fonts on its own without a separate font server. > > I assume the [1] here was meant to point to a footnote about various > very-low-level tools that do know how to explicitly talk to font > servers. It's not a large list: fslsfonts, fstobdf, mkcfm, showfont, > and xfsinfo from the Xorg app collection, and probably zero outside of > that. Doh! Indeed you are correct. I put the [1] there to add a footnote explaining xfsinfo etc. directly require xfs, but forgot to include the footnote. Good observation! ;o) > I'm of the opinion that leaving xfs enabled isn't really a big deal even > in RHEL, and that the correct fix is to fix the X server to use > fontconfig once and for all, rather than expose users to a needless > configuration change. I don't see the intermediate steps as being > worthwhile targets on their own. Replacing the core fonts system with a compatibility layer that is implemented on top of Xft/fontconfig is indeed the best long term solution IMHO. Unfortunately, such solution does not exist at this point in time, and is equally unlikely to exist in time for FC6 and RHEL5 as far as I can determine. So we need a solution for OLPC, FC6, RHEL5 which can be ready probably before test2 in order to have time to work out any kinks. The question then becomes: Do the OLPC people require a solution right now, or can they wait until some yet unnamed person writes a core fonts compatibility layer that sits on top of fontconfig/Xft? I don't know the answer to that, but I suspect that they want some kind of solution ASAP, wether it is a hack or a solid long term solution. Do you have any thoughts as to what we should do for FC6 to solve the dependency on xfs for OLPC, under the assumption that such long term fontconfig/Xft core fonts solution will not be available in time for FC6test2? Ideally, I'd like to have something in place within 2-3 weeks, or at least started. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Thu May 25 00:16:49 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 24 May 2006 20:16:49 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148422547.25336.13.camel@rousalka.dyndns.org> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> <1148422547.25336.13.camel@rousalka.dyndns.org> Message-ID: <4474F771.20904@mharris.ca> Nicolas Mailhot wrote: > Le mardi 23 mai 2006 ? 10:22 -0400, Adam Jackson a ?crit : > >> I'm of the opinion that leaving xfs enabled isn't really a big deal > > Unfortunately, as every single FCxT1 release shows, leaving xfs enabled > means various users will have their X server fail mysteriously because > of problems locating "fixed". Actually, thanks to our fairly well beaten into shape xfs initscript, the number of people who have seen the "can't find font fixed" error during X server startup in the last several years has declined significantly to a negligible few, and that's usually due to experimental test changes that have occured during development. The alternative to seeing the above error, would be having the X server start up with no error, and having applications fail individually, or start up with no visible fonts. That's not really a better situation than seeing the above error. > Notwithstanding the fact that they probably do not have a single > main app needing "fixed" anymore. That's rather speculative. Define "main app". That definition will vary from person to person, and if there are 2000000 users out there, there will probably be 1000000 definitions. Wether a "main app" fails or not doesn't matter. What matters is "Will an app that someone expects to work, actually work?" > Core font system is not "just working" and "low impact". Every once in a > while it manages to remind everyone it's still lurking under the X > server. As long as the current system is unchanged it will stay one of > the X server main points of failure. Sure, I can agree with that. But as I mentioned above, if we solve the problem that causes that error to be displayed and prevents the X server from starting, by making sure fixed is always available, then it just masks the fact that one's font configuration may be incomplete or broken. When you see the "can't find font fixed" error, it is a clear sign right now that either xfs isn't running, or xfs is misconfigured, or one or more core font directories is misconfigured or improperly prepped. IMHO, replacing that problem, with an X server that starts up ok, but where the core fonts system may still be misconfigured or otherwise unuseable by one or more apps, simply changes the problem to be a random app failure the user can't easily diagnose - causing them to flood bugzilla with various "my app starts with boxes instead of letters" problems, or worse, they click on an icon on their working desktop, and the app never starts at all - so they file a bug report against that application. At least with the current failure mode, the person has to fix the font subsystem configuration problem before they can even start the server, and once they do fix that - they are unlikely to see individual applications failing miserably for no visible reason. They're then less likely to file useless bug reports in bugzilla. It's certainly arguable which scenario is the better to choose, as it has came up many times on many mailing lists. The above is my opinion only, and I must admit that I am biased a bit against seeing bogus bug reports landing in bugzilla with my name on them as bug owner. ;o) The solution Adam suggested in the previous mail, of using fontconfig/Xft to provide core fonts is IMHO the best solution period. The main problem with that solution however, is that people have proposed that as a solution for 3 years, and nobody has shown any real interest in stepping forward to implement that solution to the best of my knowledge. > +1 to reduce its perimeter in FC to something minimalistic, lightweight > and robust. Even if it means reducing its functionnalities to the bare > minimum required by the spec. Let the apps which didn't bother with > fontconfig migration bear the weight of core font management, if they > really want to keep it alive forever. While I certainly agree with you 2000% in principle there, and I have indeed done that approach with some other changes to things in the past years, this is one that is a bit deeper IMHO. When we have applications like "emacs", "mplayer" and other apps people would probably consider "killer app, I must have or I'll go use an OS that works", we have to consider our actions much more carefully. Are we really that big of a distribution that we can say "we don't care about your core font using apps anymore"? Maybe I overestimate the number of people who would get upset over such a decision? Is it worth taking the risk to find out? ;o) And more importantly, if such risk is indeed taken, _who_ foots the criticism for the decision when people come looking for heads to roll? If I am to make any potentially drastic changes of this nature, I definitely want to have a scapegoat to pile things on. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Thu May 25 00:21:08 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 24 May 2006 20:21:08 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148424395.4474.3.camel@daxter.boston.redhat.com> References: <446FF7AB.30301@mharris.ca> <1148424395.4474.3.camel@daxter.boston.redhat.com> Message-ID: <4474F874.6070501@mharris.ca> David Zeuthen wrote: > On Sun, 2006-05-21 at 01:16 -0400, Mike A. Harris wrote: >> In particular, xfs and core fonts does not fit well into the >> One Laptop Per Child (OLPC) effort, or other Fedora derived >> embedded distributions. In these embedded systems, or >> reduced computing environments if you will, every megabyte >> of disk space and memory counts. Shedding megs of stuff out >> of the default OS installation is sure to reduce both the >> memory footprint and disk footprint of the OS installation, >> which is a net gain for these systems, and also for a lot >> of the userbase out there that do not use any applications >> which rely on core fonts. > > Just to be perfectly clear: All we are asking right now from OLPC is to > cut a few Requires here and there such that our RPM transaction (that > include xorg-x11-server-Xorg) doesn't pull in xorg-x11-xfs. This will > not break new installs nor upgrades of Fedora - for new installs, just > make sure that the comps.xml files include xorg-x11-xfs in addition to > xorg-x11-server-Xorg. > > I second that it would be nice to get rid of xfs entirely but we're not > really asking that much right now. Yep, I understand that part, but the X server isn't the only thing that drags in xfs. chkfontpath drags in xfs, as chkfontpath has to modify the xfs configuration. Every font rpm in the distro that currently configures itself to work with xfs by invoking chkfontpath, has an indirect dependency on xfs. Do you have a list of all of the font rpms that are intended to be installed on an OLPC system? If so, we can examine them all to determine wether or not we can simply remove their chkfontpath invocation. If we can do that, as far as I know, we can remove all deps on xfs from the packaging that gets used on OLPC, without killing xfs usage by default for Fedora/RHEL. That would potentially allow the whole "to xfs or not, that is the question" discussion for 2008 or so. ;) TIA -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From cmadams at hiwaay.net Thu May 25 00:24:47 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 May 2006 19:24:47 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474ED42.2010106@mharris.ca> References: <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> Message-ID: <20060525002447.GA898192@hiwaay.net> Once upon a time, Mike A. Harris said: > I figured emacs would be the killer. ;) What about xterm? You can't break xterm! :-) xterm links against libfreetype and libfontconfig, but if I stop xfs or clear the X server font path, xterm will not start. I still use plain old 6x13 (aka fixed) as my terminal font of choice. Is there a way to get the equivalent font without old-style core fonts? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From david at lovesunix.net Thu May 25 01:10:31 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 25 May 2006 03:10:31 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474F771.20904@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> <1148422547.25336.13.camel@rousalka.dyndns.org> <4474F771.20904@mharris.ca> Message-ID: <1148519431.2951.26.camel@price> ons, 24 05 2006 kl. 20:16 -0400, skrev Mike A. Harris: > Maybe I overestimate the number of people who would get upset over > such a decision? Is it worth taking the risk to find out? Definately.. no questions asked - if the only two projects major products we break are Emacs and MPlayer, then we seriously have to consider doing it when the benefits are as grand as I assume they are. MPlayer isn't shipped with FC, no garantee is given that it will work out of the box with any release from our hands. We would not be able to ship a version of MPlayer that worked to the satification of users nor upstream anyways for legal reasons. Emacs might be a problem but which instance of Emacs is affected. I assume the most commonly used console version would remain intact. They will have plenty of time to either fix their code or work on an argument for keeping xfs. As a compromise maybe we could throw out xfs for test1 and look at the response. If the breakage and complaint ratio is massive then we have time to revert it and beg upstream to fix their code in time for FC7 - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From seandarcy2 at gmail.com Thu May 25 02:44:26 2006 From: seandarcy2 at gmail.com (sean) Date: Wed, 24 May 2006 22:44:26 -0400 Subject: rawhide report: 20060523 changes In-Reply-To: <200605230733.k4N7Xj6j024604@porkchop.devel.redhat.com> References: <200605230733.k4N7Xj6j024604@porkchop.devel.redhat.com> Message-ID: Build System wrote: > > > > Updated Packages: > ................ > cups-1:1.2.1-2 > -------------- > * Mon May 22 2006 Tim Waugh 1:1.2.1-2 > - 1.2.1. > - Another STR #1705 fix (bug #192034). > - Fixed devel package multilib conflict (bug #192664). > > * Mon May 22 2006 Tim Waugh 1:1.2.0-7 > - Sync to svn5568. No longer need rpath patch. > - Added a 'conflicts:' for kdelibs to prevent bug #192548. > /usr/bin/cups-config cups-devel.x86_64 has serverbin hard-coded to /usr/lib/cups, even though libdir correctly finds /usr/lib64 sean From notting at redhat.com Thu May 25 04:00:17 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 May 2006 00:00:17 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474F1F1.10805@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> <4474F1F1.10805@mharris.ca> Message-ID: <20060525040017.GC29671@nostromo.devel.redhat.com> Mike A. Harris (mharris at mharris.ca) said: > >IIRC, delegating font rendering to xfs was just a workaround > >to avoid hanging X for too long while loading fonts with lots > >of glyphs (e.g. kanji fonts). > > That was more or less one of the primary reasons, however several > people for years now claim that it is no longer a real issue. I believe one of the other reasons was that adding it to the server's path at runtime was somewhat of a PITA (moreover, it required mucking directly with the server config file.) Bill From bernie at develer.com Thu May 25 05:50:19 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 25 May 2006 07:50:19 +0200 Subject: Future Fedora Development In-Reply-To: <20060524150805.GC1186624@hiwaay.net> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> <20060524150805.GC1186624@hiwaay.net> Message-ID: <4475459B.7030502@develer.com> Chris Adams wrote: > Once upon a time, Bernardo Innocenti said: >> What's wrong with GPL programs using the Mozilla implementation? >> Last time I checked NSS was totally GPL compatible. > > mozilla-nss requires mozilla-nspr. libnss3.so also pulls in > libpthread.so. Those are pretty heavy requirements for SSL. Yuk... I'm totally sick of this proliferation of portable runtimes which usually turn out to be incompatible with each other (license-wise or just because of conflicting definitions and types). To say nothing about the performance cost of adding a useless layer. We have APR, NSPR, glib, QtCore, libiberty, and a myriad of others. What's wrong with POSIX + SUSv3 and their friends? All modern OSes support them by now and there are even good implementations for Windows. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu May 25 06:10:16 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 25 May 2006 08:10:16 +0200 Subject: Making LDAP easier to use In-Reply-To: <1148458627.4310.567.camel@sundaram.pnq.redhat.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> Message-ID: <44754A48.8020706@develer.com> Rahul Sundaram wrote: >> As an administrator, I'm particularly embarassed to show my >> customers the tools I use to run their UNIX accounts and >> Samba domain controller. > > You might get involved and help write such tools. That would replace > embarrassment with pride. Unfortunately, it's not like you can write a couple of new applications and you're done. It would take some commitment by a distribution such as Fedora to bring the small bits together. Most tools are there already, but not designed or tested to work well together. And it's because very few people go through the pain of setting up an LDAP-based LAN. For example, Samba uses its own user database by default and it takes lots of perl glue (the smbldap-tools) to get it to fetch domain users from LDAP. You also need to add custom schemas and fiddle with obscure configuration parameters until it works. Maybe Samba4 will improve the situation. Creating users in LDAP is hard. The usual tools such as useradd and system-config-users should be teached how to do it. I still couldn't figure out how to change the posixAccount password in LDAP without using smbpasswd. Viewing and editing the LDAP database is hard. The best tool I've found is ldapvi, which is very low level and isn't even in Extras. There are lots of Java GUI tools which I'd avoid if I could and a few web-based ones with the usual slow user interface. The best one seems to be phpLdapAdmin. It's in Extras, but you have to fiddle a lot with the configuration before you can authenticate into your LDAP server. On the client side, system-config-authentication already does 90% of the work, but fails to do (or suggest) the steps required to get TLS to work. Without TLS, your passwords wil fly over the wire in clear. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From kaytiong at gmail.com Thu May 25 07:16:20 2006 From: kaytiong at gmail.com (Kay Tiong Khoo) Date: Thu, 25 May 2006 15:16:20 +0800 Subject: oprofile backtracing support [x86_64] Message-ID: <4045194D-C63B-4DC4-98FD-F49B49A81F19@gmail.com> Hello there, I have several questions with regard to oprofile backtracing support in the kernel and would appreciate responses from Red Hat Developers. 1. Currently, CONFIG_DEBUG_INFO is set in Fedora Core 5. Will it also be set in future RHEL products? 2. Because CONFIG_FRAME_POINTER is not set in Fedora Core 5, samples in the kernel will not have backtraces. Is there any possibility that future releases of Fedora Core will have CONFIG_FRAME_POINTER set? I am currently in the process of developing a front-end with a rewritten oprofile kernel module as the backend. Proper support for backtracing on Fedora and Red Hat will help customers visualize the callstacks. Thanks Kay Tiong From felipe.alfaro at gmail.com Thu May 25 09:51:54 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 25 May 2006 11:51:54 +0200 Subject: Making LDAP easier to use In-Reply-To: <44754A48.8020706@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> Message-ID: <6f6293f10605250251r6be2fc34y1b6f03210c781184@mail.gmail.com> > Unfortunately, it's not like you can write a couple of > new applications and you're done. It would take some > commitment by a distribution such as Fedora to bring the > small bits together. Right now, it requires a lot of integration work, but works pretty well. > Most tools are there already, but not designed or tested > to work well together. And it's because very few people > go through the pain of setting up an LDAP-based LAN. I have set up some LDAP-based LAN's and I think that, although not straightforward as installing Linux and clicking Next, Next, Next, i'ts not as difficult as it could seem. > Creating users in LDAP is hard. The usual tools such as > useradd and system-config-users should be teached how to do it. > I still couldn't figure out how to change the posixAccount > password in LDAP without using smbpasswd. You can use "libuser", which supports several backends, being LDAP on of then. I'm using luseradd/lusermod/luserdel/lgroupadd/lgroupdel/lgroupmod from libuser to manage my LDAP users and its work very well. From felipe.alfaro at gmail.com Thu May 25 10:13:47 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 25 May 2006 12:13:47 +0200 Subject: Making LDAP easier to use (Was: rawhide report: 20060522 changes) In-Reply-To: <1148484808.2372.14.camel@ender> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <6f6293f10605240830w4f3bb136mb2750cdad8efcfda@mail.gmail.com> <1148484808.2372.14.camel@ender> Message-ID: <6f6293f10605250313y432172d2o70fe9d3c48fe0b40@mail.gmail.com> > Sorry, I just can't agree with 'nice' and 'java' being used in > conjunction. It's just a matter of taste. I would say thay, ugly or nice, the Fedora Console is pretty usable. From samueldg at arcoscom.com Thu May 25 11:30:44 2006 From: samueldg at arcoscom.com (Samuel =?iso-8859-1?Q?D=EDaz_Garc=EDa?=) Date: Thu, 25 May 2006 13:30:44 +0200 (CEST) Subject: Problems making personalized kernel Message-ID: <37489.195.55.244.106.1148556644.squirrel@www.arcoscom.com> Hi, I fw some questions about making personal kernel. Please, help. ---------------------------- Mensaje original ---------------------------- Asunto: Problems making personalized kernel De: Samuel D?az Garc?a Fecha: Jue, 25 de Mayo de 2006, 13:25 Para: fedora-list at redhat.com Cc: fedora-devel-list at redhat.com -------------------------------------------------------------------------- Hi, I'm trying to prepare a customized kernel with some patches, using the sources from fc5. I'm preparing scripts to allow me download, prepare sources, add the patches, and make package. Download, insall src.rpm and put the patches into SOURCES and patch .spec fine. The problem is into "make ARCH=i686 nonint_oldconfig" step. This is the error when run this: rpmbuild -bp --target i686 SPECS/kernel-2.6_AC.spec The error is: .config:2966:warning: trying to reassign symbol AGP_AMD64 .config:2967:warning: trying to reassign symbol AGP_NVIDIA .config:2968:warning: trying to reassign symbol AGP_SWORKS CONFIG_IP_NF_MATCH_LAYER7 CONFIG_IP_NF_TARGET_IMQ CONFIG_IP6_NF_TARGET_IMQ CONFIG_IMQ make[1]: *** [nonint_oldconfig] Error 4 make: *** [nonint_oldconfig] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.11881 (%prep) Obviously, the patches add some new kernel options and "nonint_oldconfig" breaks rpmbuild process. I tried "make menuconfig" moving the apropiate *.config into .config and manually activate this new options. My idea is create a script that allow me automatically: 1) patch a new fedora kernel sources with some patches 2) don't breaks the standard .spec file 3) allow me patch it 4) upgrade all architectures .config with new default options 5) make kernel rpm's for various architectures I'm now in step 3, I need help in steps 4 and 5. Any help? Thanks P.D.: Sorry for my english. -- Samuel D?az Garc?a ArcosCom Wireless, S.L.L. CIF: B11828068 c/ Romero Gago, 19 Arcos de la Frontera 11630 - Cadiz http://www.arcoscom.com mailto:samueldg at arcoscom.com msn: samueldg at arcoscom.com Tlfn.: 956 70 13 15 Fax: 956 70 34 83 From fedora at camperquake.de Thu May 25 11:30:39 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 25 May 2006 13:30:39 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060525002447.GA898192@hiwaay.net> References: <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> <20060525002447.GA898192@hiwaay.net> Message-ID: <20060525133039.68fbf12e@nausicaa.camperquake.de> Hi. Chris Adams wrote: > xterm links against libfreetype and libfontconfig, but if I stop xfs or > clear the X server font path, xterm will not start. I still use plain > old 6x13 (aka fixed) as my terminal font of choice. Is there a way to > get the equivalent font without old-style core fonts? -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso10646-1 here. Sorry, but antialiased fonts in a terminal window just gives me the creeps. And not aa'ed fonts under Fedora just look plain ugly. -- Why does good news never arrive in a window envelope? From Matt_Domsch at dell.com Thu May 25 12:26:44 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 25 May 2006 07:26:44 -0500 Subject: rawhide rebuild in mock status 2006-05-24 Message-ID: <20060525122644.GA658@lists.us.dell.com> I'm going to drop openoffice from the build, it takes >6 hours on 2 x 3.6GHz systems, and needs ~4GB RAM. Shout if that's a problem. Open Bugs which now build, and can be marked CLOSED RAWHIDE: eclipse 192563 NEW Rawhide-in-Mock Build Results for x86_64 Architecture Thu May 25 06:42:02 CDT 2006 Number failed to build: 177 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 149 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 8 ---------------------------------- SDL elilo emacs gcc magma-plugins memtest86+ openoffice.org rgmanager With bugs filed: 140 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] hal-cups-utils ['192507 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Rawhide-in-Mock Build Results for i386 Architecture Thu May 25 06:42:34 CDT 2006 Number failed to build: 165 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 154 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 7 ---------------------------------- SDL apr emacs gpart magma-plugins rgmanager sg3_utils With bugs filed: 146 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] hal-cups-utils ['192507 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnotify ['191731 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] pam ['191915 ASSIGNED'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-glint ['192365 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-tseng ['192385 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ ----- End forwarded message ----- -- 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 mharris at mharris.ca Thu May 25 12:36:53 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 25 May 2006 08:36:53 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060525002447.GA898192@hiwaay.net> References: <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> <20060525002447.GA898192@hiwaay.net> Message-ID: <4475A4E5.8020607@mharris.ca> Chris Adams wrote: > Once upon a time, Mike A. Harris said: >> I figured emacs would be the killer. ;) > > What about xterm? You can't break xterm! :-) > > xterm links against libfreetype and libfontconfig, but if I stop xfs or > clear the X server font path, xterm will not start. I still use plain > old 6x13 (aka fixed) as my terminal font of choice. Is there a way to > get the equivalent font without old-style core fonts? xterm supports Xft/fontconfig, you simply need to pass the right commandline options to it. man xterm -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Thu May 25 12:42:32 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 25 May 2006 08:42:32 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060525040017.GC29671@nostromo.devel.redhat.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> <4474F1F1.10805@mharris.ca> <20060525040017.GC29671@nostromo.devel.redhat.com> Message-ID: <4475A638.2090605@mharris.ca> Bill Nottingham wrote: > Mike A. Harris (mharris at mharris.ca) said: >>> IIRC, delegating font rendering to xfs was just a workaround >>> to avoid hanging X for too long while loading fonts with lots >>> of glyphs (e.g. kanji fonts). >> That was more or less one of the primary reasons, however several >> people for years now claim that it is no longer a real issue. > > I believe one of the other reasons was that adding it to the > server's path at runtime was somewhat of a PITA (moreover, > it required mucking directly with the server config file.) xset can add/remove font paths at runtime no prob. The future of the X server seems to be heading towards having no config file, and instead having sane builtin defaults, and runtime configuration of some sort. In theory, the X server could have a built in font path that points to fixed+misc (or have them compiled into the binary), and rely on xset invoked from startup scripts to add additional font paths. xset is capable of adding font servers to the font path if desired as well, which comes in handy when xfs crashes or has to be shut down and restarted. Adding it back to the font path at runtime allows one to avoid having to restart the X server. If we were to go to a setup like this, the xinitrc package would have to be updated (probably xinitrc-common) to invoke xset for adding font paths, and we'd need a new config file somewhere to store the fontpath configuration. Any thoughts about this approach? -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From cmadams at hiwaay.net Thu May 25 13:11:54 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 May 2006 08:11:54 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4475A4E5.8020607@mharris.ca> References: <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> <20060525002447.GA898192@hiwaay.net> <4475A4E5.8020607@mharris.ca> Message-ID: <20060525131154.GA969949@hiwaay.net> Once upon a time, Mike A. Harris said: > >I still use plain > >old 6x13 (aka fixed) as my terminal font of choice. Is there a way to > >get the equivalent font without old-style core fonts? > > xterm supports Xft/fontconfig, you simply need to pass the right > commandline options to it. Yes, I know. Again, is there a way to get the same font as the old core fonts "fixed" from Xft? Is that font available from Xft? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From paul at city-fan.org Thu May 25 13:15:54 2006 From: paul at city-fan.org (Paul Howarth) Date: Thu, 25 May 2006 14:15:54 +0100 Subject: Making LDAP easier to use In-Reply-To: <44754A48.8020706@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> Message-ID: <1148562955.8185.16.camel@laurel.intra.city-fan.org> On Thu, 2006-05-25 at 08:10 +0200, Bernardo Innocenti wrote: > Viewing and editing the LDAP database is hard. The best tool > I've found is ldapvi, which is very low level and isn't even > in Extras. There are lots of Java GUI tools which I'd avoid > if I could and a few web-based ones with the usual slow user > interface. The best one seems to be phpLdapAdmin. It's in > Extras, but you have to fiddle a lot with the configuration > before you can authenticate into your LDAP server. lat (LDAP Administration Tool) is quite nice and is awaiting a maintainer in Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580 Paul. From mharris at mharris.ca Thu May 25 13:20:04 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 25 May 2006 09:20:04 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060525131154.GA969949@hiwaay.net> References: <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> <20060525002447.GA898192@hiwaay.net> <4475A4E5.8020607@mharris.ca> <20060525131154.GA969949@hiwaay.net> Message-ID: <4475AF04.60406@mharris.ca> Chris Adams wrote: > Once upon a time, Mike A. Harris said: >>> I still use plain >>> old 6x13 (aka fixed) as my terminal font of choice. Is there a way to >>> get the equivalent font without old-style core fonts? >> xterm supports Xft/fontconfig, you simply need to pass the right >> commandline options to it. > > Yes, I know. Again, is there a way to get the same font as the old core > fonts "fixed" from Xft? Is that font available from Xft? If it isn't, copy it into ~/.fonts/ or the systemwide fontconfig directory and it will be. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From tdiehl at rogueind.com Thu May 25 13:36:45 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 25 May 2006 09:36:45 -0400 (EDT) Subject: Making LDAP easier to use In-Reply-To: <1148562955.8185.16.camel@laurel.intra.city-fan.org> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> <1148562955.8185.16.camel@laurel.intra.city-fan.org> Message-ID: On Thu, 25 May 2006, Paul Howarth wrote: > On Thu, 2006-05-25 at 08:10 +0200, Bernardo Innocenti wrote: > > Viewing and editing the LDAP database is hard. The best tool > > I've found is ldapvi, which is very low level and isn't even > > in Extras. There are lots of Java GUI tools which I'd avoid > > if I could and a few web-based ones with the usual slow user > > interface. The best one seems to be phpLdapAdmin. It's in > > Extras, but you have to fiddle a lot with the configuration > > before you can authenticate into your LDAP server. > > lat (LDAP Administration Tool) is quite nice and is awaiting a > maintainer in Extras: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580 Along these lines has anyone here setup Fedora Directory server in place of openldap?? If so I am curious what if any additional problems were encountered. I have read the howto on the FDS wiki and it looks pretty streight forward but... Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From dwmw2 at infradead.org Thu May 25 13:44:52 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 25 May 2006 14:44:52 +0100 Subject: Problems making personalized kernel In-Reply-To: <37489.195.55.244.106.1148556644.squirrel@www.arcoscom.com> References: <37489.195.55.244.106.1148556644.squirrel@www.arcoscom.com> Message-ID: <1148564692.14463.11.camel@pmac.infradead.org> On Thu, 2006-05-25 at 13:30 +0200, Samuel D?az Garc?a wrote: > My idea is create a script that allow me automatically: > 1) patch a new fedora kernel sources with some patches > 2) don't breaks the standard .spec file > 3) allow me patch it > 4) upgrade all architectures .config with new default options > 5) make kernel rpm's for various architectures Why not just check it out from CVS, add your patches to the specfile, add your config options to configs/config-generic, and then build the architectures you want with something like 'make ppc ppc64'? -- dwmw2 From sundaram at fedoraproject.org Thu May 25 13:51:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 May 2006 19:21:11 +0530 Subject: Making LDAP easier to use In-Reply-To: <44754A48.8020706@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> Message-ID: <1148565071.4310.612.camel@sundaram.pnq.redhat.com> On Thu, 2006-05-25 at 08:10 +0200, Bernardo Innocenti wrote: > Rahul Sundaram wrote: > > >> As an administrator, I'm particularly embarassed to show my > >> customers the tools I use to run their UNIX accounts and > >> Samba domain controller. > > > > You might get involved and help write such tools. That would replace > > embarrassment with pride. > > Unfortunately, it's not like you can write a couple of > new applications and you're done. It would take some > commitment by a distribution such as Fedora to bring the > small bits together. A distribution is just a means for people to work together. Talking about nice ideas without development isnt going to go far. Rahul From caolanm at redhat.com Thu May 25 13:55:29 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 25 May 2006 14:55:29 +0100 Subject: rawhide rebuild in mock status 2006-05-24 In-Reply-To: <20060525122644.GA658@lists.us.dell.com> References: <20060525122644.GA658@lists.us.dell.com> Message-ID: <1148565329.19196.29.camel@localhost.localdomain> On Thu, 2006-05-25 at 07:26 -0500, Matt Domsch wrote: > I'm going to drop openoffice from the build, it takes >6 hours on > 2 x 3.6GHz systems, and needs ~4GB RAM. Shout if that's a problem. On the bright side, there was a window of time when it took 25 hours to build :-) C. From ajackson at redhat.com Thu May 25 13:15:57 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 25 May 2006 09:15:57 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474F38D.9010308@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> <4474F38D.9010308@mharris.ca> Message-ID: <4475AE0D.6080808@redhat.com> Mike A. Harris wrote: >> I'm of the opinion that leaving xfs enabled isn't really a big deal >> even in RHEL, and that the correct fix is to fix the X server to use >> fontconfig once and for all, rather than expose users to a needless >> configuration change. I don't see the intermediate steps as being >> worthwhile targets on their own. > > Replacing the core fonts system with a compatibility layer that is > implemented on top of Xft/fontconfig is indeed the best long term > solution IMHO. Unfortunately, such solution does not exist at this > point in time, and is equally unlikely to exist in time for FC6 and > RHEL5 as far as I can determine. So we need a solution for OLPC, > FC6, RHEL5 which can be ready probably before test2 in order to > have time to work out any kinks. > > The question then becomes: > > Do the OLPC people require a solution right now, or can they wait until > some yet unnamed person writes a core fonts compatibility layer that > sits on top of fontconfig/Xft? Are we really requiring FC6 and OLPC to be built from the same image, or do we get a flag for it at build time? If the latter, then it'd be really easy to do: %if %{olpc} Patch666: always-inject-misc-into-font-path.patch %endif Which would take me roughly five minutes to write and another ten to build. Obviously this wouldn't be quite so pleasant for Fedora, since it turns the failure mode from fatal to mysterious runtime weirdness; I think that's a separate issue and I just need to learn fontconfig already. - ajax From buildsys at redhat.com Thu May 25 14:51:45 2006 From: buildsys at redhat.com (Build System) Date: Thu, 25 May 2006 10:51:45 -0400 Subject: rawhide report: 20060525 changes Message-ID: <200605251451.k4PEpjGc014801@porkchop.devel.redhat.com> Updated Packages: ImageMagick-6.2.5.4-4.2.1.fc5.2 ------------------------------- * Wed May 24 2006 Matthias Clasen - 6.2.5.4-4.2.1.fc4.2 - Fix a heap overflow CVE-2006-2440 (#192279) * Mon Mar 20 2006 Matthias Clasen - 6.2.5.4-4.2.1.fc5.1 - Don't ship .la files (#185237) ORBit2-2.14.0-2 --------------- * Wed May 24 2006 Matthias Clasen - 2.14.0-2 - Don't rebuild api docs - Fix multilib conflicts anaconda-11.1.0.20-1 -------------------- * Wed May 24 2006 David Cantrell 11.1.0.20-1 - Added Netlink helper functions to libisys.a - Do not pop wait window twice in writeBootloader (clumens) - For kickstart installs only: Do not allow logical volumes to be smaller than the volume group's PE size (#186412, clumens) - initrd fixes to account for glib2 library movement (clumens) aspell-12:0.60.3-7 ------------------ * Tue May 23 2006 Ivana Varekova - 12:0.60.3-7 - fix multilib problem (used pkgconfig) evolution-connector-2.7.2-2 --------------------------- * Wed May 24 2006 Matthew Barnes - 2.7.2-2 - Add BuildRequires for gtk-doc (closes #192251). - Require specific versions of GNU Autotools packages for building. - Various spec file cleanups. fedora-release-5.89-rawhide.2 ----------------------------- file-4.17-4 ----------- * Wed May 24 2006 Radek Vok??l 4.17-4 - /usr/share/file is owned by package (#192858) - fix magic for Clamav files (#192406) * Fri Apr 21 2006 Radek Vok??l 4.17-3 - add support for OCFS or ASM (#189017) * Tue Mar 14 2006 Radek Vok??l 4.17-2 - fix segfault when compiling magic - add check for wctype.h - fix for flac and mp3 files glibc-2.4.90-10 --------------- * Wed May 24 2006 Jakub Jelinek 2.4.90-10 - on i686 make glibc owner of /lib/i686 directory (#192597) - search parent NIS+ domains (#190803) glibc-kernheaders-3.0-36 ------------------------ * Wed May 24 2006 David Woodhouse 3.0-36 - Update to 2.6.16-1.2211_FC6: - sync_file_range() flags in - sys_[gs]et_robust_range syscalls in gnome-python2-desktop-2.14.0-2 ------------------------------ * Wed May 24 2006 John (J5) Palmieri - 2.14.0-2 - Add pygtk2 BR gtkspell-2.0.11-2 ----------------- * Wed May 24 2006 Matthew Barnes - 2.0.11-2 - Remove @SPELLER_LIB@ from Libs in gtkspell-2.0.pc.in (closes #116914). - Disable gtk-doc to resolve multilib conflict (closes #192683). - Various spec file cleanups. guile-5:1.8.0-5 --------------- * Wed May 24 2006 Miroslav Lichvar - 5:1.8.0-5 - remove dependency on slib, provide support through triggers - fix multilib -devel conflicts in guile-snarf and scmconfig.h (#192684) hal-0.5.7-11 ------------ * Wed May 24 2006 John (J5) Palmieri - 0.5.7-11 - Updated autofs fix kernel-2.6.16-1.2215_FC6 ------------------------ * Thu May 25 2006 Dave Jones - 2.6.17rc5 * Wed May 24 2006 Dave Jones - 2.6.17rc4-git13 * Wed May 24 2006 Juan Quintela - remove xen-irq-patch included upstream. - rebase xen hipervisor to xen-unstable cset 10140. - rebase xen patch to linux-2.6-xen cset 22552. kudzu-1.2.36-2 -------------- * Wed May 24 2006 Bill Nottingham - 1.2.36-2 - rebuild against new libpci libdv-0:0.104-4.fc6 ------------------- * Wed May 24 2006 Jarod Wilson 0.104-4 - disable PIC patch for now, it reliably causes segfaults on x86 * Sat May 13 2006 Jarod Wilson 0.104-3 - rebuilt against latest X libs libwvstreams-4.2.2-1 -------------------- * Wed May 24 2006 Harald Hoyer 4.2.2-1 - version 4.2.2 - fixed multilib issue (bug #192717) lsof-4.77-1 ----------- * Wed May 24 2006 Karel Zak 4.77-1 - upgrade to 4.77 (fix #186637) mkinitrd-5.0.41-1 ----------------- * Wed May 24 2006 Peter Jones - 5.0.41-1 - (very) basic multipath support - minor fixes for usb neon-0.25.5-4 ------------- * Wed May 24 2006 Joe Orton 0.25.5-4 - add multilib fixes for neon-config (#192734) net-snmp-5.3.1.pre2-2 --------------------- * Wed May 24 2006 Radek Vokal 5.3.1.pre2-2 - another attempt to fix multilib issue. Generate dummy net-snmp-config.h file openoffice.org-1:2.0.3-3.2 -------------------------- * Wed May 24 2006 Caolan McNamara - 1:2.0.3-3.2 - enable lockdown functionality, fix crash on ESC on right click submenus - re-enable "Reverse" on print dialog, it's a cups option pam-0.99.4.0-4 -------------- * Wed May 24 2006 Tomas Mraz 0.99.4.0-4 - actually don't link to libssl as it is not used (#191915) * Wed May 17 2006 Tomas Mraz 0.99.4.0-3 - use md5 implementation from pam_unix in pam_namespace - pam_namespace should call setexeccon only when selinux is enabled * Tue May 16 2006 Tomas Mraz 0.99.4.0-2 - pam_console_apply shouldn't access /var when called with -r (#191401) - actually apply the large-uid patch - don't build hmactest in pam_timestamp so openssl-devel is not required - add missing buildrequires (#191915) policycoreutils-1.30.10-2 ------------------------- * Wed May 24 2006 James Antill 1.30.10-2 - secon fixes for --self-exec etc. - secon change from level => sensitivity, add clearance. - Add mass relabel AUDIT patch, but disable it until kernel problem solved. rhythmbox-0.9.4.1-5 ------------------- * Wed May 24 2006 John (J5) Palmieri - 0.9.4.1-5 - Patch to build with latest libnotify * Mon May 22 2006 Matthias Clasen - 0.9.4.1-4 - Rebuild * Sun May 21 2006 Matthias Clasen - 0.9.4.1-3 - Add missing BuildRequires (#129145) yum-2.6.1-2 ----------- * Wed May 24 2006 Paul Nasrat - 2.6.1-2 - backport mirror failure callback Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 beagle - 0.2.6-3.s390 requires mono(gmime-sharp) = 0:2.1.0.0 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 scim-chewing - 0.2.1-6.s390 requires libchewing.so.2 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 systemtap - 0.5.5-2.s390 requires kernel >= 0:2.6.9-11 tomboy - 0.3.5-4.s390 requires mono(gmime-sharp) = 0:2.1.0.0 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU beagle - 0.2.6-3.i386 requires mono(gmime-sharp) = 0:2.1.0.0 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU scim-chewing - 0.2.1-6.i386 requires libchewing.so.2 tomboy - 0.3.5-4.i386 requires mono(gmime-sharp) = 0:2.1.0.0 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 scim-chewing - 0.2.1-6.ppc64 requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU beagle - 0.2.6-3.x86_64 requires mono(gmime-sharp) = 0:2.1.0.0 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU scim-chewing - 0.2.1-6.x86_64 requires libchewing.so.2()(64bit) tomboy - 0.3.5-4.x86_64 requires mono(gmime-sharp) = 0:2.1.0.0 Broken deps for ppc ---------------------------------------------------------- beagle - 0.2.6-3.ppc requires mono(gmime-sharp) = 0:2.1.0.0 scim-chewing - 0.2.1-6.ppc requires libchewing.so.2 tomboy - 0.3.5-4.ppc requires mono(gmime-sharp) = 0:2.1.0.0 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 beagle - 0.2.6-3.s390x requires mono(gmime-sharp) = 0:2.1.0.0 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) scim-chewing - 0.2.1-6.s390x requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 systemtap - 0.5.5-2.s390x requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for ia64 ---------------------------------------------------------- beagle - 0.2.6-3.ia64 requires mono(gmime-sharp) = 0:2.1.0.0 rgmanager - 1.9.31-3.ia64 requires ccs scim-chewing - 0.2.1-6.ia64 requires libchewing.so.2()(64bit) tomboy - 0.3.5-4.ia64 requires mono(gmime-sharp) = 0:2.1.0.0 From felipe.alfaro at gmail.com Thu May 25 18:24:02 2006 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 25 May 2006 20:24:02 +0200 Subject: Making LDAP easier to use In-Reply-To: References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> <1148562955.8185.16.camel@laurel.intra.city-fan.org> Message-ID: <6f6293f10605251124x43dffe42qae9446b883226e90@mail.gmail.com> > Along these lines has anyone here setup Fedora Directory server > in place of openldap?? Me > If so I am curious what if any additional problems were encountered. Not much: it works pretty well. Fedora Directory Server 1.0.1 had problems with the pasword change extended operation, but Richard fixed the problem and the fix is already in version 1.0.2. From Matt_Domsch at dell.com Thu May 25 19:57:02 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 25 May 2006 14:57:02 -0500 Subject: rawhide rebuild in mock status 2006-05-25 Message-ID: <20060525195702.GA9628@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: pam 191915 ASSIGNED Rawhide-in-Mock Build Results for x86_64 Architecture Thu May 25 14:50:53 CDT 2006 Number failed to build: 174 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 146 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 7 ---------------------------------- elilo emacs gcc magma-plugins memtest86+ rgmanager SDL With bugs filed: 139 ---------------------------------- arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Rawhide-in-Mock Build Results for i386 Architecture Thu May 25 14:52:06 CDT 2006 Number failed to build: 163 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 152 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 7 ---------------------------------- apr emacs gpart magma-plugins rgmanager SDL sg3_utils With bugs filed: 145 ---------------------------------- arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] control-center ['192233 NEW'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnotify ['191731 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-glint ['192365 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-tseng ['192385 CLOSED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ -- 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 cra at WPI.EDU Thu May 25 20:28:39 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 25 May 2006 16:28:39 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060525131154.GA969949@hiwaay.net> References: <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> <20060525002447.GA898192@hiwaay.net> <4475A4E5.8020607@mharris.ca> <20060525131154.GA969949@hiwaay.net> Message-ID: <20060525202839.GG7685@angus.ind.WPI.EDU> On Thu, May 25, 2006 at 08:11:54AM -0500, Chris Adams wrote: > Once upon a time, Mike A. Harris said: > > >I still use plain > > >old 6x13 (aka fixed) as my terminal font of choice. Is there a way to > > >get the equivalent font without old-style core fonts? > > > > xterm supports Xft/fontconfig, you simply need to pass the right > > commandline options to it. > > Yes, I know. Again, is there a way to get the same font as the old core > fonts "fixed" from Xft? Is that font available from Xft? This looks the same to me: xterm -fa miscfixed -fs 10 From bernie at develer.com Thu May 25 21:05:40 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 25 May 2006 23:05:40 +0200 Subject: Making LDAP easier to use In-Reply-To: <1148565071.4310.612.camel@sundaram.pnq.redhat.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> <1148565071.4310.612.camel@sundaram.pnq.redhat.com> Message-ID: <44761C24.4080600@develer.com> Rahul Sundaram wrote: >> Unfortunately, it's not like you can write a couple of >> new applications and you're done. It would take some >> commitment by a distribution such as Fedora to bring the >> small bits together. > > A distribution is just a means for people to work together. Talking > about nice ideas without development isnt going to go far. You are right. In my free time, I could contribute a list of existing interoperability and usability issues. I could file them as Bugzilla entries and create a meta-bug to group them together. Would something like this be useful as a starting point? I could also go a step further and attach a few small configuration patches for the individual package maintainers to apply. Fixing code issues requires familiarity with several projects, which I don't have. Extending the Fedora administration tools requires Python, which I don't know. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From david at fubar.dk Thu May 25 22:15:54 2006 From: david at fubar.dk (David Zeuthen) Date: Thu, 25 May 2006 18:15:54 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4475AE0D.6080808@redhat.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> <4474F38D.9010308@mharris.ca> <4475AE0D.6080808@redhat.com> Message-ID: <1148595355.4600.22.camel@daxter.boston.redhat.com> On Thu, 2006-05-25 at 09:15 -0400, Adam Jackson wrote: > > Do the OLPC people require a solution right now, or can they wait until > > some yet unnamed person writes a core fonts compatibility layer that > > sits on top of fontconfig/Xft? If you're asking whether we plan to include support for core fonts in OLPC the answer is no. Not if we can avoid it :-) > Are we really requiring FC6 and OLPC to be built from the same image, or > do we get a flag for it at build time? We really don't want to rebuild X.org for OLPC if we can avoid it. There's also a world outside OLPC and Fedora, namely other derived distributions based on Fedora. They too will benefit from the requests we now put on the table and hopefully their life will become simpler too if we get the dependencies and package split-ups right in Core. David From bernie at develer.com Fri May 26 00:38:45 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 26 May 2006 02:38:45 +0200 Subject: Making LDAP easier to use In-Reply-To: <6f6293f10605250251r6be2fc34y1b6f03210c781184@mail.gmail.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> <6f6293f10605250251r6be2fc34y1b6f03210c781184@mail.gmail.com> Message-ID: <44764E15.70307@develer.com> Felipe Alfaro Solana wrote: >> Most tools are there already, but not designed or tested >> to work well together. And it's because very few people >> go through the pain of setting up an LDAP-based LAN. > > I have set up some LDAP-based LAN's and I think that, although not > straightforward as installing Linux and clicking Next, Next, Next, > i'ts not as difficult as it could seem. Really? Have you imported and existing userbase? Did you enable TLS? Replication? Kerberos? SASL? After months of occasional research and fiddling, I'm still unable to do effective Single Sign On for the intranet services (IMAP, Apache, NFS...) with any of the clients (NT, Linux, OSX). > You can use "libuser", which supports several backends, being LDAP on > of then. I'm using > luseradd/lusermod/luserdel/lgroupadd/lgroupdel/lgroupmod from libuser > to manage my LDAP users and its work very well. Looks nice! I'm currently unable to make any changes because of this: Error initializing libuser: could not negotiate TLS with LDAP server. And it's weird, because I've configured my ldap.conf to use the ldapi socket locally and no TLS is needed for the other tools I use. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Fri May 26 00:48:13 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 26 May 2006 02:48:13 +0200 Subject: Making LDAP easier to use In-Reply-To: <1148562955.8185.16.camel@laurel.intra.city-fan.org> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> <1148562955.8185.16.camel@laurel.intra.city-fan.org> Message-ID: <4476504D.1040309@develer.com> Paul Howarth wrote: > lat (LDAP Administration Tool) is quite nice and is awaiting a > maintainer in Extras: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177580 That's indeed the best GUI tool I've seen so far for managing LDAP. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From seanlkml at sympatico.ca Fri May 26 03:58:41 2006 From: seanlkml at sympatico.ca (Sean) Date: Thu, 25 May 2006 23:58:41 -0400 Subject: gtk thread segmentation faults.. Message-ID: With the latest rawhide, the following test program generates a segfault; backtrace below. Is this a known problem? If not, where should it be reported? Thanks Sean #include int main (int argc, char *argv[]) { GtkWidget *window; g_thread_init(NULL); gdk_threads_init(); gdk_threads_enter(); gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_widget_show(window); gtk_main(); gdk_threads_leave(); return 0; } [Thread debugging using libthread_db enabled] [New Thread -1208662336 (LWP 20050)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208662336 (LWP 20050)] 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 (gdb) bt #0 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 #1 0x00b481cd in g_thread_init () from /usr/lib/libgthread-1.2.so.0 #2 0x00c97a2f in g_slice_alloc () from /lib/libglib-2.0.so.0 #3 0x00c741a9 in g_hash_table_new_full () from /lib/libglib-2.0.so.0 #4 0x00c74228 in g_hash_table_new () from /lib/libglib-2.0.so.0 #5 0x00c6dc76 in g_quark_from_static_string () from /lib/libglib-2.0.so.0 #6 0x005016db in g_type_init_with_debug_flags () from /lib/libgobject-2.0.so.0 #7 0x005018b2 in g_type_init () from /lib/libgobject-2.0.so.0 #8 0x00124118 in gdk_pre_parse_libgtk_only () from /usr/lib/libgdk-x11-2.0.so.0 #9 0x0072ae65 in gtk_init_with_args () from /usr/lib/libgtk-x11-2.0.so.0 #10 0x00c8d66d in g_option_context_parse () from /lib/libglib-2.0.so.0 #11 0x0072a96c in gtk_parse_args () from /usr/lib/libgtk-x11-2.0.so.0 #12 0x0072a9e4 in gtk_init_check () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x0072aa24 in gtk_init () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x08065229 in main (argc=1, argv=0xbf875344) at qtry.c:11 From kevin.kofler at chello.at Fri May 26 06:19:34 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 26 May 2006 06:19:34 +0000 (UTC) Subject: NetworkManager system-wide use Message-ID: FYI, I found this while browsing the accepted SoC applications: http://code.google.com/soc/gentoo/appinfo.html?csaid=1875FC7DA1FE03E4 > If this is completed, work should be done on WiFi key handling: currently, > NetworkManager will ask the user for the WEP or WPA key of the wireless > network it connects to every time it connects, which isn't very > user-friendly. As Gentoo allows one to configure wireless network settings > in /etc/conf.d/wireless, the keys could be retrieved from that file. Some > changes to NetworkManager's core will be necessary to support this though, > which implies one can't be sure it'll be accepted by the core maintainers. Looks like you can take this off your TODO. :-) Kevin Kofler From sundaram at fedoraproject.org Fri May 26 07:10:24 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 May 2006 12:40:24 +0530 Subject: Making LDAP easier to use In-Reply-To: <44761C24.4080600@develer.com> References: <200605220724.k4M7OPT5015123@porkchop.devel.redhat.com> <44740E3E.9070001@develer.com> <1148456985.19927.33.camel@cutter> <447415C0.8030300@develer.com> <1148458627.4310.567.camel@sundaram.pnq.redhat.com> <44754A48.8020706@develer.com> <1148565071.4310.612.camel@sundaram.pnq.redhat.com> <44761C24.4080600@develer.com> Message-ID: <1148627425.4310.627.camel@sundaram.pnq.redhat.com> On Thu, 2006-05-25 at 23:05 +0200, Bernardo Innocenti wrote: > Rahul Sundaram wrote: > > >> Unfortunately, it's not like you can write a couple of > >> new applications and you're done. It would take some > >> commitment by a distribution such as Fedora to bring the > >> small bits together. > > > > A distribution is just a means for people to work together. Talking > > about nice ideas without development isnt going to go far. > > You are right. In my free time, I could contribute a > list of existing interoperability and usability > issues. I could file them as Bugzilla entries and > create a meta-bug to group them together. > > Would something like this be useful as a starting > point? > > I could also go a step further and attach a few small > configuration patches for the individual package > maintainers to apply. > > Fixing code issues requires familiarity with several > projects, which I don't have. Extending the Fedora > administration tools requires Python, which I don't > know. Yes. Filing bugs on issues would be a good starting point. Rahul From buildsys at redhat.com Fri May 26 07:22:05 2006 From: buildsys at redhat.com (Build System) Date: Fri, 26 May 2006 03:22:05 -0400 Subject: rawhide report: 20060526 changes Message-ID: <200605260722.k4Q7M5mF022145@porkchop.devel.redhat.com> New package pygobject2 Python bindings for gobjects Updated Packages: ImageMagick-6.2.5.4-4.2.1.fc5.3 ------------------------------- * Thu May 25 2006 Matthias Clasen - 6.2.5.4-4.2.1.fc5.3 - Include the needed .la files again anaconda-11.1.0.21-1 -------------------- * Thu May 25 2006 Chris Lumens 11.1.0.21-1 - Fix required CD dialog (pnasrat). - More anaconda class in the interfaces (dcantrel). - More netlink helper functions (dcantrel). - Don't allow logical volumes to be smaller than the volume group's PE size in interactive installs (#186412). - Make error handling for missing packages more robust and allow retrying (clumens, pnasrat, #183974). - Fix hard drive installs (#185292, #187941). - Don't always show partition review dialog in text installs. - Fix text-mode installs by adding more stuff to minstg2.img (#191991). - Skip netlink messages with invalid ARP header (dcantrel). - Add pygobject to install images (katzj). audit-1.2.3-1 ------------- * Thu May 25 2006 Steve Grubb 1.2.3-1 - Apply patch to ensure watches only associate with exit filter - Apply patch to correctly show new operators when new listing format is used - Apply patch to pull kernel's audit.h into python bindings - Collect signal sender's context autofs-1:5.0.0_beta3-1 ---------------------- * Thu May 25 2006 Ian Kent - 5.0.0_beta3-1 - update source to version 5.0.0_beta3. - add patch to remove extra debug print. - add patch to - fix memory alloc error in nis lookup module. - add "_" to "." mapname translation to nis lookup module. - add patch to add owner pid to mount list struct. - add patch to disable NFSv4 when probing hosts (at least foe now). - add patch to fix white space handling in replicated server selection code. - add patch to prevent striping of debug info macro patch (Jeff Moyer). - add patch to add sanity checks on rmdir_path and unlink (Jeff Moyer). - add patch to fix e2fsck error code check (Jeff Moyer). bash-3.1-13 ----------- * Fri May 26 2006 Tim Waugh 3.1-13 - Another fix for the sighandler patch (bug #192297). beagle-0.2.6-4 -------------- * Thu May 25 2006 Nalin Dahyabhai - 0.2.6-4 - rebuild bind-30:9.3.2-23.FC6 -------------------- * Thu May 25 2006 Jeremy Katz - 30:9.3.2-23.FC6 - rebuild for -devel deps control-center-1:2.14.1-4 ------------------------- * Thu May 25 2006 Matthias Clasen - 2.14.1-4 - Add missing buildrequires elfutils-0.120-3 ---------------- * Thu May 25 2006 Jeremy Katz - 0.120-3 - rebuild to pick up -devel deps eruby-1.0.5-6 ------------- * Thu May 25 2006 Jeremy Katz - 1.0.5-6 - rebuild to pick up -devel deps gd-2.0.33-7 ----------- * Thu May 25 2006 Ivana Varekova - 2.0.33-7 - fix multilib problem (add pkgconfig) * Fri Feb 10 2006 Jesse Keating - 2.0.33-6.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating - 2.0.33-6.1 - rebuilt for new gcc4.1 snapshot and glibc changes glib2-2.11.1-5 -------------- * Thu May 25 2006 Matthias Clasen - 2.11.1-5 - Fix some fallout * Thu May 25 2006 Matthias Clasen - 2.11.1-4 - Include static libraries, since anaconda needs them (#193143) * Thu May 25 2006 Matthias Clasen - 2.11.1-3 - Keep glibconfig.h in /usr/lib gphoto2-2.1.99-12 ----------------- * Thu May 25 2006 Radek Vokal 2.1.99-12 - fix multilib -devel conflicts (#192678) kernel-2.6.16-1.2218_FC6 ------------------------ * Thu May 25 2006 Juan Quintela - enable xen PAE kernels for testing. - rebase xen patch (linux-2.6-xen cset 22558, linux-2.6 cset 27227) libpng-2:1.2.10-5 ----------------- * Thu May 25 2006 Matthias Clasen - 2:1.2.10-5 - Fix some paths in the -config script * Tue May 23 2006 Matthias Clasen - 2:1.2.10-4 - fix multilib conflicts * Mon May 22 2006 Matthias Clasen - 2:1.2.10-3 - Add a comment about the need to keep static libraries libselinux-1.30.10-3 -------------------- * Thu May 25 2006 Dan Walsh 1.30.10-3 - Bump requires to grab latest libsepol libtiff-3.8.2-3 --------------- * Thu May 25 2006 Matthias Clasen - 3.8.2-3 - Fix overflows in tiffsplit net-snmp-5.3.1.pre2-3 --------------------- * Thu May 25 2006 Radek Vokal 5.3.1.pre2-3 - another multilib fix. Fix also net-snmp-config script policycoreutils-1.30.10-3 ------------------------- * Wed May 24 2006 James Antill 1.30.10-3 - secon man page and getopt fixes. - Enable mass relabel audit, even though it doesn't work. pygtk2-2.9.0-2 -------------- * Thu May 25 2006 John (J5) Palmieri - 2.9.0-2 - Add BR for pygobject2 - Take out files now packaged in pygobject2 from the files list * Wed May 10 2006 Matthias Clasem - 2.9.0-1 - Update to 2.9.0 pykickstart-0.30-1 ------------------ * Thu May 25 2006 Chris Lumens 0.30-1 - Change order of LVM-related writing functions (#193073). - Require urlgrabber. - Return a more useful error message on unknown commands. - Fix logvol writing typo. - Make ksvalidator validate from a URL in addition to a file. - Don't write out an empty packages section (#192851). system-config-printer-0.7.9-1 ----------------------------- * Thu May 25 2006 Tim Waugh 0.7.9-1 - Updated to pycups-1.9.11. - Updated to system-config-printer-0.7.9. tomboy-0.3.5-5 -------------- * Thu May 25 2006 Nalin Dahyabhai - 0.3.5-5 - rebuild vnc-4.1.2-0.1 ------------- * Thu May 25 2006 Jitka Kudrnacova 4.1.2-0.1 - fixed building on ppc64 xorg-x11-drv-tseng-1.1.0-3 -------------------------- * Thu May 25 2006 Mike A. Harris 1.1.0-3 - Added "BuildRequires: xorg-x11-proto-devel" for (#192385) xorg-x11-proto-devel-7.1-1 -------------------------- * Thu May 25 2006 Mike A. Harris 7.1-1 - Bump package version-release to 7.1-1 for X.Org X11R7.1 release. yum-2.6.1-3 ----------- * Thu May 25 2006 Paul Nasrat - 2.6.1-3 - Rebuild with patch Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 rhythmbox - 0.8.8-2.s390 requires libgstgconf-0.8.so.0 rhythmbox - 0.8.8-2.s390 requires libgstreamer-0.8.so.1 rhythmbox - 0.8.8-2.s390 requires libgstcontrol-0.8.so.1 scim-chewing - 0.2.1-6.s390 requires libchewing.so.2 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 systemtap - 0.5.5-2.s390 requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU scim-chewing - 0.2.1-6.i386 requires libchewing.so.2 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 scim-chewing - 0.2.1-6.ppc64 requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU scim-chewing - 0.2.1-6.x86_64 requires libchewing.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- scim-chewing - 0.2.1-6.ppc requires libchewing.so.2 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so rhythmbox - 0.8.8-2.s390x requires libgstcontrol-0.8.so.1()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstgconf-0.8.so.0()(64bit) rhythmbox - 0.8.8-2.s390x requires libgstreamer-0.8.so.1()(64bit) scim-chewing - 0.2.1-6.s390x requires libchewing.so.2()(64bit) struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 systemtap - 0.5.5-2.s390x requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs scim-chewing - 0.2.1-6.ia64 requires libchewing.so.2()(64bit) From samueldg at arcoscom.com Fri May 26 08:02:59 2006 From: samueldg at arcoscom.com (Samuel =?iso-8859-1?Q?D=EDaz_Garc=EDa?=) Date: Fri, 26 May 2006 10:02:59 +0200 (CEST) Subject: Problems compiling extensions to iptables Message-ID: <37775.195.55.244.106.1148630579.squirrel@www.arcoscom.com> I've installed iptables.src.rpm package and I'm editing iptables.spec to include some pom extensions into it. I had been edited successfully iptables.spec to allow patches add the extensions, but when I run: rpmbuild -bb --target i686 SPECS/iptables_My.spec It compiles all fine, except my extensions. If I use netfilter original sources and standard make procedure, I have no problems, but using rpmbuild (as I wrote) I can see the new iptables extensions don't compile. This extensions have 2 parts, kernel part and iptables part, the kernel part is working fine, compiles and install fine, but iptables part don't compiles those extensions, it compiles all fine and create .rpm files without problems, but the addes iptables extensions .so files weren't added. Any help/hint to allow me how to solve this problem? Thanks -- Samuel D?az Garc?a ArcosCom Wireless, S.L.L. CIF: B11828068 c/ Romero Gago, 19 Arcos de la Frontera 11630 - Cadiz http://www.arcoscom.com mailto:samueldg at arcoscom.com msn: samueldg at arcoscom.com Tlfn.: 956 70 13 15 Fax: 956 70 34 83 From nicolas.mailhot at laposte.net Fri May 26 09:54:13 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 26 May 2006 11:54:13 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474F771.20904@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> <1148422547.25336.13.camel@rousalka.dyndns.org> <4474F771.20904@mharris.ca> Message-ID: <1148637261.5126.14.camel@rousalka.dyndns.org> Le mercredi 24 mai 2006 ? 20:16 -0400, Mike A. Harris a ?crit : > When you see the "can't find font fixed" error, it is a clear sign right > now that either xfs isn't running, or xfs is misconfigured, or one or > more core font directories is misconfigured or improperly prepped. > > IMHO, replacing that problem, with an X server that starts up ok, > but where the core fonts system may still be misconfigured or otherwise > unuseable by one or more apps, simply changes the problem to be a > random app failure the user can't easily diagnose - causing them to > flood bugzilla with various "my app starts with boxes instead of > letters" problems, or worse, they click on an icon on their working > desktop, and the app never starts at all - so they file a bug report > against that application. > > At least with the current failure mode, the person has to fix the > font subsystem configuration problem before they can even start the > server, and once they do fix that - they are unlikely to see individual > applications failing miserably for no visible reason. Do you know how ridiculous this reason is nowadays ? How many people are able to "fix" the system in console mode ? You don't hear people hitting the fixed problem because they just dump Linux and forget about it - you've escalated a small problem to catastrophic level. (let me remind you that people most needing core font in FC are emacs users, emacs haven't moved to fontconfig yet because its users are "real men" which do not need aa, unicode and more-than-ascii support so these real men can edit config files and fix their xfs even if the X server started gracefully for everyone else) Nowadays a lot more apps use sound than core fonts - would you like it if the alsa maintainer dumped users to the CLI when alsa is misconfigured ? Just so he can force people to fix their config themselves instead of entering bugs ? Proposal : build in xorg a single ascii (127 char) 75 dpi fixed font, and alias it to the common used names (to comply with the letter of the spec). Have core font users install/configure anything more complex. Twist 1 : add a fail-if-no-xfs param in /etc, have xorg startup barf if this is set and xfs is dead, and have the emacs rpm scriplets set this param to true (and set it to false for the rest of the FC users) Twist 2 : build emacs or xemacs with one of the experimental fontconfig patches floating around, push it to rawhide and use the time to the next release to stabilise it I know I'm the devil's advocate here, but someone has to be -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From otaylor at redhat.com Fri May 26 09:22:41 2006 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 26 May 2006 05:22:41 -0400 Subject: gtk thread segmentation faults.. In-Reply-To: <20060525235841.acc7b19f.seanlkml@sympatico.ca> References: <20060525235841.acc7b19f.seanlkml@sympatico.ca> Message-ID: <1148635361.12495.15.camel@localhost.localdomain> On Thu, 2006-05-25 at 23:58 -0400, Sean wrote: > With the latest rawhide, the following test program generates > a segfault; backtrace below. Is this a known problem? > If not, where should it be reported? Does it work if you call gtk_init() before gdk_threads_enter()? I wouldn't consider the code below normal, though I can't *offhand* think of what problems it would cause. If not, then install the -debuginfo packages, get a decent backtrace, then report it either in Red Hat bugzilla or GNOME bugzilla; I don't think either one is particular more right then the other; it probably would be an upstream bug, but it's hard to say. Owen > Thanks > Sean > > #include > int main (int argc, char *argv[]) > { > GtkWidget *window; > > g_thread_init(NULL); > gdk_threads_init(); > gdk_threads_enter(); > > gtk_init(&argc, &argv); > > window = gtk_window_new(GTK_WINDOW_TOPLEVEL); > gtk_widget_show(window); > > gtk_main(); > gdk_threads_leave(); > > return 0; > } > > > [Thread debugging using libthread_db enabled] > [New Thread -1208662336 (LWP 20050)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208662336 (LWP 20050)] > 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 > (gdb) bt > #0 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 > #1 0x00b481cd in g_thread_init () from /usr/lib/libgthread-1.2.so.0 > #2 0x00c97a2f in g_slice_alloc () from /lib/libglib-2.0.so.0 > #3 0x00c741a9 in g_hash_table_new_full () from /lib/libglib-2.0.so.0 > #4 0x00c74228 in g_hash_table_new () from /lib/libglib-2.0.so.0 > #5 0x00c6dc76 in g_quark_from_static_string () from /lib/libglib-2.0.so.0 > #6 0x005016db in g_type_init_with_debug_flags () from /lib/libgobject-2.0.so.0 > #7 0x005018b2 in g_type_init () from /lib/libgobject-2.0.so.0 > #8 0x00124118 in gdk_pre_parse_libgtk_only () from /usr/lib/libgdk-x11-2.0.so.0 > #9 0x0072ae65 in gtk_init_with_args () from /usr/lib/libgtk-x11-2.0.so.0 > #10 0x00c8d66d in g_option_context_parse () from /lib/libglib-2.0.so.0 > #11 0x0072a96c in gtk_parse_args () from /usr/lib/libgtk-x11-2.0.so.0 > #12 0x0072a9e4 in gtk_init_check () from /usr/lib/libgtk-x11-2.0.so.0 > #13 0x0072aa24 in gtk_init () from /usr/lib/libgtk-x11-2.0.so.0 > #14 0x08065229 in main (argc=1, argv=0xbf875344) at qtry.c:11 > From mailinglists at erwinrol.com Fri May 26 12:54:23 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 26 May 2006 14:54:23 +0200 Subject: gtk thread segmentation faults.. In-Reply-To: <1148635361.12495.15.camel@localhost.localdomain> References: <20060525235841.acc7b19f.seanlkml@sympatico.ca> <1148635361.12495.15.camel@localhost.localdomain> Message-ID: <1148648063.14918.197.camel@xpc.home.erwinrol.com> I bet you tried to link with -lgthead instead of -lgthead-2.0. gcc `pkg-config --cflags --libs gtk+-2.0 gthread-2.0` -g gtk_test.c That works fine for me, but the following gives exactly your error; gcc `pkg-config --cflags --libs gtk+-2.0 gthread` -g gtk_test.c - Erwin On Fri, 2006-05-26 at 05:22 -0400, Owen Taylor wrote: > On Thu, 2006-05-25 at 23:58 -0400, Sean wrote: > > With the latest rawhide, the following test program generates > > a segfault; backtrace below. Is this a known problem? > > If not, where should it be reported? > > Does it work if you call gtk_init() before gdk_threads_enter()? > I wouldn't consider the code below normal, though I can't > *offhand* think of what problems it would cause. > > If not, then install the -debuginfo packages, get a decent backtrace, > then report it either in Red Hat bugzilla or GNOME bugzilla; I > don't think either one is particular more right then the other; > it probably would be an upstream bug, but it's hard to say. > > Owen > > > Thanks > > Sean > > > > #include > > int main (int argc, char *argv[]) > > { > > GtkWidget *window; > > > > g_thread_init(NULL); > > gdk_threads_init(); > > gdk_threads_enter(); > > > > gtk_init(&argc, &argv); > > > > window = gtk_window_new(GTK_WINDOW_TOPLEVEL); > > gtk_widget_show(window); > > > > gtk_main(); > > gdk_threads_leave(); > > > > return 0; > > } > > > > > > [Thread debugging using libthread_db enabled] > > [New Thread -1208662336 (LWP 20050)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1208662336 (LWP 20050)] > > 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 > > (gdb) bt > > #0 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 > > #1 0x00b481cd in g_thread_init () from /usr/lib/libgthread-1.2.so.0 > > #2 0x00c97a2f in g_slice_alloc () from /lib/libglib-2.0.so.0 > > #3 0x00c741a9 in g_hash_table_new_full () from /lib/libglib-2.0.so.0 > > #4 0x00c74228 in g_hash_table_new () from /lib/libglib-2.0.so.0 > > #5 0x00c6dc76 in g_quark_from_static_string () from /lib/libglib-2.0.so.0 > > #6 0x005016db in g_type_init_with_debug_flags () from /lib/libgobject-2.0.so.0 > > #7 0x005018b2 in g_type_init () from /lib/libgobject-2.0.so.0 > > #8 0x00124118 in gdk_pre_parse_libgtk_only () from /usr/lib/libgdk-x11-2.0.so.0 > > #9 0x0072ae65 in gtk_init_with_args () from /usr/lib/libgtk-x11-2.0.so.0 > > #10 0x00c8d66d in g_option_context_parse () from /lib/libglib-2.0.so.0 > > #11 0x0072a96c in gtk_parse_args () from /usr/lib/libgtk-x11-2.0.so.0 > > #12 0x0072a9e4 in gtk_init_check () from /usr/lib/libgtk-x11-2.0.so.0 > > #13 0x0072aa24 in gtk_init () from /usr/lib/libgtk-x11-2.0.so.0 > > #14 0x08065229 in main (argc=1, argv=0xbf875344) at qtry.c:11 > > > From mailinglists at erwinrol.com Fri May 26 12:58:52 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 26 May 2006 14:58:52 +0200 Subject: gtk thread segmentation faults.. In-Reply-To: <1148648063.14918.197.camel@xpc.home.erwinrol.com> References: <20060525235841.acc7b19f.seanlkml@sympatico.ca> <1148635361.12495.15.camel@localhost.localdomain> <1148648063.14918.197.camel@xpc.home.erwinrol.com> Message-ID: <1148648332.14918.201.camel@xpc.home.erwinrol.com> On Fri, 2006-05-26 at 14:54 +0200, Erwin Rol wrote: > I bet you tried to link with -lgthead instead of -lgthead-2.0. > > > Program received signal SIGSEGV, Segmentation fault. > > > [Switching to Thread -1208662336 (LWP 20050)] > > > 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 > > > (gdb) bt > > > #0 0x00acb27e in pthread_mutex_trylock () from /lib/libpthread.so.0 > > > #1 0x00b481cd in g_thread_init () from /usr/lib/libgthread-1.2.so.0 ^^^^^^^^^^^^^^^ So I won my bet already :-) - Erwin From seanlkml at sympatico.ca Fri May 26 13:02:08 2006 From: seanlkml at sympatico.ca (Sean) Date: Fri, 26 May 2006 09:02:08 -0400 Subject: gtk thread segmentation faults.. In-Reply-To: <1148648063.14918.197.camel@xpc.home.erwinrol.com> References: <20060525235841.acc7b19f.seanlkml@sympatico.ca> <1148635361.12495.15.camel@localhost.localdomain> <1148648063.14918.197.camel@xpc.home.erwinrol.com> Message-ID: On Fri, 26 May 2006 14:54:23 +0200 Erwin Rol wrote: > I bet you tried to link with -lgthead instead of -lgthead-2.0. > > gcc `pkg-config --cflags --libs gtk+-2.0 gthread-2.0` -g gtk_test.c *blush*... thanks Erwin.. Sean From dcbw at redhat.com Fri May 26 14:16:56 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 26 May 2006 10:16:56 -0400 Subject: NetworkManager system-wide use In-Reply-To: References: Message-ID: <1148653016.2468.4.camel@localhost.localdomain> On Fri, 2006-05-26 at 06:19 +0000, Kevin Kofler wrote: > FYI, I found this while browsing the accepted SoC applications: > http://code.google.com/soc/gentoo/appinfo.html?csaid=1875FC7DA1FE03E4 > > > If this is completed, work should be done on WiFi key handling: currently, > > NetworkManager will ask the user for the WEP or WPA key of the wireless > > network it connects to every time it connects, which isn't very > > user-friendly. As Gentoo allows one to configure wireless network settings > > in /etc/conf.d/wireless, the keys could be retrieved from that file. Some > > changes to NetworkManager's core will be necessary to support this though, > > which implies one can't be sure it'll be accepted by the core maintainers. > > Looks like you can take this off your TODO. :-) Sort of... We've already got plans in this area, but of course if somebody else wants to fix it, that's great :) http://live.gnome.org/NetworkManagerToDo?action=show See the top item there. We're not necessarily going to be pulling keys from config files here; instead it will be a slightly larger scoped solution. The idea here is to do it right, not just hack in a shim over the existing (somewhat-broken shellscript hacktower hell) config stuff that many distros already have. Dan From Matt_Domsch at dell.com Fri May 26 15:27:01 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 26 May 2006 10:27:01 -0500 Subject: rawhide rebuild in mock status 2006-05-26 Message-ID: <20060526152701.GA32444@lists.us.dell.com> Rawhide-in-Mock Build Results for x86_64 Architecture Fri May 26 10:24:21 CDT 2006 Number failed to build: 174 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 146 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 8 ---------------------------------- elilo emacs gcc magma-plugins memtest86+ pygtk2 rgmanager SDL With bugs filed: 138 ---------------------------------- arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] valgrind ['191820 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Rawhide-in-Mock Build Results for i386 Architecture Fri May 26 10:24:58 CDT 2006 Number failed to build: 163 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 152 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 8 ---------------------------------- apr emacs gpart magma-plugins pygtk2 rgmanager SDL sg3_utils With bugs filed: 144 ---------------------------------- arptables_jf ['191688 NEW'] arts ['192367 NEEDINFO'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] epiphany ['191665 NEW'] frysk ['192256 NEW'] gaim ['192496 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gnbd-kernel ['192573 NEW'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnucash ['192008 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libnotify ['191731 NEW'] libvte-java ['192533 NEW'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 NEW'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 ASSIGNED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-glint ['192365 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 ASSIGNED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ -- 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 katzj at redhat.com Fri May 26 15:34:04 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 26 May 2006 11:34:04 -0400 Subject: rawhide rebuild in mock status 2006-05-26 In-Reply-To: <20060526152701.GA32444@lists.us.dell.com> References: <20060526152701.GA32444@lists.us.dell.com> Message-ID: <1148657644.2558.6.camel@aglarond.local> On Fri, 2006-05-26 at 10:27 -0500, Matt Domsch wrote: > pygtk2 And I just fixed this, so no need for a bug. Jeremy From thacker at math.cornell.edu Fri May 26 15:36:53 2006 From: thacker at math.cornell.edu (John Thacker) Date: Fri, 26 May 2006 11:36:53 -0400 Subject: rawhide rebuild in mock status 2006-05-26 In-Reply-To: <20060526152701.GA32444@lists.us.dell.com> References: <20060526152701.GA32444@lists.us.dell.com> Message-ID: <20060526153653.GA5000@thacker.dyndns.org> On Fri, May 26, 2006 at 10:27:01AM -0500, Matt Domsch wrote: > Rawhide-in-Mock Build Results for i386 Architecture Fri May 26 10:24:58 CDT 2006 > (there may be some duplicates if rawhide has 2 versions of a package) > > rhythmbox ['191760 CLOSED'] Hmm. For some reason the very old rhythmbox-0.8.8-2 src rpm is sitting around in rawhide's SRPM directory. It doesn't build. rhythmbox-0.9.4.1-5.src.rpm does build (after some recent changes), hence why the bug is closed. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Fri May 26 15:46:09 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 26 May 2006 11:46:09 -0400 Subject: rawhide rebuild in mock status 2006-05-26 In-Reply-To: <20060526153653.GA5000@thacker.dyndns.org> References: <20060526152701.GA32444@lists.us.dell.com> <20060526153653.GA5000@thacker.dyndns.org> Message-ID: <1148658369.2558.9.camel@aglarond.local> On Fri, 2006-05-26 at 11:36 -0400, John Thacker wrote: > On Fri, May 26, 2006 at 10:27:01AM -0500, Matt Domsch wrote: > > Rawhide-in-Mock Build Results for i386 Architecture Fri May 26 10:24:58 CDT 2006 > > (there may be some duplicates if rawhide has 2 versions of a package) > > > > rhythmbox ['191760 CLOSED'] > > Hmm. For some reason the very old rhythmbox-0.8.8-2 src rpm is sitting > around in rawhide's SRPM directory. It doesn't build. > rhythmbox-0.9.4.1-5.src.rpm does build (after some recent changes), > hence why the bug is closed. As previously mentioned, src.rpms for all binary rpms of all arches are kept around. And current rhythmbox isn't being built on s390{,x} and so the older src.rpm is kept around. I'll take a stab at fixing the build on those arches... Jeremy From pbrobinson at gmail.com Fri May 26 16:03:21 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 26 May 2006 17:03:21 +0100 Subject: rawhide rebuild in mock status 2006-05-26 In-Reply-To: <1148658369.2558.9.camel@aglarond.local> References: <20060526152701.GA32444@lists.us.dell.com> <20060526153653.GA5000@thacker.dyndns.org> <1148658369.2558.9.camel@aglarond.local> Message-ID: <5256d0b0605260903k1c621825rb0478b93ef2c6413@mail.gmail.com> > > Hmm. For some reason the very old rhythmbox-0.8.8-2 src rpm is sitting > > around in rawhide's SRPM directory. It doesn't build. > > rhythmbox-0.9.4.1-5.src.rpm does build (after some recent changes), > > hence why the bug is closed. > > As previously mentioned, src.rpms for all binary rpms of all arches are > kept around. And current rhythmbox isn't being built on s390{,x} and so > the older src.rpm is kept around. > > I'll take a stab at fixing the build on those arches... If you look at the daily build reports the old 0.8 version doesn't build on those arches either! Peter From katzj at redhat.com Fri May 26 16:14:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 26 May 2006 12:14:49 -0400 Subject: rawhide rebuild in mock status 2006-05-26 In-Reply-To: <5256d0b0605260903k1c621825rb0478b93ef2c6413@mail.gmail.com> References: <20060526152701.GA32444@lists.us.dell.com> <20060526153653.GA5000@thacker.dyndns.org> <1148658369.2558.9.camel@aglarond.local> <5256d0b0605260903k1c621825rb0478b93ef2c6413@mail.gmail.com> Message-ID: <1148660089.2558.14.camel@aglarond.local> On Fri, 2006-05-26 at 17:03 +0100, Peter Robinson wrote: > > > Hmm. For some reason the very old rhythmbox-0.8.8-2 src rpm is sitting > > > around in rawhide's SRPM directory. It doesn't build. > > > rhythmbox-0.9.4.1-5.src.rpm does build (after some recent changes), > > > hence why the bug is closed. > > > > As previously mentioned, src.rpms for all binary rpms of all arches are > > kept around. And current rhythmbox isn't being built on s390{,x} and so > > the older src.rpm is kept around. > > > > I'll take a stab at fixing the build on those arches... > > If you look at the daily build reports the old 0.8 version doesn't > build on those arches either! It's not that it doesn't built -- it's the older build just continuing to be inherited. But the older version won't actually _run_ due to some of its other deps changing. But build of current rhythmbox is going along nicely on s390 right now, so this one should disappear tomorrow Jeremy From philipp_subx at redfish-solutions.com Fri May 26 17:11:50 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 11:11:50 -0600 Subject: A sole, standard proxy library for Fedora Message-ID: <447736D6.20204@redfish-solutions.com> I have a laptop that travels with me from work (where there's the use of web proxies) to home (where I don't), and was overwhelmed by the number of config files that I have to switch over every time I move from one place to the other. The list of applications is seemingly endless: * apt * yum * wget * rpm * thunderbird * firefox * evolution * sunbird * the myriad of scripts in Perl using libwww, etc. And it struck me: why not have a single libproxy.so for Fedora (or Linux/Freebsd) that has a single, system-wide copy of the state, rather than embedding *system-wide* state into each application's configuration? Windows does this: there's a single control panel you go into to enable/disable proxy services. Why can't Linux do that? How hard would it be to find the best/most extensible proxy sources out there, round them out to cover all possible services (including IMAP, Socks, RealAudio, etc) and then patch all of the applications incrementally (or have the owners patch each application) to make use of the Single, Unified Proxy Library (supple)? What am I missing here? It seems so obvious that I'm surprised it hasn't already been done. -Philip From philipp_subx at redfish-solutions.com Fri May 26 17:14:43 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 11:14:43 -0600 Subject: NetworkManager system-wide use In-Reply-To: <1148653016.2468.4.camel@localhost.localdomain> References: <1148653016.2468.4.camel@localhost.localdomain> Message-ID: <44773783.5040609@redfish-solutions.com> Dan Williams wrote: > On Fri, 2006-05-26 at 06:19 +0000, Kevin Kofler wrote: > >> FYI, I found this while browsing the accepted SoC applications: >> http://code.google.com/soc/gentoo/appinfo.html?csaid=1875FC7DA1FE03E4 >> >> >>> If this is completed, work should be done on WiFi key handling: currently, >>> NetworkManager will ask the user for the WEP or WPA key of the wireless >>> network it connects to every time it connects, which isn't very >>> user-friendly. As Gentoo allows one to configure wireless network settings >>> in /etc/conf.d/wireless, the keys could be retrieved from that file. Some >>> changes to NetworkManager's core will be necessary to support this though, >>> which implies one can't be sure it'll be accepted by the core maintainers. >>> >> Looks like you can take this off your TODO. :-) >> > > Sort of... We've already got plans in this area, but of course if > somebody else wants to fix it, that's great :) > > http://live.gnome.org/NetworkManagerToDo?action=show > > See the top item there. We're not necessarily going to be pulling keys > from config files here; instead it will be a slightly larger scoped > solution. The idea here is to do it right, not just hack in a shim over > the existing (somewhat-broken shellscript hacktower hell) config stuff > that many distros already have. > > Dan > Sorry for the slight digression, but can someone explain to me why NetworkManager has a dependency on wpa_supplicant? Not all wireless networks use WEP/WPA (some are wide open). Further, not all networked machines (like my desktop) have Wireless NIC's. It would seem to be an unnecessary (and unfounded) dependency. -Philip > > From dhollis at davehollis.com Fri May 26 17:34:22 2006 From: dhollis at davehollis.com (David Hollis) Date: Fri, 26 May 2006 13:34:22 -0400 Subject: A sole, standard proxy library for Fedora In-Reply-To: <447736D6.20204@redfish-solutions.com> References: <447736D6.20204@redfish-solutions.com> Message-ID: <1148664862.2472.7.camel@dhollis-lnx.sunera.com> On Fri, 2006-05-26 at 11:11 -0600, Philip Prindeville wrote: > I have a laptop that travels with me from work (where there's the > use of web proxies) to home (where I don't), and was overwhelmed > by the number of config files that I have to switch over every time > I move from one place to the other. Most CLI apps will honor http_proxy/ftp_proxy environment variables for proxying. GUI apps may or may not support that, I can't say that I've tried. Gnome (and I'm sure KDE) have their own control panel setting for that, but that only applies to apps that make use of their VFS library. If they do their own web access, they may not honor it. -- David Hollis -------------- 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 dhollis at davehollis.com Fri May 26 17:37:38 2006 From: dhollis at davehollis.com (David Hollis) Date: Fri, 26 May 2006 13:37:38 -0400 Subject: NetworkManager system-wide use In-Reply-To: <44773783.5040609@redfish-solutions.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> Message-ID: <1148665058.2472.10.camel@dhollis-lnx.sunera.com> On Fri, 2006-05-26 at 11:14 -0600, Philip Prindeville wrote: > Sorry for the slight digression, but can someone explain to me why > NetworkManager has a dependency on wpa_supplicant? Not all > wireless networks use WEP/WPA (some are wide open). Further, > not all networked machines (like my desktop) have Wireless NIC's. > > It would seem to be an unnecessary (and unfounded) dependency. Uh, unless I really don't understand your question, the dependency is there because SOME/MOST networks do use WEP/WPA. -- David Hollis -------------- 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 philipp_subx at redfish-solutions.com Fri May 26 17:44:04 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 11:44:04 -0600 Subject: A sole, standard proxy library for Fedora In-Reply-To: <1148664862.2472.7.camel@dhollis-lnx.sunera.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> Message-ID: <44773E64.5090907@redfish-solutions.com> David Hollis wrote: > On Fri, 2006-05-26 at 11:11 -0600, Philip Prindeville wrote: > >> I have a laptop that travels with me from work (where there's the >> use of web proxies) to home (where I don't), and was overwhelmed >> by the number of config files that I have to switch over every time >> I move from one place to the other. >> > > Most CLI apps will honor http_proxy/ftp_proxy environment variables for > proxying. GUI apps may or may not support that, I can't say that I've > tried. Gnome (and I'm sure KDE) have their own control panel setting > for that, but that only applies to apps that make use of their VFS > library. If they do their own web access, they may not honor it. > > That's not sufficient. If you have a running system, which you unplug, suspend, and plug back in, and resume on a new network... there is no way to propagate new environment variables into existing processes. And even if it were, it would not take effect with running processes. It's easier to do it with a library that can check the status of the config file each time a new connection request is made. -Philip From philipp_subx at redfish-solutions.com Fri May 26 17:48:30 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 11:48:30 -0600 Subject: NetworkManager system-wide use In-Reply-To: <1148665058.2472.10.camel@dhollis-lnx.sunera.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> Message-ID: <44773F6E.9050707@redfish-solutions.com> David Hollis wrote: > On Fri, 2006-05-26 at 11:14 -0600, Philip Prindeville wrote: > > >> Sorry for the slight digression, but can someone explain to me why >> NetworkManager has a dependency on wpa_supplicant? Not all >> wireless networks use WEP/WPA (some are wide open). Further, >> not all networked machines (like my desktop) have Wireless NIC's. >> >> It would seem to be an unnecessary (and unfounded) dependency. >> > > Uh, unless I really don't understand your question, the dependency is > there because SOME/MOST networks do use WEP/WPA. > Not true. A lot of hotspots (Starbuck's, Boise airport, certain municipal networks like Portland, OR, etc. are all open access, with no WEP/WPA). It is sometimes or even *mostly* the case, but not always. Therefore, in the cases where it doesn't apply, no dependency should exist. The RPM should have some way of detecting if wireless cards are present (perhaps using the contents of /etc/sysconfig/network-scripts/ifcfg-*) and then inferring a dependence of wpa_supplicant (which as I said, only applies IFF you have wireless hardware and the networks you use require authentication and/or privacy). NetworkManager should run quite happily if wpa_supplicant isn't present. -Philip From david at lovesunix.net Fri May 26 18:15:39 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 26 May 2006 20:15:39 +0200 Subject: NetworkManager system-wide use In-Reply-To: <44773F6E.9050707@redfish-solutions.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> Message-ID: <1148667340.2670.15.camel@price> fre, 26 05 2006 kl. 11:48 -0600, skrev Philip Prindeville: > David Hollis wrote: > > On Fri, 2006-05-26 at 11:14 -0600, Philip Prindeville wrote: > > > > > >> Sorry for the slight digression, but can someone explain to me why > >> NetworkManager has a dependency on wpa_supplicant? Not all > >> wireless networks use WEP/WPA (some are wide open). Further, > >> not all networked machines (like my desktop) have Wireless NIC's. > >> > >> It would seem to be an unnecessary (and unfounded) dependency. > >> > > > > Uh, unless I really don't understand your question, the dependency is > > there because SOME/MOST networks do use WEP/WPA. > > > > Not true. A lot of hotspots (Starbuck's, Boise airport, certain municipal > networks like Portland, OR, etc. are all open access, with no WEP/WPA). > > It is sometimes or even *mostly* the case, but not always. Therefore, in > the cases where it doesn't apply, no dependency should exist. > > The RPM should have some way of detecting if wireless cards are present > (perhaps using the contents of /etc/sysconfig/network-scripts/ifcfg-*) and > then inferring a dependence of wpa_supplicant (which as I said, only > applies IFF you have wireless hardware and the networks you use > require authentication and/or privacy). I read that correctly you want to install the rpm in runtime. "Oh it looks like you have wifi and you want to connect using WEP/WPA.. please give me the root password." That sounds like an utterly scary scenerio. You are forgetting the the system is dynamic, so the user can insert a wifi capable device at any time and to connect to a protected network you would then for first time require the root password to install the rpm. This should just magically work, which means the package must be installed. The natural thing to do this would be make networkmanager depend on it. What is the tradeoff here, a dependency on 241kb package vs. having to install something in runtime (the logic to do this would probably be comparable in size to be honest). Please tell me I read your proposal wrong. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jwboyer at jdub.homelinux.org Fri May 26 18:46:08 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 26 May 2006 13:46:08 -0500 Subject: NetworkManager system-wide use In-Reply-To: <1148667340.2670.15.camel@price> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> Message-ID: <1148669168.5432.1.camel@vader.jdub.homelinux.org> On Fri, 2006-05-26 at 20:15 +0200, David Nielsen wrote: > > I read that correctly you want to install the rpm in runtime. > > "Oh it looks like you have wifi and you want to connect using WEP/WPA.. > please give me the root password." > > That sounds like an utterly scary scenerio. You are forgetting the the It also sounds completely broken if you magically want to use the wifi card you just stuck and and it's the _only_ network connection you have. Major chicken/egg problem. josh From dcbw at redhat.com Fri May 26 19:08:12 2006 From: dcbw at redhat.com (Dan Williams) Date: Fri, 26 May 2006 15:08:12 -0400 Subject: NetworkManager system-wide use In-Reply-To: <44773783.5040609@redfish-solutions.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> Message-ID: <1148670492.4879.2.camel@localhost.localdomain> On Fri, 2006-05-26 at 11:14 -0600, Philip Prindeville wrote: > Dan Williams wrote: > > On Fri, 2006-05-26 at 06:19 +0000, Kevin Kofler wrote: > > > >> FYI, I found this while browsing the accepted SoC applications: > >> http://code.google.com/soc/gentoo/appinfo.html?csaid=1875FC7DA1FE03E4 > >> > >> > >>> If this is completed, work should be done on WiFi key handling: currently, > >>> NetworkManager will ask the user for the WEP or WPA key of the wireless > >>> network it connects to every time it connects, which isn't very > >>> user-friendly. As Gentoo allows one to configure wireless network settings > >>> in /etc/conf.d/wireless, the keys could be retrieved from that file. Some > >>> changes to NetworkManager's core will be necessary to support this though, > >>> which implies one can't be sure it'll be accepted by the core maintainers. > >>> > >> Looks like you can take this off your TODO. :-) > >> > > > > Sort of... We've already got plans in this area, but of course if > > somebody else wants to fix it, that's great :) > > > > http://live.gnome.org/NetworkManagerToDo?action=show > > > > See the top item there. We're not necessarily going to be pulling keys > > from config files here; instead it will be a slightly larger scoped > > solution. The idea here is to do it right, not just hack in a shim over > > the existing (somewhat-broken shellscript hacktower hell) config stuff > > that many distros already have. > > > > Dan > > > > Sorry for the slight digression, but can someone explain to me why > NetworkManager has a dependency on wpa_supplicant? Not all > wireless networks use WEP/WPA (some are wide open). Further, > not all networked machines (like my desktop) have Wireless NIC's. NM funnels _all_ wifi stuff except for scanning and strength through wpa_supplicant. There's no reason to keep two codepaths in NM for connection setup/teardown, one for non-WEP and one for WEP/WPA. Plus the whole hotplug thing. However, there are some fundamental assumptions that NM makes right now about the existence of wpa_supplicant that won't hold true once I do the dbus control interface bits for NM. So if you really, really don't want to use it, you wouldn't have to. But in the interest of having everything "just work", we'll probably keep the RPM Requires: for the forseeable future. Dan From notting at redhat.com Fri May 26 19:13:39 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 May 2006 15:13:39 -0400 Subject: rawhide rebuild in mock status 2006-05-26 In-Reply-To: <20060526152701.GA32444@lists.us.dell.com> References: <20060526152701.GA32444@lists.us.dell.com> Message-ID: <20060526191339.GD28267@nostromo.devel.redhat.com> Matt Domsch (Matt_Domsch at dell.com) said: > gnucash ['192008 CLOSED'] This is actually a guile/slib interaction issue, as opposed to buildreqs. Bill From philipp_subx at redfish-solutions.com Fri May 26 19:28:20 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 13:28:20 -0600 Subject: NetworkManager system-wide use In-Reply-To: <1148667340.2670.15.camel@price> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> Message-ID: <447756D4.7070800@redfish-solutions.com> David Nielsen wrote: > fre, 26 05 2006 kl. 11:48 -0600, skrev Philip Prindeville: > >> David Hollis wrote: >> >>> On Fri, 2006-05-26 at 11:14 -0600, Philip Prindeville wrote: >>> >>> >>> >>>> Sorry for the slight digression, but can someone explain to me why >>>> NetworkManager has a dependency on wpa_supplicant? Not all >>>> wireless networks use WEP/WPA (some are wide open). Further, >>>> not all networked machines (like my desktop) have Wireless NIC's. >>>> >>>> It would seem to be an unnecessary (and unfounded) dependency. >>>> >>>> >>> Uh, unless I really don't understand your question, the dependency is >>> there because SOME/MOST networks do use WEP/WPA. >>> >>> >> Not true. A lot of hotspots (Starbuck's, Boise airport, certain municipal >> networks like Portland, OR, etc. are all open access, with no WEP/WPA). >> >> It is sometimes or even *mostly* the case, but not always. Therefore, in >> the cases where it doesn't apply, no dependency should exist. >> >> The RPM should have some way of detecting if wireless cards are present >> (perhaps using the contents of /etc/sysconfig/network-scripts/ifcfg-*) and >> then inferring a dependence of wpa_supplicant (which as I said, only >> applies IFF you have wireless hardware and the networks you use >> require authentication and/or privacy). >> > > I read that correctly you want to install the rpm in runtime. > What? No. You can have conditional requirements in the RPM... such as "*iff* the hardware I'm running on has a wireless NIC, then require wpa_supplicant." So the RPM can detect a wireless adapter and conditionally define a Requires: wpa_supplicant line in the NetworkManager RPM. > "Oh it looks like you have wifi and you want to connect using WEP/WPA.. > please give me the root password." > > That sounds like an utterly scary scenerio. You are forgetting the the > system is dynamic, so the user can insert a wifi capable device at any > time and to connect to a protected network you would then for first time > require the root password to install the rpm. > The user is also completely capable of manually installing wpa_supplicant if he knows he will be using a plug-in wireless card (though more and more wireless cards are mini-PCI, and hence don't get unplugged much). This would be better than having an unconditional requirement for wireless support in wired-only (desktop) environments. > This should just magically work, which means the package must be > installed. The natural thing to do this would be make networkmanager > depend on it. What is the tradeoff here, a dependency on 241kb package > vs. having to install something in runtime (the logic to do this would > probably be comparable in size to be honest). > It's not the size of the package. It's the dependencies that that package in turn has (like pcsc-libs-lite, etc), the vulnerabilities and exploits that that package has plug all of its dependencies, etc. > Please tell me I read your proposal wrong. > I never said anything about run-time. It was purely install-time. You can detect most of the hardware at install-time. What you can't (i.e. a plug-in PCMCIA card) you can anticipate for and install the wpa_supplicant package for anyway. -Philip > - David > From notting at redhat.com Fri May 26 19:35:09 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 May 2006 15:35:09 -0400 Subject: NetworkManager system-wide use In-Reply-To: <447756D4.7070800@redfish-solutions.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <447756D4.7070800@redfish-solutions.com> Message-ID: <20060526193509.GF28267@nostromo.devel.redhat.com> Philip Prindeville (philipp_subx at redfish-solutions.com) said: > What? No. You can have conditional requirements in the RPM... such > as "*iff* the hardware I'm running on has a wireless NIC, then require > wpa_supplicant." So the RPM can detect a wireless adapter and > conditionally define a Requires: wpa_supplicant line in the NetworkManager > RPM. Runtime adding of dependencies based on PCI/USB/etc. probing...? I'm pretty sure RPM can't do that. > The user is also completely capable of manually installing wpa_supplicant > if he knows he will be using a plug-in wireless card (though more and > more wireless cards are mini-PCI, and hence don't get unplugged much). > > This would be better than having an unconditional requirement for wireless > support in wired-only (desktop) environments. Currently: - user uses wireless. It just works. - user doesn't use wireless. It just works, and they have an extra package. Your proposal: - user uses wireless. They must remember to install a specifically named package, otherwise, it fails completely. - user doesn't use wireless. It works. How is this better *for the user*? Bill From pmatilai at laiskiainen.org Fri May 26 20:01:04 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 26 May 2006 23:01:04 +0300 Subject: NetworkManager system-wide use In-Reply-To: <20060526193509.GF28267@nostromo.devel.redhat.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <447756D4.7070800@redfish-solutions.com> <20060526193509.GF28267@nostromo.devel.redhat.com> Message-ID: <1148673664.13737.73.camel@weasel.turre.laiskiainen.org> On Fri, 2006-05-26 at 15:35 -0400, Bill Nottingham wrote: > Philip Prindeville (philipp_subx at redfish-solutions.com) said: > > What? No. You can have conditional requirements in the RPM... such > > as "*iff* the hardware I'm running on has a wireless NIC, then require > > wpa_supplicant." So the RPM can detect a wireless adapter and > > conditionally define a Requires: wpa_supplicant line in the NetworkManager > > RPM. > > Runtime adding of dependencies based on PCI/USB/etc. probing...? I'm > pretty sure RPM can't do that. rpm >= 4.4.4 (or was it 4.4.3) has all sorts of runtime dependency possibilities including cpu flags, uname entries, file access checks and whatnot. It opens interesting possibilities, in theory. In practise, it gets quite entertaining when you think about depsolvers such as apt and smart which require full dependency closure of rpmdb at all times. - Panu - From philipp_subx at redfish-solutions.com Fri May 26 20:09:52 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 14:09:52 -0600 Subject: NetworkManager system-wide use In-Reply-To: <20060526193509.GF28267@nostromo.devel.redhat.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <447756D4.7070800@redfish-solutions.com> <20060526193509.GF28267@nostromo.devel.redhat.com> Message-ID: <44776090.5040403@redfish-solutions.com> Bill Nottingham wrote: > Philip Prindeville (philipp_subx at redfish-solutions.com) said: > >> What? No. You can have conditional requirements in the RPM... such >> as "*iff* the hardware I'm running on has a wireless NIC, then require >> wpa_supplicant." So the RPM can detect a wireless adapter and >> conditionally define a Requires: wpa_supplicant line in the NetworkManager >> RPM. >> > > Runtime adding of dependencies based on PCI/USB/etc. probing...? I'm > pretty sure RPM can't do that. > Look at /etc/sysconfig/network-scripts/network-functions, in particular is_wireless_device(). Also look at how "service network status" works. >> The user is also completely capable of manually installing wpa_supplicant >> if he knows he will be using a plug-in wireless card (though more and >> more wireless cards are mini-PCI, and hence don't get unplugged much). >> >> This would be better than having an unconditional requirement for wireless >> support in wired-only (desktop) environments. >> > > Currently: > > - user uses wireless. It just works. > - user doesn't use wireless. It just works, and they have an extra package. > > Your proposal: > > - user uses wireless. They must remember to install a specifically named > package, otherwise, it fails completely. > No, only for plug-in wireless users. But they need to do that anyway. (for the aforementioned chicken-and-the-egg reasons...) -Philip > - user doesn't use wireless. It works. > > How is this better *for the user*? > > Bill > > From Matt_Domsch at dell.com Fri May 26 20:17:50 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 26 May 2006 15:17:50 -0500 Subject: NetworkManager system-wide use In-Reply-To: <20060526193509.GF28267@nostromo.devel.redhat.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <447756D4.7070800@redfish-solutions.com> <20060526193509.GF28267@nostromo.devel.redhat.com> Message-ID: <20060526201750.GC32444@lists.us.dell.com> On Fri, May 26, 2006 at 03:35:09PM -0400, Bill Nottingham wrote: > Runtime adding of dependencies based on PCI/USB/etc. probing...? I'm > pretty sure RPM can't do that. The firmware-tools project (http://linux.dell.com/firmware-tools) gets around this by passing a set of runtime-discovered requirements to yum/up2date. # yum install $(inventory_firmware -b) # apply_updates where the program inventory_firmware spits out a list of PCI devices that are present in the system in RPM "Requires" format, like so: # inventory_firmware -b system_bios(ven_0x1028_dev_0x0182) bmc_firmware(ven_0x1028_dev_0x0182) pci_firmware(ven_0x8086_dev_0x2590_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x2591) pci_firmware(ven_0x8086_dev_0x2660) pci_firmware(ven_0x8086_dev_0x2658_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x2659_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x265a_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x265b_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x265c_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x2448) pci_firmware(ven_0x8086_dev_0x266e_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x266d_subven_0x14f1_subdev_0x5423) pci_firmware(ven_0x8086_dev_0x2641_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x2653_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x1002_dev_0x5460_subven_0x1028_subdev_0x2006) pci_firmware(ven_0x14e4_dev_0x1677_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x104c_dev_0x8036_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x104c_dev_0x8038_subven_0x1028_subdev_0x0182) pci_firmware(ven_0x8086_dev_0x4220_subven_0x8086_subdev_0x2721) -- 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 notting at redhat.com Fri May 26 20:27:40 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 May 2006 16:27:40 -0400 Subject: NetworkManager system-wide use In-Reply-To: <44776090.5040403@redfish-solutions.com> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <447756D4.7070800@redfish-solutions.com> <20060526193509.GF28267@nostromo.devel.redhat.com> <44776090.5040403@redfish-solutions.com> Message-ID: <20060526202740.GA29031@nostromo.devel.redhat.com> Philip Prindeville (philipp_subx at redfish-solutions.com) said: > >Runtime adding of dependencies based on PCI/USB/etc. probing...? I'm > >pretty sure RPM can't do that. > > Look at /etc/sysconfig/network-scripts/network-functions, in > particular is_wireless_device(). > > Also look at how "service network status" works. Again, how does any of that have anything to do with RPM dependencies? > >Currently: > > > >- user uses wireless. It just works. > >- user doesn't use wireless. It just works, and they have an extra package. > > > >Your proposal: > > > >- user uses wireless. They must remember to install a specifically named > > package, otherwise, it fails completely. > > > > No, only for plug-in wireless users. But they need to do that anyway. > > (for the aforementioned chicken-and-the-egg reasons...) I still see no reason why this situation is better for users. Bill From dwmw2 at infradead.org Fri May 26 21:30:42 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 26 May 2006 22:30:42 +0100 Subject: NetworkManager system-wide use In-Reply-To: <1148667340.2670.15.camel@price> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> Message-ID: <1148679042.10628.3.camel@pmac.infradead.org> On Fri, 2006-05-26 at 20:15 +0200, David Nielsen wrote: > That sounds like an utterly scary scenerio. You are forgetting the the > system is dynamic, so the user can insert a wifi capable device at any > time and to connect to a protected network you would then for first > time require the root password to install the rpm. By that logic, we shouldn't allow anything less than an 'Everything' install. What if the user receives a Word document in email? Are we going to demand the root password and install OpenOffice? No, we must force OpenOffice to be installed at all times instead. -- dwmw2 From jspaleta at gmail.com Fri May 26 21:37:00 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 26 May 2006 17:37:00 -0400 Subject: NetworkManager system-wide use In-Reply-To: <1148679042.10628.3.camel@pmac.infradead.org> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <1148679042.10628.3.camel@pmac.infradead.org> Message-ID: <604aa7910605261437u170980e8w3d2eb8994dd7a1e0@mail.gmail.com> On 5/26/06, David Woodhouse wrote: > What if the user receives a Word document in email? Are we going to > demand the root password and install OpenOffice? No, we must force > OpenOffice to be installed at all times instead. I think the battlelines over this issue change a bit since we are talking about something which affects network accessiblity... something 'implicitly' needed for common package management tasks in the distribution. We aren't talking about a file format support, but access to the network which will facility the ability to install additional software. I think the judgement to require the small extra dependancy at the packaging level is justified considering its connectivity impact. -jef From chabotc at xs4all.nl Fri May 26 21:43:21 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Fri, 26 May 2006 23:43:21 +0200 Subject: NetworkManager system-wide use In-Reply-To: <1148669168.5432.1.camel@vader.jdub.homelinux.org> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <1148669168.5432.1.camel@vader.jdub.homelinux.org> Message-ID: <1148679801.4570.0.camel@chris.lan> I move to include all network modules of the kernel in seperate rpm packages too! And auto install them with yum using ... umm ... umm .. carrion pigeon protocol? Ok just need sleep and ranting, i'll be quiet again :-) -- Chris On Fri, 2006-05-26 at 13:46 -0500, Josh Boyer wrote: > On Fri, 2006-05-26 at 20:15 +0200, David Nielsen wrote: > > > > I read that correctly you want to install the rpm in runtime. > > > > "Oh it looks like you have wifi and you want to connect using WEP/WPA.. > > please give me the root password." > > > > That sounds like an utterly scary scenerio. You are forgetting the the > > It also sounds completely broken if you magically want to use the wifi > card you just stuck and and it's the _only_ network connection you have. > Major chicken/egg problem. > > josh > From david at lovesunix.net Fri May 26 21:58:17 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 26 May 2006 23:58:17 +0200 Subject: NetworkManager system-wide use In-Reply-To: <1148679042.10628.3.camel@pmac.infradead.org> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <1148679042.10628.3.camel@pmac.infradead.org> Message-ID: <1148680697.2670.23.camel@price> fre, 26 05 2006 kl. 22:30 +0100, skrev David Woodhouse: > On Fri, 2006-05-26 at 20:15 +0200, David Nielsen wrote: > > That sounds like an utterly scary scenerio. You are forgetting the the > > system is dynamic, so the user can insert a wifi capable device at any > > time and to connect to a protected network you would then for first > > time require the root password to install the rpm. > > By that logic, we shouldn't allow anything less than an 'Everything' > install. > > What if the user receives a Word document in email? Are we going to > demand the root password and install OpenOffice? No, we must force > OpenOffice to be installed at all times instead. Correct me if I'm wrong but having a working network is strongly desired functionality - say if the wifi was the only connection available and it's encrypted (thus needs the package in question).. how exactly will I be installing it again? The likily scenerio would be using media or downloading it - I personally don't carry around media with me when I'm on the go so that's not an option and if I can't get online that's not possible either. However you are right we should be careful not to turn the distro into an everything install just for the sake of it - regardless I remain of the option that we can live with a 240kb package if it makes networking a bit easier. I don't have wifi so I'm really not benefiting from it anyways, still I think I can live with it without weeping bloody tears at night. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jon.nettleton at gmail.com Fri May 26 22:32:44 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 26 May 2006 18:32:44 -0400 Subject: NetworkManager system-wide use In-Reply-To: <1148680697.2670.23.camel@price> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <1148679042.10628.3.camel@pmac.infradead.org> <1148680697.2670.23.camel@price> Message-ID: <1148682765.1939.16.camel@averatec> On Fri, 2006-05-26 at 23:58 +0200, David Nielsen wrote: > fre, 26 05 2006 kl. 22:30 +0100, skrev David Woodhouse: > > On Fri, 2006-05-26 at 20:15 +0200, David Nielsen wrote: > > > That sounds like an utterly scary scenerio. You are forgetting the the > > > system is dynamic, so the user can insert a wifi capable device at any > > > time and to connect to a protected network you would then for first > > > time require the root password to install the rpm. > > > > By that logic, we shouldn't allow anything less than an 'Everything' > > install. > > > > What if the user receives a Word document in email? Are we going to > > demand the root password and install OpenOffice? No, we must force > > OpenOffice to be installed at all times instead. > > Correct me if I'm wrong but having a working network is strongly desired > functionality - say if the wifi was the only connection available and > it's encrypted (thus needs the package in question).. how exactly will I > be installing it again? The likily scenerio would be using media or > downloading it - I personally don't carry around media with me when I'm > on the go so that's not an option and if I can't get online that's not > possible either. > > However you are right we should be careful not to turn the distro into > an everything install just for the sake of it - regardless I remain of > the option that we can live with a 240kb package if it makes networking > a bit easier. I don't have wifi so I'm really not benefiting from it > anyways, still I think I can live with it without weeping bloody tears > at night. > I have to agree that this is a lot of chatter over a 240kb package that in this day and age is pretty essential to core functionality of the OS. If this is an itch for whomever brought this up, roll your own RPM's that don't need wpa_supplicant. I know that if I had to add a wireless card to a fedora desktop and fired it up and NM just sat there with a spinning icon I would be pretty unhappy. The have the user install it manually is absolutely unacceptable. I can only imagine the write-ups when Core 6 comes out, "Well I installed the distro from dvd and everything went smoothly. Anaconda is a wonderful installer. However after reboot when I plugged in my wireless card I was prompted to first install another package before I could connect to my encrypted wireless network. I had to double check and make sure the calendar didn't say 1998!". From pemboa at gmail.com Fri May 26 23:07:02 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 26 May 2006 18:07:02 -0500 Subject: A sole, standard proxy library for Fedora In-Reply-To: <1148664862.2472.7.camel@dhollis-lnx.sunera.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> Message-ID: <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> On 5/26/06, David Hollis wrote: > On Fri, 2006-05-26 at 11:11 -0600, Philip Prindeville wrote: > > I have a laptop that travels with me from work (where there's the > > use of web proxies) to home (where I don't), and was overwhelmed > > by the number of config files that I have to switch over every time > > I move from one place to the other. > > Most CLI apps will honor http_proxy/ftp_proxy environment variables for > proxying. GUI apps may or may not support that, I can't say that I've > tried. Gnome (and I'm sure KDE) have their own control panel setting > for that, but that only applies to apps that make use of their VFS > library. If they do their own web access, they may not honor it. > Can I attest to how little this helps. First of all, this solution is virtually non existant without doing some Googling. Then (at least based on the solution I found) I had to write up a script to export the variables, both in lower case and uppercase, or export them manually. And I did all this so I could use Yum. For firefox to work, I had to set its config. I tried setting up a proxy pac to work automatically based on the network I was on, but that did not work out. Luckily, KDE has Control Center to allow setting of proxy information. Machine wide setting of proxy information, esp. based on active network would be great...not even Windows has this to the best of my knowledge. Unfortunately, I have niether the time, nor the know how to implement this myself. -- To be updated... From philipp_subx at redfish-solutions.com Fri May 26 23:26:15 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 26 May 2006 17:26:15 -0600 Subject: A sole, standard proxy library for Fedora In-Reply-To: <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> Message-ID: <44778E97.2000104@redfish-solutions.com> Arthur Pemberton wrote: >On 5/26/06, David Hollis wrote: > > >>On Fri, 2006-05-26 at 11:11 -0600, Philip Prindeville wrote: >> >> >>>I have a laptop that travels with me from work (where there's the >>>use of web proxies) to home (where I don't), and was overwhelmed >>>by the number of config files that I have to switch over every time >>>I move from one place to the other. >>> >>> >>Most CLI apps will honor http_proxy/ftp_proxy environment variables for >>proxying. GUI apps may or may not support that, I can't say that I've >>tried. Gnome (and I'm sure KDE) have their own control panel setting >>for that, but that only applies to apps that make use of their VFS >>library. If they do their own web access, they may not honor it. >> >> >> > >Can I attest to how little this helps. First of all, this solution is >virtually non existant without doing some Googling. Then (at least >based on the solution I found) I had to write up a script to export >the variables, both in lower case and uppercase, or export them >manually. And I did all this so I could use Yum. For firefox to work, >I had to set its config. I tried setting up a proxy pac to work >automatically based on the network I was on, but that did not work >out. Luckily, KDE has Control Center to allow setting of proxy >information. Machine wide setting of proxy information, esp. based on >active network would be great...not even Windows has this to the best >of my knowledge. > >Unfortunately, I have niether the time, nor the know how to implement >this myself. > > Maybe we can get it onto the SOC dance card? -Philip From david at lovesunix.net Fri May 26 23:34:29 2006 From: david at lovesunix.net (David Nielsen) Date: Sat, 27 May 2006 01:34:29 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: <44778E97.2000104@redfish-solutions.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <44778E97.2000104@redfish-solutions.com> Message-ID: <1148686469.2670.27.camel@price> fre, 26 05 2006 kl. 17:26 -0600, skrev Philip Prindeville: > Maybe we can get it onto the SOC dance card? The SoC submission period is long gone, but next year it would make a good project if someone hasn't solved the issue yet. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From dennis at ausil.us Sat May 27 03:56:30 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 26 May 2006 22:56:30 -0500 Subject: NetworkManager system-wide use In-Reply-To: <447756D4.7070800@redfish-solutions.com> References: <1148667340.2670.15.camel@price> <447756D4.7070800@redfish-solutions.com> Message-ID: <200605262256.30366.dennis@ausil.us> On Friday 26 May 2006 2:28 pm, Philip Prindeville wrote: > What? No. You can have conditional requirements in the RPM... such > as "*iff* the hardware I'm running on has a wireless NIC, then require > wpa_supplicant." So the RPM can detect a wireless adapter and > conditionally define a Requires: wpa_supplicant line in the NetworkManager > RPM. Err I don't think so. rpm has no such abilities > > "Oh it looks like you have wifi and you want to connect using WEP/WPA.. > > please give me the root password." > The user is also completely capable of manually installing wpa_supplicant > if he knows he will be using a plug-in wireless card (though more and > more wireless cards are mini-PCI, and hence don't get unplugged much). > > This would be better than having an unconditional requirement for wireless > support in wired-only (desktop) environments. > > I never said anything about run-time. It was purely install-time. You > can detect most of the hardware at install-time. What you can't (i.e. > a plug-in PCMCIA card) you can anticipate for and install the > wpa_supplicant package for anyway. so a user with wireless needs to go through more hoops. you are also forgetting the case where wired users need authentication. While not all that popular at them moment some large wired networks do require this. Why i dont want you walking into the company where i work plugging into a data jack and listening on my wire. so i make you authenticate to use my wired network. There are too many cases where this is needed. -- Dennis Gilmore, RHCE Proud Australian From dennis at ausil.us Sat May 27 03:59:58 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 26 May 2006 22:59:58 -0500 Subject: NetworkManager system-wide use In-Reply-To: <20060526201750.GC32444@lists.us.dell.com> References: <20060526193509.GF28267@nostromo.devel.redhat.com> <20060526201750.GC32444@lists.us.dell.com> Message-ID: <200605262259.58316.dennis@ausil.us> On Friday 26 May 2006 3:17 pm, Matt Domsch wrote: > On Fri, May 26, 2006 at 03:35:09PM -0400, Bill Nottingham wrote: > > Runtime adding of dependencies based on PCI/USB/etc. probing...? I'm > > pretty sure RPM can't do that. > > The firmware-tools project (http://linux.dell.com/firmware-tools) gets > around this by passing a set of runtime-discovered requirements to > yum/up2date. > > # yum install $(inventory_firmware -b) > # apply_updates thats not rpm doing anything but an external script. So now we need to have rpm call yum? -- Dennis Gilmore, RHCE Proud Australian From nmiell at comcast.net Sat May 27 05:15:29 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Fri, 26 May 2006 22:15:29 -0700 Subject: What's up with elfutils? Message-ID: <1148706929.2401.14.camel@entropy> A crazy license, no documentation, no web site, no mailing list, no CVS, no real presence besides a RPM, a bugzilla component, and the occasional mention on the SystemTap list. Why is this being used instead of the other (more sensibly licensed? I can't tell, I have no idea what the elfutils license means.) libelfs and libdwarfs that are available? And where does one go to get bugs fixed, because I don't think bugzilla is it. (Although, I think this may be a bugzilla privileges issue.) -- Nicholas Miell From pemboa at gmail.com Sat May 27 05:51:08 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 27 May 2006 00:51:08 -0500 Subject: A sole, standard proxy library for Fedora In-Reply-To: <1148686469.2670.27.camel@price> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <44778E97.2000104@redfish-solutions.com> <1148686469.2670.27.camel@price> Message-ID: <16de708d0605262251o6e54bb8cl67de309070b2ccf2@mail.gmail.com> On 5/26/06, David Nielsen wrote: > fre, 26 05 2006 kl. 17:26 -0600, skrev Philip Prindeville: > > > Maybe we can get it onto the SOC dance card? > > The SoC submission period is long gone, but next year it would make a > good project if someone hasn't solved the issue yet. > > - David > To anyone regularly editing fedoraproject.org, I think this would be a good addition to FedoraBounties. -- To be updated... From sundaram at fedoraproject.org Sat May 27 07:02:05 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 12:32:05 +0530 Subject: A sole, standard proxy library for Fedora In-Reply-To: <16de708d0605262251o6e54bb8cl67de309070b2ccf2@mail.gmail.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <44778E97.2000104@redfish-solutions.com> <1148686469.2670.27.camel@price> <16de708d0605262251o6e54bb8cl67de309070b2ccf2@mail.gmail.com> Message-ID: <1148713325.4310.696.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 00:51 -0500, Arthur Pemberton wrote: > On 5/26/06, David Nielsen wrote: > > fre, 26 05 2006 kl. 17:26 -0600, skrev Philip Prindeville: > > > > > Maybe we can get it onto the SOC dance card? > > > > The SoC submission period is long gone, but next year it would make a > > good project if someone hasn't solved the issue yet. > > > > - David > > > > To anyone regularly editing fedoraproject.org, I think this would be a > good addition to FedoraBounties. > > -- http://fedoraproject.org/wiki/FedoraBounties Any work being done on the gallery? Rahul From sundaram at fedoraproject.org Sat May 27 07:03:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 12:33:11 +0530 Subject: What's up with elfutils? In-Reply-To: <1148706929.2401.14.camel@entropy> References: <1148706929.2401.14.camel@entropy> Message-ID: <1148713391.4310.698.camel@sundaram.pnq.redhat.com> On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote: > A crazy license, no documentation, no web site, no mailing list, no CVS, > no real presence besides a RPM, a bugzilla component, and the occasional > mention on the SystemTap list. > > Why is this being used instead of the other (more sensibly licensed? I > can't tell, I have no idea what the elfutils license means.) libelfs and > libdwarfs that are available? > > And where does one go to get bugs fixed, because I don't think bugzilla > is it. (Although, I think this may be a bugzilla privileges issue.) > > -- You arent able to file bug reports against elfutils in http://bugzilla.redhat.com? Rahul From buildsys at redhat.com Sat May 27 07:42:19 2006 From: buildsys at redhat.com (Build System) Date: Sat, 27 May 2006 03:42:19 -0400 Subject: rawhide report: 20060527 changes Message-ID: <200605270742.k4R7gJ3s001292@porkchop.devel.redhat.com> Updated Packages: apr-1.2.7-8 ----------- * Fri May 26 2006 Jakub Jelinek 1.2.7-8 - rebuilt with GCC 4.1.0 * Tue May 23 2006 Joe Orton 1.2.7-7 - fix another multilib conflict (#192659) * Tue May 16 2006 Joe Orton 1.2.7-6 - BR e2fsprogs-devel for libuuid arptables_jf-0:0.0.8-7 ---------------------- * Fri May 26 2006 Jay Fenlason 0:0.0.8-7 - Add warnings patch to close bz#191688 arptables_jf fails to build in mock autofs-1:5.0.0_beta3-2 ---------------------- * Fri May 26 2006 Jeff Moyer - 1:5.0.0_beta3-2 - Fix the install permissions for auto.master and auto.misc. dhcp-12:3.0.4-10 ---------------- * Fri May 26 2006 Jason Vas Dias - 12:3.0.4-10 - fix bug 193047: allow $METRIC to be specified for dhclient routes - add a '-R ' dhclient argument * Fri May 26 2006 Jason Vas Dias - 12:3.0.4-8.1 - fix a libdhcp4client memory leak (1 strdup) and fill in client->packet.siaddr before bind_lease() for pump nextServer option. * Fri May 19 2006 Jason Vas Dias - 12:3.0.4-8 - Make libdhcp4client a versioned .so (BZ 192146) dhcpv6-0.10-24.1 ---------------- * Fri May 26 2006 Jason Vas Dias 0.10-24.1 - misc libdhcp6client fixes gcc-4.1.1-1 ----------- * Thu May 25 2006 Jakub Jelinek 4.1.1-1 - update from gcc-4_1-branch (-r113848:114107) - GCC 4.1.1 release - PR fortran/27553 - fix i386/x86_64 -O0 -fpic link failure (#192816, PR target/27758) - fix gcjh on 64-bit hosts (#192700) - -fvar-tracking fixes needed for SystemTap (Alexandre Oliva, BZ#2438) * Wed May 17 2006 Jakub Jelinek 4.1.0-19 - update from gcc-4_1-branch (-r113785:113848) - PRs c++/26757, c++/27339, c++/27491, driver/26885, rtl-optimization/14261, target/26600, tree-optimization/27603 - merge gomp changes from the trunk (-r113513:113514, -r113821:113823 and -r113845:113846) - PRs middle-end/27415, middle-end/27573 - optimize handling of large CONSTRUCTORs (Bernd Schmidt, PR middle-end/27620) * Mon May 15 2006 Jakub Jelinek 4.1.0-18 - update from gcc-4_1-branch (-r113722:113785) - PRs c++/27315, c++/27581, c++/27582, rtl-optimization/22563 - merge gomp changes from the trunk (-r113786:113790) ghostscript-8.15.2-4 -------------------- * Fri May 26 2006 Tim Waugh 8.15.2-4 - Fix ijs-config not to have multilib conflicts (bug #192672) gimp-print-4.2.7-18 ------------------- * Fri May 26 2006 Tim Waugh 4.2.7-18 - Prevent gimpprint-config multilib conflicts (bug #192673). hplip-0.9.11-5 -------------- * Fri May 26 2006 Tim Waugh 0.9.11-5 - Include doc files (bug #192790). kernel-2.6.16-1.2221_FC6 ------------------------ * Fri May 26 2006 Dave Jones - 2.6.17rc5-git1 libXv-1.0.1-2 ------------- * Fri May 26 2006 Mike A. Harris 1.0.1-2 - Added "Requires: libXext-devel" to libXv-devel subpackage, to avoid all packages that depend on libXv-devel from having to manually specify that dependency themselves, as it is required by Xv. (#192167) libnl-1.0-0.9.pre5 ------------------ * Fri May 26 2006 Jason Vas Dias 1.0-0.9.pre5 - Allow build to succeed with new gcc / glibc-kernheaders (compile failed on __u64 redefinition on x86_64). - Add a static /usr/lib64/libnl.a library to libnl-devel for programs that might need to do a static link to libnl. Added after consultation with Christopher Aillon. libtool-1.5.22-3 ---------------- * Fri May 26 2006 Jakub Jelinek 1.5.22-3 - rebuilt with GCC 4.1.0 libunwind-0.98.5-1 ------------------ * Sat May 27 2006 Alexandre Oliva - 0.98.5-1 - Import version 0.98.5. man-pages-2.32-2 ---------------- * Fri May 26 2006 Ivana Varekova 2.32-2 - add nss.5 man page (#192142) - add the man-pages directories (#192998) * Mon May 15 2006 Ivana Varekova 2.32-1 - update to 2.32 - add gai.conf.5 man page (#191656) * Tue Apr 18 2006 Ivana Varekova 2.29-1 - update to 2.29 - fix sigprocmask(2) man page (#189121) nautilus-cd-burner-2.15.2-2 --------------------------- * Fri May 26 2006 Jeremy Katz - 2.15.2-2 - builds on s390 now net-snmp-5.3.1.pre2-4 --------------------- * Fri May 26 2006 Radek Vokal 5.3.1.pre2-4 - fix lib version nspr-4.6.2-1 ------------ * Fri May 26 2006 Kai Engert - 4.6.2-1 - Update to 4.6.2 - Tweak nspr-config to be identical on all platforms. nss-3.11.1-1 ------------ * Fri May 26 2006 Kai Engert - 3.11.1-1 - Update to 3.11.1 - Include upstream patch to limit curves opensp-1.5.2-2 -------------- * Fri May 26 2006 Tim Waugh 1.5.2-2 - Fixed multilib devel conflicts (bug #192741). php-5.1.4-5.1 ------------- * Wed May 24 2006 Radek Vokal 5.1.4-5.1 - rebuilt for new libnetsnmp policycoreutils-1.30.10-4 ------------------------- * Fri May 26 2006 Dan Walsh 1.30.10-4 - Fix seobject.py to not sort the file_context file. - move setfiles to /sbin pygtk2-2.9.0-3 -------------- * Fri May 26 2006 Jeremy Katz - 2.9.0-3 - BR should be pygobject2-devel, need to actually require pygobject2 at runtime pyxf86config-0.3.24-2 --------------------- * Fri May 26 2006 Adam Jackson 0.3.24-2 - BuildRequires: xorg-x11-server-sdk (#191894) rhythmbox-0.9.4.1-6 ------------------- * Fri May 26 2006 Jeremy Katz - 0.9.4.1-6 - try to fix building on s390{,x} * Wed May 24 2006 John (J5) Palmieri - 0.9.4.1-5 - Patch to build with latest libnotify * Mon May 22 2006 Matthias Clasen - 0.9.4.1-4 - Rebuild scim-chewing-0.3.0-7 -------------------- * Tue May 23 2006 Darshan Santani - Revised the version number - Rebuild * Mon May 22 2006 Darshan Santani - New source tarball added. - Rebuild. selinux-policy-2.2.42-3 ----------------------- * Wed May 24 2006 Dan Walsh 2.2.42-3 - fixes for java, openldap and webalizer * Mon May 22 2006 Dan Walsh 2.2.42-2 - Xen fixes spamassassin-3.1.2-1.fc6 ------------------------ * Fri May 26 2006 Warren Togami - 3.1.2-1 - 3.1.2 bug fix release system-config-printer-0.7.10-1 ------------------------------ * Fri May 26 2006 Tim Waugh 0.7.10-1 - Require foomatic (bug #192764). - Updated to system-config-printer-0.7.10. valgrind-1:3.1.1-3 ------------------ * Fri May 26 2006 Jakub Jelinek 3.1.1-3 - handle [sg]et_robust_list syscalls on i?86/x86_64 - handle *at syscalls on ppc - ensure on x86_64 both 32-bit and 64-bit glibc{,-devel} are installed in the buildroot (#191820) * Wed Apr 12 2006 Jakub Jelinek 3.1.1-2 - handle many syscalls that were unhandled before, especially on ppc * Mon Apr 03 2006 Jakub Jelinek 3.1.1-1 - upgrade to 3.1.1 - many bugfixes vnc-4.1.2-1 ----------- * Fri May 26 2006 Jitka Kudrnacova 4.1.2-1 - enable OpenGL support xmlrpc-0:2.0.1-1jpp_8fc ----------------------- * Fri May 26 2006 Igor Foox - 0:2.0.1-1jpp_8fc - Rebuilding for FC5 with excluded s390. * Wed Mar 08 2006 Rafael Schloming - 0:2.0.1-1jpp_7fc - excluded s390 due to eclipse xorg-x11-apps-1.0.3-2 --------------------- * Fri May 26 2006 Adam Jackson 1.0.3-2 - Add more BuildRequires to fix mock builds. (#191896) xorg-x11-drv-acecad-1.1.0-2 --------------------------- * Fri May 26 2006 Mike A. Harris 1.1.0-2 - Update sdk dependency to 1.1.0-2 to pick up indirect dependency on proto-devel. xorg-x11-drv-glint-1.1.1-4 -------------------------- * Fri May 26 2006 Mike A. Harris 1.1.1-4 - Re-enable with_dri, as --disable-dri builds are broken (fdo#7405) * Fri May 26 2006 Mike A. Harris 1.1.1-3 - Added with_dri conditionalization, defaulted to DRI being disabled. - Added "BuildRequires: libdrm-devel >= 2.0-1" for (#192358). - Added "BuildRequires: mesa-libGL-devel >= 6.4-4". - Bumped sdk dep to pick up proto-devel indirectly. xorg-x11-drv-i810-1.6.0-4 ------------------------- * Fri May 26 2006 Mike A. Harris 1.6.0-4 - Added "BuildRequires: libdrm >= 2.0-1" for (#192334), and updated sdk dep to pick up proto-devel as well. xorg-x11-drv-mga-1.4.1-3 ------------------------ * Fri May 26 2006 Mike A. Harris 1.4.1-3 - Added with_dri conditionalization (not yet working for non-dri case). - Added "BuildRequires: libdrm-devel >= 2.0-1" for (#192358). - Added "BuildRequires: mesa-libGL-devel >= 6.4-4". - Bumped sdk dep to pick up proto-devel indirectly. xorg-x11-drv-savage-2.1.1-3 --------------------------- * Fri May 26 2006 Mike A. Harris 2.1.1-3 - Added "BuildRequires: libdrm-devel >= 2.0-1" for DRI enabled builds (#192349) xorg-x11-drv-sis-0.9.1-3 ------------------------ * Fri May 26 2006 Mike A. Harris 0.9.1-3 - Added "BuildRequires: libdrm-devel >= 2.0-1" for (#192358) - Bumped sdk dep to pick up proto-devel indirectly. * Tue May 23 2006 Adam Jackson 0.9.1-2 - Rebuild for 7.1 ABI fix. * Sun Apr 09 2006 Adam Jackson 0.9.1-1 - Update to 0.9.1 from 7.1RC1. xorg-x11-drv-tdfx-1.2.1-3 ------------------------- * Fri May 26 2006 Mike A. Harris 1.2,1-3 - Added "BuildRequires: libdrm-devel >= 2.0-1" for (#192358) xorg-x11-drv-via-0.2.1-3 ------------------------ * Fri May 26 2006 Mike A. Harris 0.2.1-3 - Updated sdk dependency to pick up proto-devel automatically. (#192167) xorg-x11-drv-voodoo-1.1.0-3 --------------------------- * Fri May 26 2006 Mike A. Harris 1.1.0-3 - Bumped sdk dep to pick up proto-devel indirectly. xorg-x11-fonts-7.0-4 -------------------- * Fri May 26 2006 Mike A. Harris 7.0-4 - Added "BuildRequires: fontconfig" for (#192038) xorg-x11-server-1.1.0-2 ----------------------- * Thu May 25 2006 Mike A. Harris 1.1.0-2 - Add "Requires: xorg-x11-proto-devel >= 7.1-1" to sdk for numerous (52) bug reports of drivers failing to build with mock. * Tue May 23 2006 Adam Jackson 1.1.0-1 - Xorg 7.1 final. * Tue May 23 2006 Mike A. Harris 1.0.99.903-2 - Disable dependency on xorg-x11-drivers package, for OLPC. (#191781) - Add "BuildRequires: freetype-devel >= 2.1.10" for bug (#192021) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires libstdc++-devel = 0:4.1.0 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires libstdc++-devel = 0:4.1.0 Broken deps for ia64 ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires libstdc++-devel = 0:4.1.0 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libstdc++so7-devel - 4.2.0-0.6.20060428.s390 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.s390 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for ppc ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires libstdc++-devel = 0:4.1.0 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libstdc++so7-devel - 4.2.0-0.6.20060428.s390x requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.s390x requires libstdc++-devel = 0:4.1.0 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 From nmiell at comcast.net Sat May 27 07:30:15 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 27 May 2006 00:30:15 -0700 Subject: What's up with elfutils? In-Reply-To: <1148713391.4310.698.camel@sundaram.pnq.redhat.com> References: <1148706929.2401.14.camel@entropy> <1148713391.4310.698.camel@sundaram.pnq.redhat.com> Message-ID: <1148715016.2401.15.camel@entropy> On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote: > On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote: > > A crazy license, no documentation, no web site, no mailing list, no CVS, > > no real presence besides a RPM, a bugzilla component, and the occasional > > mention on the SystemTap list. > > > > Why is this being used instead of the other (more sensibly licensed? I > > can't tell, I have no idea what the elfutils license means.) libelfs and > > libdwarfs that are available? > > > > > And where does one go to get bugs fixed, because I don't think bugzilla > > is it. (Although, I think this may be a bugzilla privileges issue.) > > > > -- > > You arent able to file bug reports against elfutils in > http://bugzilla.redhat.com? Oh, I can, but I can't move them out of the MODIFIED state and none of the default queries (i.e. My Bugs) include MODIFIED. -- Nicholas Miell From sundaram at fedoraproject.org Sat May 27 09:33:03 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 May 2006 15:03:03 +0530 Subject: What's up with elfutils? In-Reply-To: <1148715016.2401.15.camel@entropy> References: <1148706929.2401.14.camel@entropy> <1148713391.4310.698.camel@sundaram.pnq.redhat.com> <1148715016.2401.15.camel@entropy> Message-ID: <1148722384.4310.714.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 00:30 -0700, Nicholas Miell wrote: > On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote: > > On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote: > > > A crazy license, no documentation, no web site, no mailing list, no CVS, > > > no real presence besides a RPM, a bugzilla component, and the occasional > > > mention on the SystemTap list. > > > > > > Why is this being used instead of the other (more sensibly licensed? I > > > can't tell, I have no idea what the elfutils license means.) libelfs and > > > libdwarfs that are available? > > > > > > > > And where does one go to get bugs fixed, because I don't think bugzilla > > > is it. (Although, I think this may be a bugzilla privileges issue.) > > > > > > -- > > > > You arent able to file bug reports against elfutils in > > http://bugzilla.redhat.com? > > Oh, I can, but I can't move them out of the MODIFIED state and none of > the default queries (i.e. My Bugs) include MODIFIED. What are you trying to do? Are you trying to query or change state of the reports? Which bugs? Rahul From mailinglists at erwinrol.com Sat May 27 10:41:39 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 27 May 2006 12:41:39 +0200 Subject: rawhide report: 20060527 changes In-Reply-To: <200605270742.k4R7gJ3s001292@porkchop.devel.redhat.com> References: <200605270742.k4R7gJ3s001292@porkchop.devel.redhat.com> Message-ID: <1148726500.2719.3.camel@xpc.home.erwinrol.com> Is yum from yesterdays update broken, is the repo broken or did i localy break something ? when i try yum update i get ; Setting up Update Process Setting up repositories development [1/3] //var/cache/yum/development/repomd.xml:16: parser error : Opening and ending tag mismatch: link line 15 and head ^ References: <1148706929.2401.14.camel@entropy> Message-ID: <20060527114348.GA18192@hurricane.linuxnetz.de> Hello Nicholas, On Fr, 26 Mai 2006, Nicholas Miell wrote: > A crazy license, no documentation, no web site, no mailing list, no CVS, > no real presence besides a RPM, a bugzilla component, and the occasional > mention on the SystemTap list. did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. Both are also glibc developers or even maintainers (see /lib/libc.so.6). > Why is this being used instead of the other (more sensibly licensed? I > can't tell, I have no idea what the elfutils license means.) libelfs and > libdwarfs that are available? Huh? Do you have other elfutils than me? GPL and OSL as far as I got from the elfutils spec file in Fedora Core and rest seems to be explained after reading the comments of elfutils-0.120/libdw/dwarf_attr.c for example. > And where does one go to get bugs fixed, because I don't think bugzilla > is it. (Although, I think this may be a bugzilla privileges issue.) Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, that I'm not really able to get your problem... Greetings, Robert From Lam at Lam.pl Sat May 27 11:54:58 2006 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 27 May 2006 13:54:58 +0200 Subject: rawhide report: 20060527 changes In-Reply-To: <1148726500.2719.3.camel@xpc.home.erwinrol.com> References: <200605270742.k4R7gJ3s001292@porkchop.devel.redhat.com> <1148726500.2719.3.camel@xpc.home.erwinrol.com> Message-ID: <1148730898.2750.4.camel@pensja.lam.pl> Dnia 27-05-2006, sob o godzinie 12:41 +0200, Erwin Rol napisa?(a): > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml: [Errno -1] 404, isn't it: http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml (os/) See http://fedora.redhat.com/download/mirrors/fedora-core-rawhide if you don't believe me that "os" should be there :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From mailinglists at erwinrol.com Sat May 27 12:01:35 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 27 May 2006 14:01:35 +0200 Subject: rawhide report: 20060527 changes In-Reply-To: <1148730898.2750.4.camel@pensja.lam.pl> References: <200605270742.k4R7gJ3s001292@porkchop.devel.redhat.com> <1148726500.2719.3.camel@xpc.home.erwinrol.com> <1148730898.2750.4.camel@pensja.lam.pl> Message-ID: <1148731295.2719.10.camel@xpc.home.erwinrol.com> I have not changed my yum settings in ages, just today it broke. And yes it seems to just be a 404. - Erwin On Sat, 2006-05-27 at 13:54 +0200, Leszek Matok wrote: > Dnia 27-05-2006, sob o godzinie 12:41 +0200, Erwin Rol napisa?(a): > > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml: [Errno -1] > 404, isn't it: > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/os/repodata/repomd.xml > (os/) > > See http://fedora.redhat.com/download/mirrors/fedora-core-rawhide if you > don't believe me that "os" should be there :) > > Lam > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat May 27 12:43:50 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 27 May 2006 14:43:50 +0200 Subject: rawhide report: 20060527 changes In-Reply-To: <1148731295.2719.10.camel@xpc.home.erwinrol.com> References: <200605270742.k4R7gJ3s001292@porkchop.devel.redhat.com> <1148726500.2719.3.camel@xpc.home.erwinrol.com> <1148730898.2750.4.camel@pensja.lam.pl> <1148731295.2719.10.camel@xpc.home.erwinrol.com> Message-ID: <20060527144350.78387866@python2> Erwin Rol wrote : > I have not changed my yum settings in ages, just today it broke. And yes > it seems to just be a 404. Mirrors have started using a new directory layout. See the .rpmnew files you must have in /etc/yum.repos.d/ for the new URLs ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2218_FC6 Load : 1.79 1.23 1.05 From Matt_Domsch at dell.com Sat May 27 13:09:27 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 27 May 2006 08:09:27 -0500 Subject: additional build failures with reduced buildgroup list Message-ID: <20060527130927.GA27900@lists.us.dell.com> I rebuilt all of rawhide using the FESCo reduced buildgroups package list, which removes these packages from the default list of packages in the chroots: autoconf automake automake14 automake15 automake16 automake17 bison byacc createrepo ctags diffstat doxygen flex gdb gettext indent intltool libtool openssh-server patchutils perl-XML-Dumper perl-XML-Parser perl-XML-SAX pkgconfig rpm-python strace Here's the tally: i386 Total packages: 1168 Build failures with larger list in buildgroup: 163 Build failures with smaller list in buildgroup: 322 Additional build failures due to smaller list: 159 x86_64 Total packages: 1168 Build failures with larger list in buildgroup: 174 Build failures with smaller list in buildgroup: 336 Additional build failures due to smaller list: 162 i386 additional failed packages: a2ps am-utils aqbanking atk at-spi authd automake15 automake16 autorun avahi bc brltty busybox cadaver dasher dbus desktop-printing doxygen eel2 evince evolution-connector evolution-data-server evolution-webcal fbset file-roller f-spot gail gcalctool gconf-editor gdb gedit gimp glade2 gnome-applets gnome-backgrounds gnome-bluetooth gnome-doc-utils gnome-icon-theme gnome-keyring gnome-keyring-manager gnome-media gnome-menus gnome-mime-data gnome-mount gnome-netstatus gnome-nettool gnome-panel gnome-pilot gnome-pilot-conduits gnome-power-manager gnome-screensaver gnome-session gnome-spell gnome-user-docs gnome-user-share gnome-utils gnome-vfs2 gnome-volume-manager gob2 gtk+ gtk2 gucharmap hal hwbrowser indent inn iproute iso-codes jpilot kbd krb5-auth-dialog libbonobo libbonoboui libbtctl libgcrypt libgnome libgnomecanvas libgnomecups libgnomeprint22 libgnomeprintui22 libgnomeui libgpod libgsf libgtop2 libIDL liboldX libsemanage libSM libwnck libXau libXaw libxkbfile libxkbui libxklavier libXpm libXrandr libXrender libXres libXt libXtst libXv libXvMC libXxf86dga libXxf86misc libXxf86vm linux-atm lm_sensors longrun lrzsz lynx m17n-lib metacity nautilus-sendto ncpfs openmotif pcmciautils pirut pkgconfig planner policycoreutils prelink pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus ruby sane-backends scim-chewing scim-qtimm selinux-policy sound-juicer specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tomboy tsclient vino w3m wordtrans Xaw3d xmlsec1 xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata yelp zenity x86_64 additional failed packages: a2ps am-utils aqbanking atk at-spi authd automake15 automake16 autorun avahi bc boost brltty busybox cadaver dasher dbus desktop-printing doxygen eel2 evince evolution-connector evolution-data-server evolution-webcal fbset file-roller f-spot gail gcalctool gconf-editor gdb gedit gimp glade2 gnome-applets gnome-backgrounds gnome-bluetooth gnome-doc-utils gnome-icon-theme gnome-keyring gnome-keyring-manager gnome-media gnome-menus gnome-mime-data gnome-mount gnome-netstatus gnome-nettool gnome-panel gnome-pilot gnome-pilot-conduits gnome-power-manager gnome-screensaver gnome-session gnome-spell gnome-user-docs gnome-user-share gnome-utils gnome-vfs2 gnome-volume-manager gob2 gtk+ gtk2 gucharmap hal hwbrowser indent inn iproute iso-codes jpilot kbd kdeaccessibility krb5-auth-dialog libbonobo libbonoboui libbtctl libgcrypt libgnome libgnomecanvas libgnomecups libgnomeprint22 libgnomeprintui22 libgnomeui libgpod libgsf libgtop2 libIDL libmusicbrainz liboldX libsemanage libSM libwnck libXau libXaw libxkbfile libxkbui libxklavier libXpm libXrandr libXrender libXres libXt libXtst libXv libXvMC libXxf86dga libXxf86misc libXxf86vm linux-atm lm_sensors lrzsz lynx m17n-lib metacity nautilus-sendto ncpfs openmotif pcmciautils perl pirut pkgconfig planner policycoreutils pump pwlib pycairo pykickstart qt radvd rdist redhat-artwork redhat-menus ruby sane-backends scim-chewing scim-qtimm selinux-policy sgml-common sound-juicer specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tomboy tsclient vino w3m wordtrans Xaw3d xmlsec1 xmlto xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata yelp zenity -- 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 Matt_Domsch at dell.com Sat May 27 13:26:11 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 27 May 2006 08:26:11 -0500 Subject: rawhide rebuild in mock status 2006-05-26 with trimmed buildgroups Message-ID: <20060527132611.GB27900@lists.us.dell.com> This is the first daily build from the 2006-05-26 rawhide push that uses the proposed trimmed buildgroup list. Rawhide-in-Mock Build Results for x86_64 Architecture Sat May 27 02:57:43 CDT 2006 Number failed to build: 336 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 308 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 143 ---------------------------------- a2ps am-utils aqbanking atk authd automake15 automake16 autorun bc boost brltty busybox cadaver dasher dbus doxygen elilo emacs evince evolution-data-server evolution-webcal fbset file-roller f-spot gconf-editor gdb gedit gimp glade2 gnome-applets gnome-backgrounds gnome-bluetooth gnome-doc-utils gnome-icon-theme gnome-keyring gnome-keyring-manager gnome-menus gnome-mime-data gnome-netstatus gnome-nettool gnome-pilot gnome-pilot-conduits gnome-screensaver gnome-session gnome-spell gnome-user-docs gnome-user-share gnome-vfs2 gnome-volume-manager gob2 gtk+ gtk2 gucharmap hwbrowser indent inn iproute iso-codes jpilot kbd kdeaccessibility krb5-auth-dialog libbonobo libgcrypt libgnome libgnomecanvas libgnomeprintui22 libgnomeui libgpod libgsf libgtop2 libIDL libmusicbrainz liboldX libSM libXau libXaw libxkbfile libxkbui libxklavier libXpm libXrandr libXrender libXres libXt libXtst libXv libXvMC libXxf86dga libXxf86misc libXxf86vm linux-atm lm_sensors lrzsz lynx m17n-lib magma-plugins ncpfs openmotif pcmciautils perl pirut pkgconfig policycoreutils pump pwlib pycairo pygtk2 pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm SDL selinux-policy sgml-common specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans Xaw3d xmlsec1 xmlto xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 165 ---------------------------------- arptables_jf ['191688 CLOSED'] arts ['192367 NEEDINFO'] at-spi ['192368 CLOSED'] avahi ['191663 CLOSED'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evolution-connector ['192251 CLOSED'] frysk ['192256 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gnbd-kernel ['192573 NEW'] gnome-media ['192497 CLOSED'] gnome-mount ['191680 CLOSED'] gnome-panel ['192498 CLOSED'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-utils ['191757 CLOSED'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libnl ['191973 NEW'] libnotify ['191731 NEW'] libsemanage ['191733 CLOSED'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 CLOSED'] qt ['191895 CLOSED'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] valgrind ['191820 CLOSED'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 CLOSED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 CLOSED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 CLOSED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 CLOSED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 CLOSED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 CLOSED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 CLOSED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ Rawhide-in-Mock Build Results for i386 Architecture Sat May 27 02:58:55 CDT 2006 Number failed to build: 322 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 311 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 141 ---------------------------------- a2ps am-utils apr aqbanking atk authd automake15 automake16 autorun bc brltty busybox cadaver dasher dbus doxygen emacs evince evolution-data-server evolution-webcal fbset file-roller f-spot gconf-editor gdb gedit gimp glade2 gnome-applets gnome-backgrounds gnome-bluetooth gnome-doc-utils gnome-icon-theme gnome-keyring gnome-keyring-manager gnome-menus gnome-mime-data gnome-netstatus gnome-nettool gnome-pilot gnome-pilot-conduits gnome-screensaver gnome-session gnome-spell gnome-user-docs gnome-user-share gnome-vfs2 gnome-volume-manager gob2 gpart gtk+ gtk2 gucharmap hwbrowser indent inn iproute iso-codes jpilot kbd krb5-auth-dialog libbonobo libgcrypt libgnome libgnomecanvas libgnomeprintui22 libgnomeui libgpod libgsf libgtop2 libIDL liboldX libSM libXau libXaw libxkbfile libxkbui libxklavier libXpm libXrandr libXrender libXres libXt libXtst libXv libXvMC libXxf86dga libXxf86misc libXxf86vm linux-atm lm_sensors longrun lrzsz lynx m17n-lib magma-plugins ncpfs openmotif pcmciautils pirut pkgconfig policycoreutils prelink pump pwlib pycairo pygtk2 pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm SDL selinux-policy sg3_utils specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans Xaw3d xmlsec1 xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 170 ---------------------------------- arptables_jf ['191688 CLOSED'] arts ['192367 NEEDINFO'] at-spi ['192368 CLOSED'] avahi ['191663 CLOSED'] beagle ['191664 CLOSED'] bsf ['192369 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evolution-connector ['192251 CLOSED'] frysk ['192256 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] GFS-kernel ['192569 NEW'] gnbd-kernel ['192573 NEW'] gnome-media ['192497 CLOSED'] gnome-mount ['191680 CLOSED'] gnome-panel ['192498 CLOSED'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-utils ['191757 CLOSED'] gnucash ['192008 CLOSED'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] iptraf ['192510 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libglade-java ['192532 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libnotify ['191731 NEW'] libsemanage ['191733 CLOSED'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] pyxf86config ['191894 CLOSED'] reiserfs-utils ['191889 NEW'] rhythmbox ['191760 CLOSED'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-apps ['191896 CLOSED'] xorg-x11-drv-acecad ['191900 ASSIGNED'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-glint ['192365 CLOSED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-mga ['192340 CLOSED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-savage ['192349 CLOSED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sis ['192351 CLOSED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tdfx ['192358 CLOSED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-via ['192167 CLOSED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-drv-voodoo ['192042 ASSIGNED'] xorg-x11-fonts ['192038 CLOSED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ -- 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 gauret at free.fr Sat May 27 13:33:37 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 27 May 2006 15:33:37 +0200 Subject: A sole, standard proxy library for Fedora References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > Can I attest to how little this helps. First of all, this solution is > virtually non existant without doing some Googling. Then (at least > based on the solution I found) I had to write up a script to export > the variables, both in lower case and uppercase, or export them > manually. How about having a file in /etc/profile.d, say proxy.sh and proxy.csh (yeah, that's two, well, you get the point) containing this: # Set your proxy using the following variables: # http_proxy=http://your.proxy.server:8080 # ftp_proxy=http://your.proxy.server:8080 # If you need authentication, use: # http_proxy=http://username:password at your.proxy.server:8080 At least that would save the Googling (and it's easy to do). Then, we could make a system-config-proxy which would set this file, and set the proxy in GNOME, KDE and firefox while it's at it. Or we could fix the GNOME setting app and Kcontrol to setup environment variables in /etc/profile.d/proxy.{sh,csh}. I'm not sure upstream would accept setting the proxy in Firefox too though, so we might need a system-config-proxy in the end. Yes, this is suboptimal compared to using a single libproxy.so to rule them all, but will big cross-platform apps like firefox support it ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr The only "intuitive" interface is the nipple. After that it's all learned. From Lam at Lam.pl Sat May 27 13:48:59 2006 From: Lam at Lam.pl (Leszek Matok) Date: Sat, 27 May 2006 15:48:59 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> Message-ID: <1148737739.2750.13.camel@pensja.lam.pl> Dnia 27-05-2006, sob o godzinie 15:33 +0200, Aurelien Bompard napisa?(a): > How about having a file in /etc/profile.d, say proxy.sh and proxy.csh (yeah, > that's two, well, you get the point) containing this: My tcsh reads its profile only when it starts up. It means I have to close every session I have in order to use the change. I thought this thread was about preventing this (and not introducing :)) using a library that re-checks the configuration every time any application tries to download something, without the need to restart it. Your proposal not only demands that I have to cancel and restart e.g. wget -c, it also requires me to log out and log in again. That's unacceptable for some people. I know I can just source the files any time I want, but we're talking about doing things automatically :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From bdpepple at ameritech.net Sat May 27 13:25:26 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 27 May 2006 09:25:26 -0400 Subject: additional build failures with reduced buildgroup list In-Reply-To: <20060527130927.GA27900@lists.us.dell.com> References: <20060527130927.GA27900@lists.us.dell.com> Message-ID: <1148736326.4764.1.camel@shuttle.piedmont.com> On Sat, 2006-05-27 at 08:09 -0500, Matt Domsch wrote: > I rebuilt all of rawhide using the FESCo reduced buildgroups package > list, which removes these packages from the default list of packages > in the chroots: > autoconf automake automake14 automake15 automake16 automake17 bison > byacc createrepo ctags diffstat doxygen flex gdb gettext indent > intltool libtool openssh-server patchutils perl-XML-Dumper > perl-XML-Parser perl-XML-SAX pkgconfig rpm-python strace > > Here's the tally: > > i386 > Total packages: 1168 > Build failures with larger list in buildgroup: 163 > Build failures with smaller list in buildgroup: 322 > Additional build failures due to smaller list: 159 > > x86_64 > Total packages: 1168 > Build failures with larger list in buildgroup: 174 > Build failures with smaller list in buildgroup: 336 > Additional build failures due to smaller list: 162 > That's less than I thought would fail, but still a lot. /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 fedora at leemhuis.info Sat May 27 14:09:21 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 27 May 2006 16:09:21 +0200 Subject: additional build failures with reduced buildgroup list In-Reply-To: <20060527130927.GA27900@lists.us.dell.com> References: <20060527130927.GA27900@lists.us.dell.com> Message-ID: <1148738962.2306.17.camel@localhost.localdomain> Am Samstag, den 27.05.2006, 08:09 -0500 schrieb Matt Domsch: > I rebuilt all of rawhide using the FESCo reduced buildgroups package > list, which removes these packages from the default list of packages > in the chroots: > autoconf automake automake14 automake15 automake16 automake17 bison > byacc createrepo ctags diffstat doxygen flex gdb gettext indent > intltool libtool openssh-server patchutils perl-XML-Dumper > perl-XML-Parser perl-XML-SAX pkgconfig rpm-python strace Just a bit background information: The list of packages that mock installed by default currently doesn't match the list of exceptions documented in http://www.fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 We currently try to clean this mess up and bring the guidelines and mock in sync. The current plan is to remove those packages mdomsch listed above from the default mock buildroot. Especially the auto* stuff shouldn't be needed normally. Some crucial packages are still under discussion: "which" -- some people think it shouldn't be in the list, but it's a widely used tool in Scripts, Makefiles and Specfiles. mdomsch therefor added it for now after a short discussion with spot in #fedora-extras. "gettext" -- multiple packages won't build all the translations without it. So why not add it? Well, here are parts of the discussion from FESCO-List: > > > gettext > > > This falls pretty close in line with gcc -- basically, any app with > > > translations is going to use gettext during its build process and if you > > > don't have it installed, the build probably succeeds and you just don't > > > have translations. Which is the suck. > > > > Exactly -- that's why it maybe should *not* be installed in the "default > > buildroot". I in the past multiple times ran into failed or incomplete > > rebuilds when rebuilding something as a ordinary user (e.g. without > > mock) on a system where gettext was not installed. > > > Seconded, with no maybes :) "pkgconfig" -- Also still undecided. Here are parts of the past discussion: > > > > pkgconfig > > > Might make sense to leave in, or, start having packages with .pc files > > > require pkgconfig. > > > > I'd prefer the latter. I just ran into troubles some days ago when I had > > to install the nvidia drivers on a FC5 system manually. I installed > > "xorg-x11-server-sdk" (as advised on nvnews.net) and tried to install > > the drivers with the crappy nvidia installer but it failed because > > "xorg-x11-server-sdk" ships with a .pc file, but did not require > > pkgconfig. > > Me too, and that's how it already is in the vast majority of Extras > packages that install *.pc. And FYI here the complete log from this weeks FESCo meeting on that topic: 0:02 < thl> | buildsys-build -> spot not there 0:03 < thl> | do we want to discuss this without him? 0:03 < jeremy> | thl: I think we largely had consensus on it 0:03 --- | thl has changed the topic to: FESCO Meetingin progress -- buildsys-build 0:03 < warren> | jeremy, use the Exceptions list and explicitly list everything that it pulls in? 0:03 < thl> | jeremy, what was the consens with gettext ? 0:04 < jeremy> | thl: I'm okay with not having it be in exceptions -- a spot check of packages showed the buildrequires being there 0:04 < thl> | jeremy, and pkgconfig 0:04 < thl> | ? 0:04 < jeremy> | having the packages with .pc files require pkgconfig instead of having pkgconfig in the base set is fine by me 0:04 * | scop sees no reason to except pkgconfig 0:05 < ensc> | afaik, pkgconfig is required by rpm scriptlets 0:05 < ensc> | (which produce ugly warnings else) 0:05 < scop> | which ones? 0:05 < ensc> | (e.g. about broken pipes) 0:05 < warren> | I'm 60% leaning towards adding pkgconfig to exceptions. 0:05 < ensc> | find-provides.pkgconfig 0:05 < ensc> | contains 0:05 < ensc> | test -x $pkgconfig || exit 0 0:06 < ensc> | and some find-requires clue pipes a filelist into this script 0:06 < ensc> | but these are only warnings; no errors 0:06 < scop> | sounds like a bug in rpm/redhat-rpm-config to me 0:07 < ensc> | yes 0:07 < ensc> | but I was shocked by the find-requires script and did not write a report yet 0:07 < ensc> | ;) 0:07 < warren> | I move that we add pkgconfig to the exceptions list. It is simple enough and self-contained, it doesn't pull anything else in. 0:07 < scop> | -1 0:08 < thl> | -0.5 0:08 < warren> | -1 0:08 < warren> | =) 0:09 < ensc> | -1 0:09 < warren> | so we're pretty much going with the fedora.us exception list as-is? 0:09 --> | |Jef| (Spacious..he's so!) has joined #fedora-extras 0:09 < tibbs> | Is the list expected to change over time? 0:10 < thl> | warren, I suppose we go for the list spot posted to fesco-list ? 0:10 --- | mebrown_laptop_ is now known as mebrown_laptop 0:10 < jeremy> | tibbs: at least not often 0:10 < thl> | warren, in the mail that starts with "Here is the extrapolated list of Exceptions..." 0:11 < warren> | my mail has been screwed lately 0:11 * | warren attempts to find it 0:11 < tibbs> | OK. Do you plan to change it for all supported distributions, or only for the development branch? 0:11 < scop> | all 0:11 < thl> | tibbs, good question 0:11 < thl> | all +1 0:11 < thl> | might make some trouble 0:12 < warren> | thl, I believe that is fedora.us exceptions + anything it pulls in. 0:12 < scop> | right 0:12 < tibbs> | I will certainly be happy to review against whatever list you determine, but some folks might torqued if stuff stops building. 0:12 < thl> | warren, yeah, looks like it 0:12 < thl> | tibbs, maybe we should ask mdomsch to make a rebuild check for extras, too 0:13 < thl> | jeremy, btw, is this change also okay for core? 0:13 < scop> | but dependencies change, and listing the extrapolated list is slightly harder to document and may require a bit more maintenance 0:13 < warren> | did mdomsch use that set in his core build test? 0:13 < bpepple> | warren: No. 0:13 < thl> | warren, he probably uses the old set 0:13 < thl> | with autoconf and other stuff that we kick out currently 0:13 < warren> | scop, in that case, I move that we list both the Exceptions list, and the extrapolated list. 0:13 < warren> | the extrapolated list can be regenerated based on the Exceptions list 0:13 < thl> | warren, +1 0:14 < tibbs> | Seems reasonable. 0:14 < scop> | works for me, but it probably needs to be listed separately for all distro versions 0:14 < scop> | (in case there are differences) 0:14 < warren> | We could also diff the extrapolated list to make sure we know what appeared/disappeared 0:15 < scop> | that would be useful, yes 0:16 < thl> | okay, let's work out the details when spot is back 0:16 < thl> | but we agreed on the general direction from spots mail 0:16 < thl> | e.g. kick autoconf and some other stuff out 0:16 < warren> | nod 0:16 < jeremy> | right 0:16 < tibbs> | If mdomsch shares his scripts I'll be happy to try an extras rebuild; I have ten or so quad opteron boxes I can throw at it. 0:17 < warren> | tibbs, home heating system? =) 0:17 < thl> | this ones are kicked out then: autoconf automake automake14 automake15 automake16 automake17 bison buildsys-macros byacc createrepo ctags diffstat doxygen flex gdb gettext indent intltool libtool openssh-server patchutils perl-XML-Dumper perl-XML-Parser perl-XML-SAX pkgconfig rpm-python strace which 0:17 * | scop giggles 0:17 < tibbs> | Great! 0:17 < warren> | openssh-server was an odd one 0:17 < scop> | well, buildsys-macros probably need to stay in, no? 0:18 < thl> | scop, agreed :) 0:18 < warren> | scop, add that to Exceptions list? 0:18 < ensc> | what is with 'which'? 0:18 < scop> | openssh-server is a relic from mach 0:18 < nirik> | which is used by a lot of configure scripts... 0:18 --> | finalzone (gaim) has joined #fedora-extras 0:18 < warren> | Hmm... maybe we should add which? 0:18 < nirik> | ie 'which perl' to find out what to call perl with. 0:19 < scop> | buildsys-macros is not available in FC/FE, I think it's only in a buildsys private repo 0:19 < warren> | Anybody else support the idea of adding which? 0:19 < tibbs> | It would be nice to know what breaks if a particular package gets pulled. 0:19 < thl> | warren, yeah, let's add it 0:20 < warren> | Anybody object? 0:20 < abadger1999> | Wouldn't the argument for which also apply to pkgconfig? 0:20 < thl> | some Makefiles probably rely on it, too 0:20 < scop> | openssh-server had something to do with the *host's*, not chroot's openssh-server possibly restarted/stopped on some operations 0:20 --> | Sopwith (Undisclosed) has joined #fedora-extras 0:20 * | scop throws in a blanket -1 to any additions 0:21 < warren> | I must disagree in the case of which. 0:21 < thl> | warren, let's skip the addition of which now 0:21 < warren> | ok 0:21 < thl> | we can readd it later if it should be needed 0:21 < thl> | okay, let's move on then -- Thorsten Leemhuis From jreiser at BitWagon.com Sat May 27 15:04:05 2006 From: jreiser at BitWagon.com (John Reiser) Date: Sat, 27 May 2006 08:04:05 -0700 Subject: What's up with elfutils? In-Reply-To: <20060527114348.GA18192@hurricane.linuxnetz.de> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> Message-ID: <44786A65.40206@BitWagon.com> Robert Scheck wrote: > Hello Nicholas, > > On Fr, 26 Mai 2006, Nicholas Miell wrote: > >>A crazy license, no documentation, no web site, no mailing list, no CVS, >>no real presence besides a RPM, a bugzilla component, and the occasional >>mention on the SystemTap list. > > > did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is > upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. > Both are also glibc developers or even maintainers (see /lib/libc.so.6). [snip] >>And where does one go to get bugs fixed, because I don't think bugzilla >>is it. (Although, I think this may be a bugzilla privileges issue.) > > > Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, > that I'm not really able to get your problem... Nicholas's observation about the status of elfutils, and Robert's reply, can be explained even more simply: elfutils is _not_ a Fedora project! elfutils is a Red Hat project, and so far Red Hat has not ceded control of elfutils to anyone, especially including the Fedora community. Also, so far Fedora has avoided calling attention to issues such as the ones raised by Nicholas. On the other hand, there is substantial overlap between elfutils (eu-addr2line, eu-elflint, eu-findtextrel, eu-nm, eu-readelf, eu-size, eu-strip, etc.) and binutils (addr2line, nm, readelf, size, strip, objdump, etc.) so perhaps Fedora should drop elfutils entirely. -- From fedora at leemhuis.info Sat May 27 15:37:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 27 May 2006 17:37:08 +0200 Subject: additional build failures with reduced buildgroup list In-Reply-To: <20060527130927.GA27900@lists.us.dell.com> References: <20060527130927.GA27900@lists.us.dell.com> Message-ID: <1148744228.2306.23.camel@localhost.localdomain> Am Samstag, den 27.05.2006, 08:09 -0500 schrieb Matt Domsch: > I rebuilt all of rawhide using the FESCo reduced buildgroups package > list, which removes these packages from the default list of packages > in the chroots: > autoconf automake automake14 automake15 automake16 automake17 bison > byacc createrepo ctags diffstat doxygen flex gdb gettext indent > intltool libtool openssh-server patchutils perl-XML-Dumper > perl-XML-Parser perl-XML-SAX pkgconfig rpm-python strace I took a quick and rough look at some of those newly failed packages. A missing gettext seems to be the culprit quite often. Saw also some packages that failed due to missing pkgconfig or XML::Parser. CU thl -- Thorsten Leemhuis From rhodges at cisco.com Sat May 27 15:51:26 2006 From: rhodges at cisco.com (Ryan Hodges) Date: Sat, 27 May 2006 08:51:26 -0700 Subject: A sole, standard proxy library for Fedora In-Reply-To: <1148737739.2750.13.camel@pensja.lam.pl> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <1148737739.2750.13.camel@pensja.lam.pl> Message-ID: <4478757E.9080001@cisco.com> Has this ever been discussed as part of the Linux Standards Base specification. It seems like this would be a good place for a proposal to take shape. Thanks, Ryan Leszek Matok wrote: > Dnia 27-05-2006, sob o godzinie 15:33 +0200, Aurelien Bompard > napisa?(a): >> How about having a file in /etc/profile.d, say proxy.sh and proxy.csh (yeah, >> that's two, well, you get the point) containing this: > My tcsh reads its profile only when it starts up. It means I have to > close every session I have in order to use the change. I thought this > thread was about preventing this (and not introducing :)) using a > library that re-checks the configuration every time any application > tries to download something, without the need to restart it. Your > proposal not only demands that I have to cancel and restart e.g. wget > -c, it also requires me to log out and log in again. That's unacceptable > for some people. > > I know I can just source the files any time I want, but we're talking > about doing things automatically :) > > Lam > From arjan at fenrus.demon.nl Sat May 27 15:18:53 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 27 May 2006 17:18:53 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: <1148664862.2472.7.camel@dhollis-lnx.sunera.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> Message-ID: <1148743134.3265.226.camel@laptopd505.fenrus.org> On Fri, 2006-05-26 at 13:34 -0400, David Hollis wrote: > On Fri, 2006-05-26 at 11:11 -0600, Philip Prindeville wrote: > > I have a laptop that travels with me from work (where there's the > > use of web proxies) to home (where I don't), and was overwhelmed > > by the number of config files that I have to switch over every time > > I move from one place to the other. > > Most CLI apps will honor http_proxy/ftp_proxy environment variables for > proxying. GUI apps may or may not support that, I can't say that I've > tried. Gnome (and I'm sure KDE) have their own control panel setting > for that, but that only applies to apps that make use of their VFS > library. If they do their own web access, they may not honor it. the thing is that the lib needs to really be able to deal with auto proxy scripts... ... which is more complex than just http_proxy... From david at fubar.dk Sat May 27 16:26:21 2006 From: david at fubar.dk (David Zeuthen) Date: Sat, 27 May 2006 12:26:21 -0400 Subject: Starting services when not needed (Was Re: NetworkManager system-wide use) In-Reply-To: <1148679042.10628.3.camel@pmac.infradead.org> References: <1148653016.2468.4.camel@localhost.localdomain> <44773783.5040609@redfish-solutions.com> <1148665058.2472.10.camel@dhollis-lnx.sunera.com> <44773F6E.9050707@redfish-solutions.com> <1148667340.2670.15.camel@price> <1148679042.10628.3.camel@pmac.infradead.org> Message-ID: <1148747181.2515.5.camel@daxter.boston.redhat.com> On Fri, 2006-05-26 at 22:30 +0100, David Woodhouse wrote: > What if the user receives a Word document in email? Are we going to > demand the root password and install OpenOffice? No, we must force > OpenOffice to be installed at all times instead. You know, David, this reminds me of how Fedora starts up a bunch of Bluetooth daemons in the default install even if I don't have an adapter on my system installed [1]. This is even worse than installing said software in the default install and we seem to still do this a lot in Fedora. Sure, the software should be installed since anyone can hotplug a BT adapter but we sure as hell don't want it started if there is no adapter present. Care to fix this? David [1] : You know, we already have excellent infrastructure for managing e.g. daemons whose life cycle is tied when specific hardware is available. Thought I'd just mention that. From philipp_subx at redfish-solutions.com Sat May 27 16:38:51 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 27 May 2006 10:38:51 -0600 Subject: A sole, standard proxy library for Fedora In-Reply-To: <4478757E.9080001@cisco.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <1148737739.2750.13.camel@pensja.lam.pl> <4478757E.9080001@cisco.com> Message-ID: <4478809B.7080203@redfish-solutions.com> Hey Ryan! Haven't heard from you in a while... :-) Yeah, that would probably be a good place. Or eventually the right place. The issue was that the Fedora distro has patches built into the apps, of course, which means that Fedora users could use and test the library ahead of the curve... and maybe be the testing audience getting the operational experience to make this change happen upstream (i.e. the proof that it works). -Philip Ryan Hodges wrote: >Has this ever been discussed as part of the Linux Standards Base >specification. It seems like this would be a good place for a proposal >to take shape. > >Thanks, >Ryan > > >Leszek Matok wrote: > > >>Dnia 27-05-2006, sob o godzinie 15:33 +0200, Aurelien Bompard >>napisa?(a): >> >> >>>How about having a file in /etc/profile.d, say proxy.sh and proxy.csh (yeah, >>>that's two, well, you get the point) containing this: >>> >>> >>My tcsh reads its profile only when it starts up. It means I have to >>close every session I have in order to use the change. I thought this >>thread was about preventing this (and not introducing :)) using a >>library that re-checks the configuration every time any application >>tries to download something, without the need to restart it. Your >>proposal not only demands that I have to cancel and restart e.g. wget >>-c, it also requires me to log out and log in again. That's unacceptable >>for some people. >> >>I know I can just source the files any time I want, but we're talking >>about doing things automatically :) >> >>Lam >> >> >> > > > From jkeating at redhat.com Sat May 27 17:12:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 27 May 2006 13:12:49 -0400 Subject: additional build failures with reduced buildgroup list In-Reply-To: <20060527130927.GA27900@lists.us.dell.com> References: <20060527130927.GA27900@lists.us.dell.com> Message-ID: <1148749969.7067.7.camel@ender> On Sat, 2006-05-27 at 08:09 -0500, Matt Domsch wrote: > > i386 > Total packages: 1168 > Build failures with larger list in buildgroup: 163 > Build failures with smaller list in buildgroup: 322 > Additional build failures due to smaller list: 159 > > x86_64 > Total packages: 1168 > Build failures with larger list in buildgroup: 174 > Build failures with smaller list in buildgroup: 336 > Additional build failures due to smaller list: 162 Oh my. Thats a lot of bugs to file. Matt, thanks for making this adjustment, and pointing out a whole bunch more packages that need to be fixed. -- 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 bdpepple at ameritech.net Sat May 27 17:38:03 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Sat, 27 May 2006 13:38:03 -0400 Subject: additional build failures with reduced buildgroup list In-Reply-To: <1148749969.7067.7.camel@ender> References: <20060527130927.GA27900@lists.us.dell.com> <1148749969.7067.7.camel@ender> Message-ID: <1148751483.5355.2.camel@shuttle.piedmont.com> On Sat, 2006-05-27 at 13:12 -0400, Jesse Keating wrote: > On Sat, 2006-05-27 at 08:09 -0500, Matt Domsch wrote: > > > > i386 > > Total packages: 1168 > > Build failures with larger list in buildgroup: 163 > > Build failures with smaller list in buildgroup: 322 > > Additional build failures due to smaller list: 159 > > > > x86_64 > > Total packages: 1168 > > Build failures with larger list in buildgroup: 174 > > Build failures with smaller list in buildgroup: 336 > > Additional build failures due to smaller list: 162 > > > Oh my. Thats a lot of bugs to file. Matt, thanks for making this > adjustment, and pointing out a whole bunch more packages that need to be > fixed. Yeah, probably a lot of the bugs we fixed the last couple of weeks will also need to be re-opened. /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 bernie at develer.com Sat May 27 17:53:47 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 27 May 2006 19:53:47 +0200 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474F1F1.10805@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> <4474F1F1.10805@mharris.ca> Message-ID: <4478922B.5070504@develer.com> Mike A. Harris wrote: > chkfontpath in theory could be rewritten to configure the X server, > which would work for fresh OS installs, but would more or less > totally break on OS upgrades, or yum upgrades that migrate from one > OS release to the next. For the next Fedora release, we could have chkfontpath updated to *also* add the font path to xorg.conf. xfs would remain enabled in existing systems, and could perhaps be disabled by default for new installations. chkfontpath could also add the path dynamically with xset to let the user play with new fonts without the need to restart the X server. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From arjan at fenrus.demon.nl Sat May 27 19:31:16 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 27 May 2006 21:31:16 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: <4478757E.9080001@cisco.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <1148737739.2750.13.camel@pensja.lam.pl> <4478757E.9080001@cisco.com> Message-ID: <1148758276.3265.237.camel@laptopd505.fenrus.org> On Sat, 2006-05-27 at 08:51 -0700, Ryan Hodges wrote: > Has this ever been discussed as part of the Linux Standards Base > specification. It seems like this would be a good place for a proposal > to take shape. the LSB seems to mostly try to standardize existing practices, while this would to a large degree be a new development.. (or at least.. I've not seen a "general winner" in this area that would fit in the "existing practice" box) From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat May 27 19:50:57 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 27 May 2006 21:50:57 +0200 Subject: additional build failures with reduced buildgroup list In-Reply-To: <1148749969.7067.7.camel@ender> References: <20060527130927.GA27900@lists.us.dell.com> <1148749969.7067.7.camel@ender> Message-ID: <20060527215057.1f7f69d5@python2> Jesse Keating wrote : > Oh my. Thats a lot of bugs to file. Matt, thanks for making this > adjustment, and pointing out a whole bunch more packages that need to be > fixed. Just worth pointing out an important fact here : A package not failing the build isn't necessarily a package without missing build requirements. Quite often there are "optional" features that are automatically enabled with the presence of other packages, and if these don't result in a different set of %files, they can easily go unseen. I think the next step will be to do a mass rebuild of all Rawhide packages in minimal mock roots and compare what they provide and require with the Rawhide packages of the same version built with Beehive. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2218_FC6 Load : 0.39 0.33 0.32 From nmiell at comcast.net Sat May 27 20:02:26 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 27 May 2006 13:02:26 -0700 Subject: What's up with elfutils? In-Reply-To: <1148722384.4310.714.camel@sundaram.pnq.redhat.com> References: <1148706929.2401.14.camel@entropy> <1148713391.4310.698.camel@sundaram.pnq.redhat.com> <1148715016.2401.15.camel@entropy> <1148722384.4310.714.camel@sundaram.pnq.redhat.com> Message-ID: <1148760146.2402.14.camel@entropy> On Sat, 2006-05-27 at 15:03 +0530, Rahul Sundaram wrote: > On Sat, 2006-05-27 at 00:30 -0700, Nicholas Miell wrote: > > On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote: > > > On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote: > > > > A crazy license, no documentation, no web site, no mailing list, no CVS, > > > > no real presence besides a RPM, a bugzilla component, and the occasional > > > > mention on the SystemTap list. > > > > > > > > Why is this being used instead of the other (more sensibly licensed? I > > > > can't tell, I have no idea what the elfutils license means.) libelfs and > > > > libdwarfs that are available? > > > > > > > > > > > And where does one go to get bugs fixed, because I don't think bugzilla > > > > is it. (Although, I think this may be a bugzilla privileges issue.) > > > > > > > > -- > > > > > > You arent able to file bug reports against elfutils in > > > http://bugzilla.redhat.com? > > > > Oh, I can, but I can't move them out of the MODIFIED state and none of > > the default queries (i.e. My Bugs) include MODIFIED. > > What are you trying to do? Are you trying to query or change state of > the reports? Which bugs? Well, I'd like to be able to just drop a line to the elfutils list saying "Any progress on this bug?", but no such list exists, so I'm reduced to bothering fedora-devel. Bug 187618, was submitted, partially fixed, and moved into the MODIFIED state, which bugzilla describes as "Fix applied, please test" (or something like that). I've tested it, discovered that that the fix was incomplete, and now I can't move it back to NEW or ASSIGNED or whatever and (afaict), nobody ever sees MODIFIED bugs in the normal course of bugzilla usage. -- Nicholas Miell From nmiell at comcast.net Sat May 27 20:02:28 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 27 May 2006 13:02:28 -0700 Subject: What's up with elfutils? In-Reply-To: <20060527114348.GA18192@hurricane.linuxnetz.de> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> Message-ID: <1148760148.2402.15.camel@entropy> On Sat, 2006-05-27 at 13:43 +0200, Robert Scheck wrote: > Hello Nicholas, > > On Fr, 26 Mai 2006, Nicholas Miell wrote: > > A crazy license, no documentation, no web site, no mailing list, no CVS, > > no real presence besides a RPM, a bugzilla component, and the occasional > > mention on the SystemTap list. > > did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is > upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. > Both are also glibc developers or even maintainers (see /lib/libc.so.6). > Yes, I am aware of this. Does this mean I email them personally with all elfutils questions/discussions/patches? Shouldn't that be done on a public list? > > Why is this being used instead of the other (more sensibly licensed? I > > can't tell, I have no idea what the elfutils license means.) libelfs and > > libdwarfs that are available? > > Huh? Do you have other elfutils than me? GPL and OSL as far as I got from > the elfutils spec file in Fedora Core and rest seems to be explained after > reading the comments of elfutils-0.120/libdw/dwarf_attr.c for example. > elfutils is licensed under the GPL for all the tools (which I'm perfectly OK with), and the GPL and/or something unintelligible for the libraries. AFAICT, the "something unitelligible" says that it can also be used by any OSI sufficienty viral OSI license, but I haven't paid a lawyer to explain it to me. The choice of GPL and/or viral OSI license for a library that reimplements a common API used by most (all?) ELF Unixen is strange, considering that better APIs could probably be developed if portable application compatibility is not a goal of the project, and that seems to be the case based on the licensing choice and comments by Mr. Drepper. > > And where does one go to get bugs fixed, because I don't think bugzilla > > is it. (Although, I think this may be a bugzilla privileges issue.) > > Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, > that I'm not really able to get your problem... This is being discussed elsewhere in this thread, so I'm not going to repeat myself here. -- Nicholas Miell From Matt_Domsch at dell.com Sat May 27 21:04:48 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 27 May 2006 16:04:48 -0500 Subject: additional build failures with reduced buildgroup list In-Reply-To: <20060527215057.1f7f69d5@python2> References: <20060527130927.GA27900@lists.us.dell.com> <1148749969.7067.7.camel@ender> <20060527215057.1f7f69d5@python2> Message-ID: <20060527210448.GA32644@lists.us.dell.com> On Sat, May 27, 2006 at 09:50:57PM +0200, Matthias Saou wrote: > I think the next step will be to do a mass rebuild of all Rawhide > packages in minimal mock roots and compare what they provide and > require with the Rawhide packages of the same version built with > Beehive. That's exactly what I've done. ;-) http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ For each package, there's a directory result/, with the rpmdiff (ignoring the fact that the timestamps change on the files in the package) of beehive vs mock. There's also an rpmlint output. There's also a list per-arch of those files, listing just the items added or removed (files, requires, provides, ...) http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/00-rpmdiff-added-or-removed.txt http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/00-rpmdiff-added-or-removed.txt -- 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 mailinglists at erwinrol.com Sat May 27 22:19:18 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 28 May 2006 00:19:18 +0200 Subject: autofs problems Message-ID: <1148768358.2719.79.camel@xpc.home.erwinrol.com> Since a few days i have problems with autofs. In my log file i find the following entries; when i try "ls /net/192.168.2.1/home" May 27 23:40:10 xpc automount[29328]: lookup_mount: >> /usr/sbin/showmount: can't get address for /net/192.168.2.1/home May 27 23:40:10 xpc automount[29328]: lookup_mount: lookup(program): lookup for /net/192.168.2.1/home failed and when i try "ls /net/gate/home" May 27 23:44:45 xpc automount[29521]: lookup_mount: >> /usr/sbin/showmount: can't get address for /net/gate/home May 27 23:44:45 xpc automount[29521]: lookup_mount: lookup(program): lookup for /net/gate/home failed showmount outputs the following; # showmount gate -e Export list for gate: /data * /home * Any ideas ? - Erwin From camilo at mesias.co.uk Sat May 27 16:24:16 2006 From: camilo at mesias.co.uk (Cam) Date: Sat, 27 May 2006 17:24:16 +0100 Subject: A sole, standard proxy library for Fedora In-Reply-To: <447736D6.20204@redfish-solutions.com> References: <447736D6.20204@redfish-solutions.com> Message-ID: <44787D30.6020808@mesias.co.uk> Philip > I have a laptop that travels with me from work (where there's the > use of web proxies) to home (where I don't), and was overwhelmed > by the number of config files that I have to switch over every time > I move from one place to the other. How about having a lightweight proxy on every machine. All configuration should point to the local proxy. When the network changes, only the proxy need be informed of the changes. It's a horrible hack, I know :) but configuration in the environment isn't dynamic enough, and hell will freeze over before any new configuration scheme reaches the level of acceptance that http_proxy in env has. -Cam -- <-- camilo at mesias.co.uk From pemboa at gmail.com Sun May 28 02:45:08 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 27 May 2006 21:45:08 -0500 Subject: A sole, standard proxy library for Fedora In-Reply-To: References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> Message-ID: <16de708d0605271945i50d9101ag338c651d5e796d5c@mail.gmail.com> On 5/27/06, Aurelien Bompard wrote: > Arthur Pemberton wrote: > > Can I attest to how little this helps. First of all, this solution is > > virtually non existant without doing some Googling. Then (at least > > based on the solution I found) I had to write up a script to export > > the variables, both in lower case and uppercase, or export them > > manually. > > How about having a file in /etc/profile.d, say proxy.sh and proxy.csh (yeah, > that's two, well, you get the point) containing this: > # Set your proxy using the following variables: > # http_proxy=http://your.proxy.server:8080 > # ftp_proxy=http://your.proxy.server:8080 > # If you need authentication, use: > # http_proxy=http://username:password at your.proxy.server:8080 > > At least that would save the Googling (and it's easy to do). > > Then, we could make a system-config-proxy which would set this file, and set > the proxy in GNOME, KDE and firefox while it's at it. > Or we could fix the GNOME setting app and Kcontrol to setup environment > variables in /etc/profile.d/proxy.{sh,csh}. I'm not sure upstream would > accept setting the proxy in Firefox too though, so we might need a > system-config-proxy in the end. > > Yes, this is suboptimal compared to using a single libproxy.so to rule them > all, but will big cross-platform apps like firefox support it ? > > > Aur?lien > -- > http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr > The only "intuitive" interface is the nipple. After that it's all learned. > I have tried the above approach manually. It works better on paper than in practice. Especially considering the numerous other applications that require similiar configurations. But that is one solution. -- To be updated... From philipp_subx at redfish-solutions.com Sun May 28 06:10:57 2006 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sun, 28 May 2006 00:10:57 -0600 Subject: A sole, standard proxy library for Fedora In-Reply-To: <16de708d0605271945i50d9101ag338c651d5e796d5c@mail.gmail.com> References: <447736D6.20204@redfish-solutions.com> <1148664862.2472.7.camel@dhollis-lnx.sunera.com> <16de708d0605261607n7652201j32a638bfb8ed4811@mail.gmail.com> <16de708d0605271945i50d9101ag338c651d5e796d5c@mail.gmail.com> Message-ID: <44793EF1.7000803@redfish-solutions.com> Arthur Pemberton wrote: >On 5/27/06, Aurelien Bompard wrote: > > >> How about having a file in /etc/profile.d, say proxy.sh and proxy.csh >> (yeah, >> >>that's two, well, you get the point) containing this: >># Set your proxy using the following variables: >># http_proxy=http://your.proxy.server:8080 >># ftp_proxy=http://your.proxy.server:8080 >># If you need authentication, use: >># http_proxy=http://username:password at your.proxy.server:8080 >> >>At least that would save the Googling (and it's easy to do). >> >>Then, we could make a system-config-proxy which would set this file, and set >>the proxy in GNOME, KDE and firefox while it's at it. >>Or we could fix the GNOME setting app and Kcontrol to setup environment >>variables in /etc/profile.d/proxy.{sh,csh}. I'm not sure upstream would >>accept setting the proxy in Firefox too though, so we might need a >>system-config-proxy in the end. >> >>Yes, this is suboptimal compared to using a single libproxy.so to rule them >>all, but will big cross-platform apps like firefox support it ? >> >> >>Aur?lien >>-- >>http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr >>The only "intuitive" interface is the nipple. After that it's all learned. >> >> >> > >I have tried the above approach manually. It works better on paper >than in practice. Especially considering the numerous other >applications that require similiar configurations. But that is one >solution. > > > Well, you're missing a few crucial things... Other than the fact that existing applications (and even X or login sessions) have to be restarted to accommodate this... It also doesn't allow you to layer any sort of policy onto the proxy selection on a per-connection basis. I might have rules that say, "If it's to any of these subnets, or to internal Intranet servers, then don't go through our proxies... everything else goes through the proxy." You can't do that with the environment variable hack. It doesn't even come close. The library, on the other hand, you can reconfigure without restarting applications or sessions, and you can make the proxy selection policy be arbitrarily complex. -Philip From sundaram at fedoraproject.org Sun May 28 08:35:38 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 28 May 2006 14:05:38 +0530 Subject: What's up with elfutils? In-Reply-To: <1148760146.2402.14.camel@entropy> References: <1148706929.2401.14.camel@entropy> <1148713391.4310.698.camel@sundaram.pnq.redhat.com> <1148715016.2401.15.camel@entropy> <1148722384.4310.714.camel@sundaram.pnq.redhat.com> <1148760146.2402.14.camel@entropy> Message-ID: <1148805338.4310.738.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 13:02 -0700, Nicholas Miell wrote: > On Sat, 2006-05-27 at 15:03 +0530, Rahul Sundaram wrote: > > On Sat, 2006-05-27 at 00:30 -0700, Nicholas Miell wrote: > > > On Sat, 2006-05-27 at 12:33 +0530, Rahul Sundaram wrote: > > > > On Fri, 2006-05-26 at 22:15 -0700, Nicholas Miell wrote: > > > > > A crazy license, no documentation, no web site, no mailing list, no CVS, > > > > > no real presence besides a RPM, a bugzilla component, and the occasional > > > > > mention on the SystemTap list. > > > > > > > > > > Why is this being used instead of the other (more sensibly licensed? I > > > > > can't tell, I have no idea what the elfutils license means.) libelfs and > > > > > libdwarfs that are available? > > > > > > > > > > > > > > And where does one go to get bugs fixed, because I don't think bugzilla > > > > > is it. (Although, I think this may be a bugzilla privileges issue.) > > > > > > > > > > -- > > > > > > > > You arent able to file bug reports against elfutils in > > > > http://bugzilla.redhat.com? > > > > > > Oh, I can, but I can't move them out of the MODIFIED state and none of > > > the default queries (i.e. My Bugs) include MODIFIED. > > > > What are you trying to do? Are you trying to query or change state of > > the reports? Which bugs? > > Well, I'd like to be able to just drop a line to the elfutils list > saying "Any progress on this bug?", but no such list exists, so I'm > reduced to bothering fedora-devel. If you want to ask an update on a reported bug, it is generally done within the bugzilla report as comments. > > Bug 187618, was submitted, partially fixed, and moved into the MODIFIED > state, which bugzilla describes as "Fix applied, please test" (or > something like that). I've tested it, discovered that that the fix was > incomplete, and now I can't move it back to NEW or ASSIGNED or whatever > and (afaict), nobody ever sees MODIFIED bugs in the normal course of > bugzilla usage. Looks like you got an answer from the developer now. The default queries in RH bugzilla doesnt list bugs with MODIFIED status but the relevant maintainers would be still keeping tracking of it. The larger point about having a project space setup and looking for alternatives still stands . Rahul From dtimms at bigpond.net.au Sun May 28 08:55:27 2006 From: dtimms at bigpond.net.au (David Timms) Date: Sun, 28 May 2006 18:55:27 +1000 Subject: Changing the layout of repodata to simplify making local yum repo. Message-ID: <4479657F.3090207@bigpond.net.au> I have searched the archives in relation to this but only found Jesse's: "Changing the way that Development lands", so if this has been done before kindly point me to some better google terms. What I would like to see changed is a common structure between online and CD/DVD layouts and the downloaded yum cache eg currently: online: {effectively the top level of the dvd iso} Fedora/ Fedora/RPMS repodata/ repodata/other.xml.gz repodata/filelists.xml.gz repodata/primary.xml.gz repodata/comps.xml yum cache: eg /var/cache/yum/core repomd.xml primary.xml.gz comps.xml {cachecookie} {primary.xml.gz.sqlite} headers/ packages/ {RPMS} Now, if the layouts were consistent: machine1: - yum.conf: keepcache=1 - yum update - ftp/http serv the yum cache folder. machine2: - set yum.repos.d/fedora-core.repo baseurl to machine1/core etc. - yum update would just work. No createrepo etc would be required. So if machine1 has a superset of packages required by all other internal machines, the fact that machine 1 is up2date means it becomes very easy and external bandwidth efficient to get the rest of machines up2date. This is a hindrance for updates repo, because it's repodata is stored within the /repodata on the repo server: {all the RPMS at this level} repodata/ repodata/other.xml.gz repodata/filelists.xml.gz repodata/primary.xml.gz repodata/comps.xml So if you point fedora-updates.repo @ another machines cache/yum/updates, it wont find repodata/repomd.xml This can be worked around by creating appropriate sym linking; it could however just work with some tweaking to the structure. Also, while you can point fedora-core.repo at another machine with a mounted dvd iso, the structure yum creates on disk differs from the dvd. This structure is then not immediately sharable to further machines. core dvd primary.xml: ... ... ----- It would seem that a preferred layout could be created- eg {i386/} repodata/ packages/ headers/ This could be advantageous in other ways eg: 1. the repodata folder is not inside the packages/RPMS dir, hence machines trying to ftp repodata/* wont need to cause a complete folder contents traversal of say thousands of rpms. 2. rsync or other mirroring of the structure could be done, and the result is immediately usable by yum. 3. mock building easier since a local {partial} mirror easier to setup (just copy the downloads that mock does first time, ht/f tp serve it, config mock-yum to retrieve from above. and keep it up2date with what further mock runs retrieve). Disadvantages: 1. other repos would need to catch up for the yum changes. 2. Is it of limited usefulness ? I can see that at least various bits would need to change: 1. yum to store it's cached repodata in a folder one level down called repodata, ie changes to yum itself 2. layout of each repo changed and rebuild the filelist.xml to suit 3. mirroring {as Jesse worked out for the other layout changes} needs some tricks. What problems/etc can people see with this proposal ? Is changing yum in this way a bad idea ? DaveT. From sundaram at fedoraproject.org Sun May 28 09:08:12 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 28 May 2006 14:38:12 +0530 Subject: What's up with elfutils? In-Reply-To: <44786A65.40206@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> Message-ID: <1148807292.4310.758.camel@sundaram.pnq.redhat.com> On Sat, 2006-05-27 at 08:04 -0700, John Reiser wrote: > Robert Scheck wrote: > > Hello Nicholas, > > > > On Fr, 26 Mai 2006, Nicholas Miell wrote: > > > >>A crazy license, no documentation, no web site, no mailing list, no CVS, > >>no real presence besides a RPM, a bugzilla component, and the occasional > >>mention on the SystemTap list. > > > > > > did you ever have a look to elfutils-0.120/{AUTHORS,THANKS}? Red Hat is > > upstream for elfutils and developed by Ulrich Drepper and Roland McGrath. > > Both are also glibc developers or even maintainers (see /lib/libc.so.6). > > [snip] > > >>And where does one go to get bugs fixed, because I don't think bugzilla > >>is it. (Although, I think this may be a bugzilla privileges issue.) > > > > > > Whenever Red Hat is upstream, Bugzilla is the used bugtracking tool. Sorry, > > that I'm not really able to get your problem... > > Nicholas's observation about the status of elfutils, and Robert's reply, > can be explained even more simply: elfutils is _not_ a Fedora project! > elfutils is a Red Hat project, and so far Red Hat has not ceded control > of elfutils to anyone, especially including the Fedora community. > Also, so far Fedora has avoided calling attention to issues such as > the ones raised by Nicholas. If you think there is any issues that needs to be discussed as part of Fedora development feel free to do so especially if you are willing to contribute towards resolving any such problems. > > On the other hand, there is substantial overlap between elfutils > (eu-addr2line, eu-elflint, eu-findtextrel, eu-nm, eu-readelf, eu-size, > eu-strip, etc.) and binutils (addr2line, nm, readelf, size, strip, > objdump, etc.) so perhaps Fedora should drop elfutils entirely. > > -- > Rahul From j.w.r.degoede at hhs.nl Sun May 28 09:52:38 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 28 May 2006 11:52:38 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: <44787D30.6020808@mesias.co.uk> References: <447736D6.20204@redfish-solutions.com> <44787D30.6020808@mesias.co.uk> Message-ID: <447972E6.2030606@hhs.nl> Cam wrote: > Philip > >> I have a laptop that travels with me from work (where there's the >> use of web proxies) to home (where I don't), and was overwhelmed >> by the number of config files that I have to switch over every time >> I move from one place to the other. > > How about having a lightweight proxy on every machine. All configuration > should point to the local proxy. > > When the network changes, only the proxy need be informed of the changes. > > It's a horrible hack, I know :) but configuration in the environment > isn't dynamic enough, and hell will freeze over before any new > configuration scheme reaches the level of acceptance that http_proxy in > env has. > > -Cam > > Yes, I've been following this thread and was thinking the same, that sounds like a sane & good solution. (Notice that I have no use for such a setup myself and I've got 0 experience in using proxies, so this is just IMHO). Regards, Hans From splinux at fedoraproject.org Sun May 28 10:02:16 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 28 May 2006 12:02:16 +0200 Subject: Just a word about YumApplet Message-ID: Hi all, I would like to ask the release date or complementary information about yumapplet. Development is active or this project is abandoned ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sun May 28 10:16:17 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 28 May 2006 15:46:17 +0530 Subject: Just a word about YumApplet In-Reply-To: References: Message-ID: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> On Sun, 2006-05-28 at 12:02 +0200, Damien Durand wrote: > Hi all, > > I would like to ask the release date or complementary information > about yumapplet. Development is active or this project is abandoned ? > > -- No development hasnt been done beyond writing down the specification afaik. http://fedoraproject.org/wiki/YumApplet Rahul From pemboa at gmail.com Sun May 28 10:37:55 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 28 May 2006 05:37:55 -0500 Subject: A sole, standard proxy library for Fedora In-Reply-To: <44787D30.6020808@mesias.co.uk> References: <447736D6.20204@redfish-solutions.com> <44787D30.6020808@mesias.co.uk> Message-ID: <16de708d0605280337q311c9e03t39dd5d97df5337f5@mail.gmail.com> On 5/27/06, Cam wrote: > Philip > > > I have a laptop that travels with me from work (where there's the > > use of web proxies) to home (where I don't), and was overwhelmed > > by the number of config files that I have to switch over every time > > I move from one place to the other. > > How about having a lightweight proxy on every machine. All configuration > should point to the local proxy. > > When the network changes, only the proxy need be informed of the changes. > > It's a horrible hack, I know :) but configuration in the environment > isn't dynamic enough, and hell will freeze over before any new > configuration scheme reaches the level of acceptance that http_proxy in > env has. > > -Cam > > I think that is a bit over kill. Quite possible, an iptables approach to make things more transperent, along with system wide applying of proxy configs (maybe a plugin system so diff. apps can let the configuring app know where to find them) might be easier to do. -- To be updated... From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun May 28 10:52:06 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 28 May 2006 12:52:06 +0200 Subject: additional build failures with reduced buildgroup list In-Reply-To: <20060527210448.GA32644@lists.us.dell.com> References: <20060527130927.GA27900@lists.us.dell.com> <1148749969.7067.7.camel@ender> <20060527215057.1f7f69d5@python2> <20060527210448.GA32644@lists.us.dell.com> Message-ID: <20060528125206.6ff23693@python2> Matt Domsch wrote : > On Sat, May 27, 2006 at 09:50:57PM +0200, Matthias Saou wrote: > > I think the next step will be to do a mass rebuild of all Rawhide > > packages in minimal mock roots and compare what they provide and > > require with the Rawhide packages of the same version built with > > Beehive. > > That's exactly what I've done. ;-) > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/ D'oh! :-D Great work by the way, exactly what Core needed sooner or later ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2218_FC6 Load : 0.63 0.44 0.58 From camilo at mesias.co.uk Sun May 28 10:55:39 2006 From: camilo at mesias.co.uk (Cam) Date: Sun, 28 May 2006 11:55:39 +0100 Subject: A sole, standard proxy library for Fedora In-Reply-To: <16de708d0605280337q311c9e03t39dd5d97df5337f5@mail.gmail.com> References: <447736D6.20204@redfish-solutions.com> <44787D30.6020808@mesias.co.uk> <16de708d0605280337q311c9e03t39dd5d97df5337f5@mail.gmail.com> Message-ID: <447981AB.30101@mesias.co.uk> Arthur > I think that is a bit over kill. Quite possible, an iptables approach > to make things more transperent, along with system wide applying of > proxy configs (maybe a plugin system so diff. apps can let the > configuring app know where to find them) might be easier to do. I don't see how that would be easier - it would certainly be more work. What I describe could be achieved with configuration of existing software. I use a variation of the above (with an ssh tunnel) to retrieve mail from several different networks, without having to reconfigure the mailer app. -Cam -- <-- camilo at mesias.co.uk From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sun May 28 10:57:16 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sun, 28 May 2006 12:57:16 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: <44787D30.6020808@mesias.co.uk> References: <447736D6.20204@redfish-solutions.com> <44787D30.6020808@mesias.co.uk> Message-ID: <20060528125716.1c7bef71@python2> Cam wrote : > How about having a lightweight proxy on every machine. All configuration > should point to the local proxy. > > When the network changes, only the proxy need be informed of the changes. > > It's a horrible hack, I know :) but configuration in the environment > isn't dynamic enough, and hell will freeze over before any new > configuration scheme reaches the level of acceptance that http_proxy in > env has. This is exactly what NetworkManager does with a bind instance since running applications wouldn't pick up DNS changes fast enough when switching networks on the fly. So although it does sound hackish... it's basically already been done in order to overcome the same kind of limitation. Did I just hear someone suggest integrating this in NetworkManager along with an automatic proxy detection feature? Hmmm... :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2218_FC6 Load : 0.39 0.46 0.55 From skvidal at linux.duke.edu Sun May 28 11:44:20 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 07:44:20 -0400 Subject: Just a word about YumApplet In-Reply-To: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> Message-ID: <1148816660.28729.5.camel@cutter> On Sun, 2006-05-28 at 15:46 +0530, Rahul Sundaram wrote: > On Sun, 2006-05-28 at 12:02 +0200, Damien Durand wrote: > > Hi all, > > > > I would like to ask the release date or complementary information > > about yumapplet. Development is active or this project is abandoned ? > > > > -- > > No development hasnt been done beyond writing down the specification > afaik. > > http://fedoraproject.org/wiki/YumApplet > Incorrect. 1. yum-updatesd has been written and it's more or less complete at this point 2. jeremy has been working on the applet over the last couple of weeks. so a lot of is going on w/it. -sv From splinux at fedoraproject.org Sun May 28 11:50:49 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 28 May 2006 13:50:49 +0200 Subject: Just a word about YumApplet In-Reply-To: <1148816660.28729.5.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> Message-ID: It's possible to look the sources of this application? I'm intersted to contribute, I need to know the list of thing to be made. 2006/5/28, seth vidal : > > On Sun, 2006-05-28 at 15:46 +0530, Rahul Sundaram wrote: > > On Sun, 2006-05-28 at 12:02 +0200, Damien Durand wrote: > > > Hi all, > > > > > > I would like to ask the release date or complementary information > > > about yumapplet. Development is active or this project is abandoned ? > > > > > > -- > > > > No development hasnt been done beyond writing down the specification > > afaik. > > > > http://fedoraproject.org/wiki/YumApplet > > > > Incorrect. > > 1. yum-updatesd has been written and it's more or less complete at this > point > 2. jeremy has been working on the applet over the last couple of weeks. > > so a lot of is going on w/it. > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Sun May 28 11:56:11 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 07:56:11 -0400 Subject: Just a word about YumApplet In-Reply-To: References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> Message-ID: <1148817372.28729.7.camel@cutter> On Sun, 2006-05-28 at 13:50 +0200, Damien Durand wrote: > It's possible to look the sources of this application? I'm intersted > to contribute, I need to know the list of thing to be made. the backend daemon is checked into yum cvs: http://devel.linux.duke.edu/cgi-bin/viewvc.cgi/yum/yum-updatesd.py?view=log the frontend applet is in fedora cvs, I think, but I've not seen it yet. Jeremy, where is it? -sv From splinux at fedoraproject.org Sun May 28 11:58:10 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 28 May 2006 13:58:10 +0200 Subject: Just a word about YumApplet In-Reply-To: <1148817372.28729.7.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> Message-ID: Ok thanks, If i can contribute, what can i do first? A small thing to start. And 2006/5/28, seth vidal : > > On Sun, 2006-05-28 at 13:50 +0200, Damien Durand wrote: > > It's possible to look the sources of this application? I'm intersted > > to contribute, I need to know the list of thing to be made. > > the backend daemon is checked into yum cvs: > > http://devel.linux.duke.edu/cgi-bin/viewvc.cgi/yum/yum-updatesd.py?view=log > > the frontend applet is in fedora cvs, I think, but I've not seen it yet. > Jeremy, where is it? > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sun May 28 11:58:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 28 May 2006 17:28:44 +0530 Subject: Just a word about YumApplet In-Reply-To: <1148816660.28729.5.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> Message-ID: <1148817525.4310.767.camel@sundaram.pnq.redhat.com> On Sun, 2006-05-28 at 07:44 -0400, seth vidal wrote: > On Sun, 2006-05-28 at 15:46 +0530, Rahul Sundaram wrote: > > On Sun, 2006-05-28 at 12:02 +0200, Damien Durand wrote: > > > Hi all, > > > > > > I would like to ask the release date or complementary information > > > about yumapplet. Development is active or this project is abandoned ? > > > > > > -- > > > > No development hasnt been done beyond writing down the specification > > afaik. > > > > http://fedoraproject.org/wiki/YumApplet > > > > Incorrect. > > 1. yum-updatesd has been written and it's more or less complete at this > point > 2. jeremy has been working on the applet over the last couple of weeks. > > so a lot of is going on w/it. Would be nice to have a way to keep track of these developments. Maybe a announcement to fedora-maintainers list and here when you guys start working on major projects? Rahul From splinux at fedoraproject.org Sun May 28 11:59:25 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 28 May 2006 13:59:25 +0200 Subject: Just a word about YumApplet In-Reply-To: References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> Message-ID: And about pirut/pup? 2006/5/28, Damien Durand : > > Ok thanks, If i can contribute, what can i do first? A small thing to > start. And > > 2006/5/28, seth vidal : > > > On Sun, 2006-05-28 at 13:50 +0200, Damien Durand wrote: > > > It's possible to look the sources of this application? I'm intersted > > > to contribute, I need to know the list of thing to be made. > > > > the backend daemon is checked into yum cvs: > > http://devel.linux.duke.edu/cgi-bin/viewvc.cgi/yum/yum-updatesd.py?view=log > > > > > > the frontend applet is in fedora cvs, I think, but I've not seen it yet. > > Jeremy, where is it? > > > > -sv > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Sun May 28 12:04:14 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 08:04:14 -0400 Subject: Just a word about YumApplet In-Reply-To: References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> Message-ID: <1148817854.28729.16.camel@cutter> On Sun, 2006-05-28 at 13:58 +0200, Damien Durand wrote: > Ok thanks, If i can contribute, what can i do first? A small thing to > start. And for the applet front-end, I'm not sure. If you want to test the backend script, please do so and file bugs you see. I know Jeremy was interested in threading the backend daemon so it could be downloading the packages you need for an update while also responding to dbus calls from the applet. thanks, -sv From skvidal at linux.duke.edu Sun May 28 12:06:29 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 08:06:29 -0400 Subject: Just a word about YumApplet In-Reply-To: <1148817525.4310.767.camel@sundaram.pnq.redhat.com> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817525.4310.767.camel@sundaram.pnq.redhat.com> Message-ID: <1148817990.28729.19.camel@cutter> On Sun, 2006-05-28 at 17:28 +0530, Rahul Sundaram wrote: > On Sun, 2006-05-28 at 07:44 -0400, seth vidal wrote: > > On Sun, 2006-05-28 at 15:46 +0530, Rahul Sundaram wrote: > > > On Sun, 2006-05-28 at 12:02 +0200, Damien Durand wrote: > > > > Hi all, > > > > > > > > I would like to ask the release date or complementary information > > > > about yumapplet. Development is active or this project is abandoned ? > > > > > > > > -- > > > > > > No development hasnt been done beyond writing down the specification > > > afaik. > > > > > > http://fedoraproject.org/wiki/YumApplet > > > > > > > Incorrect. > > > > 1. yum-updatesd has been written and it's more or less complete at this > > point > > 2. jeremy has been working on the applet over the last couple of weeks. > > > > so a lot of is going on w/it. > > Would be nice to have a way to keep track of these developments. Maybe a > announcement to fedora-maintainers list and here when you guys start > working on major projects? I checked it into yum-cvs and talked about it on yum-devel, briefly. It's not a fedora-only project so I didn't feel compelled to tell anyone other than yum-devel. also I wouldn't consider this a major project, it's just not that much code, thus far. -sv From skvidal at linux.duke.edu Sun May 28 12:07:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 08:07:36 -0400 Subject: Just a word about YumApplet In-Reply-To: References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> Message-ID: <1148818056.28729.22.camel@cutter> On Sun, 2006-05-28 at 13:59 +0200, Damien Durand wrote: > And about pirut/pup? > afaik the idea is for the yumapplet/puplet to just tell you when there are updates by getting a dbus event from the backend daemon then when you click on the puplet's notice it will let you open pup to apply the updates. -sv From splinux at fedoraproject.org Sun May 28 12:08:00 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 28 May 2006 14:08:00 +0200 Subject: Just a word about YumApplet In-Reply-To: <1148818056.28729.22.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> <1148818056.28729.22.camel@cutter> Message-ID: Ok Thanks, it will be nice to write a todo list on fedoraproject wiki and to update this one all the time. 2006/5/28, seth vidal : > > On Sun, 2006-05-28 at 13:59 +0200, Damien Durand wrote: > > And about pirut/pup? > > > > > afaik the idea is for the yumapplet/puplet to just tell you when there > are updates by getting a dbus event from the backend daemon then when > you click on the puplet's notice it will let you open pup to apply the > updates. > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Sun May 28 12:16:00 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 08:16:00 -0400 Subject: Just a word about YumApplet In-Reply-To: References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> <1148818056.28729.22.camel@cutter> Message-ID: <1148818560.28729.27.camel@cutter> On Sun, 2006-05-28 at 14:08 +0200, Damien Durand wrote: > Ok Thanks, it will be nice to write a todo list on fedoraproject wiki > and to update this one all the time. Take a look at the existing code that's out there. Look for bugs and problems and send in patches, please. -sv From splinux at fedoraproject.org Sun May 28 12:18:52 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sun, 28 May 2006 14:18:52 +0200 Subject: Just a word about YumApplet In-Reply-To: <1148818560.28729.27.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> <1148818056.28729.22.camel@cutter> <1148818560.28729.27.camel@cutter> Message-ID: No problem, I will do it. It's the best thing for started, thank you Seth 2006/5/28, seth vidal : > > On Sun, 2006-05-28 at 14:08 +0200, Damien Durand wrote: > > Ok Thanks, it will be nice to write a todo list on fedoraproject wiki > > and to update this one all the time. > > Take a look at the existing code that's out there. Look for bugs and > problems and send in patches, please. > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Sun May 28 12:55:47 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 28 May 2006 18:25:47 +0530 Subject: Just a word about YumApplet In-Reply-To: <1148817990.28729.19.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817525.4310.767.camel@sundaram.pnq.redhat.com> <1148817990.28729.19.camel@cutter> Message-ID: <1148820947.4310.774.camel@sundaram.pnq.redhat.com> On Sun, 2006-05-28 at 08:06 -0400, seth vidal wrote: > On Sun, 2006-05-28 at 17:28 +0530, Rahul Sundaram wrote: > > On Sun, 2006-05-28 at 07:44 -0400, seth vidal wrote: > > > On Sun, 2006-05-28 at 15:46 +0530, Rahul Sundaram wrote: > > > > On Sun, 2006-05-28 at 12:02 +0200, Damien Durand wrote: > > > > > Hi all, > > > > > > > > > > I would like to ask the release date or complementary information > > > > > about yumapplet. Development is active or this project is abandoned ? > > > > > > > > > > -- > > > > > > > > No development hasnt been done beyond writing down the specification > > > > afaik. > > > > > > > > http://fedoraproject.org/wiki/YumApplet > > > > > > > > > > Incorrect. > > > > > > 1. yum-updatesd has been written and it's more or less complete at this > > > point > > > 2. jeremy has been working on the applet over the last couple of weeks. > > > > > > so a lot of is going on w/it. > > > > Would be nice to have a way to keep track of these developments. Maybe a > > announcement to fedora-maintainers list and here when you guys start > > working on major projects? > > I checked it into yum-cvs and talked about it on yum-devel, briefly. > It's not a fedora-only project so I didn't feel compelled to tell anyone > other than yum-devel. > > also I wouldn't consider this a major project, it's just not that much > code, thus far. It might not much have much code but it is project that has a user visible component that provides a important functionality. If announcements about such development is made it helps in more than one way The community can understand what work is being done and get involved Documentation team can document these changes in the release notes and other documents Ambassadors can talk about it etc. Rahul From skvidal at linux.duke.edu Sun May 28 13:35:38 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 28 May 2006 09:35:38 -0400 Subject: Just a word about YumApplet In-Reply-To: <1148820947.4310.774.camel@sundaram.pnq.redhat.com> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817525.4310.767.camel@sundaram.pnq.redhat.com> <1148817990.28729.19.camel@cutter> <1148820947.4310.774.camel@sundaram.pnq.redhat.com> Message-ID: <1148823338.28729.29.camel@cutter> On Sun, 2006-05-28 at 18:25 +0530, Rahul Sundaram wrote: > It might not much have much code but it is project that has a user > visible component that provides a important functionality. If > announcements about such development is made it helps in more than one > way > > The community can understand what work is being done and get involved > Documentation team can document these changes in the release notes and > other documents > Ambassadors can talk about it etc. it's 288 lines of code right now. If I took the time to write an email about each thing we've started on I'd never have the time to actually start anything. no one else was going to do it from what I could tell, despite the spec being on the wiki for quite sometime. -sv From stickster at gmail.com Sun May 28 14:17:11 2006 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 28 May 2006 10:17:11 -0400 Subject: Just a word about YumApplet In-Reply-To: <1148823338.28729.29.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817525.4310.767.camel@sundaram.pnq.redhat.com> <1148817990.28729.19.camel@cutter> <1148820947.4310.774.camel@sundaram.pnq.redhat.com> <1148823338.28729.29.camel@cutter> Message-ID: <1148825831.8197.6.camel@localhost.localdomain> On Sun, 2006-05-28 at 09:35 -0400, seth vidal wrote: > On Sun, 2006-05-28 at 18:25 +0530, Rahul Sundaram wrote: > > > It might not much have much code but it is project that has a user > > visible component that provides a important functionality. If > > announcements about such development is made it helps in more than one > > way > > > > The community can understand what work is being done and get involved > > Documentation team can document these changes in the release notes and > > other documents > > Ambassadors can talk about it etc. > > it's 288 lines of code right now. > > If I took the time to write an email about each thing we've started on > I'd never have the time to actually start anything. > > no one else was going to do it from what I could tell, despite the spec > being on the wiki for quite sometime. Jeremy posted about the "puplet" in his blog, carried on the Fedora People planet feed last week: http://katzj.livejournal.com/388499.html This has a lot of community visibility in itself, but Rahul is right that more publicity is a Good Thing. However, in the time it took to carry on this back-and-forth, anyone could have sent the link to Thomas Chung at Fedora News so he can publicize it in the next issue, and changed the wiki page. (I've taken care of that.) Let's try not to badger folks who are getting work done, and instead spend our time more constructively. Thomas, if you could point this out in the next FedoraNews issue, it would be greatly appreciated, thanks! -- 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 buildsys at redhat.com Sun May 28 14:23:36 2006 From: buildsys at redhat.com (Build System) Date: Sun, 28 May 2006 10:23:36 -0400 Subject: rawhide report: 20060528 changes Message-ID: <200605281423.k4SENagX008469@porkchop.devel.redhat.com> Removed package openCryptoki Removed package s390utils Updated Packages: autofs-1:5.0.0_beta3-4 ---------------------- * Sat May 27 2006 Ian Kent - 5.0.0_beta3-4 - updated hesiod patch. * Sat May 27 2006 Ian Kent - 5.0.0_beta3-3 - update hesiod module (Jeff Moyer). - add mutex to protect against overlapping mount requests. - update return from mount request to give more sensible NSS_* values. gdb-6.3.0.0-1.130.FC6 --------------------- * Sat May 27 2006 Alexandre Oliva - 6.3.0.0-1.130 - Rewrite patch for BZ 175270, BZ 175083 so as to catch the exception earlier. - Remove too-fragile testcases from patches for CFA value and "S" augmentation. * Wed May 17 2006 Alexandre Oliva - 6.3.0.0-1.129 - Add not-automatically-generated file to fopen64 patch (BZ 191948). * Fri Apr 14 2006 Alexandre Oliva - 6.3.0.0-1.128 - Avoid race conditions caused by exceptions messing with signal masks. (BZ 175270, BZ 175083, maybe BZ 172938). - Hardcode /bin and /usr/bin paths into gstack (BZ 179829, BZ 190548). - Build in a subdir of the source tree instead of in a sibling directory. - Switch to versioning scheme that uses the same base revision number for all OSes, and uses a suffix to tell the builds apart and ensure upgradability. grub-0.97-6 ----------- * Sat May 27 2006 Peter Jones - 0.97-6 - Fix mactel keyboard problems, patch from Juergen Keil, forwarded by Linus. kernel-2.6.16-1.2224_FC6 ------------------------ * Sat May 27 2006 Dave Jones - 2.6.17rc5-git2 selinux-policy-2.2.43-2 ----------------------- * Sat May 27 2006 Dan Walsh 2.2.43-2 - Update to upstream * Fri May 26 2006 Dan Walsh 2.2.43-1 - Update to upstream * Fri May 26 2006 Dan Walsh 2.2.42-4 - fixes for spamd Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires libstdc++-devel = 0:4.1.0 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires libstdc++-devel = 0:4.1.0 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for ppc ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires libstdc++-devel = 0:4.1.0 Broken deps for ia64 ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires libstdc++-devel = 0:4.1.0 rgmanager - 1.9.31-3.ia64 requires ccs From jreiser at BitWagon.com Sun May 28 16:35:25 2006 From: jreiser at BitWagon.com (John Reiser) Date: Sun, 28 May 2006 09:35:25 -0700 Subject: What's up with elfutils? In-Reply-To: <1148807292.4310.758.camel@sundaram.pnq.redhat.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> Message-ID: <4479D14D.7050401@BitWagon.com> Rahul Sundaram wrote: > If you think there is any issues that needs to be discussed as part of > Fedora development feel free to do so especially if you are willing to > contribute towards resolving any such problems. Remove elfutils from Fedora Core. -- From katzj at redhat.com Sun May 28 16:54:52 2006 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 28 May 2006 12:54:52 -0400 Subject: What's up with elfutils? In-Reply-To: <4479D14D.7050401@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> Message-ID: <1148835292.18751.3.camel@aglarond.local> On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote: > Rahul Sundaram wrote: > > If you think there is any issues that needs to be discussed as part of > > Fedora development feel free to do so especially if you are willing to > > contribute towards resolving any such problems. > > Remove elfutils from Fedora Core. So, you're saying that anything which isn't controlled by Fedora shouldn't be shipped in Fedora Core? I guess we might as well stop trying to ship anything then as we don't have direct control over *most* of what is shipped. Note that elfutils is directly required by a number of packages within Fedora Core and thus can't just be removed Jeremy From alex at tvtransilvania.ro Sun May 28 18:05:05 2006 From: alex at tvtransilvania.ro (Alexandru Ciobanu) Date: Sun, 28 May 2006 21:05:05 +0300 (EEST) Subject: CVS system migration done In-Reply-To: References: <442873EC.1050702@GreenKey.net> Message-ID: <56147.81.180.204.180.1148839505.squirrel@www.tvtransilvania.ro> >> Elliot Lee wrote: > Hi all, > > cvs.fedoraproject.org (aka cvs.fedora.redhat.com) has been migrated to > a > new system. Please let me know if there are any problems that need > fixing... Bonsai can't locate treeconfig.pl. http://cvs.fedora.redhat.com/bonsai/toplevel.cgi?treeid=extras Regards, Alex From jreiser at BitWagon.com Sun May 28 18:46:45 2006 From: jreiser at BitWagon.com (John Reiser) Date: Sun, 28 May 2006 11:46:45 -0700 Subject: What's up with elfutils? In-Reply-To: <1148835292.18751.3.camel@aglarond.local> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> Message-ID: <4479F015.2070805@BitWagon.com> Jeremy Katz wrote: > On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote: > >>Rahul Sundaram wrote: >> >>>If you think there is any issues that needs to be discussed as part of >>>Fedora development feel free to do so especially if you are willing to >>>contribute towards resolving any such problems. >> >>Remove elfutils from Fedora Core. > > > So, you're saying that anything which isn't controlled by Fedora > shouldn't be shipped in Fedora Core? > > I guess we might as well stop trying to ship anything then as we don't > have direct control over *most* of what is shipped. Most of those projects have maintainers who respond in a somewhat timely fashion, and/or a public source tree (CVS, svn, etc.), and/or other forms of not-just-Red Hat participation. Certainly most Fedora projects have "upstream." That's fine. What is not fine is a project that just sits there like a bump on a log despite open Bugzilla issues and demonstrated interest from "downstream" Fedora. > Note that elfutils is directly required by a number of packages within > Fedora Core and thus can't just be removed According to "rpm -qR elfutils" they are [excluding self references]: libc.so.6 libdl.so.2 /sbin/ldconfig which are all part of glibc. So elfutils can be flushed just by merging it into glibc. Everybody else uses binutils. Not many developers have ever used the "eu-" versions of nm, strip, size, readelf, addr2line. -- From fedora at camperquake.de Sun May 28 19:04:01 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 28 May 2006 21:04:01 +0200 Subject: What's up with elfutils? In-Reply-To: <4479F015.2070805@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> Message-ID: <20060528210401.3cfb96fc@nausicaa.camperquake.de> Hi. John Reiser wrote: > merging it into glibc. Everybody else uses binutils. Not many > developers have ever used the "eu-" versions of nm, strip, size, > readelf, addr2line. What exactly does elfutils do that binutils doesn't, anyway? -- My grandmother started to walk five miles a day when she was 60 Now she's 95 and we don't know where the hell she is -- Ellen de Generes From nmiell at comcast.net Sun May 28 19:20:58 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sun, 28 May 2006 12:20:58 -0700 Subject: What's up with elfutils? In-Reply-To: <4479F015.2070805@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> Message-ID: <1148844058.2412.3.camel@entropy> On Sun, 2006-05-28 at 11:46 -0700, John Reiser wrote: > Jeremy Katz wrote: > > On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote: > > > >>Rahul Sundaram wrote: > >> > >>>If you think there is any issues that needs to be discussed as part of > >>>Fedora development feel free to do so especially if you are willing to > >>>contribute towards resolving any such problems. > >> > >>Remove elfutils from Fedora Core. > > I just want to jump in here and note that I'm not advocating this. > > So, you're saying that anything which isn't controlled by Fedora > > shouldn't be shipped in Fedora Core? > > > > I guess we might as well stop trying to ship anything then as we don't > > have direct control over *most* of what is shipped. > > Most of those projects have maintainers who respond in a somewhat timely > fashion, and/or a public source tree (CVS, svn, etc.), and/or other > forms of not-just-Red Hat participation. Certainly most Fedora projects > have "upstream." That's fine. What is not fine is a project that just > sits there like a bump on a log despite open Bugzilla issues and > demonstrated interest from "downstream" Fedora. > > > Note that elfutils is directly required by a number of packages within > > Fedora Core and thus can't just be removed > > According to "rpm -qR elfutils" they are [excluding self references]: > libc.so.6 > libdl.so.2 > /sbin/ldconfig > which are all part of glibc. So elfutils can be flushed just by > merging it into glibc. Everybody else uses binutils. Not many > developers have ever used the "eu-" versions of nm, strip, size, > readelf, addr2line. ITYM: [root at entropy ~]# repoquery --whatrequires --alldeps --resolve "elfutils*" | sort -u | grep -v "^elfutils" ddd-0:3.3.11-5.2.x86_64 ltrace-0:0.3.36-4.2.i386 ltrace-0:0.3.36-4.2.x86_64 net-snmp-devel-0:5.3-4.2.x86_64 prelink-0:0.3.6-3.x86_64 rpm-0:4.4.2-15.2.x86_64 rpm-build-0:4.4.2-15.2.x86_64 rpm-devel-0:4.4.2-15.2.x86_64 rpm-libs-0:4.4.2-15.2.x86_64 rpm-python-0:4.4.2-15.2.x86_64 systemtap-0:0.5.4-2.2.x86_64 And, having looked at binutils compared to elfutils and the other libelfs out there, I'd much rather use libelf than libbfd. -- Nicholas Miell From kloczek at zie.pg.gda.pl Sun May 28 19:29:06 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Sun, 28 May 2006 21:29:06 +0200 Subject: What's up with elfutils? In-Reply-To: <20060528210401.3cfb96fc@nausicaa.camperquake.de> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <20060528210401.3cfb96fc@nausicaa.camperquake.de> Message-ID: <1148844546.2503.3.camel@kloczek01.pracownicy.zie> Dnia 28-05-2006, nie o godzinie 21:04 +0200, Ralf Ertzinger napisa?(a): > Hi. > > John Reiser wrote: > > > merging it into glibc. Everybody else uses binutils. Not many > > developers have ever used the "eu-" versions of nm, strip, size, > > readelf, addr2line. > > What exactly does elfutils do that binutils doesn't, anyway? Now ? nothing. Current binutils strip can handle output stipped data to separated file. Currently eu-strip is used only in /usr/lib/rpm/find-debuginfo.sh script and s/eu-strip/strip/ will allow drop elfutils. kloczek From Matt_Domsch at dell.com Sun May 28 20:16:52 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 28 May 2006 15:16:52 -0500 Subject: FE BuildReq blocker #193444 opened Message-ID: <20060528201643.GA19932@lists.us.dell.com> Analogous to the BuildReq blocker bug for Core, I opened one for Extras. Bug 193444: Tracker bug for BuildRequires fixes for FE This lets my stats scripts for Core work when rebuilding Extras too, and lets us track the progress of fixing BuildRequires in Extras. Thanks, Matt -- 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 pjones at redhat.com Sun May 28 20:32:35 2006 From: pjones at redhat.com (Peter Jones) Date: Sun, 28 May 2006 16:32:35 -0400 Subject: What's up with elfutils? In-Reply-To: <4479F015.2070805@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> Message-ID: <1148848355.6261.3.camel@localhost.localdomain> On Sun, 2006-05-28 at 11:46 -0700, John Reiser wrote: > Jeremy Katz wrote: > > On Sun, 2006-05-28 at 09:35 -0700, John Reiser wrote: > > > >>Rahul Sundaram wrote: > >> > >>>If you think there is any issues that needs to be discussed as part of > >>>Fedora development feel free to do so especially if you are willing to > >>>contribute towards resolving any such problems. > >> > >>Remove elfutils from Fedora Core. > > > > > > So, you're saying that anything which isn't controlled by Fedora > > shouldn't be shipped in Fedora Core? > > > > I guess we might as well stop trying to ship anything then as we don't > > have direct control over *most* of what is shipped. > > Most of those projects have maintainers who respond in a somewhat timely > fashion, and/or a public source tree (CVS, svn, etc.), and/or other > forms of not-just-Red Hat participation. Certainly most Fedora projects > have "upstream." That's fine. What is not fine is a project that just > sits there like a bump on a log despite open Bugzilla issues and > demonstrated interest from "downstream" Fedora. > > > Note that elfutils is directly required by a number of packages within > > Fedora Core and thus can't just be removed > > According to "rpm -qR elfutils" they are [excluding self references]: > libc.so.6 > libdl.so.2 > /sbin/ldconfig > which are all part of glibc. So elfutils can be flushed just by > merging it into glibc. Everybody else uses binutils. Not many > developers have ever used the "eu-" versions of nm, strip, size, > readelf, addr2line. I, for one, use eu-readelf and eu-nm very, very often. I suspect I'm not as alone as you assert. Also note that eu-strip is required to make debuginfo packages. -- Peter From kloczek at zie.pg.gda.pl Sun May 28 21:35:50 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Sun, 28 May 2006 23:35:50 +0200 Subject: What's up with elfutils? In-Reply-To: <1148848355.6261.3.camel@localhost.localdomain> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <1148848355.6261.3.camel@localhost.localdomain> Message-ID: <1148852150.2503.5.camel@kloczek01.pracownicy.zie> Dnia 28-05-2006, nie o godzinie 16:32 -0400, Peter Jones napisa?(a): [..] > Also note that eu-strip is required to make debuginfo packages. $ grep eu-strip /usr/lib/rpm/* -r /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" || : /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" || : kloczek From kloczek at zie.pg.gda.pl Sun May 28 21:39:51 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Sun, 28 May 2006 23:39:51 +0200 Subject: What's up with elfutils? In-Reply-To: <1148852150.2503.5.camel@kloczek01.pracownicy.zie> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <1148848355.6261.3.camel@localhost.localdomain> <1148852150.2503.5.camel@kloczek01.pracownicy.zie> Message-ID: <1148852391.2503.8.camel@kloczek01.pracownicy.zie> Dnia 28-05-2006, nie o godzinie 23:35 +0200, Tomasz K?oczko napisa?(a): > Dnia 28-05-2006, nie o godzinie 16:32 -0400, Peter Jones napisa?(a): > [..] > > Also note that eu-strip is required to make debuginfo packages. > > $ grep eu-strip /usr/lib/rpm/* -r > /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" > || : > /usr/lib/rpm/find-debuginfo.sh: eu-strip -f "${debugfn}" "$f" > || : Sorry my fault. binutils stip does not have -f option :> Is porting handle -f option to binutils strip will be so hard ? kloczek From Matt_Domsch at dell.com Sun May 28 22:02:52 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 28 May 2006 17:02:52 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-05-28 Message-ID: <20060528220252.GB19932@lists.us.dell.com> extras Rawhide-in-Mock Build Results for x86_64 Sun May 28 15:57:08 CDT 2006 Number failed to build: 190 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 179 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 179 ---------------------------------- alacarte amaya anjuta-gdl apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp Coin2 colorscheme contact-lookup-applet cowbell d4x ddskk dia dietlibc dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella gtkhtml36 Gtk-Perl gtktalog gtkwave gtk-xfce-engine gtorrentviewer gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libqalculate libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife Macaulay2 MagicPoint mail-notification mhonarc multisync mysql-administrator nautilus-actions nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc new OpenSceneGraph pam_mount paps perl-HTML-Mason perl-Image-Info perl-Log-Log4perl perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl pypoker-eval python-cheetah python-dateutil python-goopy python-reportlab python-TestGears qemu qof qtparted quarry R-gnomeGUI rpmDirectoryCheck sabayon scmxx scponly SDL_ttf ser serpentine sloccount splint stow stratagus supertux swh-plugins synaptic synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint uqm ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp yumex z88dk With bugs filed: 0 ---------------------------------- Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Sun May 28 22:03:27 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 28 May 2006 17:03:27 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-28 Message-ID: <20060528220327.GC19932@lists.us.dell.com> extras Rawhide-in-Mock Build Results for i386 Sun May 28 15:57:50 CDT 2006 Number failed to build: 179 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 178 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 178 ---------------------------------- abe alacarte amaya anjuta-gdl balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp clearsilver Coin2 colorscheme contact-lookup-applet cowbell csmash ddskk dia dillo diradmin directfb drgeo ebtables enigma epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge freedroid gambas gazpacho gcompris gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella gtkhtml36 Gtk-Perl gtktalog gtkwave gtk-xfce-engine gtorrentviewer gurlchecker gwget Hermes ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libqalculate libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd lincity-ng linkchecker lmarbles logjam lucidlife MagicPoint mail-notification mfstools multisync mysql-administrator naim nautilus-actions nautilus-open-terminal nautilus-search-tool nazghul ncmpc nco netpanzer NetworkManager-vpnc OpenSceneGraph paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl ppracer pygame pypoker-eval python-cheetah python-goopy python-TestGears qemu qof qtparted quarry R-gnomeGUI rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly SDL_net SDL_ttf ser serpentine sloccount splint stow stratagus supertux swh-plugins synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont torcs tuxpaint tuxtype2 ushare verbiste viruskiller WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp yumex With bugs filed: 0 ---------------------------------- Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Sun May 28 22:08:02 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 28 May 2006 17:08:02 -0500 Subject: Core i386 rawhide rebuild in mock status 2006-05-28 Message-ID: <20060528220802.GD19932@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libnl 191973 NEW xorg-x11-drv-acecad 191900 ASSIGNED xorg-x11-drv-voodoo 192042 ASSIGNED core Rawhide-in-Mock Build Results for i386 Sun May 28 15:56:13 CDT 2006 Number failed to build: 304 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 295 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 61 ---------------------------------- automake15 automake16 emacs libXres libXt libXtst libXv libXvMC libXxf86dga libXxf86misc libXxf86vm linux-atm lm_sensors longrun lrzsz lynx m17n-lib magma-plugins ncpfs openmotif pcmciautils pirut pkgconfig policycoreutils prelink pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm SDL sg3_utils specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans Xaw3d xmlsec1 xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 234 ---------------------------------- a2ps ['193345 CLOSED', '193346 NEW'] am-utils ['193347 NEW'] aqbanking ['193348 NEW'] arts ['192367 NEEDINFO'] atk ['193349 NEW'] at-spi ['192368 CLOSED'] authd ['193350 CLOSED'] autorun ['193351 NEW'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] busybox ['193354 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 NEW'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] fbset ['193362 NEW'] file-roller ['193363 NEW'] frysk ['192256 NEW'] f-spot ['193364 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] GFS-kernel ['192569 NEW'] gimp ['193368 NEW'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 NEW'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-keyring ['193377 NEW'] gnome-keyring-manager ['193378 NEW'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-user-share ['193391 NEW'] gnome-utils ['191757 CLOSED'] gnome-vfs2 ['193392 NEW'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gob2 ['193395 NEW'] gpart ['193396 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] hwbrowser ['193400 NEW'] indent ['193401 NEW'] inn ['193402 CLOSED'] iproute ['193403 CLOSED'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jpilot ['193405 NEW'] jsch ['191668 NEW'] kbd ['193406 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 NEW'] libgtop2 ['193418 NEW'] libIDL ['193419 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libSM ['193421 NEW'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Sun May 28 22:08:18 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 28 May 2006 17:08:18 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2006-05-28 Message-ID: <20060528220818.GE19932@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libnl 191973 NEW xorg-x11-drv-acecad 191900 ASSIGNED xorg-x11-drv-voodoo 192042 ASSIGNED core Rawhide-in-Mock Build Results for x86_64 Sun May 28 15:55:31 CDT 2006 Number failed to build: 318 Number expected to fail due to ExclusiveArch or ExcludeArch: 26 Leaving: 292 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 65 ---------------------------------- automake15 automake16 boost elilo emacs kdeaccessibility libmusicbrainz libXres libXt libXtst libXv libXvMC libXxf86dga libXxf86misc libXxf86vm linux-atm lm_sensors lrzsz lynx m17n-lib magma-plugins ncpfs openmotif pcmciautils perl pirut pkgconfig policycoreutils pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm SDL sgml-common specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans Xaw3d xmlsec1 xmlto xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 227 ---------------------------------- a2ps ['193345 CLOSED', '193346 NEW'] am-utils ['193347 NEW'] aqbanking ['193348 NEW'] arts ['192367 NEEDINFO'] atk ['193349 NEW'] at-spi ['192368 CLOSED'] authd ['193350 CLOSED'] autorun ['193351 NEW'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] busybox ['193354 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 NEW'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] fbset ['193362 NEW'] file-roller ['193363 NEW'] frysk ['192256 NEW'] f-spot ['193364 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] GFS-kernel ['192569 NEW'] gimp ['193368 NEW'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 NEW'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-keyring ['193377 NEW'] gnome-keyring-manager ['193378 NEW'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-user-share ['193391 NEW'] gnome-utils ['191757 CLOSED'] gnome-vfs2 ['193392 NEW'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gob2 ['193395 NEW'] grub ['192504 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] hwbrowser ['193400 NEW'] ImageMagick ['192036 NEW'] indent ['193401 NEW'] inn ['193402 CLOSED'] iproute ['193403 CLOSED'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jpilot ['193405 NEW'] jsch ['191668 NEW'] kbd ['193406 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 NEW'] libgtop2 ['193418 NEW'] libIDL ['193419 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libSM ['193421 NEW'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] qt ['191895 CLOSED'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 drepper at redhat.com Sun May 28 23:59:51 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 28 May 2006 16:59:51 -0700 Subject: What's up with elfutils? In-Reply-To: <4479F015.2070805@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> Message-ID: <447A3977.7030703@redhat.com> If you don't want elfutils, don't install it. Your choice. But don't make judgments for which you don't have the information: - there are no known problems in elfutils. At least none known to me and none in BZ (which aren't fixed). - the tools in elfutils compared with binutils are a) smaller, b) faster (several times, usually), c) less buggy, d) more featureful - there are several tools which are not available in binutils which are in (wide) use - there are several more tools which use the elfutils libraries (systemtap, frysk, ...) - there are more libraries part of elfutils which are not yet installed because they are not finished yet - almost everybody who has ever worked on binutils will attest what a horrible mess it is. it deserves nothing but to die since you cannot salvage the disaster. Using an intermediate format which is not ELF not only adds overhead, it also means that there will always be cases when information is lost in one of the transformations. This all is especially true when it comes to DWARF handling. - it is certainly is my goal to finish the last gap in the tools vs binutils. So at that time it would be a _possibility_ to drop binutils. But I think this is not really the main resentment. People complained that there is no public CVS? Why should there, you have all the sources. Releases are made regularly after every major change (given the constraints of the package maintainer). Other complain there is no release as tarballs. Very simple, I consider tarballs to be the wrong form. To guarantee consistency one needs something like src.rpm. Another complain is that there is no mailing list. Well, you can create a mailing list whenever and wherever you want. But one way or another you cannot force me to take time to read all the extra traffic. I've no time for that. Bugs can be filed in BZ and will be handled if necessary and reasonable. And yes, we cannot except outside contributions. Still not. This is a problem with our legal department who still hasn't set up a mechanism which allows us to accept assignments. And that's necessary, the code is copyrighted by me and Red Hat. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jreiser at BitWagon.com Mon May 29 03:33:47 2006 From: jreiser at BitWagon.com (John Reiser) Date: Sun, 28 May 2006 20:33:47 -0700 Subject: What's up with elfutils? In-Reply-To: <447A3977.7030703@redhat.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <447A3977.7030703@redhat.com> Message-ID: <447A6B9B.9030503@BitWagon.com> Ulrich Drepper wrote: > If you don't want elfutils, don't install it. Your choice. But don't > make judgments for which you don't have the information: In this particular case, I have 7 years of more-than-casual experience in this area of software for Linux and have produced ELF utilities used by others (including elfvector, rtldi, tub, tunelfso), but have never invoked any eu-* utility directly "by hand" or by script which I wrote. I also have entered and tracked many BZ reports in related projects such as glibc and strace, projects which share maintainers with elfutils. So I believe that I have at least moderate information on the topic of object file utilities and Fedora. > - there are no known problems in elfutils. At least none known to me > and none in BZ (which aren't fixed). Oh, but there are. Part of Nicholas Miell's reason for posting was that one of the BZ entries was fixed incompletely. He has the evidence, tried to get it considered through the BZ process, and felt stymied because that process is not as open as he felt it should be. > - the tools in elfutils compared with binutils are a) smaller, b) faster > (several times, usually), c) less buggy, d) more featureful Those conclusions are important to state explicitly. [Where is the data?] > - there are several tools which are not available in binutils which are > in (wide) use It always helps to give two or three specific examples. Then others who are interested can increase their knowledge of both elfutils and binutils, which might lead to improvements in both packages. Besides "eu-strip -f" for creating separate .debuginfo packages, what else is available in elfutils but not binutils? > - there are several more tools which use the elfutils libraries > (systemtap, frysk, ...) > > - there are more libraries part of elfutils which are not yet installed > because they are not finished yet Would now be a good time for input [of all kinds, including even code] from a larger community? > - almost everybody who has ever worked on binutils will attest what a > horrible mess it is. it deserves nothing but to die since you cannot > salvage the disaster. I agree that binutils is extremely poor software. However, binutils does cover more than the 10 architectures covered by elfutils [alpha, arm, i386, ia64, mips, ppc, ppc64, sh, sparc, x86_64.] Elfutils certainly covers the most important archs, but not every one; for instance: m68k. > Using an intermediate format which is not ELF not > only adds overhead, it also means that there will always be cases when > information is lost in one of the transformations. This all is > especially true when it comes to DWARF handling. > > - it is certainly is my goal to finish the last gap in the tools vs > binutils. So at that time it would be a _possibility_ to drop binutils. > > > But I think this is not really the main resentment. People complained > that there is no public CVS? Why should there, you have all the > sources. Releases are made regularly after every major change (given > the constraints of the package maintainer). Other complain there is no > release as tarballs. Very simple, I consider tarballs to be the wrong > form. To guarantee consistency one needs something like src.rpm. > Another complain is that there is no mailing list. Well, you can create > a mailing list whenever and wherever you want. But one way or another > you cannot force me to take time to read all the extra traffic. I've no > time for that. Bugs can be filed in BZ and will be handled if necessary > and reasonable. And yes, we cannot except outside contributions. Still > not. This is a problem with our legal department who still hasn't set > up a mechanism which allows us to accept assignments. And that's > necessary, the code is copyrighted by me and Red Hat. Part of my reason for entering and prolonging this thread is to increase the documentation for elfutils. Eliciting Ulrich Drepper's remark: > - the tools in elfutils compared with binutils are a) smaller, b) faster > (several times, usually), c) less buggy, d) more featureful counts as a success, which would be even more signficant if accompanied by some data to substantiate claims. I even made a deliberate mistake in using "rpm -qR" which Nicholas Miell pointed out should have been "--whatrequires" instead. I believe that the output (which indicates uses by rpm and rpm-python), and Ulrich Drepper's remarks about Red Hat legal department and copyrights, reveal significant new information to the Fedora community about the reasons why elfutils is the way it is. Elfutils is effectively part of RPM. Elfutils is a part of the Red Hat "crown jewels," which confers special status on elfutils. -- From ph18 at cornell.edu Mon May 29 03:51:18 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Sun, 28 May 2006 23:51:18 -0400 (EDT) Subject: helix, file selectors, and all that In-Reply-To: <447A3977.7030703@redhat.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <447A3977.7030703@redhat.com> Message-ID: <45233.74.32.150.66.1148874678.squirrel@webmail.cornell.edu> Some people say that Fedora needs mp3 because you can't download music in ogg format -- despite the name, http://www.allofmp3.com/ lets you download music in ogg format, at attractive prices: you decide the format and the bitrate you want, and they charge you by the megabyte. It costs me about $2.50 to download a typical album at 200 kb/s ogg, which is much better quality than you get from iTunes. Now, I'm a command-line guy (I've been into UNIX ever since my wardialer found a machine that belonged to the phone company in the mid 80's), so I find it really easy to do $ cd music $ cd Jefferson-Starship $ cd Red-Octopus $ ogg123 *.ogg particularly when bash helps me out with command line completion. Still, I've been impressed with the GUI in FC5, so let's try playing music with the GUI... I click on an ogg file and it plays in Helix player; that works great. Next I click on "File/Open" and notice that I can only select one file at a time. That's not good. I spend most of my workday in front of a Windows machine that mostly works as a VNC terminal for an RHEL 4 machine in the basement. I listen to music at work with both the Yahoo Music Engine (nice UI, but it screws up all the time) and Winamp (limited UI, but it works consistently). When you hit the "eject" button on Winamp, it comes up with a standard Windows file selector. Honestly I can't remember what does what, but you can use Shift+click and Ctrl+click to either select a range of files or to select individual files. (My unconcious mind knows, so I can do this effortless) You can go to the directory that an album is in, select all the files, and listen to the whole album. Winamp is screwy, because the files play in the opposite order that they should play -- if you drag down from the top, the album will play backwards, but if you drag up from the bottom, the album plays forwards. This is the opposite of the intuitive behavior, but once you get used to it, it's easy to listen to a whole album in Winamp. Helix on FC isn't like that -- shift+click, ctrl+click doesn't do anything different from 'click', so I have to play a whole album at a time. I can't say I know what GUI toolkit that Helix is using to generate it's file selector... I think it's gnome, but it's not like any documentation exists for this stuff... But it's little things like this that make the difference between a GUI that's useful, and a GUI that's not. From nmiell at comcast.net Mon May 29 04:21:47 2006 From: nmiell at comcast.net (Nicholas Miell) Date: Sun, 28 May 2006 21:21:47 -0700 Subject: What's up with elfutils? In-Reply-To: <447A6B9B.9030503@BitWagon.com> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <447A3977.7030703@redhat.com> <447A6B9B.9030503@BitWagon.com> Message-ID: <1148876507.2412.7.camel@entropy> On Sun, 2006-05-28 at 20:33 -0700, John Reiser wrote: > Part of my reason for entering and prolonging this thread is to increase > the documentation for elfutils. Eliciting Ulrich Drepper's remark: > > - the tools in elfutils compared with binutils are a) smaller, b) faster > > (several times, usually), c) less buggy, d) more featureful > counts as a success, which would be even more signficant if accompanied > by some data to substantiate claims. I even made a deliberate mistake > in using "rpm -qR" which Nicholas Miell pointed out should have been > "--whatrequires" instead. I believe that the output (which indicates > uses by rpm and rpm-python), and Ulrich Drepper's remarks about Red Hat > legal department and copyrights, reveal significant new information > to the Fedora community about the reasons why elfutils is the way it is. > Elfutils is effectively part of RPM. Elfutils is a part of the Red Hat > "crown jewels," which confers special status on elfutils. I don't know what drugs you're on, but please stop dragging me into your paranoid delusions. -- Nicholas Miell From otaylor at redhat.com Mon May 29 04:53:45 2006 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 29 May 2006 00:53:45 -0400 Subject: helix, file selectors, and all that In-Reply-To: <45233.74.32.150.66.1148874678.squirrel@webmail.cornell.edu> References: <1148706929.2401.14.camel@entropy> <20060527114348.GA18192@hurricane.linuxnetz.de> <44786A65.40206@BitWagon.com> <1148807292.4310.758.camel@sundaram.pnq.redhat.com> <4479D14D.7050401@BitWagon.com> <1148835292.18751.3.camel@aglarond.local> <4479F015.2070805@BitWagon.com> <447A3977.7030703@redhat.com> <45233.74.32.150.66.1148874678.squirrel@webmail.cornell.edu> Message-ID: <1148878425.2695.43.camel@huygens.localdomain> On Sun, 2006-05-28 at 23:51 -0400, Paul A Houle wrote: > Helix on FC isn't like that -- shift+click, ctrl+click doesn't do > anything different from 'click', so I have to play a whole album at > a time. I can't say I know what GUI toolkit that Helix is using to > generate it's file selector... I think it's gnome, but it's not > like any documentation exists for this stuff... But it's little > things like this that make the difference between a GUI that's > useful, and a GUI that's not. The GTK+ file selector supports multiple selection (try gedit, say); the application is, however, responsible for turning that on ... it doesn't make sense in all cases. You might want to file an upstream bug report against helix. I personally find rhythmbox a whole lot nicer for playing local music, but tastes vary. Owen From buildsys at redhat.com Mon May 29 07:17:35 2006 From: buildsys at redhat.com (Build System) Date: Mon, 29 May 2006 03:17:35 -0400 Subject: rawhide report: 20060529 changes Message-ID: <200605290717.k4T7HZb9009980@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.7.0-0.cvs20060529.1 ------------------------------------ * Mon May 29 2006 Dan Williams - 0.7.0-0.cvs20060529 - Update to latest CVS o Gnome.org #333420: dialog do not have window icons o Gnome.org #336913: HIG tweaks for vpn properties pages o Gnome.org #336846: HIG tweaks for nm-vpn-properties o Gnome.org #336847: some bugs in nm-vpn-properties args parsing o Gnome.org #341306: nm-vpn-properties crashes on startup o Gnome.org #341263: Version 0.6.2-0ubuntu5 crashes on nm_device_802_11_wireless_get_type o Gnome.org #341297: displays repeated keyring dialogs on resume from suspend o Gnome.org #342400: Building libnm-util --without-gcrypt results in linker error o Gnome.org #342398: Eleminate Gnome dependency for NetworkManager o Gnome.org #336532: declaration of 'link' shadows a global declaration - Specfile fixes (#rh187489#) * Sun May 21 2006 Dan Williams - 0.7.0-0.cvs20060521 - Update to latest CVS - Drop special-case-madwifi.patch, since WEXT code is in madwifi-ng trunk now * Fri May 19 2006 Bill Nottingham - 0.6.2-3.fc6 - use the same 0.6.2 tarball as FC5, so we have the same VPN interface (did he fire ten args, or only nine?) kbd-1.12-15 ----------- * Mon May 29 2006 Miloslav Trmac - 1.12-15 - Fix missing BuildRequires (#193406) kernel-2.6.16-1.2227_FC6 ------------------------ * Sun May 28 2006 Dave Jones - 2.6.17rc5-git4 man-pages-ja-20060515-1 ----------------------- * Mon May 29 2006 Akira TAGOH - 20060515-1 - updates to 20060515. selinux-policy-2.2.43-3 ----------------------- * Sun May 28 2006 Dan Walsh 2.2.43-3 - Fix for hplip and Picasa Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires libstdc++-devel = 0:4.1.0 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires libstdc++-devel = 0:4.1.0 Broken deps for ppc ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires libstdc++-devel = 0:4.1.0 Broken deps for ia64 ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires libstdc++-devel = 0:4.1.0 rgmanager - 1.9.31-3.ia64 requires ccs From raven at themaw.net Mon May 29 07:48:06 2006 From: raven at themaw.net (Ian Kent) Date: Mon, 29 May 2006 15:48:06 +0800 (WST) Subject: autofs problems In-Reply-To: <1148768358.2719.79.camel@xpc.home.erwinrol.com> References: <1148768358.2719.79.camel@xpc.home.erwinrol.com> Message-ID: On Sun, 28 May 2006, Erwin Rol wrote: > Since a few days i have problems with autofs. In my log file i find the > following entries; > > when i try "ls /net/192.168.2.1/home" > > May 27 23:40:10 xpc automount[29328]: lookup_mount: >> /usr/sbin/showmount: can't get address for /net/192.168.2.1/home > May 27 23:40:10 xpc automount[29328]: lookup_mount: lookup(program): lookup for /net/192.168.2.1/home failed > > and when i try "ls /net/gate/home" > > May 27 23:44:45 xpc automount[29521]: lookup_mount: >> /usr/sbin/showmount: can't get address for /net/gate/home > May 27 23:44:45 xpc automount[29521]: lookup_mount: lookup(program): lookup for /net/gate/home failed > > showmount outputs the following; > > # showmount gate -e > Export list for gate: > /data * > /home * > > Any ideas ? You've really need to specify the version of your install, kernel and autofs. Ian From raven at themaw.net Mon May 29 08:44:55 2006 From: raven at themaw.net (Ian Kent) Date: Mon, 29 May 2006 16:44:55 +0800 (WST) Subject: autofs problems In-Reply-To: References: <1148768358.2719.79.camel@xpc.home.erwinrol.com> Message-ID: On Mon, 29 May 2006, Ian Kent wrote: > On Sun, 28 May 2006, Erwin Rol wrote: > > > Since a few days i have problems with autofs. In my log file i find the > > following entries; > > > > when i try "ls /net/192.168.2.1/home" > > > > May 27 23:40:10 xpc automount[29328]: lookup_mount: >> /usr/sbin/showmount: can't get address for /net/192.168.2.1/home > > May 27 23:40:10 xpc automount[29328]: lookup_mount: lookup(program): lookup for /net/192.168.2.1/home failed > > > > and when i try "ls /net/gate/home" > > > > May 27 23:44:45 xpc automount[29521]: lookup_mount: >> /usr/sbin/showmount: can't get address for /net/gate/home > > May 27 23:44:45 xpc automount[29521]: lookup_mount: lookup(program): lookup for /net/gate/home failed > > > > showmount outputs the following; > > > > # showmount gate -e > > Export list for gate: > > /data * > > /home * > > > > Any ideas ? > > You've really need to specify the version of your install, kernel and > autofs. Never mind. I've been able to duplicate it. It will be fixed in the next update, Ian From list at suedkaliber.de Mon May 29 11:04:57 2006 From: list at suedkaliber.de (Florian Obradovic) Date: Mon, 29 May 2006 13:04:57 +0200 Subject: AIGLX - blue screen Message-ID: <1148900697.3389.6.camel@localhost> hi people out there - i'm new to the list ;) i have aiglx installed on my gentoo box - when i enable aiglx in metacity i get an blue screen with shadows... USE_MAGNIFIER=0 metacity --replace & doesn't help... :( it looks like this (see atachment), and sometimes it flashes to normal view...: i have current libcm from cvs, mesa from cvs, and latest xorg. my kernel is 2.6.17-rc4. anyone an idea? -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.jpg Type: image/jpeg Size: 17451 bytes Desc: not available URL: From dragoran at feuerpokemon.de Mon May 29 11:19:18 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 29 May 2006 13:19:18 +0200 Subject: AIGLX - blue screen In-Reply-To: <1148900697.3389.6.camel@localhost> References: <1148900697.3389.6.camel@localhost> Message-ID: <447AD8B6.4010803@feuerpokemon.de> Florian Obradovic wrote: > hi people out there - i'm new to the list ;) > i have aiglx installed on my gentoo box - when i enable aiglx in > metacity i get an blue screen with shadows... > > USE_MAGNIFIER=0 metacity --replace & > > doesn't help... :( > > it looks like this (see atachment), and sometimes it flashes to normal > view...: > > i have current libcm from cvs, mesa from cvs, and latest xorg. > my kernel is 2.6.17-rc4. > > anyone an idea? > > > > ------------------------------------------------------------------------ > vga card + driver? From sundaram at fedoraproject.org Mon May 29 11:19:45 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 29 May 2006 16:49:45 +0530 Subject: AIGLX - blue screen In-Reply-To: <1148900697.3389.6.camel@localhost> References: <1148900697.3389.6.camel@localhost> Message-ID: <1148901585.4310.821.camel@sundaram.pnq.redhat.com> On Mon, 2006-05-29 at 13:04 +0200, Florian Obradovic wrote: > hi people out there - i'm new to the list ;) > i have aiglx installed on my gentoo box - when i enable aiglx in > metacity i get an blue screen with shadows... > > USE_MAGNIFIER=0 metacity --replace & > > doesn't help... :( > > it looks like this (see atachment), and sometimes it flashes to normal > view...: > > i have current libcm from cvs, mesa from cvs, and latest xorg. > my kernel is 2.6.17-rc4. > > anyone an idea? Since you are using Gentoo, http://lists.freedesktop.org/archives/xorg/ might be a better place for this discussion. AIGLX having been merged into upstream Xorg isnt Fedora specific anymore. Rahul From list at suedkaliber.de Mon May 29 11:24:59 2006 From: list at suedkaliber.de (Florian Obradovic) Date: Mon, 29 May 2006 13:24:59 +0200 Subject: AIGLX - blue screen In-Reply-To: <447AD8B6.4010803@feuerpokemon.de> References: <1148900697.3389.6.camel@localhost> <447AD8B6.4010803@feuerpokemon.de> Message-ID: <1148901899.4093.0.camel@localhost> hi, oh sorry ;) its an i915 intel graka... 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) greets, flo Am Montag, den 29.05.2006, 13:19 +0200 schrieb dragoran: > Florian Obradovic wrote: > > hi people out there - i'm new to the list ;) > > i have aiglx installed on my gentoo box - when i enable aiglx in > > metacity i get an blue screen with shadows... > > > > USE_MAGNIFIER=0 metacity --replace & > > > > doesn't help... :( > > > > it looks like this (see atachment), and sometimes it flashes to normal > > view...: > > > > i have current libcm from cvs, mesa from cvs, and latest xorg. > > my kernel is 2.6.17-rc4. > > > > anyone an idea? > > > > > > > > ------------------------------------------------------------------------ > > > > vga card + driver? > From list at suedkaliber.de Mon May 29 11:25:50 2006 From: list at suedkaliber.de (Florian Obradovic) Date: Mon, 29 May 2006 13:25:50 +0200 Subject: AIGLX - blue screen In-Reply-To: <1148901585.4310.821.camel@sundaram.pnq.redhat.com> References: <1148900697.3389.6.camel@localhost> <1148901585.4310.821.camel@sundaram.pnq.redhat.com> Message-ID: <1148901950.4093.2.camel@localhost> hi, yes i know that, but i saw some people having same problems here on the list - not yet solved... Am Montag, den 29.05.2006, 16:49 +0530 schrieb Rahul Sundaram: > On Mon, 2006-05-29 at 13:04 +0200, Florian Obradovic wrote: > > hi people out there - i'm new to the list ;) > > i have aiglx installed on my gentoo box - when i enable aiglx in > > metacity i get an blue screen with shadows... > > > > USE_MAGNIFIER=0 metacity --replace & > > > > doesn't help... :( > > > > it looks like this (see atachment), and sometimes it flashes to normal > > view...: > > > > i have current libcm from cvs, mesa from cvs, and latest xorg. > > my kernel is 2.6.17-rc4. > > > > anyone an idea? > > Since you are using Gentoo, http://lists.freedesktop.org/archives/xorg/ > might be a better place for this discussion. AIGLX having been merged > into upstream Xorg isnt Fedora specific anymore. > > Rahul > From tla-ml at rasmil.dk Mon May 29 11:28:43 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Mon, 29 May 2006 13:28:43 +0200 Subject: Just a word about YumApplet In-Reply-To: <1148817372.28729.7.camel@cutter> References: <1148811377.4310.762.camel@sundaram.pnq.redhat.com> <1148816660.28729.5.camel@cutter> <1148817372.28729.7.camel@cutter> Message-ID: <447ADAEB.2010203@rasmil.dk> seth vidal wrote: > On Sun, 2006-05-28 at 13:50 +0200, Damien Durand wrote: > >> It's possible to look the sources of this application? I'm intersted >> to contribute, I need to know the list of thing to be made. >> > > the backend daemon is checked into yum cvs: > http://devel.linux.duke.edu/cgi-bin/viewvc.cgi/yum/yum-updatesd.py?view=log > > the frontend applet is in fedora cvs, I think, but I've not seen it yet. > Jeremy, where is it? > > -sv > > > I found Jeremy's code here. export CVSROOT=:pserver:anonymous at elvis.redhat.com:/usr/local/CVS cvs login cvs checkout pirut take a look at publet.py. I have done a little test. 1. copy 'etc/yum-updatesd.conf' from yum CVS Head to ' /etc/dbus-1/system.d/' 2. create '/etc/yum/yum-updatesd.conf' add: [main] emit_via = dbus run_interval = 60 # Check for update every 60 sek. 3. run 'sudo python yum-updatesd.py -f' from a directory containing yum CVS head. 4. run 'dbus-monitor --system' in another window to monitor DBus signals. 5. run 'python publet.py' from a directory containing the pirut CVS checkout. Every 60 sek, you will see DBus signal from yum-updatesd.py telling is any updates is availible. If any updates is available, publet.py will show an icon in the notification area. I have used FC5 for the test and gnome-python2-libegg need to be installed for puplet.py. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From nphilipp at redhat.com Mon May 29 13:32:12 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 29 May 2006 15:32:12 +0200 Subject: A sole, standard proxy library for Fedora In-Reply-To: <44787D30.6020808@mesias.co.uk> References: <447736D6.20204@redfish-solutions.com> <44787D30.6020808@mesias.co.uk> Message-ID: <1148909533.24213.9.camel@gibraltar.stuttgart.redhat.com> On Sat, 2006-05-27 at 17:24 +0100, Cam wrote: > Philip > > > I have a laptop that travels with me from work (where there's the > > use of web proxies) to home (where I don't), and was overwhelmed > > by the number of config files that I have to switch over every time > > I move from one place to the other. > > How about having a lightweight proxy on every machine. All configuration > should point to the local proxy. > > When the network changes, only the proxy need be informed of the changes. > > It's a horrible hack, I know :) but configuration in the environment > isn't dynamic enough, and hell will freeze over before any new > configuration scheme reaches the level of acceptance that http_proxy in > env has. Seconded. I have used privoxy to accomodate my laptop to several networks where some require use of a proxy, some offer a proxy and some don't. Drawbacks of using privoxy are: - when changing settings, they only took effect on the second connection afterwards - privoxy can't proxy FTP URLs, you have to use a local squid if there aren't any other proxies available if you want to do FTP (yuck) - you have to configure away any "privacy enhancing" settings of privoxy if you don't want them Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From david at lovesunix.net Mon May 29 17:44:19 2006 From: david at lovesunix.net (David Nielsen) Date: Mon, 29 May 2006 19:44:19 +0200 Subject: AIGLX - blue screen In-Reply-To: <1148901899.4093.0.camel@localhost> References: <1148900697.3389.6.camel@localhost> <447AD8B6.4010803@feuerpokemon.de> <1148901899.4093.0.camel@localhost> Message-ID: <1148924659.2670.81.camel@price> man, 29 05 2006 kl. 13:24 +0200, skrev Florian Obradovic: > hi, oh sorry > ;) > > its an i915 intel graka... > 00:02.0 VGA compatible controller: Intel Corporation Mobile > 915GM/GMS/910GML Express Graphics Controller (rev 03) > > greets, flo I can ack this failure on Fedora Development using a Radeon 9250 (r200) card. This is an AMD64 box should that matter. I also know of a user on an intel chip who is seeing the same. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From list at suedkaliber.de Mon May 29 21:51:38 2006 From: list at suedkaliber.de (Florian Obradovic) Date: Mon, 29 May 2006 23:51:38 +0200 Subject: AIGLX - blue screen In-Reply-To: <1148924659.2670.81.camel@price> References: <1148900697.3389.6.camel@localhost> <447AD8B6.4010803@feuerpokemon.de> <1148901899.4093.0.camel@localhost> <1148924659.2670.81.camel@price> Message-ID: <1148939498.3622.1.camel@localhost> yes, i am an intel user with this prob. ;) i tried installing metacity from cvs, but make failes when compositor is enabled: --snip c-window.o: In function `meta_comp_window_refresh_attrs': /home/flo/tmp/src/metacity/src/c-window.c:660: undefined reference to `cm_drawable_node_get_viewable' c-window.o: In function `send_sync_request': /home/flo/tmp/src/metacity/src/c-window.c:611: undefined reference to `ws_window_send_client_message' c-window.o: In function `send_configure_notify': /home/flo/tmp/src/metacity/src/c-window.c:367: undefined reference to `ws_window_query_override_redirect' /home/flo/tmp/src/metacity/src/c-window.c:367: undefined reference to `ws_window_send_configure_notify' c-window.o: In function `update_explosion': /home/flo/tmp/src/metacity/src/c-window.c:754: undefined reference to `cm_drawable_node_get_viewable' c-window.o: In function `meta_comp_window_explode': /home/flo/tmp/src/metacity/src/c-window.c:783: undefined reference to `cm_drawable_node_get_viewable' collect2: ld returned 1 exit status make[4]: *** [metacity] Fehler 1 make[4]: Leaving directory `/home/flo/tmp/src/metacity/src' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/home/flo/tmp/src/metacity/src' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/home/flo/tmp/src/metacity/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/flo/tmp/src/metacity' make: *** [all] Fehler 2 --snip any idea? Am Montag, den 29.05.2006, 19:44 +0200 schrieb David Nielsen: > man, 29 05 2006 kl. 13:24 +0200, skrev Florian Obradovic: > > hi, oh sorry > > ;) > > > > its an i915 intel graka... > > 00:02.0 VGA compatible controller: Intel Corporation Mobile > > 915GM/GMS/910GML Express Graphics Controller (rev 03) > > > > greets, flo > > I can ack this failure on Fedora Development using a Radeon 9250 (r200) > card. This is an AMD64 box should that matter. > > I also know of a user on an intel chip who is seeing the same. > > - David > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From seg at haxxed.com Mon May 29 23:01:46 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 18:01:46 -0500 Subject: Future Fedora Development In-Reply-To: <20060524150805.GC1186624@hiwaay.net> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> <20060524150805.GC1186624@hiwaay.net> Message-ID: <1148943706.22592.4.camel@localhost> On Wed, 2006-05-24 at 10:08 -0500, Chris Adams wrote: > Once upon a time, Bernardo Innocenti said: > > What's wrong with GPL programs using the Mozilla implementation? > > Last time I checked NSS was totally GPL compatible. > > mozilla-nss requires mozilla-nspr. libnss3.so also pulls in > libpthread.so. Those are pretty heavy requirements for SSL. Even OpenSSL is so bloaty that the smallest I can get it down to (on MIPS, who's code size seem to be about 2x i386) is 1.5mb. Making it impossible to fit into the 2mb flash on a belkin router. Sigh. There's MatrixSSL, but there's next to nothing that actually uses it... -------------- 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 peter at thecodergeek.com Mon May 29 23:09:40 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 29 May 2006 16:09:40 -0700 Subject: Future Fedora Development In-Reply-To: <1148943706.22592.4.camel@localhost> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> <20060524150805.GC1186624@hiwaay.net> <1148943706.22592.4.camel@localhost> Message-ID: <447B7F34.8050106@thecodergeek.com> Callum Lerwick wrote: > On Wed, 2006-05-24 at 10:08 -0500, Chris Adams wrote: >> Once upon a time, Bernardo Innocenti said: >>> What's wrong with GPL programs using the Mozilla implementation? >>> Last time I checked NSS was totally GPL compatible. >> mozilla-nss requires mozilla-nspr. libnss3.so also pulls in >> libpthread.so. Those are pretty heavy requirements for SSL. > > Even OpenSSL is so bloaty that the smallest I can get it down to (on > MIPS, who's code size seem to be about 2x i386) is 1.5mb. Making it > impossible to fit into the 2mb flash on a belkin router. Sigh. > > There's MatrixSSL, but there's next to nothing that actually uses it... > There's also GnuTLS, which (according to `yum info`) is less than a megabyte fully installed. Not sure if fits the requirements for this though... -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From seg at haxxed.com Mon May 29 23:20:39 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 18:20:39 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148422547.25336.13.camel@rousalka.dyndns.org> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <4471F827.3010804@mharris.ca> <44731AAC.3030909@redhat.com> <1148422547.25336.13.camel@rousalka.dyndns.org> Message-ID: <1148944839.22592.9.camel@localhost> On Wed, 2006-05-24 at 00:15 +0200, Nicolas Mailhot wrote: > Unfortunately, as every single FCxT1 release shows, leaving xfs > enabled > means various users will have their X server fail mysteriously because > of problems locating "fixed". Notwithstanding the fact that they > probably do not have a single main app needing "fixed" anymore. Just compile "fixed" into the x server? Then the X server can never fail to start because it can't find "fixed"... I know kdrive can do this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Mon May 29 23:37:51 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 18:37:51 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <44721137.2010806@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> Message-ID: <1148945872.22592.17.camel@localhost> On Mon, 2006-05-22 at 15:29 -0400, Mike A. Harris wrote: > - Run ntsysv (or equivalent) and disable the xfs service from > starting at boot time. > > - Run "service xfs stop" to shut down xfs > > - Edit xorg.conf and comment out the unix:/7100 font path. > Add a FontPath that points to the "misc" font directory. > > - Start the X server. It should start correctly as long as you > have properly configured the misc font path, as it will then > still be able to find "fixed" and "cursor". I've been doing this ever since GNOME2 was released. The only apps I use anymore that depend on core fonts are xmms (GTK 1.x) and vnviewer (Toolkit: ???). xscreensaver was finally killed off by gnome-screensaver. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Mon May 29 23:40:21 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 18:40:21 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <20060525131154.GA969949@hiwaay.net> References: <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <1148322125.5620.1.camel@scrappy.miketc.com> <44721137.2010806@mharris.ca> <1148422325.15474.6.camel@scrappy.miketc.com> <4474ED42.2010106@mharris.ca> <20060525002447.GA898192@hiwaay.net> <4475A4E5.8020607@mharris.ca> <20060525131154.GA969949@hiwaay.net> Message-ID: <1148946022.22592.20.camel@localhost> On Thu, 2006-05-25 at 08:11 -0500, Chris Adams wrote: > Yes, I know. Again, is there a way to get the same font as the old core > fonts "fixed" from Xft? Is that font available from Xft? Xft support bitmap fonts just fine. Point it at where the bitmap fonts are and you can use them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue May 30 00:01:42 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 19:01:42 -0500 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <4474F1F1.10805@mharris.ca> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> <4474F1F1.10805@mharris.ca> Message-ID: <1148947303.22592.33.camel@localhost> On Wed, 2006-05-24 at 19:53 -0400, Mike A. Harris wrote: > I can't guess how many users use nedit, but emacs > and mplayer have a massive userbase. And thus have plenty of motivation, and available manpower with which to port them over to using Xft. GVIM and Xine have been using GTK2/Xft for some time now. (Warning: Contains flamebait.) Fiddling around with compatibility layers, or trying to get the X server itself to handle fonts rather than xfs, is a waste of effort better put towards simply porting apps over to using Xft. Either we put our foot down, and completely rip out core fonts now, or we leave it as is and have this argument yet again during FC7 devel... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue May 30 00:48:43 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 19:48:43 -0500 Subject: Future Fedora Development In-Reply-To: <447B7F34.8050106@thecodergeek.com> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> <20060524150805.GC1186624@hiwaay.net> <1148943706.22592.4.camel@localhost> <447B7F34.8050106@thecodergeek.com> Message-ID: <1148950123.22592.47.camel@localhost> On Mon, 2006-05-29 at 16:09 -0700, Peter Gordon wrote: > There's also GnuTLS, which (according to `yum info`) is less than a > megabyte fully installed. Not sure if fits the requirements for this > though... Hmmm, gnutls-devel has .a files in it? GnuTLS might fit, but the goal would be to use something like OpenVPN or an IPsec IKE daemon like racoon or whatever Openswan uses. Unless they can be compiled against GnuTLS its kinda moot... (There's tinc, but its naive encryption implementation doesn't thrill me.) -------------- 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 peter at thecodergeek.com Tue May 30 01:09:02 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 29 May 2006 18:09:02 -0700 Subject: Future Fedora Development In-Reply-To: <1148950123.22592.47.camel@localhost> References: <44701330.4030807@ntlworld.com> <1148225922.4296.8.camel@atlantis.mpeters.local> <4470CA50.8060000@ntlworld.com> <1148245245.21278.22.camel@kloczek01.pracownicy.zie> <4474129A.5050201@develer.com> <20060524113718.GA16163@devserv.devel.redhat.com> <44747440.8070101@develer.com> <20060524150805.GC1186624@hiwaay.net> <1148943706.22592.4.camel@localhost> <447B7F34.8050106@thecodergeek.com> <1148950123.22592.47.camel@localhost> Message-ID: <447B9B2E.9050801@thecodergeek.com> Callum Lerwick wrote: > Hmmm, gnutls-devel has .a files in it? GnuTLS might fit, but the goal > would be to use something like OpenVPN or an IPsec IKE daemon like > racoon or whatever Openswan uses. Unless they can be compiled against > GnuTLS its kinda moot... > > (There's tinc, but its naive encryption implementation doesn't thrill > me.) > Ah. Thanks for clearing that up for me. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From seg at haxxed.com Tue May 30 01:10:47 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 May 2006 20:10:47 -0500 Subject: Resource sharing for two users logged in locally simultaneously In-Reply-To: <20060523110001.6a62775e@python2> References: <20060523110001.6a62775e@python2> Message-ID: <1148951447.22592.64.camel@localhost> On Tue, 2006-05-23 at 11:00 +0200, Matthias Saou wrote: > Here's the one big feature I'd like to have in Fedora for my current > needs : The possibility to have everything "just work" when more than > one user is logged into X (from gdm). Also of note, is multiseat configurations. This is very similar, but slightly different. You have multiple users active *simultaneously*. Me and my wife are now sharing a single desktop box, as it seemed to be a better use of money to sink it all into a single decent-ish box rather than two as-cheapass-as-possible boxes. In this case, I want to assign separate sound cards to each seat, rather than share one. (Actually, a neat trick would be to split up the cheezy onboard 6 channel sound, four channels on one seat, two on the other. Some asoundrc hacking might accomplish this...) As well as say "Anything plugged into these two USB ports belongs to seat 1, these other two belong to seat 2..." (Or even combine the two, and plug a USB audio adapter into one seat, and have it "just work"...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Tue May 30 04:18:37 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 29 May 2006 23:18:37 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-05-29 Message-ID: <20060530041837.GB24614@lists.us.dell.com> extras Rawhide-in-Mock Build Results for x86_64 Mon May 29 22:59:15 CDT 2006 Number failed to build: 187 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 176 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 174 ---------------------------------- alacarte amaya anjuta-gdl apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp Coin2 colorscheme contact-lookup-applet cowbell d4x ddskk dia dietlibc dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife Macaulay2 MagicPoint mail-notification mhonarc multisync mysql-administrator nautilus-actions nautilus-open-terminal nautilus-search-tool ncmpc nco NetworkManager-vpnc new OpenSceneGraph pam_mount paps perl-HTML-Mason perl-Image-Info perl-Log-Log4perl perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl pypoker-eval python-cheetah python-dateutil python-goopy python-reportlab python-TestGears qemu qtparted quarry R-gnomeGUI rpmDirectoryCheck sabayon scmxx scponly SDL_ttf ser serpentine sloccount splint stow stratagus supertux swh-plugins synaptic synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont tuxpaint uqm ushare verbiste WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp yumex z88dk With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] libqalculate ['193481 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Tue May 30 04:19:01 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 29 May 2006 23:19:01 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 Message-ID: <20060530041900.GC24614@lists.us.dell.com> extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 Number failed to build: 176 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 175 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 173 ---------------------------------- abe alacarte amaya anjuta-gdl balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp clearsilver Coin2 colorscheme contact-lookup-applet cowbell csmash ddskk dia dillo diradmin directfb drgeo ebtables enigma epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge freedroid gambas gazpacho gcompris gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics GtkAda gtk-gnutella Gtk-Perl gtktalog gtk-xfce-engine gurlchecker gwget Hermes ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd lincity-ng linkchecker lmarbles logjam lucidlife MagicPoint mail-notification mfstools multisync mysql-administrator naim nautilus-actions nautilus-open-terminal nautilus-search-tool nazghul ncmpc nco netpanzer NetworkManager-vpnc OpenSceneGraph paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl ppracer pygame pypoker-eval python-cheetah python-goopy python-TestGears qemu qtparted quarry R-gnomeGUI rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly SDL_net SDL_ttf ser serpentine sloccount splint stow stratagus supertux swh-plugins synce-software-manager synce-trayicon tagtool Terminal tetex-eurofont torcs tuxpaint tuxtype2 ushare verbiste viruskiller WindowMaker wlassistant xbase xbindkeys xbsql xcin xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfce-utils xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp yumex With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] libqalculate ['193481 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Tue May 30 04:19:32 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 29 May 2006 23:19:32 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2006-05-29 Message-ID: <20060530041932.GD24614@lists.us.dell.com> core Rawhide-in-Mock Build Results for x86_64 Mon May 29 22:56:34 CDT 2006 Number failed to build: 317 Number expected to fail due to ExclusiveArch or ExcludeArch: 26 Leaving: 291 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 50 ---------------------------------- automake15 automake16 boost elilo emacs kdeaccessibility libmusicbrainz openmotif pcmciautils perl pirut pkgconfig policycoreutils pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm SDL sgml-common specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans Xaw3d xmlsec1 xmlto xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 241 ---------------------------------- a2ps ['193345 CLOSED', '193346 NEW'] am-utils ['193347 ASSIGNED'] aqbanking ['193348 NEW'] arts ['192367 NEEDINFO'] atk ['193349 NEW'] at-spi ['192368 CLOSED'] authd ['193350 CLOSED'] autorun ['193351 CLOSED'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] busybox ['193354 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 NEW'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] fbset ['193362 CLOSED'] file-roller ['193363 NEW'] frysk ['192256 NEW'] f-spot ['193364 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] GFS-kernel ['192569 NEW'] gimp ['193368 NEW'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 CLOSED'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-keyring ['193377 CLOSED'] gnome-keyring-manager ['193378 CLOSED'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-user-share ['193391 CLOSED'] gnome-utils ['191757 CLOSED'] gnome-vfs2 ['193392 NEW'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gob2 ['193395 NEW'] grub ['192504 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] hwbrowser ['193400 NEW'] ImageMagick ['192036 NEW'] indent ['193401 NEW'] inn ['193402 CLOSED'] iproute ['193403 CLOSED'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jpilot ['193405 CLOSED'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 MODIFIED'] libgtop2 ['193418 NEW'] libIDL ['193419 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libSM ['193421 NEW'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] libXres ['193502 NEW'] libXt ['193503 NEW'] libXtst ['193504 NEW'] libXv ['193505 NEW'] libXvMC ['193506 NEW'] libXxf86dga ['193507 NEW'] libXxf86misc ['193508 NEW'] libXxf86vm ['193509 NEW'] linux-atm ['193510 CLOSED'] lm_sensors ['193511 NEW'] lrzsz ['193513 NEW'] lynx ['193515 NEW'] m17n-lib ['193524 NEW'] magma-plugins ['193525 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] ncpfs ['193526 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] qt ['191895 CLOSED'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ ----- End forwarded message ----- -- 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 Matt_Domsch at dell.com Tue May 30 04:20:02 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 29 May 2006 23:20:02 -0500 Subject: Core i386 rawhide rebuild in mock status 2006-05-29 Message-ID: <20060530042002.GE24614@lists.us.dell.com> core Rawhide-in-Mock Build Results for i386 Mon May 29 22:57:44 CDT 2006 Number failed to build: 303 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 294 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 45 ---------------------------------- automake15 automake16 emacs openmotif pcmciautils pirut pkgconfig policycoreutils prelink pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm SDL sg3_utils specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans Xaw3d xmlsec1 xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 249 ---------------------------------- a2ps ['193345 CLOSED', '193346 NEW'] am-utils ['193347 ASSIGNED'] aqbanking ['193348 NEW'] arts ['192367 NEEDINFO'] atk ['193349 NEW'] at-spi ['192368 CLOSED'] authd ['193350 CLOSED'] autorun ['193351 CLOSED'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] busybox ['193354 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 NEW'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] fbset ['193362 CLOSED'] file-roller ['193363 NEW'] frysk ['192256 NEW'] f-spot ['193364 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] GFS-kernel ['192569 NEW'] gimp ['193368 NEW'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 CLOSED'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-keyring ['193377 CLOSED'] gnome-keyring-manager ['193378 CLOSED'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-user-share ['193391 CLOSED'] gnome-utils ['191757 CLOSED'] gnome-vfs2 ['193392 NEW'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gob2 ['193395 NEW'] gpart ['193396 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] HelixPlayer ['192512 NEW'] hwbrowser ['193400 NEW'] indent ['193401 NEW'] inn ['193402 CLOSED'] iproute ['193403 CLOSED'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jpilot ['193405 CLOSED'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 MODIFIED'] libgtop2 ['193418 NEW'] libIDL ['193419 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libSM ['193421 NEW'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] libXres ['193502 NEW'] libXt ['193503 NEW'] libXtst ['193504 NEW'] libXv ['193505 NEW'] libXvMC ['193506 NEW'] libXxf86dga ['193507 NEW'] libXxf86misc ['193508 NEW'] libXxf86vm ['193509 NEW'] linux-atm ['193510 CLOSED'] lm_sensors ['193511 NEW'] longrun ['193512 NEW'] lrzsz ['193513 NEW'] lynx ['193515 NEW'] m17n-lib ['193524 NEW'] magma-plugins ['193525 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] ncpfs ['193526 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 NEW'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 buildsys at redhat.com Tue May 30 07:26:16 2006 From: buildsys at redhat.com (Build System) Date: Tue, 30 May 2006 03:26:16 -0400 Subject: rawhide report: 20060530 changes Message-ID: <200605300726.k4U7QGgD027413@porkchop.devel.redhat.com> Updated Packages: autorun-3.19-1 -------------- * Mon May 29 2006 Harald Hoyer - 3.19 - translation update - more build requires fbset-2.1-21 ------------ * Mon May 29 2006 Jindrich Novy 2.1-21 - add BuildRequires: bison (#193362) gnome-bluetooth-0.7.0-4 ----------------------- * Mon May 29 2006 Harald Hoyer - 0.7.0-3 - more build requires (bug #193374) gnome-media-2.14.2-2 -------------------- * Mon May 29 2006 Matthias Clasen - 2.14.2-2 - Update to 2.14.2 gphoto2-2.1.99-13 ----------------- * Mon May 29 2006 Radek Vokal 2.1.99-13 - remove Canon IXUS 700 support (#167347) - add new USB ids jpilot-0.99.8-6 --------------- * Mon May 29 2006 Ivana Varekova 0.99.8-6 - add prereq (perl-XML-Parser) (#193405) kernel-2.6.16-1.2230_FC6 ------------------------ * Mon May 29 2006 Dave Jones - 2.6.17rc5-git5 - autofs4: spoof negative dentries from mount fails on browseable indirect map mount points - Make acpi-cpufreq sticky. m17n-db-1.3.3-4 --------------- * Mon May 29 2006 Mayank Jain - Added icon for marathi inscript - thanks to aalam at redhat.com openoffice.org-1:2.0.3-4.1 -------------------------- * Mon May 29 2006 Caolan McNamara - 1:2.0.3-4.1 - 2.0.3 RC4 - add openoffice.org-2.0.3.ooo65852.vcl.a11ywizard.patch for rh#193246# Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires libstdc++-devel = 0:4.1.0 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires libstdc++-devel = 0:4.1.0 Broken deps for ppc ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires libstdc++-devel = 0:4.1.0 Broken deps for ia64 ---------------------------------------------------------- libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires libstdc++-devel = 0:4.1.0 rgmanager - 1.9.31-3.ia64 requires ccs From fedora at wir-sind-cool.org Tue May 30 09:50:14 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 30 May 2006 11:50:14 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530041900.GC24614@lists.us.dell.com> References: <20060530041900.GC24614@lists.us.dell.com> Message-ID: <20060530115014.7afcf968.fedora@wir-sind-cool.org> On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote: > extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 > Number failed to build: 176 > Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > Leaving: 175 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 173 > ---------------------------------- > abe > alacarte > amaya > anjuta-gdl > balsa -snip- Note sure what the goal of this rebuild attempt is. Extras buildsys uses mock for a long time. So every package in Extras has built successfully in mock before. Most (if not all) of the rebuild failures you've caught here are due to updates in Rawhide, such as compiler updates or API changes. This report is misleading. From paul at city-fan.org Tue May 30 10:53:58 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 11:53:58 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530115014.7afcf968.fedora@wir-sind-cool.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> Message-ID: <447C2446.8010506@city-fan.org> Michael Schwendt wrote: > On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote: > >> extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 >> Number failed to build: 176 >> Number expected to fail due to ExclusiveArch or ExcludeArch: 1 >> Leaving: 175 >> (there may be some duplicates if rawhide has 2 versions of a package) >> >> Of those expected to have worked... >> Without a bug filed: 173 >> ---------------------------------- >> abe >> alacarte >> amaya >> anjuta-gdl >> balsa > > -snip- > > Note sure what the goal of this rebuild attempt is. Extras buildsys uses > mock for a long time. So every package in Extras has built successfully in > mock before. Most (if not all) of the rebuild failures you've caught here > are due to updates in Rawhide, such as compiler updates or API changes. > This report is misleading. No, it's because he's building the packages with the reduced build environment that closely matches the exceptions list in the packaging guidelines rather than default mock configuration that pulls in lots of extra packages. So these build failures are mostly due to missing buildreqs of things like perl(XML::Parser), gettext, flex, etc. Paul. From fedora at wir-sind-cool.org Tue May 30 09:57:18 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 30 May 2006 11:57:18 +0200 Subject: FE BuildReq blocker #193444 opened In-Reply-To: <20060528201643.GA19932@lists.us.dell.com> References: <20060528201643.GA19932@lists.us.dell.com> Message-ID: <20060530115718.1f6fb1d2.fedora@wir-sind-cool.org> On Sun, 28 May 2006 15:16:52 -0500, Matt Domsch wrote: > Analogous to the BuildReq blocker bug for Core, I opened one for > Extras. > > Bug 193444: Tracker bug for BuildRequires fixes for FE > > This lets my stats scripts for Core work when rebuilding Extras too, > and lets us track the progress of fixing BuildRequires in Extras. Why is this not announced/discussed on fedora-extras-list? That is the development mailing list for Fedora Extras! The bug tracker for general issues in Extras which "ought to be fixed before next release of Fedora Core" is 187071 (alias FE6Target). We've used it for rebuild request tickets before, too. I've linked it, now, but another tracker bug is unnecessary IMHO. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 30 10:58:23 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 30 May 2006 12:58:23 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530115014.7afcf968.fedora@wir-sind-cool.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> Message-ID: <20060530125823.4b56627d@python2> Michael Schwendt wrote : > On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote: > > > extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 > > Number failed to build: 176 > > Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > > Leaving: 175 > > (there may be some duplicates if rawhide has 2 versions of a package) > > > > Of those expected to have worked... > > Without a bug filed: 173 > > ---------------------------------- > > abe > > alacarte > > amaya > > anjuta-gdl > > balsa > > -snip- > > Note sure what the goal of this rebuild attempt is. Extras buildsys uses > mock for a long time. So every package in Extras has built successfully in > mock before. Most (if not all) of the rebuild failures you've caught here > are due to updates in Rawhide, such as compiler updates or API changes. > This report is misleading. ...or the minor differences in the minimal set of packages used. I've checked the failure of one of my packages (lighttpd), and found out that it's because pkgconfig wasn't installed. Typically something simple that we need to reach consensus on (and probably a package somewhere providing a .pc file but not requiring pkgconfig). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2221_FC6 Load : 0.78 0.70 0.63 From fedora at wir-sind-cool.org Tue May 30 11:17:20 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 30 May 2006 13:17:20 +0200 Subject: Reporting bugs upstream In-Reply-To: <43D0BD74.7020304@mharris.ca> References: <43CE33C7.7010007@zoeloelip.be> <43CE8594.7050603@research.att.com> <43D0BD74.7020304@mharris.ca> Message-ID: <20060530131720.cc793008.fedora@wir-sind-cool.org> On Fri, 20 Jan 2006 05:37:40 -0500, Mike A. Harris wrote: > > I propose that it be a policy that Fedora maintainers are themselves > > responsible for forwarding the bug upsteam if necessary. Good proposal. > That does sometimes happen, but it is not something a bug reporter > should expect to happen. Red Hat engineering manpower is a limited > resource, and our man hours are prioritized across quite a number > of tasks. The amount of work that any given engineer "has" to do, > plus the amount of work that they could "potentially" do (such as > various random bugzilla bug reports), plus various meetings, and > other things that fill the day, is generally many times more than > the hours available. Have you ever before thought about this from the user's perspective? How many bug tracking systems does a single user need to create an account for? How many other forms of bug reporting systems does a single user need to subscribe to [and need to stay subscribed to for a long time] before communication with upstream developers becomes possible? How much knowledge of a given OS environment and an application's dependencies is needed to decide whether a problem is OS-specific or not? What the user thinks when he encounters a problem is that "Red Hat's [or Fedora's] product is broken". And that's right. It ought to be in your best interest to track each and every defect and make sure as many defects as possible are fixed either in conjunction with upstream developers or by yourself. As a user, being confronted with "just another feature-overloaded bug tracker" which contains many new and poorly named and insufficiently described "products" and "components" and hundreds of open bug reports, it is a very frustrating experience to spend time on _trying_ to help by reporting something upstream only to learn that the report is ignored or closed as duplicate or closed as NOTOURBUG or not been looked at for many months. From fedora at wir-sind-cool.org Tue May 30 11:33:44 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 30 May 2006 13:33:44 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <447C2446.8010506@city-fan.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> Message-ID: <20060530133344.5203a0bc.fedora@wir-sind-cool.org> On Tue, 30 May 2006 11:53:58 +0100, Paul Howarth wrote: > Michael Schwendt wrote: > > On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote: > > > >> extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 > >> Number failed to build: 176 > >> Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > >> Leaving: 175 > >> (there may be some duplicates if rawhide has 2 versions of a package) > >> > >> Of those expected to have worked... > >> Without a bug filed: 173 > >> ---------------------------------- > >> abe > >> alacarte > >> amaya > >> anjuta-gdl > >> balsa > > > > -snip- > > > > Note sure what the goal of this rebuild attempt is. Extras buildsys uses > > mock for a long time. So every package in Extras has built successfully in > > mock before. Most (if not all) of the rebuild failures you've caught here > > are due to updates in Rawhide, such as compiler updates or API changes. > > This report is misleading. > > No, it's because he's building the packages with the reduced build > environment that closely matches the exceptions list in the packaging > guidelines rather than default mock configuration that pulls in lots of > extra packages. So these build failures are mostly due to missing > buildreqs of things like perl(XML::Parser), gettext, flex, etc. That is not the impression I got after looking at probably two dozen builds reports. Only a few were due to missing BR. Is this modified version of mock ready and available in Extras? From paul at city-fan.org Tue May 30 11:55:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 12:55:50 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530133344.5203a0bc.fedora@wir-sind-cool.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> <20060530133344.5203a0bc.fedora@wir-sind-cool.org> Message-ID: <447C32C6.8040806@city-fan.org> Michael Schwendt wrote: > On Tue, 30 May 2006 11:53:58 +0100, Paul Howarth wrote: > >> Michael Schwendt wrote: >>> On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote: >>> >>>> extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 >>>> Number failed to build: 176 >>>> Number expected to fail due to ExclusiveArch or ExcludeArch: 1 >>>> Leaving: 175 >>>> (there may be some duplicates if rawhide has 2 versions of a package) >>>> >>>> Of those expected to have worked... >>>> Without a bug filed: 173 >>>> ---------------------------------- >>>> abe >>>> alacarte >>>> amaya >>>> anjuta-gdl >>>> balsa >>> -snip- >>> >>> Note sure what the goal of this rebuild attempt is. Extras buildsys uses >>> mock for a long time. So every package in Extras has built successfully in >>> mock before. Most (if not all) of the rebuild failures you've caught here >>> are due to updates in Rawhide, such as compiler updates or API changes. >>> This report is misleading. >> No, it's because he's building the packages with the reduced build >> environment that closely matches the exceptions list in the packaging >> guidelines rather than default mock configuration that pulls in lots of >> extra packages. So these build failures are mostly due to missing >> buildreqs of things like perl(XML::Parser), gettext, flex, etc. > > That is not the impression I got after looking at probably two dozen > builds reports. Only a few were due to missing BR. You've looked at more than I have then. I've only looked at my own packages, two of which had missing buildreqss that I fixed in cvs before Matt's first "Extras" email, and one that had a missing buildreq that didn't actually cause a build failure. Having been through my own packages, I then looked at Matt's list and submitted bugs for the two listed packages that I'd done the original reviews for. Those were missing buildreqs too. > Is this modified version of mock ready and available in Extras? There's a new version in CVS that I believe behaves this way. Seth doesn't go for the "release early, release often" mantra though. The current Extras mock can quite easily be configured to use a minimal buildroot though. You just need to create a local "groups" repo. * In some convenient location, download the buildsys-macros packages from http://fedoraproject.org/buildgroups/development/YOURARCH/ * Create a minimal.xml file in the same directory, containing: build true Minimal Install bash bzip2 coreutils cpio diffutils fedora-release gcc gcc-c++ gzip make patch perl rpm-build redhat-rpm-config sed tar unzip buildsys-macros * Create the repo: $ createrepo -g minimal.xml . * Point your mock config at the local repo: [groups] name=groups #baseurl=http://fedoraproject.org/buildgroups/development/i386/ baseurl=file:///path/to/local/repo/YOURARCH/ That should do it. Paul. From fedora at leemhuis.info Tue May 30 11:56:14 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 30 May 2006 13:56:14 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530133344.5203a0bc.fedora@wir-sind-cool.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> <20060530133344.5203a0bc.fedora@wir-sind-cool.org> Message-ID: <1148990174.12983.21.camel@thl.ct.heise.de> Am Dienstag, den 30.05.2006, 13:33 +0200 schrieb Michael Schwendt: > On Tue, 30 May 2006 11:53:58 +0100, Paul Howarth wrote: > > Michael Schwendt wrote: > > > On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote: > > > > > >> extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006 > > >> Number failed to build: 176 > > >> Number expected to fail due to ExclusiveArch or ExcludeArch: 1 > > >> Leaving: 175 > > >> (there may be some duplicates if rawhide has 2 versions of a package) > > >> > > >> Of those expected to have worked... > > >> Without a bug filed: 173 > > >> ---------------------------------- > > >> abe > > >> alacarte > > >> amaya > > >> anjuta-gdl > > >> balsa > > > > > > -snip- > > > > > > Note sure what the goal of this rebuild attempt is. Extras buildsys uses > > > mock for a long time. So every package in Extras has built successfully in > > > mock before. Most (if not all) of the rebuild failures you've caught here > > > are due to updates in Rawhide, such as compiler updates or API changes. > > > This report is misleading. > > > > No, it's because he's building the packages with the reduced build > > environment that closely matches the exceptions list in the packaging > > guidelines rather than default mock configuration that pulls in lots of > > extra packages. See https://www.redhat.com/archives/fedora-devel-list/2006-May/msg00807.html for further details. [...] > Is this modified version of mock ready and available in Extras? No modified version is required. mdomsch simply uses a local version of the data at http://fedoraproject.org/buildgroups/ e.g. a trimmed down version of http://fedoraproject.org/buildgroups/5/i386/buildroots.xml CU thl From skvidal at linux.duke.edu Tue May 30 12:05:34 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 30 May 2006 08:05:34 -0400 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <447C32C6.8040806@city-fan.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> <20060530133344.5203a0bc.fedora@wir-sind-cool.org> <447C32C6.8040806@city-fan.org> Message-ID: <1148990734.28729.52.camel@cutter> On Tue, 2006-05-30 at 12:55 +0100, Paul Howarth wrote: > There's a new version in CVS that I believe behaves this way. Seth > doesn't go for the "release early, release often" mantra though. Umm, what? Why don't you NOT speak for me, okay? I took the weekend off to do non-work things this weekend. For the last 2 weeks we've been getting patches in and it's nice to make sure we're not pushing out something terribly broken. everything Matt is using is checked into mock cvs in the public fedora cvs tree. -sv From paul at city-fan.org Tue May 30 12:05:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 May 2006 13:05:50 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <1148990734.28729.52.camel@cutter> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> <20060530133344.5203a0bc.fedora@wir-sind-cool.org> <447C32C6.8040806@city-fan.org> <1148990734.28729.52.camel@cutter> Message-ID: <447C351E.1000903@city-fan.org> seth vidal wrote: > On Tue, 2006-05-30 at 12:55 +0100, Paul Howarth wrote: >> There's a new version in CVS that I believe behaves this way. Seth >> doesn't go for the "release early, release often" mantra though. > > Umm, what? Why don't you NOT speak for me, okay? > > I took the weekend off to do non-work things this weekend. For the last > 2 weeks we've been getting patches in and it's nice to make sure we're > not pushing out something terribly broken. > > everything Matt is using is checked into mock cvs in the public fedora > cvs tree. None of what you've just written contradicts what I wrote. I never said that not releasing after every cvs commit was a bad thing. Chill a bit, eh? Paul. From fedora at wir-sind-cool.org Tue May 30 12:34:08 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 30 May 2006 14:34:08 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530125823.4b56627d@python2> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <20060530125823.4b56627d@python2> Message-ID: <20060530143408.6219512a.fedora@wir-sind-cool.org> On Tue, 30 May 2006 12:58:23 +0200, Matthias Saou wrote: > I've > checked the failure of one of my packages (lighttpd), and found out > that it's because pkgconfig wasn't installed. Typically something > simple that we need to reach consensus on (and probably a package > somewhere providing a .pc file but not requiring pkgconfig). All -devel packages, which contain .pc files, must require pkgconfig. Yes, all of those. Including those libraries, which can be used conveniently without querying pkg-config. And especially those libraries which store headers in a versioned non-standard path, which is unlikely to be found without querying pkg-config. The rationale is simple. Many configure checks fail in non-obvious ways if pkg-config is not installed. If there is no dependency on pkgconfig it is too easy to either miss it or uninstall it. And in that case it would need to become a BuildRequires, which in turn would "solve" the problem at the wrong place. Additionally, -devel packages which don't get it right often break the .pc file dependency chain, so that is the place where to fix the "Requires". From Matt_Domsch at dell.com Tue May 30 12:44:07 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 30 May 2006 07:44:07 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2006-05-30 Message-ID: <20060530124407.GA20646@lists.us.dell.com> Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information. Core Rawhide-in-Mock Build Results for x86_64 Tue May 30 07:00:52 CDT 2006 Number failed to build: 316 Number expected to fail due to ExclusiveArch or ExcludeArch: 26 Leaving: 290 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 49 ---------------------------------- SDL Xaw3d automake15 automake16 boost elilo emacs kdeaccessibility libmusicbrainz openmotif pcmciautils perl pirut pkgconfig pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm sgml-common specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans xmlsec1 xmlto xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 241 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] a2ps ['193345 CLOSED', '193346 NEW'] am-utils ['193347 ASSIGNED'] aqbanking ['193348 CLOSED'] arts ['192367 NEEDINFO'] at-spi ['192368 CLOSED'] atk ['193349 NEW'] authd ['193350 CLOSED'] autorun ['193351 CLOSED'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] busybox ['193354 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 NEW'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] f-spot ['193364 NEW'] fbset ['193362 CLOSED'] file-roller ['193363 NEW'] frysk ['192256 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] gimp ['193368 NEW'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 CLOSED'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-keyring ['193377 CLOSED'] gnome-keyring-manager ['193378 CLOSED'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-user-share ['193391 CLOSED'] gnome-utils ['191757 CLOSED'] gnome-vfs2 ['193392 NEW'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gob2 ['193395 NEW'] grub ['192504 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] hwbrowser ['193400 NEW'] indent ['193401 NEW'] inn ['193402 CLOSED'] iproute ['193403 CLOSED'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libIDL ['193419 NEW'] libSM ['193421 NEW'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] libXres ['193502 NEW'] libXt ['193503 NEW'] libXtst ['193504 NEW'] libXv ['193505 NEW'] libXvMC ['193506 NEW'] libXxf86dga ['193507 NEW'] libXxf86misc ['193508 NEW'] libXxf86vm ['193509 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 MODIFIED'] libgtop2 ['193418 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] linux-atm ['193510 CLOSED'] lm_sensors ['193511 NEW'] lrzsz ['193513 NEW'] lynx ['193515 NEW'] m17n-lib ['193524 ASSIGNED'] magma-plugins ['193525 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] ncpfs ['193526 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] policycoreutils ['193537 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] qt ['191895 CLOSED'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 ASSIGNED'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ ----- End forwarded message ----- -- 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 Matt_Domsch at dell.com Tue May 30 12:44:44 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 30 May 2006 07:44:44 -0500 Subject: Core i386 rawhide rebuild in mock status 2006-05-30 Message-ID: <20060530124444.GB20646@lists.us.dell.com> Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information. Core Rawhide-in-Mock Build Results for i386 Tue May 30 07:02:17 CDT 2006 Number failed to build: 302 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 293 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 44 ---------------------------------- SDL Xaw3d automake15 automake16 emacs openmotif pcmciautils pirut pkgconfig prelink pump pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm sg3_utils specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans xmlsec1 xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 249 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] a2ps ['193345 CLOSED', '193346 NEW'] am-utils ['193347 ASSIGNED'] aqbanking ['193348 CLOSED'] arts ['192367 NEEDINFO'] at-spi ['192368 CLOSED'] atk ['193349 NEW'] authd ['193350 CLOSED'] autorun ['193351 CLOSED'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] busybox ['193354 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 NEW'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] f-spot ['193364 NEW'] fbset ['193362 CLOSED'] file-roller ['193363 NEW'] frysk ['192256 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 NEW'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] gimp ['193368 NEW'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 CLOSED'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-keyring ['193377 CLOSED'] gnome-keyring-manager ['193378 CLOSED'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-user-share ['193391 CLOSED'] gnome-utils ['191757 CLOSED'] gnome-vfs2 ['193392 NEW'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gob2 ['193395 NEW'] gpart ['193396 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] hwbrowser ['193400 NEW'] indent ['193401 NEW'] inn ['193402 CLOSED'] iproute ['193403 CLOSED'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libIDL ['193419 NEW'] libSM ['193421 NEW'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] libXres ['193502 NEW'] libXt ['193503 NEW'] libXtst ['193504 NEW'] libXv ['193505 NEW'] libXvMC ['193506 NEW'] libXxf86dga ['193507 NEW'] libXxf86misc ['193508 NEW'] libXxf86vm ['193509 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 MODIFIED'] libgtop2 ['193418 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] linux-atm ['193510 CLOSED'] lm_sensors ['193511 NEW'] longrun ['193512 NEW'] lrzsz ['193513 NEW'] lynx ['193515 NEW'] m17n-lib ['193524 ASSIGNED'] magma-plugins ['193525 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] ncpfs ['193526 NEW'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 NEW'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] planner ['191808 CLOSED'] policycoreutils ['193537 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 ASSIGNED'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vixie-cron ['191823 ASSIGNED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fbdev ['192325 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vesa ['192359 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] xorg-x11-xdm ['191858 ASSIGNED'] xorg-x11-xfs ['191856 ASSIGNED'] xorg-x11-xfwp ['191813 ASSIGNED'] xorg-x11-xsm ['191802 ASSIGNED'] xscreensaver ['191769 NEW'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 vonbrand at inf.utfsm.cl Tue May 30 12:47:51 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 30 May 2006 08:47:51 -0400 Subject: Reporting bugs upstream In-Reply-To: Your message of "Tue, 30 May 2006 13:17:20 +0200." <20060530131720.cc793008.fedora@wir-sind-cool.org> Message-ID: <200605301247.k4UClptQ003703@laptop11.inf.utfsm.cl> Michael Schwendt wrote: > On Fri, 20 Jan 2006 05:37:40 -0500, Mike A. Harris wrote: > > > I propose that it be a policy that Fedora maintainers are themselves > > > responsible for forwarding the bug upsteam if necessary. > > Good proposal. > > > That does sometimes happen, but it is not something a bug reporter > > should expect to happen. Red Hat engineering manpower is a limited > > resource, and our man hours are prioritized across quite a number > > of tasks. The amount of work that any given engineer "has" to do, > > plus the amount of work that they could "potentially" do (such as > > various random bugzilla bug reports), plus various meetings, and > > other things that fill the day, is generally many times more than > > the hours available. > > Have you ever before thought about this from the user's perspective? [...] > As a user, being confronted with "just another feature-overloaded bug > tracker" which contains many new and poorly named and insufficiently > described "products" and "components" and hundreds of open bug reports, it > is a very frustrating experience to spend time on _trying_ to help by > reporting something upstream only to learn that the report is ignored or > closed as duplicate or closed as NOTOURBUG or not been looked at for > many months. Why not adopt some packages, and help out by keeping an eye on bugzilla for them, trying to reproduce bugs, and kick them upstream as needed? That way you don't have to learn about many upstream bug trackers, just a few. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From sundaram at fedoraproject.org Tue May 30 12:50:02 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 30 May 2006 18:20:02 +0530 Subject: Reporting bugs upstream In-Reply-To: <200605301247.k4UClptQ003703@laptop11.inf.utfsm.cl> References: <200605301247.k4UClptQ003703@laptop11.inf.utfsm.cl> Message-ID: <1148993402.4310.843.camel@sundaram.pnq.redhat.com> On Tue, 2006-05-30 at 08:47 -0400, Horst von Brand wrote: > Michael Schwendt wrote: > > As a user, being confronted with "just another feature-overloaded bug > > tracker" which contains many new and poorly named and insufficiently > > described "products" and "components" and hundreds of open bug reports, it > > is a very frustrating experience to spend time on _trying_ to help by > > reporting something upstream only to learn that the report is ignored or > > closed as duplicate or closed as NOTOURBUG or not been looked at for > > many months. > > Why not adopt some packages, and help out by keeping an eye on bugzilla for > them, trying to reproduce bugs, and kick them upstream as needed? That way > you don't have to learn about many upstream bug trackers, just a few. > -- If anyone is interested in that, http://fedoraproject.org/wiki/BugZappers Rahul From fedora at nodata.co.uk Tue May 30 13:01:10 2006 From: fedora at nodata.co.uk (nodata) Date: Tue, 30 May 2006 15:01:10 +0200 (CEST) Subject: Reporting bugs upstream In-Reply-To: <1148993402.4310.843.camel@sundaram.pnq.redhat.com> References: <200605301247.k4UClptQ003703@laptop11.inf.utfsm.cl> <1148993402.4310.843.camel@sundaram.pnq.redhat.com> Message-ID: <29254.213.164.3.90.1148994070.squirrel@www.nodata.co.uk> > On Tue, 2006-05-30 at 08:47 -0400, Horst von Brand wrote: >> Michael Schwendt wrote: > >> > As a user, being confronted with "just another feature-overloaded bug >> > tracker" which contains many new and poorly named and insufficiently >> > described "products" and "components" and hundreds of open bug >> reports, it >> > is a very frustrating experience to spend time on _trying_ to help by >> > reporting something upstream only to learn that the report is ignored >> or >> > closed as duplicate or closed as NOTOURBUG or not been looked at for >> > many months. >> >> Why not adopt some packages, and help out by keeping an eye on bugzilla >> for >> them, trying to reproduce bugs, and kick them upstream as needed? That >> way >> you don't have to learn about many upstream bug trackers, just a few. >> -- > > If anyone is interested in that, > http://fedoraproject.org/wiki/BugZappers > > Rahul Isn't this a workaround for bugzilla lacking an easy way to move bugs upstream? Wasn't the XML RPC interface meant to solve this? From sundaram at fedoraproject.org Tue May 30 13:04:27 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 30 May 2006 18:34:27 +0530 Subject: Reporting bugs upstream In-Reply-To: <29254.213.164.3.90.1148994070.squirrel@www.nodata.co.uk> References: <200605301247.k4UClptQ003703@laptop11.inf.utfsm.cl> <1148993402.4310.843.camel@sundaram.pnq.redhat.com> <29254.213.164.3.90.1148994070.squirrel@www.nodata.co.uk> Message-ID: <1148994267.4310.849.camel@sundaram.pnq.redhat.com> On Tue, 2006-05-30 at 15:01 +0200, nodata wrote: > > On Tue, 2006-05-30 at 08:47 -0400, Horst von Brand wrote: > >> Michael Schwendt wrote: > > > >> > As a user, being confronted with "just another feature-overloaded bug > >> > tracker" which contains many new and poorly named and insufficiently > >> > described "products" and "components" and hundreds of open bug > >> reports, it > >> > is a very frustrating experience to spend time on _trying_ to help by > >> > reporting something upstream only to learn that the report is ignored > >> or > >> > closed as duplicate or closed as NOTOURBUG or not been looked at for > >> > many months. > >> > >> Why not adopt some packages, and help out by keeping an eye on bugzilla > >> for > >> them, trying to reproduce bugs, and kick them upstream as needed? That > >> way > >> you don't have to learn about many upstream bug trackers, just a few. > >> -- > > > > If anyone is interested in that, > > http://fedoraproject.org/wiki/BugZappers > > > > Rahul > > Isn't this a workaround for bugzilla lacking an easy way to move bugs > upstream? Wasn't the XML RPC interface meant to solve this? Upstream projects use different versions of bugzilla and various other bug tracking systems. There isnt a universal method of doing it automatically. In some cases XML RPC does help. Rahul From fedora at nodata.co.uk Tue May 30 13:07:17 2006 From: fedora at nodata.co.uk (nodata) Date: Tue, 30 May 2006 15:07:17 +0200 (CEST) Subject: Reporting bugs upstream In-Reply-To: <1148994267.4310.849.camel@sundaram.pnq.redhat.com> References: <200605301247.k4UClptQ003703@laptop11.inf.utfsm.cl> <1148993402.4310.843.camel@sundaram.pnq.redhat.com> <29254.213.164.3.90.1148994070.squirrel@www.nodata.co.uk> <1148994267.4310.849.camel@sundaram.pnq.redhat.com> Message-ID: <14406.213.164.3.90.1148994437.squirrel@www.nodata.co.uk> > On Tue, 2006-05-30 at 15:01 +0200, nodata wrote: >> > On Tue, 2006-05-30 at 08:47 -0400, Horst von Brand wrote: >> >> Michael Schwendt wrote: >> > >> >> > As a user, being confronted with "just another feature-overloaded >> bug >> >> > tracker" which contains many new and poorly named and >> insufficiently >> >> > described "products" and "components" and hundreds of open bug >> >> reports, it >> >> > is a very frustrating experience to spend time on _trying_ to help >> by >> >> > reporting something upstream only to learn that the report is >> ignored >> >> or >> >> > closed as duplicate or closed as NOTOURBUG or not been looked at >> for >> >> > many months. >> >> >> >> Why not adopt some packages, and help out by keeping an eye on >> bugzilla >> >> for >> >> them, trying to reproduce bugs, and kick them upstream as needed? >> That >> >> way >> >> you don't have to learn about many upstream bug trackers, just a few. >> >> -- >> > >> > If anyone is interested in that, >> > http://fedoraproject.org/wiki/BugZappers >> > >> > Rahul >> >> Isn't this a workaround for bugzilla lacking an easy way to move bugs >> upstream? Wasn't the XML RPC interface meant to solve this? > > Upstream projects use different versions of bugzilla and various other > bug tracking systems. So if upstream uses bugzilla (like kernel and Gnome do), is this possible? > There isnt a universal method of doing it > automatically. In some cases XML RPC does help. > > Rahul So I guess this is being worked on? From skvidal at linux.duke.edu Tue May 30 13:23:05 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 30 May 2006 09:23:05 -0400 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <447C351E.1000903@city-fan.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> <20060530133344.5203a0bc.fedora@wir-sind-cool.org> <447C32C6.8040806@city-fan.org> <1148990734.28729.52.camel@cutter> <447C351E.1000903@city-fan.org> Message-ID: <1148995386.31949.3.camel@cutter> On Tue, 2006-05-30 at 13:05 +0100, Paul Howarth wrote: > None of what you've just written contradicts what I wrote. I never said > that not releasing after every cvs commit was a bad thing. Chill a bit, eh? Actually it does, I have no objection to release early, release often, and if you knew anything about me you'd know that. My problem is with releasing a broken piece of critical infrastructure. I will not chill about anyone speaking for me or casting aspersions on MY actions. Do not speak for me, in any forum, ever again. To not make claims about what I will or will not do. -sv From smooge at gmail.com Tue May 30 14:22:32 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 30 May 2006 08:22:32 -0600 Subject: 2MB flash space Message-ID: <80d7e4090605300722y43662b06ye85f703e0f212492@mail.gmail.com> On 5/29/06, Callum Lerwick wrote: > On Wed, 2006-05-24 at 10:08 -0500, Chris Adams wrote: > > Once upon a time, Bernardo Innocenti said: > > > What's wrong with GPL programs using the Mozilla implementation? > > > Last time I checked NSS was totally GPL compatible. > > > > mozilla-nss requires mozilla-nspr. libnss3.so also pulls in > > libpthread.so. Those are pretty heavy requirements for SSL. > > Even OpenSSL is so bloaty that the smallest I can get it down to (on > MIPS, who's code size seem to be about 2x i386) is 1.5mb. Making it > impossible to fit into the 2mb flash on a belkin router. Sigh. > > There's MatrixSSL, but there's next to nothing that actually uses it... > What do you want to do in 2MB? I mean in that space I doubt you could get many encryption algorithm beyond 1 or 2 ( one for key exchange, one for cipher). At that size point, I would just look for whatever encryptions are in the kernel source code and use those all the time. -- Stephen J Smoogen. CSIRT/Linux System Administrator From david.jamison1 at ntlworld.com Tue May 30 17:08:13 2006 From: david.jamison1 at ntlworld.com (David) Date: Tue, 30 May 2006 18:08:13 +0100 Subject: Obtaining a Fedora Account Message-ID: <447C7BFD.5020906@ntlworld.com> Hi Folks, I filled in the appropriate details on http://fedoraproject.org/wiki/Infrastructure/AccountSystem/NewAccount a couple of weeks back. I havent heard anything back as yet. Is there any way of finding out what the position with this application of mine? Cheers David From icon at fedoraproject.org Tue May 30 20:13:25 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 30 May 2006 16:13:25 -0400 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <1148995386.31949.3.camel@cutter> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <447C2446.8010506@city-fan.org> <20060530133344.5203a0bc.fedora@wir-sind-cool.org> <447C32C6.8040806@city-fan.org> <1148990734.28729.52.camel@cutter> <447C351E.1000903@city-fan.org> <1148995386.31949.3.camel@cutter> Message-ID: On 5/30/06, seth vidal wrote: > I will not chill about anyone speaking for me or casting aspersions on > MY actions. Do not speak for me, in any forum, ever again. To not make > claims about what I will or will not do. Seth doesn't go for the "pussy-footing around" or "beating about the bush" mantras, that's for certain. ;) -- Konstantin Ryabitsev Montr?al, Qu?bec From ajackson at redhat.com Tue May 30 20:27:46 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 30 May 2006 16:27:46 -0400 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <1148947303.22592.33.camel@localhost> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> <4474F1F1.10805@mharris.ca> <1148947303.22592.33.camel@localhost> Message-ID: <447CAAC2.8050305@redhat.com> Callum Lerwick wrote: > On Wed, 2006-05-24 at 19:53 -0400, Mike A. Harris wrote: >> I can't guess how many users use nedit, but emacs >> and mplayer have a massive userbase. > > And thus have plenty of motivation, and available manpower with which to > port them over to using Xft. > > GVIM and Xine have been using GTK2/Xft for some time now. (Warning: > Contains flamebait.) > > Fiddling around with compatibility layers, or trying to get the X server > itself to handle fonts rather than xfs, is a waste of effort better put > towards simply porting apps over to using Xft. > > Either we put our foot down, and completely rip out core fonts now, or > we leave it as is and have this argument yet again during FC7 devel... We can not delete core font support. Full stop. Anyway it turns out this is a lot of noise over nothing, it's not looking too difficult to fontconfigify libXfont, which will solve the problem for xfs and all the X servers all at once. So I'm just going to fix the real bug now, and you're all going to stop bikeshedding, k? - ajax From buildsys at redhat.com Wed May 31 07:52:53 2006 From: buildsys at redhat.com (Build System) Date: Wed, 31 May 2006 03:52:53 -0400 Subject: rawhide report: 20060531 changes Message-ID: <200605310752.k4V7qqah024883@porkchop.devel.redhat.com> New package openCryptoki Implementation of Cryptoki v2.11 for IBM Crypto Hardware New package s390utils Linux/390 specific utilities. Removed package xscreensaver Updated Packages: a2ps-4.13b-51 ------------- * Tue May 30 2006 Tim Waugh 4.13b-51 - Build requires gettext (bug #193346). anaconda-11.1.0.23-1 -------------------- * Tue May 30 2006 Chris Lumens 11.1.0.23-1 - Require glib2-devel. - Look for libglib in the right place on 64-bit machines. * Tue May 30 2006 Chris Lumens 11.1.0.22-1 - Fix going back in the UI. - Don't try to mount protected partitions twice. - Hook up new netlink code, debugging (dcantrell). - Package is actually named pyobject2 (katzj). aqbanking-1.8.1beta-4 --------------------- * Tue May 30 2006 Bill Nottingham - 1.8.1beta-4 - add gettext buildreq (#193348) authd-1.4.3-8 ------------- * Sun May 28 2006 Martin Stransky - 1.4.3-8 - added gettext dependency (#193350) autofs-1:5.0.0_beta3-6 ---------------------- * Mon May 29 2006 Ian Kent - 5.0.0_beta3-6 - add back test for nested mount in program map lookup. - I must have commented this out for a reason. I guess we'll find out soon enough. * Mon May 29 2006 Ian Kent - 5.0.0_beta3-5 - fix handling of autofs filesystem mount fail on init. avahi-0.6.10-1.FC6 ------------------ * Tue May 30 2006 Jason Vas Dias - 0.6.10-1.FC6 - Upgrade to upstream version 0.6.10 - fix bug 192080: split avahi-compat-libdns_sd into separate package (same goes for avahi-compat-howl) busybox-1:1.1.2-3 ----------------- * Mon May 29 2006 Ivana Varekova -1:1.1.2-3 - fix Makefile typo (#193354) cdrtools-8:2.01.01.0.a09-1 -------------------------- * Mon May 29 2006 Harald Hoyer 8:2.01.01.0.a09-1 - version 2.01.01a09 control-center-1:2.14.2-2 ------------------------- * Mon May 29 2006 Matthias Clasen - 2.14.2-2 - Update to 2.14.2 dhcdbd-1.15-1.FC6 ----------------- * Tue May 30 2006 Jason Vas Dias - 1.15-1.FC6 - fix bug 193562: remove 'servicedir' entry from dhcdbd.conf dhcp-12:3.0.4-12 ---------------- * Tue May 30 2006 Jason Vas Dias - 12:3.0.4-12 - Make -R option take effect in per-interface client configs dovecot-1.0-0.beta8.1 --------------------- * Thu May 04 2006 Petr Rockai - 1.0-0.beta8.1 - upgrade to latest upstream beta release (beta8) - contains a security fix in mbox handling elinks-0.11.1-2 --------------- * Mon May 29 2006 Karel Zak 0.11.1-2 - update to new upstream version ethereal-1.1.0-0.svn.1 ---------------------- * Mon May 29 2006 Radek Vokal 1.1.0-0.svn.1 - update to latest svn version, 1.1.0 pre-release evolution-2.7.2.1-4 ------------------- * Mon May 29 2006 Dan Williams - 2.7.2.1-4 - Don't crash on quit when trying to save window size (Gnome.org #343331) * Tue May 23 2006 Matthew Barnes 2.7.2.1-3 - Port evolution-2.7.1-notification-cleanups.patch to new libnotify API. - Require libnotify >= 0.4. * Fri May 19 2006 Matthew Barnes - 2.7.2.1-2 - Require specific versions of GNU Autotools packages for building. - Add evolution-2.7.2-preedit-gnome.bz-264485.patch (Mayank Jain). - Various spec file cleanups. - Pick up new libnotify. evolution-data-server-1.7.2-2 ----------------------------- * Sat May 27 2006 Matthew Barnes - 1.7.2-2 - Add missing BuildRequires for gettext (#193360). file-roller-2.14.3-2 -------------------- * Mon May 29 2006 Matthias Clasen - 2.14.3-2 - Update to 2.14.3 * Tue Apr 18 2006 Matthias Clasen - 2.14.2-3 - Remove dot from summary firstboot-1.4.10-1 ------------------ * Fri May 26 2006 Chris Lumens 1.4.10-1 - Fix reconfig mode. g-wrap-1.9.6-7 -------------- * Tue May 30 2006 Bill Nottingham 1.9.6-5 - move ffi headers to %{_libdir}, as they're arch-dependent (#192685) - buildprereq glib2-devel, not glib-devel gnome-applets-1:2.14.2-2 ------------------------ * Sun May 28 2006 Matthias Clasen - 2.14.2-2 - Update to 2.14.2 gnome-bluetooth-0.7.0-5 ----------------------- * Tue May 30 2006 Harald Hoyer - 0.7.0-5 - install schemata correctly (bug #193518) gnome-keyring-0.4.9-2 --------------------- * Mon May 29 2006 Alexander Larsson - 0.4.9-2 - buildrequire gettext (#193377) gnome-keyring-manager-2.14.0-2 ------------------------------ * Mon May 29 2006 Alexander Larsson - 2.14.0-2 - buildrequire gettext and perl-XML-Parser - Fixed summary (#151022) gnome-panel-2.14.2-2 -------------------- * Mon May 29 2006 Matthias Clasen - 2.14.2-2 - Update to 2.14.2 - Drop upstreamed patches gnome-python2-desktop-2.15.2-1 ------------------------------ * Tue May 30 2006 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 - Add subpackages gnome-python2-rsvg and gnome-python2-gnomedesktop gnome-terminal-2.15.1-2 ----------------------- * Mon May 29 2006 Kristian H??gsberg - 2.15.1-2 - Update transparency patch to use gdk_screen_is_composited(). gnome-user-share-0.10-3 ----------------------- * Mon May 29 2006 Alexander Larsson - 0.10-3 - buildrequire gettext and perl-XML-Parser (#193391) gnome-vfs2-2.15.1-2 ------------------- * Mon May 29 2006 Alexander Larsson - 2.15.1-2 - buildrequires gettext (#193392) gob2-2.0.14-1 ------------- * Mon May 29 2006 Harald Hoyer - 2.0.14-1 - more build requires (bug #193395) - new version 2.0.14 inn-2.4.3-2 ----------- * Sun May 28 2006 Martin Stransky 2.4.3-2 - file conflicts for inn (#192689) - added byacc to dependencies (#193402) iproute-2.6.16-2 ---------------- * Sun May 28 2006 Radek Vok??l - 2.6.16-2 - fix BuildRequires: flex (#193403) kasumi-2.0-1.fc6 ---------------- * Tue May 30 2006 Akira TAGOH - 2.0-1 - New upstream release. kernel-2.6.16-1.2232_FC6 ------------------------ * Tue May 30 2006 Dave Jones - Fix up CFQ locking bug. - 2.6.17rc5-git6 libgsf-1.14.1-4 --------------- * Mon May 29 2006 Caolan McNamara 1.14.1-4 - rh#193417# Add BuildRequires perl-XML-Parser libselinux-1.30.10-4 -------------------- * Fri May 26 2006 Dan Walsh 1.30.10-4 - Remove getseuser libsepol-1.12.14-1 ------------------ * Tue May 30 2006 Dan Walsh 1.12.14-1 - Upgrade to latest from NSA * Fixed bool_ids overflow bug in cond_node_find and cond_copy_list, based on bug report and suggested fix by Cedric Roux. * Merged sens_copy_callback, check_role_hierarchy_callback, and node_from_record fixes from Serge Hallyn. libusb-0.1.12-3 --------------- * Tue May 30 2006 Jindrich Novy 0.1.12-3 - use pkg-config calls in libusb-config instead of hardcoded defaults to avoid multiarch conflicts (#192714) linux-atm-2.5.0-0.20050118.3.3 ------------------------------ * Tue May 30 2006 David Woodhouse - 2.5.0-0.20050118.3.3 - BuildRequires: byacc lynx-2.8.5-28 ------------- * Tue May 30 2006 Ivana Varekova - 2.8.5-28 - add buildreq gettext (#193515) mc-1:4.6.1a-16 -------------- * Mon May 29 2006 Jindrich Novy 4.6.1a-16 - fix the free space widget patch: stat()s filesystem less frequently, display correct info in all circumstances * Wed May 17 2006 Jindrich Novy 4.6.1a-15 - update from CVS - drop .fish-upload patch, applied upstream - sync .showfree patch * Fri Apr 28 2006 Jindrich Novy 4.6.1a-14 - don't reread panel contents while in panelized mode (#188438) mesa-6.5-8 ---------- * Mon May 29 2006 Kristian H??gsberg 6.5-8 - Bump for rawhide build. * Mon May 29 2006 Kristian H??gsberg 6.5-7 - Update mesa-6.5-texture-from-pixmap-fixes.patch to include new tokens and change tfp functions to return void. Yes, a new mesa snapshot would be nice. metacity-2.15.3-4 ----------------- * Tue May 30 2006 Kristian H??gsberg 2.15.3-4 - Bump for rawhide build. * Mon May 29 2006 Kristian H??gsberg - 2.15.3-3 - Bump libGL build requires so libcm picks up the right tfp tokens. mkinitrd-5.0.41-3 ----------------- * Tue May 30 2006 Peter Jones - 5.0.41-3 - rebuild on all arches * Sat May 27 2006 Peter Jones - 5.0.41-2 - fix "stabilized" to actually stat where appropriate - use stabilized for sbp2 (firewire) as well nautilus-cd-burner-2.15.2-3 --------------------------- * Mon May 29 2006 Alexander Larsson - 2.15.2-3 - Fix schema name (#193325) parted-1.7.1-3 -------------- * Sun May 28 2006 David Cantrell - 1.7.1-3 - Rebuild * Sun May 28 2006 David Cantrell - 1.7.1-2 - Removed mac-swraid patch (added upstream) - Updated device-mapper patch for parted-1.7.1 * Sat May 27 2006 David Cantrell - 1.7.1-1 - Upgraded to parted-1.7.1 pyparted-1.7.1-1 ---------------- * Sun May 28 2006 David Cantrell - 1.7.1-1 - Bump version to 1.7.1 and require parted >= 1.7.1 screen-4.0.2-14 --------------- * Tue May 30 2006 Petr Rockai - 4.0.2-14 - put /usr/share/screen into the package (so the package owns the directory as well, not only the files below); fixes BR 192852 squid-7:2.5.STABLE13-5 ---------------------- * Sun May 28 2006 Martin Stransky - 7:2.5.STABLE13-5 - fixed libbind patch (#193298) sudo-1.6.8p12-6 --------------- * Mon May 29 2006 Karel Zak 1.6.8p12-6 - fix #190062 - "ssh localhost sudo su" will show the password in clear system-config-printer-0.7.10-2 ------------------------------ * Sat May 27 2006 Tim Waugh 0.7.10-2 - Requires gobject2 (bug #192764). tcpdump-14:3.9.4-4 ------------------ * Mon May 29 2006 Martin Stransky - 14:3.9.4-4 - added libpcap-devel package (#193189) vim-2:7.0.017-1 --------------- * Tue May 30 2006 Karsten Hopp 7.0.017-1 - patchlevel 17, although it affects just the Motif version - own some directories (#192787) vixie-cron-4:4.1-55.FC6 ----------------------- * Tue May 30 2006 Jason Vas Dias - 4:4.1-55.FC6 - fix bug 191823: fix missing BuildRequires: audit-libs-devel vte-0.13.1-3 ------------ * Sun May 28 2006 Stepan Kasal - 0.13.1-3 - Fix the URL of Source:. * Tue May 23 2006 Matthias Clasen 0.13.1-2 - Make it build in mock xdelta-1.1.3-19 --------------- * Tue May 30 2006 Ludek Smid 1.1.3-19 - libtoolize and autotools are now run during build phase - resolved multilib conflict using pkgconfig tool xmlrpc-0:2.0.1-1jpp_6fc ----------------------- * Mon Mar 06 2006 Jeremy Katz - 0:2.0.1-1jpp_6fc - stop scriptlet spew * Fri Feb 24 2006 Igor Foox - 0:2.0.1-1jpp_5fc - Added post/postun dependency on coreutils. * Fri Feb 10 2006 Jesse Keating - 0:2.0.1-1jpp_4fc - bump again for double-long bug on ppc(64) xorg-x11-drv-fbdev-0.3.0-1 -------------------------- * Tue May 23 2006 Adam Jackson 0.3.0-1 - Update to 0.3.0 from 7.1. xorg-x11-drv-vesa-1.2.0-1 ------------------------- * Tue May 30 2006 Adam Jackson 1.2.0-1 - Update to 1.2.0 from 7.1. xorg-x11-xdm-1:1.0.4-2 ---------------------- * Tue May 30 2006 Adam Jackson 1:1.0.4-2 - Fix BuildRequires (#191858) xorg-x11-xfs-1:1.0.2-2 ---------------------- * Tue May 30 2006 Adam Jackson 1:1.0.2-2 - Fix BuildRequires (#191856). xorg-x11-xfwp-1.0.1-2 --------------------- * Tue May 30 2006 Adam Jackson 1.0.1-2 - Fix BuildRequires (#191813) and add some LBX avoidance. * Fri Feb 10 2006 Jesse Keating 1.0.1-1.2 - bump again for double-long bug on ppc(64) * Tue Feb 07 2006 Jesse Keating 1.0.1-1.1 - rebuilt for new gcc4.1 snapshot and glibc changes xorg-x11-xsm-1.0.2-2 -------------------- * Tue May 30 2006 Adam Jackson 1.0.2-2 - Fix BuildRequires (#191802) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 GFS-kernel-smp - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5smp GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.i686 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 cman-kernel-smp - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5smp cman-kernel-xen0 - 2.6.15.1-0.FC5.21.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 dlm-kernel-smp - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5smp dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.i686 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires kernel-smp = 0:2.6.16-1.2122_FC5 gnbd-kernel-smp - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5smp gnbd-kernel-xen0 - 2.6.15-5.FC5.28.i686 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.i686 requires /lib/modules/2.6.16-1.2122_FC5xenU kdeartwork - 3.5.2-1.i386 requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.i386 requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.i386 requires libstdc++-devel = 0:4.1.0 Broken deps for s390 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 kdeartwork - 3.5.2-1.s390 requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.s390 requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.s390 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.s390 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.s390 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390 requires tomcat5 systemtap - 0.5.5-2.s390 requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390 requires servletapi5 xmlrpc - 2.0.1-1jpp_6fc.s390 requires servletapi5 Broken deps for ppc64 ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_7fc.ppc64 requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.ppc64 requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 kdeartwork - 3.5.2-1.ppc64 requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.ppc64 requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc64 requires libstdc++-devel = 0:4.1.0 struts - 1.2.8-2jpp_9fc.ppc64 requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.ppc64 requires tomcat5 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.ppc64 requires servletapi5 Broken deps for s390x ---------------------------------------------------------- avalon-logkit - 1.2-3jpp_3fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_2fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_7fc.s390x requires servletapi5 hsqldb - 1.80.1-1jpp_8fc.s390x requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_5fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_3fc.noarch requires servletapi5 >= 0:5.0.16 kdeartwork - 3.5.2-1.s390x requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.s390x requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.s390x requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.s390x requires libstdc++-devel = 0:4.1.0 openCryptoki - 2.2.4-1.s390x requires PKCS11_ICA.so openCryptoki - 2.2.4-1.s390x requires PKCS11_API.so struts - 1.2.8-2jpp_9fc.s390x requires servletapi5 struts-webapps-tomcat5 - 1.2.8-2jpp_9fc.s390x requires tomcat5 systemtap - 0.5.5-2.s390x requires kernel >= 0:2.6.9-11 velocity - 1.4-3jpp_4fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-3jpp_9fc.s390x requires servletapi5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 GFS-kernel - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 GFS-kernel-xen0 - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 GFS-kernel-xenU - 2.6.15.1-5.FC5.22.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 cman-kernel - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 cman-kernel-xen0 - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 cman-kernel-xenU - 2.6.15.1-0.FC5.21.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 dlm-kernel - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 dlm-kernel-xen0 - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 dlm-kernel-xenU - 2.6.15.1-0.FC5.19.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires kernel = 0:2.6.16-1.2122_FC5 gnbd-kernel - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5 gnbd-kernel-xen0 - 2.6.15-5.FC5.28.x86_64 requires kernel-xen0 = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires kernel-xenU = 0:2.6.16-1.2122_FC5 gnbd-kernel-xenU - 2.6.15-5.FC5.28.x86_64 requires /lib/modules/2.6.16-1.2122_FC5xenU kdeartwork - 3.5.2-1.x86_64 requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.x86_64 requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.x86_64 requires libstdc++-devel = 0:4.1.0 Broken deps for ia64 ---------------------------------------------------------- kdeartwork - 3.5.2-1.ia64 requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.ia64 requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ia64 requires libstdc++-devel = 0:4.1.0 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- kdeartwork - 3.5.2-1.ppc requires xscreensaver-extras libpcap-devel - 14:0.9.4-4.ppc requires libpcap = 0:0.9.4 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires gcc-c++ = 0:4.1.0 libstdc++so7-devel - 4.2.0-0.6.20060428.ppc requires libstdc++-devel = 0:4.1.0 From stransky at redhat.com Wed May 31 09:56:58 2006 From: stransky at redhat.com (Martin Stransky) Date: Wed, 31 May 2006 11:56:58 +0200 Subject: new libpcap-devel package Message-ID: <447D686A.1090102@redhat.com> Hello guys, there is a new libpcap-devel package so please add proper BuildRequires to your packages. Thanks Martin From dtimms at bigpond.net.au Wed May 31 10:11:15 2006 From: dtimms at bigpond.net.au (David Timms) Date: Wed, 31 May 2006 20:11:15 +1000 Subject: Obtaining a Fedora Account In-Reply-To: <447C7BFD.5020906@ntlworld.com> References: <447C7BFD.5020906@ntlworld.com> Message-ID: <447D6BC3.1050104@bigpond.net.au> David wrote: > Hi Folks, > > I filled in the appropriate details on > http://fedoraproject.org/wiki/Infrastructure/AccountSystem/NewAccount a > couple of weeks back. > I havent heard anything back as yet. Is there any way of finding out > what the position with this application of mine? Did you receive the contributor license agreement ? You do need to make a digital signature and digitally sign this document. There is a lot of steps in this process, did you do them all eg. bugzilla account etc ? DaveT. From sundaram at fedoraproject.org Wed May 31 10:15:13 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 31 May 2006 15:45:13 +0530 Subject: RFC: Making the xfs font server optional in Fedora Core and its derivatives. In-Reply-To: <447CAAC2.8050305@redhat.com> References: <446FF7AB.30301@mharris.ca> <1148221387.1941.13.camel@dimi> <20060521143717.GA9482@lists.us.dell.com> <1148243982.8958.4.camel@rousalka.dyndns.org> <1148247151.1941.15.camel@dimi> <4471F9E2.4070106@mharris.ca> <5256d0b0605221102p782ee2a3naeecae37fcf26e4b@mail.gmail.com> <4471FFC8.4080503@mharris.ca> <447408AD.3090706@develer.com> <4474F1F1.10805@mharris.ca> <1148947303.22592.33.camel@localhost> <447CAAC2.8050305@redhat.com> Message-ID: <1149070513.4310.859.camel@sundaram.pnq.redhat.com> On Tue, 2006-05-30 at 16:27 -0400, Adam Jackson wrote: > Callum Lerwick wrote: > > On Wed, 2006-05-24 at 19:53 -0400, Mike A. Harris wrote: > >> I can't guess how many users use nedit, but emacs > >> and mplayer have a massive userbase. > > > > And thus have plenty of motivation, and available manpower with which to > > port them over to using Xft. > > > > GVIM and Xine have been using GTK2/Xft for some time now. (Warning: > > Contains flamebait.) > > > > Fiddling around with compatibility layers, or trying to get the X server > > itself to handle fonts rather than xfs, is a waste of effort better put > > towards simply porting apps over to using Xft. > > > > Either we put our foot down, and completely rip out core fonts now, or > > we leave it as is and have this argument yet again during FC7 devel... > > We can not delete core font support. Full stop. > > Anyway it turns out this is a lot of noise over nothing, it's not > looking too difficult to fontconfigify libXfont, which will solve the > problem for xfs and all the X servers all at once. So I'm just going to > fix the real bug now, and you're all going to stop bikeshedding, k? > > - ajax Deal. Rahul From kloczek at zie.pg.gda.pl Wed May 31 12:20:22 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 31 May 2006 14:20:22 +0200 Subject: Buildrequire: perl-XML-Parser (Was: Re: rawhide report: 20060531 changes) In-Reply-To: <200605310752.k4V7qqah024883@porkchop.devel.redhat.com> References: <200605310752.k4V7qqah024883@porkchop.devel.redhat.com> Message-ID: <1149078022.3761.7.camel@kloczek01.pracownicy.zie> Dnia 31-05-2006, ?ro o godzinie 03:52 -0400, Build System napisa?(a): [..] > gnome-keyring-manager-2.14.0-2 > ------------------------------ > * Mon May 29 2006 Alexander Larsson - 2.14.0-2 > - buildrequire gettext and perl-XML-Parser *All* this kind changes are incorrect. BuildRequires for perl-XML-Parser must be replaced by intltool because for exaple gnome-keyring-manager build automation do not uses directly perl-XML-Parser but intltool and intltool uses perl-XML-Parser (yess inltool acelocal macro display messages about looking for perl-XML-Parser but it dosent matter). Intltool must have Require not gettext but gettext-devel. IIRC Requires rule for neccessary perl modules from perl-XML-Parser is autogenerated so adding explicite in intltool spec Require rule for perl-XML-Parser isn't neccessary. kloczek From nphilipp at redhat.com Wed May 31 12:56:54 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 31 May 2006 14:56:54 +0200 Subject: Buildrequire: perl-XML-Parser (Was: Re: rawhide report: 20060531 changes) In-Reply-To: <1149078022.3761.7.camel@kloczek01.pracownicy.zie> References: <200605310752.k4V7qqah024883@porkchop.devel.redhat.com> <1149078022.3761.7.camel@kloczek01.pracownicy.zie> Message-ID: <1149080215.12514.7.camel@gibraltar.stuttgart.redhat.com> On Wed, 2006-05-31 at 14:20 +0200, Tomasz K?oczko wrote: > Dnia 31-05-2006, ?ro o godzinie 03:52 -0400, Build System napisa?(a): > [..] > > gnome-keyring-manager-2.14.0-2 > > ------------------------------ > > * Mon May 29 2006 Alexander Larsson - 2.14.0-2 > > - buildrequire gettext and perl-XML-Parser > > *All* this kind changes are incorrect. > BuildRequires for perl-XML-Parser must be replaced by intltool because > for exaple gnome-keyring-manager build automation do not uses directly > perl-XML-Parser but intltool and intltool uses perl-XML-Parser (yess > inltool acelocal macro display messages about looking for > perl-XML-Parser but it dosent matter). > > Intltool must have Require not gettext but gettext-devel. IIRC Requires > rule for neccessary perl modules from perl-XML-Parser is autogenerated > so adding explicite in intltool spec Require rule for perl-XML-Parser > isn't neccessary. Objection. I also have a package concerned by this (hwbrowser) and it (by itself) contains intltool scripts (no external dependency on intltool) which require perl-XML-Parser. Therefore this package requires "perl-XML-Parser" for building. Note that with packages using an external intltool YMMV. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From paul at city-fan.org Wed May 31 13:11:09 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 14:11:09 +0100 Subject: Buildrequire: perl-XML-Parser (Was: Re: rawhide report: 20060531 changes) In-Reply-To: <1149080215.12514.7.camel@gibraltar.stuttgart.redhat.com> References: <200605310752.k4V7qqah024883@porkchop.devel.redhat.com> <1149078022.3761.7.camel@kloczek01.pracownicy.zie> <1149080215.12514.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: <447D95ED.5040208@city-fan.org> Nils Philippsen wrote: > On Wed, 2006-05-31 at 14:20 +0200, Tomasz K?oczko wrote: >> Dnia 31-05-2006, ?ro o godzinie 03:52 -0400, Build System napisa?(a): >> [..] >>> gnome-keyring-manager-2.14.0-2 >>> ------------------------------ >>> * Mon May 29 2006 Alexander Larsson - 2.14.0-2 >>> - buildrequire gettext and perl-XML-Parser >> *All* this kind changes are incorrect. >> BuildRequires for perl-XML-Parser must be replaced by intltool because >> for exaple gnome-keyring-manager build automation do not uses directly >> perl-XML-Parser but intltool and intltool uses perl-XML-Parser (yess >> inltool acelocal macro display messages about looking for >> perl-XML-Parser but it dosent matter). >> >> Intltool must have Require not gettext but gettext-devel. IIRC Requires >> rule for neccessary perl modules from perl-XML-Parser is autogenerated >> so adding explicite in intltool spec Require rule for perl-XML-Parser >> isn't neccessary. > > Objection. I also have a package concerned by this (hwbrowser) and it > (by itself) contains intltool scripts (no external dependency on > intltool) which require perl-XML-Parser. Therefore this package requires > "perl-XML-Parser" for building. Note that with packages using an > external intltool YMMV. Shouldn't the dep be perl(XML::Parser) rather than perl-XML-Parser? In case it gets bundled with perl someday for instance. Paul. From tjb at unh.edu Wed May 31 13:17:16 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 31 May 2006 09:17:16 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <1147917712.3434.11.camel@continuity> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> Message-ID: <1149081436.4310.13.camel@raptor.sr.unh.edu> On Wed, 2006-05-17 at 22:01 -0400, Thomas J. Baker wrote: > On Wed, 2006-05-17 at 20:35 -0400, John (J5) Palmieri wrote: > > On Wed, 2006-05-17 at 20:21 -0400, Thomas J. Baker wrote: > > > I had aiglx working fine on my laptop for quite a while now. I've got a > > > ATI Technologies Inc Radeon R250 Lf [FireGL 9000] but within the last > > > week, I've succumb to the everything-is-blue-with-metacity-compositing > > > enabled bug. Anyone else had it working and then have it recently break? > > > > Ohh, I've seen this on my ATI mobility and I have a stacktrace from GDB > > sitting at work. I thought it was just my bad luck having a card that > > is busted with aiglx but it is nice to see that is is a regression. Can > > log into failsafe xterm mode, ssh in from another computer as your user > > and run these commands: > > > > export DISPLAY=:0 > > export XAUTHORITY=~/.Xauthority > > export METACITY_SYNC=1 > > gdb metacity > > gdb> run > > > > Metacity should crash at some point (if it doesn't try to grab the xterm > > window and move it around). After it crashes run this command in gdb: > > > > gdb> bt > > > > Open a bug and attach that output. Thanks. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192163 > Fixed with today's update. Menus are a much too translucent though... Would that be metacity or something else? tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From sundaram at fedoraproject.org Wed May 31 13:26:44 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 31 May 2006 18:56:44 +0530 Subject: Recent AIGLX Breakage? In-Reply-To: <1149081436.4310.13.camel@raptor.sr.unh.edu> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> Message-ID: <1149082004.4310.861.camel@sundaram.pnq.redhat.com> On Wed, 2006-05-31 at 09:17 -0400, Thomas J. Baker wrote: > On Wed, 2006-05-17 at 22:01 -0400, Thomas J. Baker wrote: > > On Wed, 2006-05-17 at 20:35 -0400, John (J5) Palmieri wrote: > > > On Wed, 2006-05-17 at 20:21 -0400, Thomas J. Baker wrote: > > > > I had aiglx working fine on my laptop for quite a while now. I've got a > > > > ATI Technologies Inc Radeon R250 Lf [FireGL 9000] but within the last > > > > week, I've succumb to the everything-is-blue-with-metacity-compositing > > > > enabled bug. Anyone else had it working and then have it recently break? > > > > > > Ohh, I've seen this on my ATI mobility and I have a stacktrace from GDB > > > sitting at work. I thought it was just my bad luck having a card that > > > is busted with aiglx but it is nice to see that is is a regression. Can > > > log into failsafe xterm mode, ssh in from another computer as your user > > > and run these commands: > > > > > > export DISPLAY=:0 > > > export XAUTHORITY=~/.Xauthority > > > export METACITY_SYNC=1 > > > gdb metacity > > > gdb> run > > > > > > Metacity should crash at some point (if it doesn't try to grab the xterm > > > window and move it around). After it crashes run this command in gdb: > > > > > > gdb> bt > > > > > > Open a bug and attach that output. Thanks. > > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192163 > > > > Fixed with today's update. Menus are a much too translucent though... > Would that be metacity or something else? That would be metacity. Rahul From jspaleta at gmail.com Wed May 31 13:32:24 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 31 May 2006 09:32:24 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <1149081436.4310.13.camel@raptor.sr.unh.edu> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> Message-ID: <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> On 5/31/06, Thomas J. Baker wrote: > Fixed with today's update. Menus are a much too translucent though... > Would that be metacity or something else? Assuming you define 'too translucent' like I do, meaning any translucency at all, the fix is to turn off the bling completely. --jef"So who is going to sponsor the usability study to determine the best level of default transparency percentage down to the fifth significant digit? I simply can't wait to read over the minutia of that discussion. blaaaaah"spaleta From tjb at unh.edu Wed May 31 13:47:13 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 31 May 2006 09:47:13 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> Message-ID: <1149083233.4310.23.camel@raptor.sr.unh.edu> On Wed, 2006-05-31 at 09:32 -0400, Jeff Spaleta wrote: > On 5/31/06, Thomas J. Baker wrote: > > Fixed with today's update. Menus are a much too translucent though... > > Would that be metacity or something else? > > Assuming you define 'too translucent' like I do, meaning any > translucency at all, the fix is to turn off the bling completely. > > > --jef"So who is going to sponsor the usability study to determine the > best level of default transparency percentage down to the fifth > significant digit? I simply can't wait to read over the minutia of > that discussion. blaaaaah"spaleta > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193655 At first blush, being a bling fanboy, I thought it was just too much translucency and could be tweaked. The more I think about it though, the more I lean towards menus not being translucent at all. tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From jspaleta at gmail.com Wed May 31 14:13:43 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 31 May 2006 10:13:43 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <1149083233.4310.23.camel@raptor.sr.unh.edu> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> <1149083233.4310.23.camel@raptor.sr.unh.edu> Message-ID: <604aa7910605310713i56a6d4bfjccfe4b4c2f88fbae@mail.gmail.com> On 5/31/06, Thomas J. Baker wrote: > At first blush, being a bling fanboy, I thought it was just too much > translucency and could be tweaked. The more I think about it though, the > more I lean towards menus not being translucent at all. Transulency in any layering textual element that users are expected to read is a usability killer.. full stop. Being able to sort of read the desktop underneath the text in an semi-transparent open window, just means you can sort of not read any of the text at all. Down with transulency in functional information display contexts. Keep that crap where it belongs, window dressing for flavor-of-the-day media player "skins." --jef"pines for the days for the sanity of a userbase who prefer unfocused wireframes over transparency by default to avoid a mismash of unreadable layers of text garbage, when there are 3+ layers windows open.. instead of the mad rush to shove transparency into every aspect of the default visible display in an effort to prove to everyone that the system has the capability to do it. The fascination with transparency in an Xwindows system is like watching a 21 year old go out for their first legal night of drinking and abuse alcohol to the extremes of bodily endurance and then having to report the work at 8 am and be productive. Look at us! We can now drink our fill of transparency.. chug chug chug!!!!!! "spaleta From dragoran at feuerpokemon.de Wed May 31 14:16:28 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 31 May 2006 16:16:28 +0200 Subject: Recent AIGLX Breakage? In-Reply-To: <1149083233.4310.23.camel@raptor.sr.unh.edu> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> <1149083233.4310.23.camel@raptor.sr.unh.edu> Message-ID: <447DA53C.7000708@feuerpokemon.de> Thomas J. Baker wrote: > On Wed, 2006-05-31 at 09:32 -0400, Jeff Spaleta wrote: > >> On 5/31/06, Thomas J. Baker wrote: >> >>> Fixed with today's update. Menus are a much too translucent though... >>> Would that be metacity or something else? >>> >> Assuming you define 'too translucent' like I do, meaning any >> translucency at all, the fix is to turn off the bling completely. >> >> >> --jef"So who is going to sponsor the usability study to determine the >> best level of default transparency percentage down to the fifth >> significant digit? I simply can't wait to read over the minutia of >> that discussion. blaaaaah"spaleta >> >> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193655 > > At first blush, being a bling fanboy, I thought it was just too much > translucency and could be tweaked. The more I think about it though, the > more I lean towards menus not being translucent at all. > > tjb > any screenshot? From tjb at unh.edu Wed May 31 14:23:53 2006 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 31 May 2006 10:23:53 -0400 Subject: Recent AIGLX Breakage? In-Reply-To: <447DA53C.7000708@feuerpokemon.de> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> <1149083233.4310.23.camel@raptor.sr.unh.edu> <447DA53C.7000708@feuerpokemon.de> Message-ID: <1149085433.4504.4.camel@raptor.sr.unh.edu> On Wed, 2006-05-31 at 16:16 +0200, dragoran wrote: > Thomas J. Baker wrote: > > On Wed, 2006-05-31 at 09:32 -0400, Jeff Spaleta wrote: > > > >> On 5/31/06, Thomas J. Baker wrote: > >> > >>> Fixed with today's update. Menus are a much too translucent though... > >>> Would that be metacity or something else? > >>> > >> Assuming you define 'too translucent' like I do, meaning any > >> translucency at all, the fix is to turn off the bling completely. > >> > >> > >> --jef"So who is going to sponsor the usability study to determine the > >> best level of default transparency percentage down to the fifth > >> significant digit? I simply can't wait to read over the minutia of > >> that discussion. blaaaaah"spaleta > >> > >> > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193655 > > > > At first blush, being a bling fanboy, I thought it was just too much > > translucency and could be tweaked. The more I think about it though, the > > more I lean towards menus not being translucent at all. > > > > tjb > > > any screenshot? > http://wintermute.sr.unh.edu/~tjb/Screenshot.png tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From kloczek at zie.pg.gda.pl Wed May 31 14:28:14 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Wed, 31 May 2006 16:28:14 +0200 Subject: Buildrequire: perl-XML-Parser (Was: Re: rawhide report: 20060531 changes) In-Reply-To: <1149080215.12514.7.camel@gibraltar.stuttgart.redhat.com> References: <200605310752.k4V7qqah024883@porkchop.devel.redhat.com> <1149078022.3761.7.camel@kloczek01.pracownicy.zie> <1149080215.12514.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1149085694.27101.43.camel@kloczek01.pracownicy.zie> Cc: to intltool developer. Dnia 31-05-2006, ?ro o godzinie 14:56 +0200, Nils Philippsen napisa?(a): > On Wed, 2006-05-31 at 14:20 +0200, Tomasz K?oczko wrote: > > Dnia 31-05-2006, ?ro o godzinie 03:52 -0400, Build System napisa?(a): > > [..] > > > gnome-keyring-manager-2.14.0-2 > > > ------------------------------ > > > * Mon May 29 2006 Alexander Larsson - 2.14.0-2 > > > - buildrequire gettext and perl-XML-Parser > > > > *All* this kind changes are incorrect. > > BuildRequires for perl-XML-Parser must be replaced by intltool because > > for exaple gnome-keyring-manager build automation do not uses directly > > perl-XML-Parser but intltool and intltool uses perl-XML-Parser (yess > > inltool acelocal macro display messages about looking for > > perl-XML-Parser but it dosent matter). > > > > Intltool must have Require not gettext but gettext-devel. IIRC Requires > > rule for neccessary perl modules from perl-XML-Parser is autogenerated > > so adding explicite in intltool spec Require rule for perl-XML-Parser > > isn't neccessary. > > Objection. I also have a package concerned by this (hwbrowser) and it > (by itself) contains intltool scripts (no external dependency on > intltool) which require perl-XML-Parser. Therefore this package requires > "perl-XML-Parser" for building. Note that with packages using an > external intltool YMMV. OK you are right and I'm wrong. Now I'm after looking on this closer. Ab ovo .. libtoolize install in project tree intltool*.in files. config.status generates from this in files intltool-{extract,merge,update} scripts. Diffrence beetween .in fileas adn generated seems is only in first line where is placed perl binary path. And .. intltool package provides the same copy of this scripts files with perl binary path in preable line. For me current scheme using intltool look like performing some little stupid things because: - intltool and all .in files have the same requirements, - looks like intltool is backward compatible because anywhere is required intltool is required minimal version, - distributing copy intlook scripts as .in files it is plain waste of hard disks space and connections bandwitch. Better will be change this to: - from intltool removed intoollize scripts and .in files. Installed intltool package can contain only above three scripts with correct perl binary path (temporaty it can be changed to /bin/true link for not breaking some autogen scripts :), - add to intltool for examle intltool.pc file which will allow detect on autoconf level intltool avalaibility and minimal version (all this can be performed by change IT_PROG_INTLTOOL aclocal macro so introduce this will not require some additional changes in each project which now uses intltool, - during update desktop, schemas and other fiels use system avalaible intltool-* scripts, - if in system are avalaible intltool-* scripts perl path detection can be dropped (perl-XML-Parser too) because all this detection was performed on intltool install stage (directly from tar ball or from dist rpm/deb/whatever package). .. faster (on autoconf level), less consuming disks across the network, simpler. Also looks like performing above changes will do not require change on each projects which now uses intltool. If next version intltool will use this this can be backward compatible without installing new intltool in system resources because current intltool package provides %{_bindir}/intltool-{extract,merge,update} which can be used directly. kloczek From Matt_Domsch at dell.com Wed May 31 15:14:13 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:14:13 -0500 Subject: Core i386 rawhide rebuild in mock status 2006-05-31 Message-ID: <20060531151413.GA30021@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnome-vfs2 193392 NEW vixie-cron 191823 ASSIGNED xorg-x11-drv-fbdev 192325 ASSIGNED xorg-x11-drv-vesa 192359 ASSIGNED xorg-x11-xdm 191858 ASSIGNED xscreensaver 191769 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Core Rawhide-in-Mock Build Results for i386 Wed May 31 09:59:43 CDT 2006 Number failed to build: 286 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 275 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 44 ---------------------------------- SDL Xaw3d automake15 automake16 emacs ethereal kasumi openmotif pcmciautils pirut prelink pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm sg3_utils specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans xmlsec1 xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 231 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] am-utils ['193347 ASSIGNED'] arts ['192367 NEEDINFO'] at-spi ['192368 CLOSED'] atk ['193349 NEW'] autorun ['193351 CLOSED'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] compat-gcc-296 ['191696 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 CLOSED'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] f-spot ['193364 NEW'] fbset ['193362 CLOSED'] file-roller ['193363 NEW'] frysk ['192256 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 MODIFIED'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] gimp ['193368 CLOSED'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 CLOSED'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-utils ['191757 CLOSED'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] gpart ['193396 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] hwbrowser ['193400 CLOSED'] indent ['193401 NEW'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libIDL ['193419 NEW'] libSM ['193421 NEW'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] libXres ['193502 NEW'] libXt ['193503 NEW'] libXtst ['193504 NEW'] libXv ['193505 NEW'] libXvMC ['193506 NEW'] libXxf86dga ['193507 NEW'] libXxf86misc ['193508 NEW'] libXxf86vm ['193509 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 MODIFIED'] libgtop2 ['193418 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] linux-atm ['193510 CLOSED'] lm_sensors ['193511 NEW'] longrun ['193512 CLOSED'] lrzsz ['193513 NEW'] m17n-lib ['193524 ASSIGNED'] magma-plugins ['193525 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] ncpfs ['193526 NEEDINFO_REPORTER'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 CLOSED'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] pkgconfig ['193552 NEW'] planner ['191808 CLOSED'] policycoreutils ['193537 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pump ['193554 NEW'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 ASSIGNED'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-apm ['192333 ASSIGNED'] xorg-x11-drv-ark ['191905 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-chips ['192361 ASSIGNED'] xorg-x11-drv-cirrus ['192362 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-cyrix ['192364 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i128 ['192373 ASSIGNED'] xorg-x11-drv-i740 ['192370 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-neomagic ['192382 ASSIGNED'] xorg-x11-drv-nsc ['192376 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-rendition ['192384 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Wed May 31 15:14:37 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:14:37 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2006-05-31 Message-ID: <20060531151437.GB30021@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: gnome-vfs2 193392 NEW vixie-cron 191823 ASSIGNED xorg-x11-drv-fbdev 192325 ASSIGNED xorg-x11-drv-vesa 192359 ASSIGNED xorg-x11-xdm 191858 ASSIGNED xscreensaver 191769 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Core Rawhide-in-Mock Build Results for x86_64 Wed May 31 09:58:18 CDT 2006 Number failed to build: 300 Number expected to fail due to ExclusiveArch or ExcludeArch: 28 Leaving: 272 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 49 ---------------------------------- SDL Xaw3d automake15 automake16 boost elilo emacs ethereal kasumi kdeaccessibility libmusicbrainz openmotif pcmciautils perl pirut pwlib pycairo pykickstart radvd rdist redhat-artwork redhat-menus rgmanager ruby sane-backends scim-chewing scim-qtimm sgml-common specspo squirrelmail switchdesk sysstat system-config-bind system-config-boot system-config-cluster system-config-display system-config-kickstart system-config-lvm system-config-services system-config-soundcard tsclient w3m wordtrans xmlsec1 xmlto xorg-x11-twm xorg-x11-xinit xorg-x11-xkbdata zenity With bugs filed: 223 ---------------------------------- GFS-kernel ['192569 NEW'] HelixPlayer ['192512 NEW'] ImageMagick ['192036 NEW'] am-utils ['193347 ASSIGNED'] arts ['192367 NEEDINFO'] at-spi ['192368 CLOSED'] atk ['193349 NEW'] autorun ['193351 CLOSED'] avahi ['191663 CLOSED'] bc ['193352 NEW'] beagle ['191664 CLOSED'] brltty ['193353 NEW'] bsf ['192369 NEW'] cadaver ['193355 NEW'] cairo-java ['192371 NEW'] classpathx-jaf ['192372 ASSIGNED'] cman-kernel ['192570 NEW'] dasher ['193356 NEW'] dbus ['193357 NEW'] desktop-printing ['192239 CLOSED'] device-mapper-multipath ['192242 NEEDINFO'] dlm-kernel ['192572 NEW'] doxygen ['193358 NEW'] e2fsprogs ['192247 NEW'] eel2 ['191909 CLOSED'] epiphany ['191665 NEW'] evince ['193359 CLOSED'] evolution-connector ['192251 CLOSED'] evolution-data-server ['193360 NEW'] evolution-webcal ['193361 NEW'] f-spot ['193364 NEW'] fbset ['193362 CLOSED'] file-roller ['193363 NEW'] frysk ['192256 NEW'] gail ['192492 CLOSED'] gaim ['192496 NEW'] gcalctool ['191910 CLOSED'] gconf-editor ['193365 NEW'] gdb ['193366 MODIFIED'] gdk-pixbuf ['192493 NEW'] gecko-sharp2 ['192495 NEW'] gedit ['193367 NEW'] gimp ['193368 CLOSED'] glade2 ['193371 NEW'] gnbd-kernel ['192573 NEW'] gnome-applets ['193372 NEW'] gnome-backgrounds ['193373 NEW'] gnome-bluetooth ['193374 CLOSED'] gnome-doc-utils ['193375 NEW'] gnome-icon-theme ['193376 NEW'] gnome-media ['192497 CLOSED'] gnome-menus ['193379 NEW'] gnome-mime-data ['193381 NEW'] gnome-mount ['191680 CLOSED'] gnome-netstatus ['193382 NEW'] gnome-nettool ['193383 NEW'] gnome-panel ['192498 CLOSED'] gnome-pilot ['193384 NEW'] gnome-pilot-conduits ['193385 NEW'] gnome-power-manager ['191720 CLOSED'] gnome-python2 ['192499 NEW'] gnome-python2-desktop ['192500 CLOSED'] gnome-python2-extras ['192501 NEW'] gnome-screensaver ['193387 NEW'] gnome-session ['193388 NEW'] gnome-spell ['193389 NEW'] gnome-user-docs ['193390 NEW'] gnome-utils ['191757 CLOSED'] gnome-volume-manager ['193393 NEW'] gnucash ['192008 CLOSED'] grub ['192504 NEW'] gtk+ ['193397 NEW'] gtk2 ['193398 NEW'] gucharmap ['193399 NEW'] hal ['191675 CLOSED'] hal-cups-utils ['192507 NEW'] hwbrowser ['193400 CLOSED'] indent ['193401 NEW'] iptraf ['192510 NEW'] iso-codes ['193404 NEW'] jakarta-commons-codec ['192511 NEW'] jakarta-commons-dbcp ['192515 NEW'] jakarta-commons-el ['192514 NEW'] jakarta-commons-pool ['192516 NEW'] jakarta-taglibs-standard ['192517 NEW'] java-1.4.2-gcj-compat ['192518 NEW'] jsch ['191668 NEW'] kdeartwork ['192519 NEW'] kdebase ['192037 NEW'] kdegames ['192521 CLOSED'] kdelibs ['192522 CLOSED'] kdemultimedia ['192523 CLOSED'] kdenetwork ['192525 CLOSED'] kdepim ['192526 CLOSED'] kdesdk ['192527 CLOSED'] kdevelop ['192529 CLOSED'] kdewebdev ['191983 NEEDINFO_REPORTER'] krb5-auth-dialog ['193407 NEW'] latex2html ['191762 NEW'] ldapjdk ['192530 NEW'] libIDL ['193419 NEW'] libSM ['193421 NEW'] libXau ['193422 NEW'] libXaw ['193423 NEW'] libXpm ['193427 NEW'] libXrandr ['193428 NEW'] libXrender ['193429 NEW'] libXres ['193502 NEW'] libXt ['193503 NEW'] libXtst ['193504 NEW'] libXv ['193505 NEW'] libXvMC ['193506 NEW'] libXxf86dga ['193507 NEW'] libXxf86misc ['193508 NEW'] libXxf86vm ['193509 NEW'] libbonobo ['193408 NEW'] libbonoboui ['191728 CLOSED'] libbtctl ['191981 CLOSED'] libgconf-java ['192531 NEW'] libgcrypt ['193409 NEW'] libglade-java ['192532 NEW'] libgnome ['193410 NEW'] libgnomecanvas ['193411 NEW'] libgnomecups ['191747 CLOSED'] libgnomeprint22 ['191976 CLOSED'] libgnomeprintui22 ['193414 NEW'] libgnomeui ['193415 NEW'] libgpod ['193416 NEW'] libgsf ['193417 MODIFIED'] libgtop2 ['193418 NEW'] libnotify ['191731 NEW'] liboldX ['193420 NEW'] libsemanage ['191733 CLOSED'] libvte-java ['192533 NEW'] libwnck ['191756 CLOSED'] libxkbfile ['193424 NEW'] libxkbui ['193425 NEW'] libxklavier ['193426 NEW'] linux-atm ['193510 CLOSED'] lm_sensors ['193511 NEW'] lrzsz ['193513 NEW'] m17n-lib ['193524 ASSIGNED'] magma-plugins ['193525 NEW'] metacity ['191960 CLOSED'] mozilla ['191984 NEW'] mx4j ['192534 NEW'] nautilus-sendto ['191818 CLOSED'] ncpfs ['193526 NEEDINFO_REPORTER'] nfs-utils ['191943 NEW'] nfs-utils-lib ['191749 NEW'] notify-daemon ['191810 NEW'] opal ['191936 CLOSED'] openhpi ['191935 NEW'] perl-XML-Simple ['191911 NEW'] pkgconfig ['193552 NEW'] planner ['191808 CLOSED'] policycoreutils ['193537 NEW'] psgml ['191902 NEEDINFO_REPORTER'] psmisc ['191901 CLOSED'] pump ['193554 NEW'] pydict ['191898 NEW'] python-pyblock ['191866 NEW'] qt ['191895 CLOSED'] reiserfs-utils ['191889 NEW'] scim ['191886 ASSIGNED'] sound-juicer ['182174 CLOSED'] squashfs-tools ['191880 CLOSED'] stardict ['191878 NEW'] struts ['192489 NEW'] subversion ['191611 NEW'] syslinux ['192488 NEW'] system-config-netboot ['192537 ASSIGNED'] tetex ['191874 ASSIGNED'] thunderbird ['191881 NEW'] tomboy ['191833 CLOSED'] tomcat5 ['192565 NEW'] tux ['191828 NEW'] vino ['191827 CLOSED'] vte ['192484 CLOSED'] xdoclet ['192483 NEW'] xen ['192539 NEW'] xjavadoc ['192057 NEW'] xorg-x11-drv-aiptek ['191903 ASSIGNED'] xorg-x11-drv-calcomp ['191904 ASSIGNED'] xorg-x11-drv-citron ['192292 ASSIGNED'] xorg-x11-drv-digitaledge ['192316 ASSIGNED'] xorg-x11-drv-dmc ['192312 ASSIGNED'] xorg-x11-drv-dummy ['192304 ASSIGNED'] xorg-x11-drv-dynapro ['192300 ASSIGNED'] xorg-x11-drv-elo2300 ['192320 ASSIGNED'] xorg-x11-drv-elographics ['192318 ASSIGNED'] xorg-x11-drv-evdev ['192317 ASSIGNED'] xorg-x11-drv-fpit ['192324 ASSIGNED'] xorg-x11-drv-hyperpen ['192326 ASSIGNED'] xorg-x11-drv-i810 ['192334 CLOSED'] xorg-x11-drv-jamstudio ['192335 ASSIGNED'] xorg-x11-drv-joystick ['192336 ASSIGNED'] xorg-x11-drv-keyboard ['192337 ASSIGNED'] xorg-x11-drv-magellan ['192338 ASSIGNED'] xorg-x11-drv-magictouch ['192339 ASSIGNED'] xorg-x11-drv-microtouch ['192341 ASSIGNED'] xorg-x11-drv-mutouch ['192342 ASSIGNED'] xorg-x11-drv-nv ['192343 ASSIGNED'] xorg-x11-drv-palmax ['192346 ASSIGNED'] xorg-x11-drv-penmount ['192344 ASSIGNED'] xorg-x11-drv-s3 ['192347 ASSIGNED'] xorg-x11-drv-s3virge ['192348 ASSIGNED'] xorg-x11-drv-siliconmotion ['192350 ASSIGNED'] xorg-x11-drv-sisusb ['192352 ASSIGNED'] xorg-x11-drv-spaceorb ['192353 ASSIGNED'] xorg-x11-drv-summa ['192354 ASSIGNED'] xorg-x11-drv-tek4957 ['192357 NEW'] xorg-x11-drv-trident ['192356 ASSIGNED'] xorg-x11-drv-ur98 ['192360 ASSIGNED'] xorg-x11-drv-vga ['192168 ASSIGNED'] xorg-x11-drv-vmmouse ['192047 CLOSED'] xorg-x11-drv-vmware ['192046 ASSIGNED'] xorg-x11-drv-void ['192045 ASSIGNED'] xorg-x11-resutils ['192040 ASSIGNED'] xorg-x11-server-utils ['191987 ASSIGNED'] xorg-x11-utils ['191966 ASSIGNED'] yelp ['191660 CLOSED'] zsh ['191647 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Wed May 31 15:15:20 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:15:20 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 Message-ID: <20060531151520.GC30021@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for i386 Wed May 31 10:03:11 CDT 2006 Number failed to build: 174 Number expected to fail due to ExclusiveArch or ExcludeArch: 1 Leaving: 173 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 171 ---------------------------------- Gtk-Perl GtkAda Hermes MagicPoint NetworkManager-vpnc OpenSceneGraph R-gnomeGUI SDL_net SDL_ttf Terminal WindowMaker abe alacarte amaya anjuta-gdl balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp clearsilver colorscheme contact-lookup-applet cowbell csmash dbus-qt ddskk dia dillo diradmin directfb drgeo ebtables enigma epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge freedroid gambas gazpacho gcompris gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics gtk-gnutella gtk-xfce-engine gtktalog gurlchecker gwget ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd lincity-ng linkchecker lmarbles logjam lucidlife maxima mfstools multisync mysql-administrator naim nautilus-open-terminal nautilus-search-tool nazghul ncmpc nco netpanzer paps perl-HTML-Mason perl-Image-Info php-extras pipenightdreams pitivi pl ppracer pygame pypoker-eval python-TestGears python-cheetah python-goopy qemu qtparted quarry rpmDirectoryCheck sabayon sblim-cmpi-base scmxx scponly ser serpentine sloccount splint stow stratagus supertux swh-plugins synce-software-manager synce-trayicon tagtool tetex-eurofont torcs tuxpaint tuxtype2 ushare verbiste viruskiller wlassistant xbase xbindkeys xbsql xcin xfce-utils xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 Matt_Domsch at dell.com Wed May 31 15:15:55 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:15:55 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2006-05-31 Message-ID: <20060531151555.GD30021@lists.us.dell.com> Open Bugs which now build, and can be marked CLOSED RAWHIDE: libgpg-error 193550 NEW Note: This is using a reduced set of packages in the build chroot as compared to the standard Fedora Extras build system before FC6test1. See http://fedoraproject.org/wiki/QA/FixBuildRequires for more information, including the list of packages removed from the default build chroot. Extras Rawhide-in-Mock Build Results for x86_64 Wed May 31 10:01:38 CDT 2006 Number failed to build: 185 Number expected to fail due to ExclusiveArch or ExcludeArch: 11 Leaving: 174 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 172 ---------------------------------- Gtk-Perl GtkAda Macaulay2 MagicPoint NetworkManager-vpnc OpenSceneGraph R-gnomeGUI SDL_ttf Terminal WindowMaker alacarte amaya anjuta-gdl apt atitvout balsa banshee baobab bidiv bmp bsd-games byzanz camstream ccrtp colorscheme contact-lookup-applet cowbell d4x dbus-qt ddskk dia dietlibc dillo diradmin directfb drgeo ebtables epiphany-extensions epylog exim exo factory fillets-ng fish flim flow-tools fontforge gambas gazpacho gdesklets gif2png glabels gnomad2 gnome-applet-music gnome-applet-rhythmbox gnome-ppp gnome-schedule gnome-sudoku gnome-themes-extras gnupg2 gobby gpgme gphpedit graveman grhino gstreamer08 gstreamer08-python gsynaptics gtk-gnutella gtk-xfce-engine gtktalog gurlchecker gwget hercules ifplugd jam john kanatest kdemultimedia-extras kdissert kmymoney2 koffice kover ladspa leafpad libassetml libeXosip2 libfac libgda libgnomedb libksba libopensync-plugin-kdepim libpolyxmass libtabe libtomoe-gtk libtranslate libxfcegui4 licq lighttpd linkchecker logjam lucidlife maxima mhonarc multisync mysql-administrator nautilus-open-terminal nautilus-search-tool ncmpc nco new pam_mount paps perl-HTML-Mason perl-Image-Info perl-Log-Log4perl perl-Unicode-Map8 perl-Unicode-MapUTF8 php-extras php-pear-DB pipenightdreams pitivi pl pypoker-eval python-TestGears python-cheetah python-dateutil python-goopy python-reportlab qemu qtparted quarry rpmDirectoryCheck sabayon scmxx scponly ser serpentine sloccount splint stow stratagus supertux swh-plugins synaptic synce-software-manager synce-trayicon tagtool tetex-eurofont tuxpaint uqm ushare verbiste wlassistant xbase xbindkeys xbsql xcin xfce-utils xfce4-modemlights-plugin xfce4-mount-plugin xfce4-panel xfce4-taskmanager xfce4-weather-plugin xfdesktop xffm xfprint xfwm4 xmms-crossfade xplanet xsp z88dk With bugs filed: 2 ---------------------------------- gtkhtml36 ['193476 NEW'] yumex ['193549 NEW'] Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ -- 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 davej at redhat.com Wed May 31 15:29:42 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 31 May 2006 11:29:42 -0400 Subject: Core i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531151413.GA30021@lists.us.dell.com> References: <20060531151413.GA30021@lists.us.dell.com> Message-ID: <20060531152942.GC17699@redhat.com> On Wed, May 31, 2006 at 10:14:13AM -0500, Matt Domsch wrote: > longrun ['193512 CLOSED'] this is getting dropped for FC6 Dave -- http://www.codemonkey.org.uk From Matt_Domsch at dell.com Wed May 31 15:36:15 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 10:36:15 -0500 Subject: Core i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531152942.GC17699@redhat.com> References: <20060531151413.GA30021@lists.us.dell.com> <20060531152942.GC17699@redhat.com> Message-ID: <20060531153615.GE30021@lists.us.dell.com> On Wed, May 31, 2006 at 11:29:42AM -0400, Dave Jones wrote: > On Wed, May 31, 2006 at 10:14:13AM -0500, Matt Domsch wrote: > > longrun ['193512 CLOSED'] > > this is getting dropped for FC6 Great, I've now excluded it from the run. Can the powers-that-be remove the SRPM from the rawhide directory? :-) Thanks, Matt -- 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 paul at city-fan.org Wed May 31 16:36:46 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 17:36:46 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060530143408.6219512a.fedora@wir-sind-cool.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <20060530125823.4b56627d@python2> <20060530143408.6219512a.fedora@wir-sind-cool.org> Message-ID: <447DC61E.3000707@city-fan.org> Michael Schwendt wrote: > On Tue, 30 May 2006 12:58:23 +0200, Matthias Saou wrote: > >> I've >> checked the failure of one of my packages (lighttpd), and found out >> that it's because pkgconfig wasn't installed. Typically something >> simple that we need to reach consensus on (and probably a package >> somewhere providing a .pc file but not requiring pkgconfig). > > All -devel packages, which contain .pc files, must require pkgconfig. > > Yes, all of those. Including those libraries, which can be used > conveniently without querying pkg-config. And especially those libraries > which store headers in a versioned non-standard path, which is unlikely to > be found without querying pkg-config. > > The rationale is simple. Many configure checks fail in non-obvious ways if > pkg-config is not installed. If there is no dependency on pkgconfig it is > too easy to either miss it or uninstall it. And in that case it would need > to become a BuildRequires, which in turn would "solve" the problem at the > wrong place. > > Additionally, -devel packages which don't get it right often break the .pc > file dependency chain, so that is the place where to fix the "Requires". Two questions: 1. should bugs be raised on packages like freetype, which has a -devel subpackage that includes a .pc file but has no dep on pkgconfig? 2. If the answer to the first question is yes, should the raised bug be a blocker of the BuildReqBlocker bug? Or should it be a blocker of a bug for a specific package that's failing to build because pkg-config is not present (as in Matthias' example). Something as low down in the dependency chain as freetype could potentially fix a lot of package build issues. Paul. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed May 31 16:52:15 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 31 May 2006 18:52:15 +0200 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <447DC61E.3000707@city-fan.org> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <20060530125823.4b56627d@python2> <20060530143408.6219512a.fedora@wir-sind-cool.org> <447DC61E.3000707@city-fan.org> Message-ID: <20060531185215.62b320e8@python2> Paul Howarth wrote : [...] > > Additionally, -devel packages which don't get it right often break the .pc > > file dependency chain, so that is the place where to fix the "Requires". > > Two questions: > > 1. should bugs be raised on packages like freetype, which has a -devel > subpackage that includes a .pc file but has no dep on pkgconfig? > > 2. If the answer to the first question is yes, should the raised bug be > a blocker of the BuildReqBlocker bug? Or should it be a blocker of a bug > for a specific package that's failing to build because pkg-config is not > present (as in Matthias' example). > > Something as low down in the dependency chain as freetype could > potentially fix a lot of package build issues. I remember having filed a bug against gtk2 or glib2 a long time ago because the -devel sub-package didn't require pkgconfig, but the maintainer didn't want to make the change. If general consensus is to go in that direction now, and the minimal set of build packages reflects that, then I'm all for it. I've actually filed that exact same bug for lua a moment ago since Matt's reports show that it makes the lighttpd rebuild fail : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193674 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.89 (Rawhide) - Linux kernel 2.6.16-1.2232_FC6 Load : 0.74 0.49 0.35 From paul at city-fan.org Wed May 31 17:11:48 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 18:11:48 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-29 In-Reply-To: <20060531185215.62b320e8@python2> References: <20060530041900.GC24614@lists.us.dell.com> <20060530115014.7afcf968.fedora@wir-sind-cool.org> <20060530125823.4b56627d@python2> <20060530143408.6219512a.fedora@wir-sind-cool.org> <447DC61E.3000707@city-fan.org> <20060531185215.62b320e8@python2> Message-ID: <447DCE54.6040504@city-fan.org> Matthias Saou wrote: > Paul Howarth wrote : > > [...] >>> Additionally, -devel packages which don't get it right often break the .pc >>> file dependency chain, so that is the place where to fix the "Requires". >> Two questions: >> >> 1. should bugs be raised on packages like freetype, which has a -devel >> subpackage that includes a .pc file but has no dep on pkgconfig? >> >> 2. If the answer to the first question is yes, should the raised bug be >> a blocker of the BuildReqBlocker bug? Or should it be a blocker of a bug >> for a specific package that's failing to build because pkg-config is not >> present (as in Matthias' example). >> >> Something as low down in the dependency chain as freetype could >> potentially fix a lot of package build issues. > > I remember having filed a bug against gtk2 or glib2 a long time ago > because the -devel sub-package didn't require pkgconfig, but the > maintainer didn't want to make the change. If general consensus is to > go in that direction now, and the minimal set of build packages > reflects that, then I'm all for it. > > I've actually filed that exact same bug for lua a moment ago since > Matt's reports show that it makes the lighttpd rebuild fail : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193674 WindowMaker has buildreqs that, with their dep chain, pull in the following -devel packages: glibc-devel i386 2.4.90-10 core 1.9 M libstdc++-devel i386 4.1.1-1 core 9.5 M fontconfig-devel i386 2.3.95-3 core 169 k gettext-devel i386 0.14.5-3 core 1.1 M giflib-devel i386 4.1.3-7 core 109 k libICE-devel i386 1.0.1-1 core 13 k libSM-devel i386 1.0.1-1 core 9.2 k libX11-devel i386 1.0.1-1 core 679 k libXext-devel i386 1.0.1-1 core 58 k libXft-devel i386 2.1.8.2-3.2 core 16 k libXinerama-devel i386 1.0.1-1.2 core 5.0 k libXpm-devel i386 3.5.5-1 core 31 k libXrender-devel i386 0.9.1-1 core 8.5 k libjpeg-devel i386 6b-36.2.1 core 106 k libpng-devel i386 2:1.2.10-5 core 182 k libtiff-devel i386 3.8.2-3 core 497 k xorg-x11-proto-devel i386 7.1-1 core 264 k zlib-devel i386 1.2.3-1.2.1 core 101 k freetype-devel i386 2.1.10-6 core 577 k libXau-devel i386 1.0.1-1 core 11 k libXdmcp-devel i386 1.0.1-1 core 7.1 k mesa-libGL-devel i386 6.5-6 core 118 k If just one of those had a dep on pkgconfig, WindowMaker would build (I realise that not all of them ship .pc files, but many of them do). Paul. From mike at miketc.com Wed May 31 17:50:23 2006 From: mike at miketc.com (Mike Chambers) Date: Wed, 31 May 2006 12:50:23 -0500 Subject: Recent AIGLX Breakage? In-Reply-To: <1149085433.4504.4.camel@raptor.sr.unh.edu> References: <1147911717.3434.9.camel@continuity> <1147912511.27961.9.camel@localhost.localdomain> <1147917712.3434.11.camel@continuity> <1149081436.4310.13.camel@raptor.sr.unh.edu> <604aa7910605310632r610b451rc2f314a2e4e3177a@mail.gmail.com> <1149083233.4310.23.camel@raptor.sr.unh.edu> <447DA53C.7000708@feuerpokemon.de> <1149085433.4504.4.camel@raptor.sr.unh.edu> Message-ID: <1149097823.12850.3.camel@scrappy.miketc.com> On Wed, 2006-05-31 at 10:23 -0400, Thomas J. Baker wrote: > http://wintermute.sr.unh.edu/~tjb/Screenshot.png Heh, I forgot how to turn on AIGLX. What is the webpage again or is that out of date? Thank, Mike From Matt_Domsch at dell.com Wed May 31 19:57:41 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 14:57:41 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531193110.GG30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> Message-ID: <20060531195741.GH30021@lists.us.dell.com> On Wed, May 31, 2006 at 02:31:11PM -0500, Matt Domsch wrote: > On Wed, May 31, 2006 at 12:06:24PM -0700, Christopher Stone wrote: > > On 5/31/06, Matt Domsch wrote: > > >Of those expected to have worked... > > >pygame > > > > I do not understand why pygame is failing to build on i386 only. It > > does not look like it is a missing BR issue since it works fine in > > x86_64. Here is a snippit from the build log: > > [snip] > > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > > after reloc: Permission denied > > selinux perhaps? OK, this is definitely selinux. However, the workaround posted here: http://fedoraproject.org/wiki/Extras/MockTricks isn't working for me. The build succeeds, but semodule fails. # semodule -i mock.pp libsemanage.semanage_install_active: setfiles returned error code 1. libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! If I can get past this, I'll add this workaround to my build systems and rerun all the failed builds. Thanks, Matt -- 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 paul at city-fan.org Wed May 31 20:06:43 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 31 May 2006 21:06:43 +0100 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531195741.GH30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> <20060531195741.GH30021@lists.us.dell.com> Message-ID: <1149106004.14432.1.camel@laurel.intra.city-fan.org> On Wed, 2006-05-31 at 14:57 -0500, Matt Domsch wrote: > On Wed, May 31, 2006 at 02:31:11PM -0500, Matt Domsch wrote: > > On Wed, May 31, 2006 at 12:06:24PM -0700, Christopher Stone wrote: > > > On 5/31/06, Matt Domsch wrote: > > > >Of those expected to have worked... > > > >pygame > > > > > > I do not understand why pygame is failing to build on i386 only. It > > > does not look like it is a missing BR issue since it works fine in > > > x86_64. Here is a snippit from the build log: > > > > [snip] > > > ImportError: /usr/lib/libSDL-1.2.so.0: cannot restore segment prot > > > after reloc: Permission denied > > > > selinux perhaps? > > OK, this is definitely selinux. However, the workaround posted here: > http://fedoraproject.org/wiki/Extras/MockTricks > > isn't working for me. The build succeeds, but semodule fails. > > # semodule -i mock.pp > libsemanage.semanage_install_active: setfiles returned error code 1. > libsemanage.semanage_install_active: setfiles returned error code 1. > semodule: Failed! Is your host system also running rawhide? Someone just posted a very similar-looking issue on fedora-selinux-list. http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00258.html Paul. From dtimms at bigpond.net.au Wed May 31 20:43:18 2006 From: dtimms at bigpond.net.au (David Timms) Date: Thu, 01 Jun 2006 06:43:18 +1000 Subject: Changing the layout of repodata to simplify making local yum repo. In-Reply-To: <4479657F.3090207@bigpond.net.au> References: <4479657F.3090207@bigpond.net.au> Message-ID: <447DFFE6.6000406@bigpond.net.au> David Timms wrote: > I have searched the archives in relation to this but only found Jesse's: > "Changing the way that Development lands", so if this has been done > before kindly point me to some better google terms. > > What I would like to see changed is a common structure between online > and CD/DVD layouts and the downloaded yum cache eg currently: > > online: {effectively the top level of the dvd iso} > > > Fedora/ > Fedora/RPMS > repodata/ > repodata/other.xml.gz > repodata/filelists.xml.gz > repodata/primary.xml.gz > repodata/comps.xml > > yum cache: > eg /var/cache/yum/core > repomd.xml > primary.xml.gz > comps.xml > {cachecookie} > {primary.xml.gz.sqlite} > headers/ > packages/ {RPMS} > > Now, if the layouts were consistent: > machine1: > - yum.conf: keepcache=1 > - yum update > - ftp/http serv the yum cache folder. > machine2: > - set yum.repos.d/fedora-core.repo baseurl to machine1/core etc. > - yum update > would just work. No createrepo etc would be required. > > So if machine1 has a superset of packages required by all other internal > machines, the fact that machine 1 is up2date means it becomes very easy > and external bandwidth efficient to get the rest of machines up2date. > > This is a hindrance for updates repo, because it's repodata is stored > within the /repodata on the repo server: > > {all the RPMS at this level} > repodata/ > repodata/other.xml.gz > repodata/filelists.xml.gz > repodata/primary.xml.gz > repodata/comps.xml > > So if you point fedora-updates.repo @ another machines > cache/yum/updates, it wont find repodata/repomd.xml > This can be worked around by creating appropriate sym linking; it could > however just work with some tweaking to the structure. > > Also, while you can point fedora-core.repo at another machine with a > mounted dvd iso, the structure yum creates on disk differs from the dvd. > This structure is then not immediately sharable to further machines. > > core dvd primary.xml: > ... > > ... > ----- > It would seem that a preferred layout could be created- eg {i386/} > repodata/ > packages/ > headers/ > > This could be advantageous in other ways eg: > 1. the repodata folder is not inside the packages/RPMS dir, hence > machines trying to ftp repodata/* wont need to cause a complete folder > contents traversal of say thousands of rpms. > 2. rsync or other mirroring of the structure could be done, and the > result is immediately usable by yum. > 3. mock building easier since a local {partial} mirror easier to setup > (just copy the downloads that mock does first time, ht/f tp serve it, > config mock-yum to retrieve from above. and keep it up2date with what > further mock runs retrieve). > > Disadvantages: > 1. other repos would need to catch up for the yum changes. > 2. Is it of limited usefulness ? > > I can see that at least various bits would need to change: > 1. yum to store it's cached repodata in a folder one level down called > repodata, ie changes to yum itself > 2. layout of each repo changed and rebuild the filelist.xml to suit > 3. mirroring {as Jesse worked out for the other layout changes} needs > some tricks. > > What problems/etc can people see with this proposal ? Is changing yum in > this way a bad idea ? DaveT, we shouldn't do this because: - I have no interest in this, it won't help me achieve anything ... - don't mess with something that {sort-of} works. - it will open a black fedora hole in the vicinity of earth Rather than being shot down, I seem to have been completely ignored, which is really rare in here. What I mean to ask is - did my previous request / discussion starter make it past other eyes ? DaveT. From Matt_Domsch at dell.com Wed May 31 21:38:21 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 31 May 2006 16:38:21 -0500 Subject: Extras i386 rawhide rebuild in mock status 2006-05-31 In-Reply-To: <20060531195741.GH30021@lists.us.dell.com> References: <20060531151520.GC30021@lists.us.dell.com> <20060531193110.GG30021@lists.us.dell.com> <20060531195741.GH30021@lists.us.dell.com> Message-ID: <20060531213821.GI30021@lists.us.dell.com> On Wed, May 31, 2006 at 02:57:41PM -0500, Matt Domsch wrote: > OK, this is definitely selinux. However, the workaround posted here: > http://fedoraproject.org/wiki/Extras/MockTricks > > isn't working for me. The build succeeds, but semodule fails. > > # semodule -i mock.pp > libsemanage.semanage_install_active: setfiles returned error code 1. > libsemanage.semanage_install_active: setfiles returned error code 1. > semodule: Failed! > > If I can get past this, I'll add this workaround to my build > systems and rerun all the failed builds. This worked for me now on my FC5 build systems, and for various reasons I've got selinux disabled on my FC-devel build systems, so I'm good now. I've started rebuilding all the previously-failed packages; results tomorrow. Thanks, Matt -- 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 jkeating at j2solutions.net Wed May 31 22:42:09 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 31 May 2006 17:42:09 -0500 Subject: Changing the layout of repodata to simplify making local yum repo. In-Reply-To: <447DFFE6.6000406@bigpond.net.au> References: <4479657F.3090207@bigpond.net.au> <447DFFE6.6000406@bigpond.net.au> Message-ID: <1149115329.12361.0.camel@ender> On Thu, 2006-06-01 at 06:43 +1000, David Timms wrote: > > What I mean to ask is - did my previous request / discussion starter > make it past other eyes ? Try the yum development list. Thats where the folks that really care about it would be. From a Fedora aspect, I don't think we'll care if the cache location moves, as long as upgrades to the new yum don't break things. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bob at lorez.org Wed May 31 22:52:18 2006 From: bob at lorez.org (Bob Richmond) Date: Wed, 31 May 2006 15:52:18 -0700 Subject: Source address routing policy defined in a System V way Message-ID: <447E1E22.6010802@lorez.org> Ok, so this seems like it should be a fairly common configuration and there's no method I can see to define it entirely via System V configuration files. Say you have two network interfaces on two different networks and with two different default routes. This can be used, for instance, if you had two different ISPs and wanted to provide the same services to both links from one server. You can set up two routing tables for each default route, and set up a rule that any packets originating from a particular network must be responded to through the same corresponding gateway: ip rule add from 192.168.0.0/24 lookup 100 pref 100 ip route add table 100 default via 192.168.0.1 dev eth1 Now, being able to define a GATEWAY for each interface definition (eg: ifcfg-eth0) IMPLIES (at least in my mind) that you can define a different default route to use to respond to packets received from a particular interface. This, however, is not the case. :) I'm not sure how this variable is typically meant to be used. Can this be made into a new feature, or am I going about this all wrong?