From arjanv at redhat.com Mon Aug 1 05:48:48 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 1 Aug 2005 07:48:48 +0200 Subject: Exec-shield and memory randomization In-Reply-To: <1122852436.4422.104.camel@linux.droberts.com> References: <1122682010.4422.74.camel@linux.droberts.com> <1122726925.3388.15.camel@localhost.localdomain> <1122750604.4422.93.camel@linux.droberts.com> <1122831990.3286.12.camel@laptopd505.fenrus.org> <1122852436.4422.104.camel@linux.droberts.com> Message-ID: <20050801054848.GA31253@devserv.devel.redhat.com> On Sun, Jul 31, 2005 at 04:27:16PM -0700, Dave Roberts wrote: > On Sun, 2005-07-31 at 19:46 +0200, Arjan van de Ven wrote: > > > . That it, they seem independent, but most of the > > > documentation on exec-shield I have seen seems to suggest that turning > > > off exec-shield should turn off just about everything and leave you with > > > a pretty standard system, ala the pre-exec-shield days. Is that no > > > longer true? > > > > well.. randomisation is now merged upstream.... > > I'm not sure I understand. So that means "yes, they are now > independent" ? > > So assuming that's the case, what does the kernel look for in > determining whether to turn of randomization on a per-binary basis? Nowhere.. it's on for everything. The theory is that randomisation doesn't do anything "odd" at all that couldn't happen otherwise. (by for example upgrading a few libraries or so) So I'd like to get to the bottom of why this app is breaking From skvidal at phy.duke.edu Mon Aug 1 06:41:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 02:41:16 -0400 Subject: Yesterday's rawhide sunk my iBook In-Reply-To: <20050728174123.GA10679@dudweiler.stuttgart.redhat.com> References: <20050728104820.GA731@ryoko.camperquake.de> <1122567216.28128.78.camel@hades.cambridge.redhat.com> <20050728184656.23324de5@nausicaa.camperquake.de> <604aa79105072810116a292ef3@mail.gmail.com> <1122571839.28128.80.camel@hades.cambridge.redhat.com> <1122572261.19679.20.camel@cutter> <20050728174123.GA10679@dudweiler.stuttgart.redhat.com> Message-ID: <1122878476.7609.62.camel@cutter> > What about the cleanup scripts or removing old files? Looks to me > like all that is only done at the very end right now. Maybe completing > individual package updates in one step before updating the next > package should be an option for users. again - once this is handed off to ts.run() yum only reports what rpm does. so if this is going to be an option (which I think is a bit silly, tbh) it would need to be supported in rpm, first. -sv From buildsys at redhat.com Mon Aug 1 11:16:03 2005 From: buildsys at redhat.com (Build System) Date: Mon, 1 Aug 2005 07:16:03 -0400 Subject: rawhide report: 20050801 changes Message-ID: <200508011116.j71BG3FZ003137@porkchop.devel.redhat.com> Updated Packages: MAKEDEV-3.19-4 -------------- * Sun Jul 31 2005 Florian La Roche - remove /dev/MAKEDEV to build with newest rpm * Thu Jul 21 2005 Nalin Dahyabhai 3.19-3 - rebuild * Thu Jul 21 2005 Nalin Dahyabhai 3.19-2 - move usb-specific config file out, go with the mainline devices-2.6+.txt file - update to 12 May devices-2.6+.txt: - add usb/legousbtower - add xvd - rename ttyIOC4 to ttyIOC - add 32 more ttyIOC nodes - add ttySIOC am-utils-5:6.0.9-13 ------------------- * Sun Jul 31 2005 Florian La Roche - package all symlinks to libs compat-slang-1.4.5-11 --------------------- * Sun Jul 31 2005 Florian La Roche - build with newest rpm cpufreq-utils-1:0.3-1.1.16 -------------------------- * Sun Jul 31 2005 Florian La Roche - package all files ctags-5.5.4-4 ------------- * Sun Jul 31 2005 Florian La Roche - remove etags devhelp-0.10-3 -------------- * Sun Jul 31 2005 Christopher Aillon 0.10.0-3 - Rebuild against new mozilla epiphany-1.7.3-2 ---------------- * Sat Jul 30 2005 Christopher Aillon - 1.7.3-2 - Rebuild against new mozilla gaim-1:1.4.0-5.fc5 ------------------ * Sun Jul 31 2005 Warren Togami 1:1.4.0-5 - FC5+ automatic -fstack-protector-all switch - 150: MSN buddy names with space disconnect and profile corruption (supercedes patch 149) - 151: Gadu Gadu memory alignment crash - 152: Rename Group Merge crash - 153: mailto: parse crash (util.c) - 154: mailto: parse crash (MSN) - 155: mailto: parse crash (Zephyr) jwhois-3.2.3-1 -------------- * Mon Aug 01 2005 Miloslav Trmac - 3.2.3-1 - Update to jwhois-3.2.3 - Don't compress jwhois.info manually krbafs-1.2.2-8 -------------- * Sun Jul 31 2005 Florian La Roche - build with current rpm ppp-2.4.3-3 ----------- * Sun Jul 31 2005 Florian La Roche - rebuild for libpcap of the day schedutils-1.5.0-4 ------------------ * Sun Jul 31 2005 Dave Jones - 1.5.0 yelp-2.11.1-3 ------------- * Sun Jul 31 2005 Christopher Aillon 2.11.1-3 - Rebuild against newer mozilla Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 evolution-connector - 2.2.2-5.i386 requires libecal-1.2.so.2 evolution-connector - 2.2.2-5.i386 requires libcamel-provider-1.2.so.3 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 ethereal - 0.10.11-4.i386 requires libpcap.so.0.9.1 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 ethereal-gnome - 0.10.11-4.i386 requires libpcap.so.0.9.1 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 ethereal-gnome - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit) ethereal - 0.10.11-4.x86_64 requires libpcap.so.0.9.1()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 evolution-connector - 2.2.2-5.x86_64 requires libcamel-provider-1.2.so.3()(64bit) evolution-connector - 2.2.2-5.x86_64 requires libecal-1.2.so.2()(64bit) gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- ppc64-utils - 0.7-9.ppc64 requires yaboot gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 firstboot - 1.3.43-1.noarch requires system-config-display cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 ethereal - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config system-config-mouse - 1.2.11-1.noarch requires pyxf86config control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) ethereal-gnome - 0.10.11-4.ppc64 requires libpcap.so.0.9.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) Broken deps for s390 ---------------------------------------------------------- dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 ethereal-gnome - 0.10.11-4.s390 requires libpcap.so.0.9.1 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 ethereal - 0.10.11-4.s390 requires libpcap.so.0.9.1 nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14 evolution-connector - 2.2.2-5.s390 requires libecal-1.2.so.2 evolution-connector - 2.2.2-5.s390 requires libcamel-provider-1.2.so.3 Broken deps for ppc ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 ethereal-gnome - 0.10.11-4.ppc requires libpcap.so.0.9.1 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 ethereal - 0.10.11-4.ppc requires libpcap.so.0.9.1 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 evolution-connector - 2.2.2-5.ppc requires libecal-1.2.so.2 evolution-connector - 2.2.2-5.ppc requires libcamel-provider-1.2.so.3 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390x ---------------------------------------------------------- libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 evolution-connector - 2.2.2-5.s390x requires libcamel-provider-1.2.so.3()(64bit) evolution-connector - 2.2.2-5.s390x requires libecal-1.2.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14 jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 ethereal-gnome - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit) ethereal - 0.10.11-4.s390x requires libpcap.so.0.9.1()(64bit) quota - 1:3.12-6.s390x requires kernel >= 0:2.4 Broken deps for ia64 ---------------------------------------------------------- ethereal - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit) nfs-utils - 1.0.7-10.ia64 requires kernel >= 0:2.2.14 gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2 evolution-connector - 2.2.2-5.ia64 requires libcamel-provider-1.2.so.3()(64bit) evolution-connector - 2.2.2-5.ia64 requires libecal-1.2.so.2()(64bit) quota - 1:3.12-6.ia64 requires kernel >= 0:2.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) selinux-policy-strict-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 rgmanager - 1.9.31-3.ia64 requires ccs sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21 lvm2 - 2.01.13-1.0.ia64 requires kernel >= 0:2.6 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 selinux-policy-targeted-sources - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0 ethereal-gnome - 0.10.11-4.ia64 requires libpcap.so.0.9.1()(64bit) dhcp - 11:3.0.3-1.ia64 requires kernel >= 0:2.2.18 selinux-policy-targeted - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.3-8.noarch requires kernel >= 0:2.6.11-1.1219 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11 jonas - 4.3.3-1jpp_7fc.noarch requires carol = 0:1.8.9.3 arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 From thomas at apestaart.org Mon Aug 1 14:41:51 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 01 Aug 2005 16:41:51 +0200 Subject: new mach release Message-ID: <1122907311.4520.10.camel@thomas.amantes> Hi everyone, after some prerelease testing, a final mach 0.4.7 release has been made. Please find the release notes attached. This version works with either apt or yum, and works with selinux enabled. I'm still looking for people interested in discussing the refactoring of mach into a more pythonic project (work going on in the mach3 directory in cvs) - I need people to discuss ideas and approaches with. Meanwhile, a package for Fedora Extras should soon be hitting the repository. Enjoy, Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I love the way you love but I hate the way I'm supposed to love you back <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ -------------- next part -------------- mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.4.7 - "Long Time No See". WHAT IS IT ---------- mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. This clean build root can be used to run jailed services, create disk images, or build clean packages. mach can currently set up roots for the following distributions: - Fedora 4 (core, updated, extras, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Fedora 1, 2, 3 (core, updated, www.fedora.us, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Red Hat 8.0, 9 (basic, updated, www.fedora.us, rpm.livna.org, JPackage, GStreamer, FreshRPMS) - Red Hat 7.2, 7.3 (basic, updated, FreshRPMS, JPackage) - Red Hat 7.0, 7.1 (basic, updated, FreshRPMS) - SuSE 8.1/8.2/9 - Connectiva - Yellowdog Linux 3.0 (basic, updated, FreshRPMS) - Yellowdog Linux 2.3 (basic, updated, FreshRPMS) - Dave/Dina 0.0/oven/fridge Read the README included in the distribution for a better overview. CHANGES ------- - add yum support (various people) - Work with SELinux enabled (Thomas) - Remove all matches when removing packages (Rudi) - Better config error handling (Ville) - Fix filename munging on collect (Jeff) - add support for FC3 and FC4 (Thomas) - Create /dev/null properly (Rudi) - Add runuser support (Rudi) - support fedora extra's "dist" var (Thomas) - Fix urlgrab exceptions (Ville) - upgrade packages before snapshotting build list (Thomas) WHY WOULD YOU USE IT -------------------- mach is helpful: - to create minimal chroot environments to jail services in - to create clean packages for distributions - to catch spec file mistakes, missing buildrequires, and more INFORMATION ----------- mach's homepage is at http://thomas.apestaart.org/projects/mach/ mach is hosted on SourceForge; the project page is http://www.sourceforge.net/projects/mach/ There is a mailing list for development and use of mach. See http://lists.sourceforge.net/lists/listinfo/mach-devel QUICKSTART ---------- a) On a Fedora 4 Core system, install the mach rpm from http://thomas.apestaart.org/download/mach b) su - mach c) mach setup base d) mach chroot poke around a bit in the fresh root e) exit f) mach rebuild http://ayo.freshrpms.net/fedora/linux/4/i386/SRPMS.core/vorbis-tools-1.0.1-6.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! MAILING LIST ------------ A mailing list has been set up for discussion of mach use and development. Check http://lists.sourceforge.net/lists/listinfo/mach-devel for information. The list is low-volume. BUGS ---- Please report all bugs to the mailing list mentioned above. Always state what platform you are running on, if it's a clean install or somehow updated, how I can reproduce the bug, and output of a run of the failed command with -d (debugging). CONTRIBUTORS ------------ Contributors to this release include - Thomas Vander Stichele - Ville Skytt? - Jeff Pitman - Rudi Chiarito From jfrieben at freesurf.fr Mon Aug 1 17:41:41 2005 From: jfrieben at freesurf.fr (jfrieben at freesurf.fr) Date: Mon, 1 Aug 2005 19:41:41 +0200 (CEST) Subject: SuperSavage/IXC 64 hassle making DRI and SELinux work together In-Reply-To: <42EA0147.4020601@redhat.com> References: <42EA0147.4020601@redhat.com> Message-ID: <57269.194.94.224.254.1122918101.squirrel@jose.freesurf.fr> Hi Dan, thanks a lot for pointing this out. However, this seems to be due to "SELinux" being work in progress. I have reinstalled FC4 from scratch, installed alle available updates, and still obtain the same AVC messages without even touching DRI. However, here the good news: after reinstalling FC4 from scratch, both of "xorg-x11-6.8.2-37" (FC4 updates) and "xorg-x11-6.8.99.16-0.homebrewn" (derived from M. Harris unstable "xorg-x11-6.8.99.14-3" SRPM) allow for direct rendering even when "SELinux" is active. The latter has the advantage of being up to date in terms of OpenGL compatibility. It seems that the successive updates of various packages, probably "audit" and "selinux-policy-targeted", messed up the system. I still have the "mtrr: base(0xe4000000) is not aligned on a size(0x5000000) boundary" warning, but apparently, it does not matter. Cheers, -Joachim > This looks like you have some kind of labeleing problem. utmp is > labled init_var_run_t, it should be initrc_var_run_t > You may want to relabel. > Have you tried to boot with enforcing=0? > > Dan > > -- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From florin at andrei.myip.org Mon Aug 1 20:46:26 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 01 Aug 2005 13:46:26 -0700 Subject: include talkback in Firefox? Message-ID: <1122929186.21040.45.camel@stantz.corp.sgi.com> Any chance talkback could be included in Firefox, maybe as a separate package installed optionally? (don't know if that's possible at all, just assuming) The thing is, I stumbled upon a page that could reproducibly crash the latest Firefox on FC4. But before the problem could be reproduced by the FF developers, the page was modified and the browser does not crash anymore: https://bugzilla.mozilla.org/show_bug.cgi?id=302675 Because talkback is not enabled in FC4's Firefox, I couldn't provide useful info to the developers. -- Florin Andrei http://florin.myip.org/ From mrsam at courier-mta.com Mon Aug 1 23:33:30 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 01 Aug 2005 19:33:30 -0400 Subject: Regression in the 2.6.12 kernel errata? Message-ID: I was just about to enter this into Bugzilla, but thought to run this by some eyeballs first. Perhaps I'm missing something, but the strace appears to show a weird bug in IPv6 handling in the 2.6.12 errata. When I go back to the 2.6.11 kernel I cannot reproduce this problem any more. FWIW, I'm seeing this on the x86_64 kernel. It's possible that this is a 64bit-related bug. I think I'm seeing a regression problem in the 2.6.12's handling of IPv6. After rebooting back to the 2.6.11 kernel, I no longer see the following problem: Scenario: Existing socket on file descriptor #3 Create IPv4 socket on file descriptor #4 dup2(4, 3) connect(3) to an IPv4 address. The connect works when old fd 3 is an IPv4 socket, and fails when the original fd 3 is an IPv6 socket. In both cases fd 4 gets created as an IPv4 socket, so after the dup2() fd 3 should always be an IPv4 socket, and connect() receives an IPv4 address. After the socket is duped, fd 3 should always be an IPv4 socket, so the connect should be valid. Here's an strace of when fd 3 is originally an IPv4 socket, and everything goes correctly: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4 getsockname(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, [22595719865040912]) = 0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 dup2(4, 3) = 3 close(4) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ?}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaabb7000 write(1, "Checking existing socket\n", 25) = 25 getsockname(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, [8589934608]) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(1080), sin_addr=inet_addr("192.168.0.5")}, 16) = -1 EINPROGRESS (Operation now in progress) The first getsockname() shows an IPv4 socket on fd #3, the second getsockname() still shows an IPv4 socket on fd #3, and the connect() goes through. Now, if the original fd #3 is an IPv6 socket, the connect breaks: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4 getsockname(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [22595719865040924]) = 0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0 dup2(4, 3) = 3 close(4) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ?}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaabb7000 write(1, "Checking existing socket\n", 25) = 25 getsockname(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, [8589934608]) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(1080), sin_addr=inet_addr("192.168.0.5")}, 28) = -1 EINVAL (Invalid argument) Can anyone tell me why this is _not_ a kernel bug? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mitr at volny.cz Mon Aug 1 23:41:49 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 02 Aug 2005 01:41:49 +0200 Subject: Regression in the 2.6.12 kernel errata? In-Reply-To: References: Message-ID: <42EEB33D.7070108@volny.cz> Hello, Sam Varshavchik wrote: > Here's an strace of when fd 3 is originally an IPv4 socket, and > everything goes correctly: > > connect(3, {sa_family=AF_INET, sin_port=htons(1080), > sin_addr=inet_addr("192.168.0.5")}, 16) = -1 EINPROGRESS (Operation now > in progress) > > Now, if the original fd #3 is an IPv6 socket, the connect breaks: > > connect(3, {sa_family=AF_INET, sin_port=htons(1080), > sin_addr=inet_addr("192.168.0.5")}, 28) = -1 EINVAL (Invalid argument) Note that in the first case the third argument to connect is 16 (sizeof struct sockaddr_in), but in the second case it is 28 (sizeof struct sockaddr_in6). While the base kernel allows larger sizes than (sizeof struct sockaddr_in), SELinux performs additional checks which prohibit this, see e.g. #158234. > Can anyone tell me why this is _not_ a kernel bug? It does break existing applications, but the definite specification is probably SUSv3, which seems to allow this behavior. Mirek From mrsam at courier-mta.com Tue Aug 2 00:04:29 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 01 Aug 2005 20:04:29 -0400 Subject: Regression in the 2.6.12 kernel errata? References: <42EEB33D.7070108@volny.cz> Message-ID: Miloslav Trmac writes: >> connect(3, {sa_family=AF_INET, sin_port=htons(1080), >> sin_addr=inet_addr("192.168.0.5")}, 28) = -1 EINVAL (Invalid argument) > Note that in the first case the third argument to connect is 16 > (sizeof struct sockaddr_in), but in the second case it is 28 (sizeof > struct sockaddr_in6). While the base kernel allows larger sizes > than (sizeof struct sockaddr_in), SELinux performs additional checks > which prohibit this, see e.g. #158234. Aha. >> Can anyone tell me why this is _not_ a kernel bug? > It does break existing applications, but the definite specification is > probably SUSv3, which seems to allow this behavior. > Mirek Well, sockaddr_in already has some padding right off the bat? But, mystery solved anyway? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dalive at flashmail.com Tue Aug 2 02:05:49 2005 From: dalive at flashmail.com (Arthur Pemberton) Date: Mon, 01 Aug 2005 22:05:49 -0400 Subject: include talkback in Firefox? In-Reply-To: <1122929186.21040.45.camel@stantz.corp.sgi.com> References: <1122929186.21040.45.camel@stantz.corp.sgi.com> Message-ID: <42EED4FD.20107@flashmail.com> Florin Andrei wrote: >Any chance talkback could be included in Firefox, maybe as a separate >package installed optionally? (don't know if that's possible at all, >just assuming) > >The thing is, I stumbled upon a page that could reproducibly crash the >latest Firefox on FC4. But before the problem could be reproduced by the >FF developers, the page was modified and the browser does not crash >anymore: > >https://bugzilla.mozilla.org/show_bug.cgi?id=302675 > >Because talkback is not enabled in FC4's Firefox, I couldn't provide >useful info to the developers. > > > Have you tried for a google cache of the page? From caillon at redhat.com Tue Aug 2 04:45:21 2005 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 02 Aug 2005 00:45:21 -0400 Subject: include talkback in Firefox? In-Reply-To: <1122929186.21040.45.camel@stantz.corp.sgi.com> References: <1122929186.21040.45.camel@stantz.corp.sgi.com> Message-ID: <42EEFA61.5060609@redhat.com> Florin Andrei wrote: > Any chance talkback could be included in Firefox, maybe as a separate > package installed optionally? (don't know if that's possible at all, > just assuming) > > The thing is, I stumbled upon a page that could reproducibly crash the > latest Firefox on FC4. But before the problem could be reproduced by the > FF developers, the page was modified and the browser does not crash > anymore: > > https://bugzilla.mozilla.org/show_bug.cgi?id=302675 > > Because talkback is not enabled in FC4's Firefox, I couldn't provide > useful info to the developers. > As far as I know, talkback is not open source. From caillon at redhat.com Tue Aug 2 04:52:58 2005 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 02 Aug 2005 00:52:58 -0400 Subject: include talkback in Firefox? In-Reply-To: <1122929186.21040.45.camel@stantz.corp.sgi.com> References: <1122929186.21040.45.camel@stantz.corp.sgi.com> Message-ID: <42EEFC2A.50007@redhat.com> Florin Andrei wrote: > Because talkback is not enabled in FC4's Firefox, I couldn't provide > useful info to the developers. > Also, there's a feature in Firefox which lets you save an entire webpage including images and other external objects. In fact, it is the default behavior when you save a webpage. Next time, just save it and attach it. The crash should be reproducible that way. From nicu_fedora at nicubunu.ro Tue Aug 2 06:09:41 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 02 Aug 2005 09:09:41 +0300 Subject: include talkback in Firefox? In-Reply-To: <42EEFC2A.50007@redhat.com> References: <1122929186.21040.45.camel@stantz.corp.sgi.com> <42EEFC2A.50007@redhat.com> Message-ID: <42EF0E25.1080109@nicubunu.ro> Christopher Aillon wrote: > Florin Andrei wrote: > >> Because talkback is not enabled in FC4's Firefox, I couldn't provide >> useful info to the developers. >> > > Also, there's a feature in Firefox which lets you save an entire webpage > including images and other external objects. In fact, it is the default > behavior when you save a webpage. Next time, just save it and attach > it. The crash should be reproducible that way. AFAIK, Mozilla save the page in the form is rendered, not exactly as it is on the server (there are some differences, for example in the case of broken HTML) Anyway, if Firefox crash before finishing loading the page is not possible to save it from inside of Firefox, a better option is to download the page with something like wget. -- nicu Open Clip Art Library: http://www.openclipart.org From buildsys at redhat.com Tue Aug 2 11:22:21 2005 From: buildsys at redhat.com (Build System) Date: Tue, 2 Aug 2005 07:22:21 -0400 Subject: rawhide report: 20050802 changes Message-ID: <200508021122.j72BMLm2002982@porkchop.devel.redhat.com> New package scim-anthy SCIM IMEngine for anthy for Japanese input New package scim-tables SCIM Generic Table IMEngine Updated Packages: GConf-1.0.9-17 -------------- * Sun Jul 31 2005 Florian La Roche - remove gconftool to build with newest rpm * Wed Mar 02 2005 Mark McLoughlin 1.0.9-16 - Rebuild with gcc4 * Fri Aug 06 2004 Tim Waugh 1.0.9-15 - Fixed underquoted m4 definitions. anthy-6700b-2 ------------- * Mon Aug 01 2005 Akira TAGOH - 6700b-2 - added Provides: anthy-libs = %{name}-%{version} arts-8:1.4.2-1 -------------- * Mon Aug 01 2005 Than Ngo 8:1.4.2-1 - update to 1.4.2 carol-0:1.8.9.3-1jpp_5fc ------------------------ * Mon Aug 01 2005 Gary Benson 0:1.8.9.3-1jpp_5fc - Remove explicit references to jacorb and jonathan-rmi. - Switch to aot-compile-rpm. - Build on ia64, ppc64, s390 and s390x. ckermit-8.0.211-2 ----------------- * Fri Jul 29 2005 Peter Vrabec 8.0.211-2 - use openpty library (#156417,#164465) ethereal-0.10.12-4 ------------------ * Mon Aug 01 2005 Jindrich Novy 0.10.12-4 - additional PIE fix for s390, s390x - rebuilt * Sun Jul 31 2005 Florian La Roche - rebuild for new libpcap * Thu Jul 28 2005 Jindrich Novy 0.10.12-2 - package /usr/sbin/randpkt - compile ethereal and tethereal as PIE (#160780) evolution-2.3.6.1-3 ------------------- * Mon Aug 01 2005 David Malcolm - 2.3.6.1-3 - Improved version of evolution-2.3.5.1-fix-150458.patch (#150458) evolution-connector-2.3.6-2 --------------------------- * Mon Aug 01 2005 David Malcolm - 2.3.6-2 - bump evo_major from 2.2 to 2.4 - Removed the various test programs (they no longer exist in the upstream tarball) - Renamed more instances of "ximian-connector" to "evolution-exchange" as appropriate. * Thu Jul 28 2005 David Malcolm - 2.3.6-1 - 2.3.6 * Tue Jul 26 2005 David Malcolm - 2.3.5-2 - increase evolution requirement to 2.3.5.1 fonts-japanese-0.20050222-6 --------------------------- * Tue Aug 02 2005 Akira TAGOH - 0.20050222-6 - contain Sazanami fonts. gaim-1:1.4.0-6.fc5 ------------------ * Mon Aug 01 2005 Warren Togami 1:1.4.0-6 - FC5+ bash regex replace for -fstack-protector-all (mharris) gnupg-1.4.1-3 ------------- * Thu May 05 2005 Nalin Dahyabhai 1.4.1-3 - fix the execstack problem correctly this time (arjanv) * Thu Apr 28 2005 Nalin Dahyabhai 1.4.1-2 - add -Wa,--noexecstack back to CFLAGS when invoking configure, the --enable-noexecstack flag only seems to affect asm modules * Wed Mar 16 2005 Nalin Dahyabhai 1.4.1-1 - update to 1.4.1 jonathan-core-0:4.1-1jpp_4fc ---------------------------- * Mon Aug 01 2005 Gary Benson 0:4.1-1jpp_4fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. jonathan-jeremie-0:4.2-1jpp_4fc ------------------------------- * Mon Aug 01 2005 Gary Benson 0:4.2-1jpp_4fc - Remove explicit references to jacorb and jonathan-rmi. - Switch to aot-compile-rpm. - Build on ia64, ppc64, s390 and s390x. jotm-0:2.0.5-1jpp_3fc --------------------- * Mon Aug 01 2005 Gary Benson 0:2.0.5-1jpp_3fc - Remove explicit references to jacorb and jonathan-rmi. - Switch to aot-compile-rpm. - Build on ia64, ppc64, s390 and s390x. kdelibs-6:3.4.2-1 ----------------- * Mon Aug 01 2005 Than Ngo 6:3.4.2-1 - update to 3.4.2 kernel-2.6.12-1.1446_FC5 ------------------------ * Tue Aug 02 2005 Dave Jones - 2.6.13-rc5 * Mon Aug 01 2005 Dave Jones - 2.6.13-rc4-git4 * Mon Aug 01 2005 Dave Jones - 2.6.13-rc4-git3 libpng10-1.0.18-3 ----------------- * Sun Jul 31 2005 Florian La Roche - build with newest rpm, rm -f libpng.so libtermcap-2.0.8-42 ------------------- * Sun Jul 31 2005 Florian La Roche - build with newest rpm libxslt-1.1.14-3 ---------------- * Sun Jul 31 2005 Florian La Roche - package all python files to build with newest rpm logrotate-3.7.2-1 ----------------- * Mon Aug 01 2005 Peter Vrabec 3.7.2-1 - new upstream release monolog-0:1.8.6-1jpp_5fc ------------------------ * Mon Aug 01 2005 Gary Benson 0:1.8.6-1jpp_5fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. ncpfs-2.2.4-9 ------------- * Sun Jul 31 2005 Florian La Roche - package mount.ncp.8 netdump-0.7.10-4 ---------------- * Mon Aug 01 2005 Jeff Moyer 0.7.10-4 - Updated README and netdump-server.8 files to specify that the script files must be executable and owned by netdump. - Removed funky copyright characters from netdump and netdump-server man pages. - If the sysconfig file specifies all of the needed information, then don't fail in the event that the server is either unreachable or the name is unresolvable at load time. * Tue Apr 05 2005 Florian La Roche 0.7.7-6 - add a "exit 0" to some scripts * Wed Mar 02 2005 Jeff Moyer 0.7.7-5 - Add support for auto-detecting the first hop on the way to the netdump server. openswan-2.3.1-4 ---------------- * Sun Jul 31 2005 Florian La Roche - remove sysv startup links to build with current rpm pam-0.80-6 ---------- * Mon Aug 01 2005 Tomas Mraz 0.80-6 - add option to pam_loginuid to require auditd * Fri Jul 29 2005 Tomas Mraz 0.80-5 - fix NULL dereference in pam_userdb (#164418) * Tue Jul 26 2005 Tomas Mraz 0.80-4 - fix 64bit bug in pam_pwdb - don't crash in pam_unix if pam_get_data fail redhat-rpm-config-8.0.38-1 -------------------------- * Mon Aug 01 2005 Elliot Lee - 8.0.38-1 - Add -Wall into cflags * Mon Aug 01 2005 Elliot Lee - 8.0.37-1 - Patch from Uli: enable stack protector, fix sparc & ppc cflags scim-1.4.0-3 ------------ * Mon Aug 01 2005 Jens Petersen - 1.4.0-3 - bring back the xinput alternatives settings for now - quote the postun readlink test (wcalee at myrealbox.com, #164674) * Sat Jul 30 2005 Ryo Dairiki - 1.4.0-2.2 - don't explicitly --disable-ld-version-script since this turns on versioning * Sat Jul 30 2005 Jens Petersen - 1.4.0-2.1 - own the system xinput.d dir selinux-policy-strict-1.25.3-10 ------------------------------- * Mon Aug 01 2005 Dan Walsh 1.25.3-10 - Fixes for saslauthd, cyrus communication * Thu Jul 28 2005 Dan Walsh 1.25.3-9 - Bump for FC4 selinux-policy-targeted-1.25.3-10 --------------------------------- * Mon Aug 01 2005 Dan Walsh 1.25.3-10 - Fixes for saslauthd, cyrus communication * Thu Jul 28 2005 Dan Walsh 1.25.3-9 - Bump for FC4 system-config-soundcard-1.2.12-4 -------------------------------- * Wed Jul 27 2005 Martin Stransky 0.0.18-8 - Requires w3m (bug #164798). Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 scim-anthy - 0.5.3-5.x86_64 requires /usr/lib64/scim-1.0/update-xinput-scim gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) Broken deps for i386 ---------------------------------------------------------- GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 scim-anthy - 0.5.3-5.i386 requires /usr/lib/scim-1.0/update-xinput-scim dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 Broken deps for s390x ---------------------------------------------------------- libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) quota - 1:3.12-6.s390x requires kernel >= 0:2.4 selinux-policy-targeted - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) scim-anthy - 0.5.3-5.s390x requires /usr/lib64/scim-1.0/update-xinput-scim dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 selinux-policy-strict-sources - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 selinux-policy-targeted-sources - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 Broken deps for ia64 ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) quota - 1:3.12-6.ia64 requires kernel >= 0:2.4 hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11 selinux-policy-strict-sources - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 rgmanager - 1.9.31-3.ia64 requires ccs pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21 selinux-policy-strict - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0 nfs-utils - 1.0.7-10.ia64 requires kernel >= 0:2.2.14 scim-anthy - 0.5.3-5.ia64 requires /usr/lib/scim-1.0/update-xinput-scim dhcp - 11:3.0.3-1.ia64 requires kernel >= 0:2.2.18 lvm2 - 2.01.13-1.0.ia64 requires kernel >= 0:2.6 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2 selinux-policy-targeted - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) Broken deps for ppc ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 scim-anthy - 0.5.3-5.ppc requires /usr/lib/scim-1.0/update-xinput-scim Broken deps for ppc64 ---------------------------------------------------------- scim-anthy - 0.5.3-5.ppc64 requires /usr/lib64/scim-1.0/update-xinput-scim gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 firstboot - 1.3.43-1.noarch requires system-config-display control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config Broken deps for s390 ---------------------------------------------------------- sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 selinux-policy-targeted-sources - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 selinux-policy-strict-sources - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.3-10.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 scim-anthy - 0.5.3-5.s390 requires /usr/lib/scim-1.0/update-xinput-scim libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 From caillon at redhat.com Tue Aug 2 15:15:25 2005 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 02 Aug 2005 11:15:25 -0400 Subject: include talkback in Firefox? In-Reply-To: <42EF0E25.1080109@nicubunu.ro> References: <1122929186.21040.45.camel@stantz.corp.sgi.com> <42EEFC2A.50007@redhat.com> <42EF0E25.1080109@nicubunu.ro> Message-ID: <42EF8E0D.3040900@redhat.com> On 08/02/2005 02:09 AM, Nicu Buculei wrote: > Christopher Aillon wrote: > >> Florin Andrei wrote: >> >>> Because talkback is not enabled in FC4's Firefox, I couldn't provide >>> useful info to the developers. >>> >> >> Also, there's a feature in Firefox which lets you save an entire >> webpage including images and other external objects. In fact, it is >> the default behavior when you save a webpage. Next time, just save >> it and attach it. The crash should be reproducible that way. > > > AFAIK, Mozilla save the page in the form is rendered, not exactly as > it is on the server (there are some differences, for example in the > case of broken HTML) It should be saving it exactly as it came in on the wire. If not, then something broke somewhere, and you should probably file a bug. > Anyway, if Firefox crash before finishing loading the page is not > possible to save it from inside of Firefox, a better option is to > download the page with something like wget. Sure. One can generally find another build which doesn't crash (or temporarily, another browser which doesn't crash -- I've resorted on occasion to using Konqueror and friends to get web "snapshots" when all else failed). From ph18 at cornell.edu Tue Aug 2 17:10:08 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 02 Aug 2005 13:10:08 -0400 Subject: 4KSTACKS et al... Message-ID: <42EFA8F0.4030309@cornell.edu> A few weeks ago we had a 4-way amd64 web server running RHEL 4 that crashed sporadically -- nothing left in the syslog. up2date didn't find a new kernel, so I just downloaded and installed the latest kernel from kernel.org and the system has been stable ever since. I'm not sure if I could have gone to RH for support because Cornell has a site license, and even if I had a direct line to RH management, it would take me more time to explain the problem than it would take to try a mainstream kernel. Overall, I'm quite happy with the four-digit revision mainstream linux kernels. We had a crash on our main machine that left a stack trace, did some research on the web, found that this had been fixed in 2.6.11.something, upgraded the kernel, case closed. People are willing to pay $$ to get an "enterprise" product which is reliable, and supported, but this is another case where the generic product turns out to be more reliable than the branded product, and looking at what's happening with Fedora, I've got a lot of concern that RH's pursuit of innovation will always lead to a kernel long on gee-whiz features and short on reliability. Crashes mean I get calls from the NOC at 4am, and god forbid that my toddler hears the phone ring or me walking down the stairs, because I'll need to entertain him while dealing with the crash and for the rest of the morning. Then a week later I go to netcraft and they say my uptime is seven days and I feel like a jerk because the whole world knows about my problems. I think there are two reasons for the RHEL 4 instability: (i) the quarterly release cycle means that I have to wait for bug fixes -- and if you're running a non-x86 architecture, it seems like 2.6 is shaking out bugs at a high rate, and (ii) RH is aggressively pushing new features. I really don't know what's in RHEL 4 (it would take me more time to look at the patches than it would to revert to mainstream) but the activation of 4KSTACKS in Fedora is one of those changes that reduces reliably. I've been looking, and I've never found out what benefit that 4KSTACKS has for end users. The kernel team is sensible, so I'm sure that there are some real benefits, but looking at the problem reports and at the attitudes of some people on this list, I start to wonder if it's just a vindicitive attempt to put an end to ndiswrappers. (I'd really love to see an explanation of the benefits of 4KSTACKS) The real trouble is that 4KSTACKS problems aren't in kernel modules per se, but really are in the combination of modules that are running. Yeah, maybe they can get reiserfs running under 4KSTACKS, but what if you're running an NFSv4 server with all the whizzy options turned on, and IPv6 with tunneling and it's a reiserfs filesystem and you're using LVM and RAID and a particularly funky SCSI driver, what then? By adopting 4KSTACKS early, Fedora has helped shake out problems with 4KSTACKS, but when 4KSTACKS becomes the main option in the mainstream kernel, we'll see people dealing with weird problems that happen sporadically on certain setups for years to come. We seem to have one of the worst workloads in the world, and the last thing I need is more crashes. From arjanv at redhat.com Tue Aug 2 17:21:00 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 02 Aug 2005 19:21:00 +0200 Subject: 4KSTACKS et al... In-Reply-To: <42EFA8F0.4030309@cornell.edu> References: <42EFA8F0.4030309@cornell.edu> Message-ID: <1123003260.3247.38.camel@laptopd505.fenrus.org> On Tue, 2005-08-02 at 13:10 -0400, Paul A Houle wrote: > A few weeks ago we had a 4-way amd64 web server running RHEL 4 that 1) this is the fedora list not the RHEL list. 2) If you have an amd64 you are running the 64 bit OS, right? The 64 bit OS has 8K stacks > I really don't know what's in RHEL 4 (it would take me more time to > look at the patches than it would to revert to mainstream) but the > activation of 4KSTACKS in Fedora is one of those changes that reduces > reliably. > > I've been looking, and I've never found out what benefit that > 4KSTACKS has for end users. 1) more threads in userspace 2) FAR FAR less vm problems > By adopting 4KSTACKS early, Fedora has helped shake out problems > with 4KSTACKS, but when 4KSTACKS becomes the main option in the it already is a main option, and soon to be the only option. but given that you don't seem to be running a 4K stacks kernel at all anyway (eg 64 bit OS) I wonder what your flame is really about... -------------- 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 nutello at sweetness.com Tue Aug 2 17:21:26 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 2 Aug 2005 19:21:26 +0200 Subject: 4KSTACKS et al... In-Reply-To: <42EFA8F0.4030309@cornell.edu> References: <42EFA8F0.4030309@cornell.edu> Message-ID: <20050802172126.GG10261@plain.rackshack.net> On Tue, Aug 02, 2005 at 01:10:08PM -0400, Paul A Houle wrote: > I've been looking, and I've never found out what benefit that > 4KSTACKS has for end users. The kernel team is sensible, so I'm sure I don't think x86_64 has 4KSTACKS, has it? It should be 8K for 64 bit kernels. I even just looked at the 2.6.12 config file in /boot and can't find any mention of stack sizes. -- Rudi From piet at www.piet.net Tue Aug 2 17:25:44 2005 From: piet at www.piet.net (Piet Delaney) Date: Tue, 02 Aug 2005 10:25:44 -0700 Subject: FC4 update problem on x86_64 in /usr/share/rhn/up2date_client/repoBackends/genericRepo.py", line 17, in __getattr__ Message-ID: <1123003544.7595.7.camel@hammer.piet.net> Updates on two i386 systems went fine (other than GUI not indicating that updates were available). My x86_64/AMD Hammer system is hanging when the python scripts go to get the rpm modules. Here's the msg in the /var/log/up2date file: -- [Tue Aug 2 10:01:54 2005] up2date File "/usr/sbin/up2date", line 1265, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 891, in main gui.main() File "/usr/share/rhn/up2date_client/gui.py", line 2158, in main gtk.mainloop() File "/usr/src/build/535816-x86_64/install/usr/lib64/python2.4/site-packages/gtk-2.0/gtk/__init__.py", line 70, in __call__ File "/usr/share/rhn/up2date_client/gui.py", line 1822, in doRetrieval self.setRetrievalProgress) File "/usr/share/rhn/up2date_client/up2date.py", line 178, in getPackage buf = rpcServer.doCall(repos.getPackage, pkg, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpcServer.py", line 316, in doCall ret = apply(method, args, kwargs) File "/usr/share/rhn/up2date_client/repoDirector.py", line 36, in getPackage return self.handlers[channel['type']].getPackage(pkg, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/rpmSource.py", line 186, in getPackage package = source.getPackage(pkg, MsgCallback, progressCallback) File "/usr/share/rhn/up2date_client/repoBackends/repomdRepo.py", line 251, in getPackage self.initRepo() File "/usr/share/rhn/up2date_client/repoBackends/repomdRepo.py", line 123, in initRepo log.trace_me() File "/usr/share/rhn/up2date_client/up2dateLog.py", line 35, in trace_me x = traceback.extract_stack() [Tue Aug 2 10:01:59 2005] up2date File "/usr/share/rhn/up2date_client/gui.py", line 1822, in doRetrieval self.setRetrievalProgress) File "/usr/share/rhn/up2date_client/up2date.py", line 192, in getPackage progressCallback) File "/usr/share/rhn/up2date_client/rpcServer.py", line 316, in doCall ret = apply(method, args, kwargs) File "/usr/share/rhn/up2date_client/repoDirector.py", line 39, in getPackageSource return self.handlers[channel['type']].getPackageSource(channel, pkg, msgCallback, progressCallback) File "/usr/share/rhn/up2date_client/repoBackends/genericRepo.py", line 17, in __getattr__ self.psc.setSourceInstances(self.sources[name]) I tried deleting the rpm's in /var/spool/up2date/ and it didn't help, thought deleting the hdr files might be worth trying next. -piet From davej at redhat.com Tue Aug 2 17:43:16 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 2 Aug 2005 13:43:16 -0400 Subject: 4KSTACKS et al... In-Reply-To: <42EFA8F0.4030309@cornell.edu> References: <42EFA8F0.4030309@cornell.edu> Message-ID: <20050802174316.GD18410@redhat.com> On Tue, Aug 02, 2005 at 01:10:08PM -0400, Paul A Houle wrote: > People are willing to pay $$ to get an "enterprise" product which is > reliable, and supported, but this is another case where the generic > product turns out to be more reliable than the branded product, This is entirely subjective. Look at the bugzilla stats for proof of this. Open kernel bugs: FC3: 616 FC4: 256 rawhide: 170 RHEL4: 189 RHEL4 bugs get fixed very quickly. It being a supported product, engineers devote time to fixing those problems. Fedora bugs have no guarantee of being fixed in the next update, or even the next release. A lot of Fedora bugs that get closed happen just due to the rebasing to a newer upstream release. Looking at the numbers month over month, Fedora bugs go up, RHEL bugs go down. This may disappoint a lot of Fedora users, but this is the harsh reality. A lot of the kernel bugs filed against Fedora are also bugs that are relevant upstream. More recently, I've been pushing these bugs to their upstream maintainers in an attempt to try and beat down the volume. (Things were actually even worse a few months back). Your complaint seems to be that some bug you hit was fixed upstream, but not in RHEL, yet at the same time you mention that you never filed a RHEL bug on this. We'll work on psychic-bug-reporting for RHEL5, but in the meantime, we need to know when things break to fix them. Whilst we watch upstream, and backport some fixes, with upstream committing ~4000 changes per point release, its not feasible to catch everything. Changes also need to be evaluated in terms of risk before they go into a RHEL release. > and looking at what's happening with Fedora, I've got a lot of concern that > RH's pursuit of innovation will always lead to a kernel long on gee-whiz > features and short on reliability. gee-whiz features ? Exec-shield and Tux are the only real big-ticket items we carry these days in Fedora, and they're in RHEL too. Fedora kernels are a lot closer to mainline than any of the RHL kernels were. > I think there are two reasons for the RHEL 4 instability: (i) the > quarterly release cycle means that I have to wait for bug fixes We do push out interim updates for really important problems (typically dataloss/corruption/security issues). > -- and > if you're running a non-x86 architecture, it seems like 2.6 is shaking > out bugs at a high rate, upstream is also introducing regressions at a high rate. After rebasing the FC3 kernel last week to 2.6.12, from 2.6.11, ~50 bugs got closed, and ~50 new ones got filed. This pattern has been going on for the last few releases. Some releases are worse than others, and we get more new issues than we get closed issues. > and (ii) RH is aggressively pushing new features. Such as ? > I really don't know what's in RHEL 4 (it would take me more time to > look at the patches than it would to revert to mainstream) The GA release was very close to a Fedora kernel circa FC3. Subsequent updates have diverged. > but the activation of 4KSTACKS in Fedora is one of those changes that > reduces reliably. Funny, our evidence shows the contrary. FC2 was plagued with VM problems that magically went away when we moved to 4K stacks, and separate interrupt stacks. The fact is that on 32bit x86, you never had all of that 8kb stack anyway. > I've been looking, and I've never found out what benefit that > 4KSTACKS has for end users. Better reliability under load. > I start to wonder if > it's just a vindicitive attempt to put an end to ndiswrappers. (I'd > really love to see an explanation of the benefits of 4KSTACKS) If you're using ndiswrapper, there's your problem right there. Windows drivers expect a 12KB stack. So in certain circumstances, you're out of luck even with 4k stacks disabled. Dave From jfontain at free.fr Tue Aug 2 18:14:53 2005 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Tue, 02 Aug 2005 20:14:53 +0200 Subject: 4KSTACKS et al... In-Reply-To: <20050802174316.GD18410@redhat.com> References: <42EFA8F0.4030309@cornell.edu> <20050802174316.GD18410@redhat.com> Message-ID: <42EFB81D.70109@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you very much indeed Dave, for a knowledgeable, instructing, honest and reassuring reply, which gives me great confidence in the Red Hat/Fedora project. Sincerely, - -- Jean-Luc Fontaine http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC77gckG/MMvcT1qQRAnFJAJ4zDUBtM5rDy8YxUpFH7qodooX+OwCeN3gq Kl47Q3ZEgvvbHC19NeO8Z3A= =9pGS -----END PGP SIGNATURE----- From piet at www.piet.net Tue Aug 2 19:52:53 2005 From: piet at www.piet.net (Piet Delaney) Date: Tue, 02 Aug 2005 12:52:53 -0700 Subject: FC4 update problem on x86_64 in /usr/share/rhn/up2date_client/repoBackends/genericRepo.py", line 17, in __getattr__ In-Reply-To: <1123003544.7595.7.camel@hammer.piet.net> References: <1123003544.7595.7.camel@hammer.piet.net> Message-ID: <1123012374.7595.11.camel@hammer.piet.net> On Tue, 2005-08-02 at 10:25 -0700, Piet Delaney wrote: Seems the problem was my enabling source rpm's to be downloaded. I'd prefer to download the src rpm with the updates, especially the kernel src. Any reason this isn't worthy of being fixed? -piet > Updates on two i386 systems went fine (other than GUI not indicating > that updates were available). My x86_64/AMD Hammer system is hanging > when the python scripts go to get the rpm modules. Here's the msg in > the /var/log/up2date file: > > > -- [Tue Aug 2 10:01:54 2005] up2date File "/usr/sbin/up2date", line > 1265, in ? > sys.exit(main() or 0) > File "/usr/sbin/up2date", line 891, in main > gui.main() > File "/usr/share/rhn/up2date_client/gui.py", line 2158, in main > gtk.mainloop() > File > "/usr/src/build/535816-x86_64/install/usr/lib64/python2.4/site-packages/gtk-2.0/gtk/__init__.py", line 70, in __call__ > File "/usr/share/rhn/up2date_client/gui.py", line 1822, in > doRetrieval > self.setRetrievalProgress) > File "/usr/share/rhn/up2date_client/up2date.py", line 178, in > getPackage > buf = rpcServer.doCall(repos.getPackage, pkg, msgCallback, > progressCallback) > File "/usr/share/rhn/up2date_client/rpcServer.py", line 316, in > doCall > ret = apply(method, args, kwargs) > File "/usr/share/rhn/up2date_client/repoDirector.py", line 36, in > getPackage > return self.handlers[channel['type']].getPackage(pkg, msgCallback, > progressCallback) > File "/usr/share/rhn/up2date_client/rpmSource.py", line 186, in > getPackage > package = source.getPackage(pkg, MsgCallback, progressCallback) > File "/usr/share/rhn/up2date_client/repoBackends/repomdRepo.py", line > 251, in getPackage > self.initRepo() > File "/usr/share/rhn/up2date_client/repoBackends/repomdRepo.py", line > 123, in initRepo > log.trace_me() > File "/usr/share/rhn/up2date_client/up2dateLog.py", line 35, in > trace_me > x = traceback.extract_stack() > > [Tue Aug 2 10:01:59 2005] up2date File > "/usr/share/rhn/up2date_client/gui.py", line 1822, in doRetrieval > self.setRetrievalProgress) > File "/usr/share/rhn/up2date_client/up2date.py", line 192, in > getPackage > progressCallback) > File "/usr/share/rhn/up2date_client/rpcServer.py", line 316, in > doCall > ret = apply(method, args, kwargs) > File "/usr/share/rhn/up2date_client/repoDirector.py", line 39, in > getPackageSource > return self.handlers[channel['type']].getPackageSource(channel, pkg, > msgCallback, progressCallback) > File "/usr/share/rhn/up2date_client/repoBackends/genericRepo.py", > line 17, in __getattr__ > self.psc.setSourceInstances(self.sources[name]) > > > I tried deleting the rpm's in /var/spool/up2date/ and it didn't help, > thought deleting the hdr files might be worth trying next. > > -piet > -- Piet Delaney Rocky Mountain Linux Lab From ph18 at cornell.edu Tue Aug 2 20:06:45 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 02 Aug 2005 16:06:45 -0400 Subject: 4KSTACKS et al... In-Reply-To: <20050802174316.GD18410@redhat.com> References: <42EFA8F0.4030309@cornell.edu> <20050802174316.GD18410@redhat.com> Message-ID: <42EFD255.5000108@cornell.edu> Dave Jones wrote: > >Your complaint seems to be that some bug you hit was fixed upstream, >but not in RHEL, yet at the same time you mention that you never >filed a RHEL bug on this. We'll work on psychic-bug-reporting >for RHEL5, but in the meantime, we need to know when things break >to fix them. Whilst we watch upstream, and backport some fixes, >with upstream committing ~4000 changes per point release, its >not feasible to catch everything. Changes also need to be evaluated >in terms of risk before they go into a RHEL release. > > > It would have taken me a great deal of time to have filed a useful bug report. I had no stack trace and I can say little more about it than has already been said, other than the hardware details of the machine. The only cheap way that you could (possibly) resolve the problem for me is to send me a kernel that has more recent patches from upstream and hope that the problem goes away. (Maybe that's what you do -- if you do, than it might ~not~ be a waste of time for me to go through your process.) On the other hand, my experience is that going straight to upstream solves problems rapidly and lets me go back to work. Yes, I can be an 'altruist' and spend more of my time helping RH fix a product that costs $2000 per server, or I can get the job done. If my quick method didn't resolve my problem then I'd have the choice of going to LKML with a mainstream kernel (meaning I can have an e-mail message read by someone who knows how to fix a race condition) or submitting a bug report to RH (which starts with a password reset for my redhat.com account, and, if RH is like any other vendor, having to explain my problem several times to people who don't know how to fix race conditions.) I'll consider going back to an RHEL kernel if the machine in question has problems that I can't fix my way, and then I'll try your process. >We do push out interim updates for really important problems >(typically dataloss/corruption/security issues). > > > That's great, but it doesn't solve my problem. Anyway, I know that these problems aren't easy, and they are things that don't really fit into one box (reliability of RHEL, Fedora and the Linux kernel) but I've really got a lot of concerns about reliability and there are days that I envy the guys in the other office who work with a SPARC/Solaris stack. I've got concerns that bad things are going to come in the upstream kernel -- for instance, there's a lot of cleanup and simplification of the network stack in 2.6.13 that will be nice a year from now, but they'll probably drop something on the floor, so I'll probably wait until 2.6.13.something to upgrade. The funny thing is that the world is increasingly believing the Linux is "ready for the enterprise" in a time that I'm questioning my faith. From fedora-devel at tlarson.com Tue Aug 2 20:55:14 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 02 Aug 2005 14:55:14 -0600 Subject: 4KSTACKS et al... In-Reply-To: <42EFD255.5000108@cornell.edu> References: <42EFA8F0.4030309@cornell.edu> <20050802174316.GD18410@redhat.com> <42EFD255.5000108@cornell.edu> Message-ID: <42EFDDB2.1000501@tlarson.com> Paul A Houle wrote: > On the other hand, my experience is that going straight to upstream > solves problems rapidly and lets me go back to work. Yes, I can be an > 'altruist' and spend more of my time helping RH fix a product that costs > $2000 per server, or I can get the job done. At the risk of sounding trollish, I'd like to voice some of the words that the rest of us are muttering under our breath-- You're complaining about RHEL on the Fedora devel mailing list. And despite the fact that this has already been brought to your attention, your reply does not even hint as to why you think that this behavior is okay, but rather contains even more complaints about a distro that this list does not support. In Fedora Land (which is where you're posting, by the way) the user is expected to help out. "Altruism" has nothing to do with it--the bugs that users identify will be fixed first because those are the bugs we know about. Dave has been surprisingly gracious and has addressed your concerns to a degree far beyond what your original (flaming) post would merit. Yet the scathing and disparaging nature of your reply indicates a level of disdainful indifference that simply does not belong in this community. Please understand that here we talk about Fedora (not RHEL), and here we behave as a friendly community. Please do not badger the talent. Dave does a very good job and we all appreciate his help. From buildsys at redhat.com Wed Aug 3 11:21:28 2005 From: buildsys at redhat.com (Build System) Date: Wed, 3 Aug 2005 07:21:28 -0400 Subject: rawhide report: 20050803 changes Message-ID: <200508031121.j73BLS0r003105@porkchop.devel.redhat.com> Updated Packages: cairo-0.6.0-2 ------------- * Tue Aug 02 2005 Kristian H??gsberg - 0.6.0-2 - Add cairo-0.6.0-font-options-to-scaled-font.patch to make sure font cache eviction works correctly (#164664). checkpolicy-1.25.3-1 -------------------- * Thu Jul 28 2005 Dan Walsh 1.25.3-1 - Update to NSA Release * Merged hierarchy check fix from Joshua Brindle (Tresys). ethereal-0.10.12-5 ------------------ * Tue Aug 02 2005 Jindrich Novy 0.10.12-5 - add -fstack-protector-all to CFLAGS (#164830) firstboot-1.3.44-1 ------------------ * Tue Aug 02 2005 Chris Lumens 1.3.44-1 - Allow modules to specify that the system should be rebooted after firstboot has run via the needsReboot module attribute. - Enable checking for capital letters in usernames again to be consistent with system-config-users (#164852). - Use libuser for adding users again (#164160). - Rebuilt translations. gamin-0.1.3-1 ------------- * Tue Aug 02 2005 Daniel Veillard 0.1.3-1 - Fix to compile on older gcc versions - Inotify back-end changes and optimizations - Debug ouput cleanup, pid and process name reports - Dropped kernel monitor bugfix - Removed the old glist copy used for debugging - Maintain mounted filesystems knowledge, and per fstype preferences glib2-2.7.5-1 ------------- * Tue Aug 02 2005 Matthias Clasen - 2.7.5-1 - Update to 2.7.5 gperf-3.0.1-7 ------------- * Tue Aug 02 2005 Karsten Hopp 3.0.1-7 - Gcc4 fix (Tomo Vuckovic) #164885 guile-5:1.6.7-3 --------------- inn-2.4.2-4 ----------- * Tue Aug 02 2005 Karsten Hopp 2.4.2-4 - rebuild with current rpm - include .pyc and pyo files created by /usr/lib/rpm/brp-python-bytecompile iprutils-2.0.15.3-1 ------------------- * Tue Aug 02 2005 Paul Nasrat - 2.0.15.3-1 - update to 2.0.15.3-1 * Wed May 11 2005 Paul Nasrat - 2.0.14.2-1 - update to 2.0.14.2 (#156934) * Thu Feb 24 2005 Paul Nasrat - 2.0.13.7-1 - Update to 2.0.13.7 (#144654) - Project moved location to sourceforge joram-0:4.1.5-1jpp_4fc ---------------------- * Tue Aug 02 2005 Gary Benson 0:4.1.5-1jpp_4fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. kdebase-6:3.4.2-1 ----------------- * Mon Aug 01 2005 Than Ngo 3.4.2-1 - update to 3.4.2 * Mon Jul 04 2005 Than Ngo 3.4.1-4 - fix uninitialized variable warning #16231 * Mon Jun 27 2005 Than Ngo 3.4.1-3 - apply patch to fix genkdmconfig crash #161751 kdemultimedia-6:3.4.2-1 ----------------------- * Tue Aug 02 2005 Than Ngo 6:3.4.2-1 - update to 3.4.2 kdepim-6:3.4.2-1 ---------------- * Tue Aug 02 2005 Than Ngo 6:3.4.2-1 - update 3.4.2 - apply patch to fix kmail bug, kde#109003 lam-2:7.1.1-7.FC5 ----------------- * Tue Aug 02 2005 Jason Vas Dias - 2:7.1.1-7 - fix bug 164898: 7.0.6's '--enable-trillium' -> 7.1.1's '--with-trillium' * Fri Jul 08 2005 Jason Vas Dias - 2:7.1.1-6 - fix bug 161028 - build for FC4 updates libpixman-0.1.6-1 ----------------- * Tue Aug 02 2005 Kristian H??gsberg - 0.1.6-1 - Update to 0.1.6. openoffice.org-1:1.9.122-1.2.0.fc5 ---------------------------------- * Tue Aug 02 2005 Caolan McNamara - 1:1.9.122-1 - next version * Tue Aug 02 2005 Caolan McNamara - 1:1.9.121-4 - return of ppc policycoreutils-1.25.4-1 ------------------------ * Thu Jul 28 2005 Dan Walsh 1.25.4-1 - Update to match NSA * Changed semodule* to link with libsemanage. scim-anthy-0.5.3-6 ------------------ * Tue Aug 02 2005 Akira TAGOH - 0.5.3-6 - removed PreReq as well. selinux-policy-strict-1.25.3-11 ------------------------------- * Tue Aug 02 2005 Dan Walsh 1.25.3-11 - Fix NetworkManager-vpnc stuff selinux-policy-targeted-1.25.3-11 --------------------------------- * Tue Aug 02 2005 Dan Walsh 1.25.3-11 - Fix NetworkManager-vpnc stuff udev-063-4 ---------- * Tue Aug 02 2005 Harald Hoyer - 063-4 - fixed typo for tape devices and changed mode to 0660 Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) lvm2 - 2.01.13-1.0.ia64 requires kernel >= 0:2.6 dhcp - 11:3.0.3-1.ia64 requires kernel >= 0:2.2.18 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 quota - 1:3.12-6.ia64 requires kernel >= 0:2.4 sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2 gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 nfs-utils - 1.0.7-10.ia64 requires kernel >= 0:2.2.14 rgmanager - 1.9.31-3.ia64 requires ccs gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390 ---------------------------------------------------------- selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 lvm2 - 2.01.13-1.0.s390 requires kernel >= 0:2.6 nfs-utils - 1.0.7-10.s390 requires kernel >= 0:2.2.14 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 Broken deps for s390x ---------------------------------------------------------- sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.13-1.0.s390x requires kernel >= 0:2.6 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 nfs-utils - 1.0.7-10.s390x requires kernel >= 0:2.2.14 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- ppc64-utils - 0.7-9.ppc64 requires yaboot gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config system-config-keyboard - 1.2.6-2.noarch requires pyxf86config gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 firstboot - 1.3.44-1.noarch requires system-config-display dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) From gmaxwell at gmail.com Thu Aug 4 03:25:40 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 3 Aug 2005 23:25:40 -0400 Subject: Fedora Internationalization: Hacked by Chinese? Message-ID: A friend of mine directed me to a recent blog entry of his: http://iblog.chomped.org/index.php?p=108 Fedora ships with the flags removed from the KDE keyboard mapping selector. This causes a practical issue for users that switch between US and US/international bindings which could be resolved in some way other than the flags. What I find interesting is that his bugzilla entry for the issue (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164705) was closed as a duplicate of a bug which is not publicly available (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=70235). It appears, from Ian's blog entry, that the flags were removed as a result of pressure from the Chinese government because the included flag set included a Taiwanese flag. I can't confirm this because I can't actually see that bug. If this is actually the case, I find it somewhat concerning: Making decisions to diverge from upstream in secret as a result of such pressure will only serve to substantiate the concerns of those who are worried that Free Software will be used to suppress human rights, and whom wish to further bifurcate the state of free software licensing by introducing additional license restrictions to inhibit such behavior by distributors. The Taiwan/China issue is nuanced and complex, and certainly not as simple of a matter as Ian makes it out to be... But I agree with him that this feels wrong. I'd like to know if his statements about the reason for this change are correct, and why was this change undertaken behind closed doors? I'll leave it to the professional paranoids to dream up slippery slope scenarios. From buildsys at redhat.com Thu Aug 4 11:19:02 2005 From: buildsys at redhat.com (Build System) Date: Thu, 4 Aug 2005 07:19:02 -0400 Subject: rawhide report: 20050804 changes Message-ID: <200508041119.j74BJ2ON023551@porkchop.devel.redhat.com> New package scim-hangul Hangul Input Method Engine for SCIM Updated Packages: GConf2-2.11.90-1 ---------------- * Wed Aug 03 2005 Ray Strode 2.11.90-1 - Newer upstream version MySQL-python-1.2.0-2 -------------------- * Wed Aug 03 2005 Karsten Hopp 1.2.0-2 - package all python files. INSTALLED_FILES doesn't contain files created by the brp-python-bytecompile script ant-0:1.6.2-3jpp_14fc --------------------- * Wed Aug 03 2005 Gary Benson 0:1.6.2-3jpp_14fc - Allow subpackages not in Fedora to be installed from JPackage. - Obsolete the jmf subpackage (#164389). * Thu Jul 21 2005 Gary Benson 0:1.6.2-3jpp_13fc - Disable the style and xmlvalidate tasks on ppc64 and s390x (#163689). * Mon Jul 18 2005 Gary Benson 0:1.6.2-3jpp_12fc - Built on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm (also BC-compiles subpackages). - Remove the jmf subpackage since it wasn't being built anyway. audit-1.0.1-2 ------------- * Wed Aug 03 2005 Steve Grubb 1.0.1-1 - Add check for fields that cannot be used with syscall entry in auditctl - Make auditctl not tolerate duplicate rule and watches - Remove uid check in ausearch * Tue Aug 02 2005 Steve Grubb 1.0-1 - Update sample CAPP config - Remove warning for trimming file path in auditctl - Make auditctl tolerate duplicate rule and watches - auditd has new option so it doesn't overwrite log files - Fixed bug in autrace that was reporting bad descriptor bug-buddy-1:2.11.1-1 -------------------- * Wed Aug 03 2005 Ray Strode - 2.11.1-1 - Update to upstream version 2.11.1 control-center-1:2.11.90-1 -------------------------- * Wed Aug 03 2005 Matthias Clasen - 1:2.11.90-1 - New upstream version device-mapper-1.01.04-1.0 ------------------------- * Tue Aug 02 2005 Alasdair Kergon - 1.01.04-1.0 - Fix dmsetup handling with empty table (needed by multipath). eclipse-pydev-1:0.9.3_fc-11 --------------------------- * Tue Aug 02 2005 Jeff Pound 0.9.3_fc-11 - Add patch to make python 2.4 default (bz#164847). eel2-2.11.90-1 -------------- * Wed Aug 03 2005 Matthias Clasen 2.11.90-1 - New upstream version * Tue Jul 12 2005 David Zeuthen - Fix BuildRequires (#163043) gedit-1:2.10.3-1 ---------------- * Wed Aug 03 2005 Ray Strode - 2.10.3-1 - Update to upstream version 2.10.3 * Mon Jun 13 2005 Ray Strode 1:2.10.2-6 - Remove some patches that are already upstream glib2-2.7.6-1 ------------- * Wed Aug 03 2005 Matthias Clasen - 2.7.6-1 - Update to 2.7.6 gnome-menus-2.11.90-1 --------------------- * Wed Aug 03 2005 Ray Strode - 2.11.90-1 - Update to upstream version 2.11.90 jonas-0:4.3.3-1jpp_8fc ---------------------- * Tue Aug 02 2005 Gary Benson - 4.3.3-1jpp_8fc - BC-compile. kernel-2.6.12-1.1448_FC5 ------------------------ * Wed Aug 03 2005 Dave Jones - 2.6.13-rc5-git1 libsepol-1.7.9-1 ---------------- * Tue Aug 02 2005 Dan Walsh 1.7.9-1 - Upgrade to latest from NSA * Enabled further compiler warning flags and fixed them. * Merged user, context, port records patch from Ivan Gyurdiev. * Merged key extract function patch from Ivan Gyurdiev. * Merged mls_context_to_sid bugfix from Ivan Gyurdiev. lvm2-2.01.14-1.0 ---------------- * Thu Aug 04 2005 Alasdair Kergon - 2.01.14-1.0 - And a few more bugs fixes. ncurses-5.4-18 -------------- * Wed Aug 03 2005 Karsten Hopp 5.4-18 - rebuild with new rpm net-tools-1.60-56 ----------------- * Wed Aug 03 2005 Radek Vokal 1.60-56 - fixed buffer overflow in arp (#164695) nfs-utils-1.0.7-12 ------------------ * Tue Aug 02 2005 Steve Dickson 1.0.7-12 - Changed useradd to use new -l flag (bz149407) - 64bit fix in gssd code (bz 163139) - updated broken dependencies - updated rquotad to compile with latest quota version. * Thu May 26 2005 Steve Dickson 1.0.7-8 - Fixed subscripting problem in idmapd (bz 158188) * Thu May 19 2005 Steve Dickson 1.0.7-7 - Fixed buffer overflow in rpc.svcgssd (bz 114288) pam_krb5-2.1.8-2 ---------------- * Wed Aug 03 2005 Nalin Dahyabhai - 2.1.8-2 - rebuild * Wed Aug 03 2005 Nalin Dahyabhai - 2.1.8-1 - backport ccache-refresh-on-setcred-with-reinitialize from HEAD (#153257) - return PAM_USER_UNKNOWN from account management if we didn't participate in authenticating the user (#164794) pyOpenSSL-0.6-1.p24.5 --------------------- * Wed Aug 03 2005 Karsten Hopp 0.6-1.p24.5 - current rpm creates .pyo files, include them in filelist readahead-1:1.1-1.16 -------------------- * Tue Aug 02 2005 Dave Jones - Fix inverted free memory test in startup script. (#164872) strace-4.5.13-1 --------------- * Wed Aug 03 2005 Roland McGrath - 4.5.13-1 - Fix setsockopt decoding on 64-bit (#162449). - Fix typos in socket option name strings (#161578). - Display more IPV6 socket options by name (#162450). - Don't display inappropriate syscalls for -e trace=file (#159340). - New selector type -e trace=desc for file-descriptor using calls (#159400). - Fix 32-bit old_mmap syscall decoding on x86-64 (#162467, #164215). - Fix errors detaching from multithreaded process on interrupt (#161919). - Note 4.5.12 fix for crash handling bad signal numbers (#162739). system-config-securitylevel-1.6.1-2 ----------------------------------- * Tue Aug 02 2005 Chris Lumens 1.6.1-2 - Fix packaging. * Tue Aug 02 2005 Chris Lumens 1.6.1-1 - Fix a typo in SELinux booleans (#164889). - Remove trusted devices section from firewall page. - Simplify choices on SELinux page (#164701). - Split firewall and SELinux into separate firstboot pages. - Require reboot after firstboot is done if SELinux options were changed. systemtap-0.2.1-2 ----------------- * Wed Aug 03 2005 Roland McGrath - 0.2.1-2 - Rebuilt for FC5. * Wed Aug 03 2005 Roland McGrath - 0.2.1-1 - New version 0.2.1, various fixes. ttmkfdir-3.0.9-17 ----------------- * Wed Aug 03 2005 Jens Petersen - 3.0.9-17 - replace ttmkfdir-3.0.9-defautl_enc_size.patch and ttmkfdir-3.0.9-crashplus.patch with ttmkfdir-3.0.9-fix-crash.patch to fix missing native encodings of fonts (Akira Tagoh, #143941) - buildrequire flex - add ttmkfdir-3.0.9-warnings.patch to silence most of compiler warnings udev-063-5 ---------- * Tue Aug 02 2005 Bill Nottingham - 063-5 - add rule to allow function id matching for pcmcia after loading modules (#164665) unzip-5.51-12 ------------- * Wed Aug 03 2005 Ivana Varekova 5.51-12 - fix bug 164928 - TOCTOU issue in unzip vlock-1.3-20 ------------ * Wed Aug 03 2005 Karel Zak 1.3-20 - #164950 - call account management and credential reinitialization functions (patch by Nalin Dahyabhai) Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- sysstat - 5.0.5-10.fc.ia64 requires kernel >= 0:2.2.16-21 quota - 1:3.12-6.ia64 requires kernel >= 0:2.4 hal - 0.5.3-2.ia64 requires kernel >= 0:2.6.11 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 nfs-utils - 1.0.7-12.ia64 requires kernel >= 0:2.2.14 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 dhcp - 11:3.0.3-1.ia64 requires kernel >= 0:2.2.18 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 arptables_jf - 0.0.8-5.ia64 requires kernel >= 0:2.4.0 gkrellm - 2.2.7-1.ia64 requires kernel >= 0:2.6.2 libpcap - 14:0.9.3-2.ia64 requires kernel >= 0:2.2.0 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 rgmanager - 1.9.31-3.ia64 requires ccs gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) Broken deps for s390x ---------------------------------------------------------- lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) Broken deps for s390 ---------------------------------------------------------- prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- system-config-keyboard - 1.2.6-2.noarch requires pyxf86config control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 firstboot - 1.3.44-1.noarch requires system-config-display gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) Broken deps for ppc ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 From jspaleta at gmail.com Thu Aug 4 11:21:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 4 Aug 2005 07:21:15 -0400 Subject: Fedora Internationalization: Hacked by Chinese? In-Reply-To: References: Message-ID: <604aa79105080404215897d6cb@mail.gmail.com> On 8/3/05, Gregory Maxwell wrote: > A friend of mine directed me to a recent blog entry of his: > http://iblog.chomped.org/index.php?p=108 > > Fedora ships with the flags removed from the KDE keyboard mapping > selector. This causes a practical issue for users that switch between > US and US/international bindings which could be resolved in some way > other than the flags. > > What I find interesting is that his bugzilla entry for the issue > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164705) was > closed as a duplicate of a bug which is not publicly available > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=70235). > > It appears, from Ian's blog entry, that the flags were removed as a > result of pressure from the Chinese government because the included > flag set included a Taiwanese flag. I can't confirm this because I > can't actually see that bug. 70235 is a really really old bug... it definitely pre-dates fedora. I bet if you try hard enough and look back through the archives for redhat-list or redhat-beta-list I bet you can find a smattering of discussion around the time that change was introduced.. like 3 years ago. The decision was made in the context of rhl and rhel when fedora wasn't even a glimmer in anyone's beer yet. So how about you look at the decision to pull the flags and the decision to make the bug report private in the correct context for the timeframe when those original decisions were made...before this was a community project. Fedora isn't completely new, and has inherited decisions. Whether or not its worthy bringing this specific decision backup for discussion and review in the context of Fedora is an open question. But I will say that I find the original blog entry and this post a little bit over-the-top with reference to the impact this decision is going to have on larger issues concerning human rights and I'm not sure it's going to be productive conversation with such grandiose scope being encouraged by one of the protagonists. -jef"3 years ago....."spaleta From alan at redhat.com Thu Aug 4 13:03:59 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 4 Aug 2005 09:03:59 -0400 Subject: Fedora Internationalization: Hacked by Chinese? In-Reply-To: References: Message-ID: <20050804130359.GG31053@devserv.devel.redhat.com> On Wed, Aug 03, 2005 at 11:25:40PM -0400, Gregory Maxwell wrote: > It appears, from Ian's blog entry, that the flags were removed as a > result of pressure from the Chinese government because the included > flag set included a Taiwanese flag. I can't confirm this because I > can't actually see that bug. We pulled the flags for a variety of reasons - the Taiwan/China thing is only one. Many flags carry huge amounts of historical and political baggage that are best avoided. Names usually (but not always) don't carry the same baggage around as people will read a name and interpret it to their belief rather than the way flags and maps tend to be interpreted. Alan From twaugh at redhat.com Thu Aug 4 13:14:27 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 4 Aug 2005 14:14:27 +0100 Subject: Help needed with fonts problem Message-ID: <20050804131427.GC7718@redhat.com> Hi, I'm scratching my head looking at ghostscript bug #163231, "vertical writing is messed up": https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163231 I don't really know where to start with this. Would someone with more knowledge about fonts than I mind taking a quick look? There are two problems. From comment #7: 1. wrong glyph are used. I mean even if CMap for the vertical writing, such as -V is specified, the glyphs for the horizontal writing is used. Actually the fonts has the glyphs for the vertical writing and freetype is just rendering it with given glyph ID. so gs8 must passes the proper glyph ID to freetype. 2. baseline of glyphs are wrong. basically it's different between the horizontal writing and the vertical writing. but gs8 always calculates it with the horizontal writing's baseline. this isn't also freetype fault, but gs8 fault. Thanks, Tim. */ -------------- 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 Thu Aug 4 13:38:27 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 4 Aug 2005 08:38:27 -0500 Subject: Fedora Internationalization: Hacked by Chinese? In-Reply-To: <604aa79105080404215897d6cb@mail.gmail.com> References: <604aa79105080404215897d6cb@mail.gmail.com> Message-ID: <20050804133827.GC1130459@hiwaay.net> Once upon a time, Jeff Spaleta said: > The decision was made in the context of rhl and rhel when fedora > wasn't even a glimmer in anyone's beer yet. So how about you look at > the decision to pull the flags and the decision to make the bug report > private in the correct context for the timeframe when those original > decisions were made...before this was a community project. Well, if a new bug was closed as a dupe of an old (private) bug, it pulls the old bug up to the present, implying it is relevant to Fedora (but we can't see because it is a private bug). It would be nice if public bugs were not closed as dupes of private bugs (except for security bugs that should only be private for a short time). If RH wants to do that for RHEL, that is their business, but I'd say it is a bad idea for Fedora. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jsnell at iki.fi Thu Aug 4 04:43:10 2005 From: jsnell at iki.fi (Juho Snellman) Date: Thu, 4 Aug 2005 04:43:10 +0000 (UTC) Subject: Exec-shield and memory randomization References: <1122682010.4422.74.camel@linux.droberts.com> <1122726925.3388.15.camel@localhost.localdomain> <1122750604.4422.93.camel@linux.droberts.com> <1122831990.3286.12.camel@laptopd505.fenrus.org> <1122852436.4422.104.camel@linux.droberts.com> <20050801054848.GA31253@devserv.devel.redhat.com> Message-ID: wrote: > Nowhere.. it's on for everything. The theory is that randomisation doesn't > do anything "odd" at all that couldn't happen otherwise. (by for example > upgrading a few libraries or so) I believe brk randomization is a new effect. > So I'd like to get to the bottom of why this app is breaking SBCL needs to mmap lots of non-relocatable data into certain memory spaces, and the randomized heap location can overlap with one of these spaces. I'm sure that making such assumptions about the memory layout is technically incorrect. Still, this is rather unfortunate as there seems to be no reasonable way to get the ELF loader to reserve memory ranges. -- Juho Snellman From carljohan at design.chalmers.se Thu Aug 4 15:12:26 2005 From: carljohan at design.chalmers.se (Carl-Johan Kjellander) Date: Thu, 04 Aug 2005 17:12:26 +0200 Subject: BUG: stateless-linux can't reboot or shutdown, RPC 101 error Message-ID: <42F2305A.1020802@design.chalmers.se> We've been annoyed that stateless-linux machines with / mounted as NFS couldn't reboot. It always barfed with infinite RPC 101 errors. Reason: It's bad to unmount / before you are done rebooting. Quick and dirty solution: rm /etc/rc{0,6}.d/{K75netfs,K90network} Alternate solution: Make stateless-snapshooter remove these files. The best solution would probably be to make netfs and network stateless aware and not shut down networking or unmount / if / is mounted as NFS. The reason is that it's ok to unmount SMB or CIFS filesystems and problably even most NFS filsesystems except / and maybe /usr. /cjk -- begin 644 carljohan_at_kjellander_dot_com.gif Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I Y*=NX,2 at OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6HQI6:7"A>Y?):D2^*U at NCV RLZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L` -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3296 bytes Desc: S/MIME Cryptographic Signature URL: From prarit at sgi.com Thu Aug 4 15:38:28 2005 From: prarit at sgi.com (Prarit Bhargava) Date: Thu, 04 Aug 2005 11:38:28 -0400 Subject: ia64 arch for kernel rpm removed? Message-ID: <42F23674.2080608@sgi.com> Just noticed that the latest nightly fedora development builds weren't building ia64 any more ... wondering if there was a reason for this change in the kernel rpm's spec file? #ExclusiveArch: noarch %{all_x86} x86_64 ppc64 ppc64iseries sparc sparc64 ppc s390 s390x ia64 ExclusiveArch: noarch %{all_x86} x86_64 ppc64 sparc sparc64 ppc P. From davej at redhat.com Thu Aug 4 17:00:43 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 4 Aug 2005 13:00:43 -0400 Subject: ia64 arch for kernel rpm removed? In-Reply-To: <42F23674.2080608@sgi.com> References: <42F23674.2080608@sgi.com> Message-ID: <20050804170043.GF22886@redhat.com> On Thu, Aug 04, 2005 at 11:38:28AM -0400, Prarit Bhargava wrote: > Just noticed that the latest nightly fedora development builds weren't > building ia64 any more ... wondering if there was a reason for this change > in the kernel rpm's spec file? > > #ExclusiveArch: noarch %{all_x86} x86_64 ppc64 ppc64iseries sparc sparc64 > ppc s390 s390x ia64 > ExclusiveArch: noarch %{all_x86} x86_64 ppc64 sparc sparc64 ppc IA64 build host was dead last time I tried. I'll reenable for todays build and see if someones resurrected it. Dave From roland at redhat.com Thu Aug 4 20:46:49 2005 From: roland at redhat.com (Roland McGrath) Date: Thu, 4 Aug 2005 13:46:49 -0700 (PDT) Subject: Exec-shield and memory randomization In-Reply-To: Juho Snellman's message of Thursday, 4 August 2005 04:43:10 +0000 Message-ID: <20050804204649.2D24A180980@magilla.sf.frob.com> > Still, this is rather unfortunate as there seems to be no reasonable way > to get the ELF loader to reserve memory ranges. The specified way is to use a PT_LOAD segment with p_flags 0, yielding a PROT_NONE mapping that your program can mmap over or munmap after startup. If this does not work right, then please file a bug about it. From twaugh at redhat.com Thu Aug 4 22:20:41 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 4 Aug 2005 23:20:41 +0100 Subject: Printing system proposal In-Reply-To: <1110172278.2451.100.camel@localhost.localdomain> References: <422B77D4.9010408@beryllium.net> <604aa791050306140651612405@mail.gmail.com> <422B82F8.5050000@beryllium.net> <604aa7910503061509567ac811@mail.gmail.com> <1110172278.2451.100.camel@localhost.localdomain> Message-ID: <20050804222040.GH7718@redhat.com> On Mon, Mar 07, 2005 at 12:11:18AM -0500, John (J5) Palmieri wrote: > There have been numerous pitfalls I had run into in designing the > current desktop auto configuration system in FC3 and have insight > into what needs to be fixed which was somewhat reflected in the > previous thread. One month is not a huge amount of time as I don't > think everything will be fixed in the core 4 time frame. Well, it won't be fixed in the Fedora Core 5 time frame either unfortunately. We seriously need to be designing a new printer configuration tool or mechanism now to stand any chance of getting this fixed for Fedora Core 6. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From raven at themaw.net Fri Aug 5 01:22:55 2005 From: raven at themaw.net (Ian Kent) Date: Fri, 5 Aug 2005 09:22:55 +0800 (WST) Subject: 4KSTACKS et al... In-Reply-To: <42EFA8F0.4030309@cornell.edu> References: <42EFA8F0.4030309@cornell.edu> Message-ID: On Tue, 2 Aug 2005, Paul A Houle wrote: > A few weeks ago we had a 4-way amd64 web server running RHEL 4 that > crashed sporadically -- nothing left in the syslog. up2date didn't find > a new kernel, so I just downloaded and installed the latest kernel from > kernel.org and the system has been stable ever since. I'm not sure if I > could have gone to RH for support because Cornell has a site license, > and even if I had a direct line to RH management, it would take me more > time to explain the problem than it would take to try a mainstream kernel. > > Overall, I'm quite happy with the four-digit revision mainstream > linux kernels. We had a crash on our main machine that left a stack > trace, did some research on the web, found that this had been fixed in > 2.6.11.something, upgraded the kernel, case closed. > > People are willing to pay $$ to get an "enterprise" product which is > reliable, and supported, but this is another case where the generic > product turns out to be more reliable than the branded product, and > looking at what's happening with Fedora, I've got a lot of concern that > RH's pursuit of innovation will always lead to a kernel long on gee-whiz > features and short on reliability. Crashes mean I get calls from the > NOC at 4am, and god forbid that my toddler hears the phone ring or me > walking down the stairs, because I'll need to entertain him while > dealing with the crash and for the rest of the morning. Then a week > later I go to netcraft and they say my uptime is seven days and I feel > like a jerk because the whole world knows about my problems. > > I think there are two reasons for the RHEL 4 instability: (i) the > quarterly release cycle means that I have to wait for bug fixes -- and > if you're running a non-x86 architecture, it seems like 2.6 is shaking > out bugs at a high rate, and (ii) RH is aggressively pushing new features. > > I really don't know what's in RHEL 4 (it would take me more time to > look at the patches than it would to revert to mainstream) but the > activation of 4KSTACKS in Fedora is one of those changes that reduces > reliably. > > I've been looking, and I've never found out what benefit that > 4KSTACKS has for end users. The kernel team is sensible, so I'm sure > that there are some real benefits, but looking at the problem reports > and at the attitudes of some people on this list, I start to wonder if > it's just a vindicitive attempt to put an end to ndiswrappers. (I'd > really love to see an explanation of the benefits of 4KSTACKS) > > The real trouble is that 4KSTACKS problems aren't in kernel modules > per se, but really are in the combination of modules that are running. > Yeah, maybe they can get reiserfs running under 4KSTACKS, but what if > you're running an NFSv4 server with all the whizzy options turned on, > and IPv6 with tunneling and it's a reiserfs filesystem and you're using > LVM and RAID and a particularly funky SCSI driver, what then? > > By adopting 4KSTACKS early, Fedora has helped shake out problems > with 4KSTACKS, but when 4KSTACKS becomes the main option in the > mainstream kernel, we'll see people dealing with weird problems that > happen sporadically on certain setups for years to come. We seem to > have one of the worst workloads in the world, and the last thing I need > is more crashes. I find it hard to understand why it is so important to remove this option, making the kernel 4K stacks only, as was proposed not so long ago. I also find it hard to understand why it is such a problem having a larger stack. As you point out, as software evolves it ultimately becomes more complex. If the developers design needs it and the software is reliable and efficient (aka performs well) then why not. A quick caclulation. 2000*4k is about 8M in say 1G at least. Not a large percentage overhead I think. But of course I don't know the reasoning behind the change (as I missed the thread), I just get a little burned by the consequences from time to time, like yourself. Ian From raven at themaw.net Fri Aug 5 01:26:10 2005 From: raven at themaw.net (Ian Kent) Date: Fri, 5 Aug 2005 09:26:10 +0800 (WST) Subject: 4KSTACKS et al... In-Reply-To: <1123003260.3247.38.camel@laptopd505.fenrus.org> References: <42EFA8F0.4030309@cornell.edu> <1123003260.3247.38.camel@laptopd505.fenrus.org> Message-ID: On Tue, 2 Aug 2005, Arjan van de Ven wrote: > > > > I've been looking, and I've never found out what benefit that > > 4KSTACKS has for end users. > > 1) more threads in userspace > 2) FAR FAR less vm problems OK. Sounds like some homework for me! Ian From davej at redhat.com Fri Aug 5 01:43:12 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 4 Aug 2005 21:43:12 -0400 Subject: 4KSTACKS et al... In-Reply-To: References: <42EFA8F0.4030309@cornell.edu> Message-ID: <20050805014312.GF2241@redhat.com> On Fri, Aug 05, 2005 at 09:22:55AM +0800, Ian Kent wrote: > I also find it hard to understand why it is such a problem having a larger > stack. As you point out, as software evolves it ultimately becomes more > complex. If the developers design needs it and the software is reliable > and efficient (aka performs well) then why not. > > A quick caclulation. > > 2000*4k is about 8M in say 1G at least. > > Not a large percentage overhead I think. Now try finding 2000 _contiguous_ pairs of pages after the machine has been up for a while, under load. Memory fragmentation makes this a really nasty problem, and the VM eats its own head after repeatedly scanning every page in the system. Dave From jsnell at iki.fi Fri Aug 5 03:12:13 2005 From: jsnell at iki.fi (Juho Snellman) Date: Fri, 5 Aug 2005 03:12:13 +0000 (UTC) Subject: Exec-shield and memory randomization References: <20050804204649.2D24A180980@magilla.sf.frob.com> Message-ID: wrote: >> Still, this is rather unfortunate as there seems to be no reasonable way >> to get the ELF loader to reserve memory ranges. > > The specified way is to use a PT_LOAD segment with p_flags 0, yielding a > PROT_NONE mapping that your program can mmap over or munmap after startup. > If this does not work right, then please file a bug about it. I don't feel it's a reasonable solution. (But I recognize that others might think I'm being unreasonable here). * Linker scripts are too fragile. You can't specify "use the internal default script, but add this PHDR and this section", so you need to copy the default, munge it in strange ways to actually make it work, and then hope that the next glibc/binutils/etc update doesn't break the script. We've had problems like this with the linker script on the platform where we're forced to use it for other reasons. Case in point, the script you posted a couple of years ago at doesn't work any more, but requires moving the "required" PHDR below the other two PT_LOADs, and adding a FILEHDR option to it. This seems like a bizarre change, but that's the only way the script would accept more than two PT_LOADs. * @nobits PT_LOADed segments don't just reserve the address space, but also count as allocated space for overcommit purposes (with the default 0 in /proc/sys/vm/overcommit_memory) unlike memory allocated with mmap. (Apparently because the protection bits are discarded, http://bugzilla.kernel.org/show_bug.cgi?id=2255) We need to reserve large spaces and also run on low-memory machines. * Even if both of the above problems were to be fixed in the next release of FC, we'd still need to find a solution that also works on older Linux installations. The other common suggestion of writing/borrowing a ld.so replacement doesn't seem much more palatable. -- Juho Snellman From subsolar at subsolar.com Fri Aug 5 03:27:43 2005 From: subsolar at subsolar.com (Paul) Date: Thu, 04 Aug 2005 22:27:43 -0500 Subject: 4KSTACKS et al... In-Reply-To: <20050805014312.GF2241@redhat.com> References: <42EFA8F0.4030309@cornell.edu> <20050805014312.GF2241@redhat.com> Message-ID: <1123212463.31808.5.camel@localhost> On Thu, 2005-08-04 at 21:43 -0400, Dave Jones wrote: > On Fri, Aug 05, 2005 at 09:22:55AM +0800, Ian Kent wrote: > > I also find it hard to understand why it is such a problem having a larger > > stack. As you point out, as software evolves it ultimately becomes more > > complex. If the developers design needs it and the software is reliable > > and efficient (aka performs well) then why not. > > > > A quick caclulation. > > > > 2000*4k is about 8M in say 1G at least. > > > > Not a large percentage overhead I think. > > Now try finding 2000 _contiguous_ pairs of pages after the machine > has been up for a while, under load. Memory fragmentation makes > this a really nasty problem, and the VM eats its own head after > repeatedly scanning every page in the system. I thought I heard that there was some work being done in the upstream kernel to have a process "defrag" memory in the background. This would help alleviate this problem on systems with long up-times. Paul From raven at themaw.net Fri Aug 5 04:55:57 2005 From: raven at themaw.net (Ian Kent) Date: Fri, 5 Aug 2005 12:55:57 +0800 (WST) Subject: 4KSTACKS et al... In-Reply-To: <1123212463.31808.5.camel@localhost> References: <42EFA8F0.4030309@cornell.edu> <20050805014312.GF2241@redhat.com> <1123212463.31808.5.camel@localhost> Message-ID: On Thu, 4 Aug 2005, Paul wrote: > On Thu, 2005-08-04 at 21:43 -0400, Dave Jones wrote: > > On Fri, Aug 05, 2005 at 09:22:55AM +0800, Ian Kent wrote: > > > I also find it hard to understand why it is such a problem having a larger > > > stack. As you point out, as software evolves it ultimately becomes more > > > complex. If the developers design needs it and the software is reliable > > > and efficient (aka performs well) then why not. > > > > > > A quick caclulation. > > > > > > 2000*4k is about 8M in say 1G at least. > > > > > > Not a large percentage overhead I think. > > > > Now try finding 2000 _contiguous_ pairs of pages after the machine > > has been up for a while, under load. Memory fragmentation makes > > this a really nasty problem, and the VM eats its own head after > > repeatedly scanning every page in the system. > > I thought I heard that there was some work being done in the upstream > kernel to have a process "defrag" memory in the background. This would > help alleviate this problem on systems with long up-times. I'm afraid I have to agree with Dave on this. Scanning pagelists really needs to be reduced to a minimum where ever possible. Ian From arjanv at redhat.com Fri Aug 5 07:46:54 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 05 Aug 2005 09:46:54 +0200 Subject: 4KSTACKS et al... In-Reply-To: <1123212463.31808.5.camel@localhost> References: <42EFA8F0.4030309@cornell.edu> <20050805014312.GF2241@redhat.com> <1123212463.31808.5.camel@localhost> Message-ID: <1123228014.3239.15.camel@laptopd505.fenrus.org> On Thu, 2005-08-04 at 22:27 -0500, Paul wrote: > On Thu, 2005-08-04 at 21:43 -0400, Dave Jones wrote: > > On Fri, Aug 05, 2005 at 09:22:55AM +0800, Ian Kent wrote: > > > I also find it hard to understand why it is such a problem having a larger > > > stack. As you point out, as software evolves it ultimately becomes more > > > complex. If the developers design needs it and the software is reliable > > > and efficient (aka performs well) then why not. > > > > > > A quick caclulation. > > > > > > 2000*4k is about 8M in say 1G at least. > > > > > > Not a large percentage overhead I think. > > > > Now try finding 2000 _contiguous_ pairs of pages after the machine > > has been up for a while, under load. Memory fragmentation makes > > this a really nasty problem, and the VM eats its own head after > > repeatedly scanning every page in the system. > > I thought I heard that there was some work being done in the upstream > kernel to have a process "defrag" memory in the background. This would > help alleviate this problem on systems with long up-times. actually that work is different; it is intended to defrag *userspace* pages; not kernel pages. And the existing vm already can reclaim those (by freeing them; the defrag work is there to avoid the actual free just to move them). The problem really is more complex than that, and the kernel VM got a lot of robustness back by having 4Kb stacks. (Now on x86-64 and other 64 bit machines this is FAR less of a problem; actually it's almost exclusively a x86 problem. x86 has a 1Gb lowmem zone where all kernel stacks and other kernel datastructures have to go, and the rest of memory goes into a highmem zone. This split is like quadrupling the VM pain; without this split, multi-page stacks are still not pretty but an order of magnitude less of a problem) -------------- 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 dragoran at feuerpokemon.de Fri Aug 5 09:41:32 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 05 Aug 2005 11:41:32 +0200 Subject: Fedora Kernel and Audio Latency Problems Message-ID: <42F3344C.4080003@feuerpokemon.de> Hello. I am using kernel-2.6.12-1.1398_FC4. I tryed to play doom3 with 5.1 Sound and got this Problem: idAudioHardwareALSA::Write: 4096 frames overflowed and dropped and hear no sound. doing echo 1024 > /proc/sys/dev/rtc/max-user-freq solves the problem. Why is this default to 64? Would (voluntary/realtime) preemt solve this issue too? If yes why did voluntary preemt dissappeard from the FC kernels? From paul at all-the-johnsons.co.uk Fri Aug 5 10:35:45 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 05 Aug 2005 11:35:45 +0100 Subject: Current devel kernel - possible security hole Message-ID: <1123238145.28662.25.camel@localhost> Hi, Using kernel-2.6.12-1.1448_FC5 Is there any way to check a potential hole I unearthed last night? I need to know if it is Mono causing the problem or the kernel or some other component. I have a small mono application which uses threading. Somehow, I managed to run the application and kill the desktop, but was then able to access, as a standard user, and both read and write to anywhere on my hard drive. I can reproduce the problem with the same application, but not with same code using C or C++. Can anyone advise me on this? I don't know if it is the threading model used in mono (which I have a feeling is POSIX so that shouldn't make much of a difference), a FC component or the kernel. Source code is below - sorry about it being in C#. The code was deliberately written to chew system resources. TTFN Paul using System; using System.Threading; using System.Windows.Forms; using System.Drawing; public class Sharing1 : Form { private TextBox accessCountBox = new TextBox(); private Button start = new Button(); private Button watch = new Button(); private int accessCount = 0; public void incrementAccess() { accessCount++; accessCountBox.Text = accessCount.ToString(); } private int numCounters = 12; private int numWatchers = 15; private TwoCounter[] s; public Sharing1() { ClientSize = new Size(450, 480); Panel p = new Panel(); p.Size = new Size(400, 50); start.Click += new EventHandler(StartAllThreads); watch.Click += new EventHandler(StartAllWatchers); accessCountBox.Text = "0"; accessCountBox.Location = new Point(10, 10); start.Text = "Start threads"; start.Location = new Point(110, 10); watch.Text = "Begin watching"; watch.Location = new Point(210, 10); p.Controls.Add(start); p.Controls.Add(watch); p.Controls.Add(accessCountBox); s = new TwoCounter[numCounters]; for (int i = 0; i < s.Length; i++) { s[i] = new TwoCounter(new TwoCounter.IncrementAccess(incrementAccess)); s[i].Location = new Point(10, 50 + s[i].Height * i); Controls.Add(s[i]); } this.Closed += new EventHandler(StopAllThreads); Controls.Add(p); } public void StartAllThreads(object sender, EventArgs ea) { for (int i = 0; i < s.Length; i++) s[i].Start(); } public void StopAllThreads(object sender, EventArgs ea) { for (int i = 0; i < s.Length; i++) if (s[i] != null) s[i].Stop(); } public void StartAllWatchers(object sender, EventArgs ea) { for (int i = 0; i < numWatchers; i++) new Watcher(s); } public static void Main(string [] args) { Sharing1 app = new Sharing1(); if (args.Length > 0) { app.numCounters = SByte.Parse(args[0]); if (args.Length == 2) app.numCounters = SByte.Parse(args[1]); } Application.Run(app); } } class TwoCounter : Panel { private bool started = false; private Label t1; private Label t2; private Label lbl; private Thread t; private int count1 = 0, count2 = 0; public delegate void IncrementAccess(); IncrementAccess del; public TwoCounter(IncrementAccess del) { this.del = del; this.Size = new Size(350, 30); this.BorderStyle = BorderStyle.Fixed3D; t1 = new Label(); t1.Location = new Point(10, 10); t2 = new Label(); t2.Location = new Point(110, 10); lbl = new Label(); lbl.Location = new Point(210, 10); lbl.Text = "Count1 == Count2"; Controls.AddRange(new Control[] {t1, t2, lbl} ); t = new Thread(new ThreadStart(run)); } public void Start() { if (!started) { started = true; t.Start(); } } public void Stop() { t.Abort(); } public void run() { while(true) { t1.Text = (++count1).ToString(); t2.Text = (++count2).ToString(); Thread.Sleep(500); } } public void synchTest() { del(); if (count1 != count2) lbl.Text = "Unsynched"; } } class Watcher { TwoCounter[] s; public Watcher(TwoCounter[] s) { this.s = s; new Thread(new ThreadStart(run)).Start(); } public void run() { while(true) { for(int i = 0; i < s.Length; i++) s[i].synchTest(); Thread.Sleep(500); } } } -- "Some people will do anything for a woman in uniform" - The Doctor - Unregenerate (Big Finish audio) -------------- 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 bart.vanbrabant at zoeloelip.be Fri Aug 5 17:27:18 2005 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Fri, 05 Aug 2005 13:27:18 -0400 Subject: Bootup delays In-Reply-To: <20050716041039.GB5755@nostromo.devel.redhat.com> References: <42D838EC.1060402@zoeloelip.be> <20050716041039.GB5755@nostromo.devel.redhat.com> Message-ID: <42F3A176.8050307@zoeloelip.be> Bill Nottingham wrote: >Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: > > >>>From kernel 1432 and 1433 in rawhide my boot process has some serious >>delays where my system doesn't seem to do anything and doesn't respond. >>This also happens when logining in and starting gnome. >>I made a bootchart from the 1426 kernel which runs fine and one form >>1433 which suffers from those delays. >>http://files.zoeloelip.be/1426.png >>http://files.zoeloelip.be/1433.png >> >> > >Looks like there's a 30 second process of just insmod, unless it's grouping >them. If you could track down what driver is being silly, that could >help a lot. > >Bill > > > Hello, I finally found the problem. It's caused by the battery acpi module. I searched for insmod in rc.sysinit and there is only one part that uses insmod instead of modprobe. When I change this into modprobe my system boots normal and haldeamon starts. But the battery-applet doesn't work. I tried to do /sbin/insmod battery.ko and it takes a long time to finish. Hal crashes when I boot with a new kernel. I now move the battery.ko module out the acpi directory, this way I can boot in a normal way but the battery applet doesn't work of course. What should I do now? Cheers, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From buildsys at redhat.com Fri Aug 5 11:28:47 2005 From: buildsys at redhat.com (Build System) Date: Fri, 5 Aug 2005 07:28:47 -0400 Subject: rawhide report: 20050805 changes Message-ID: <200508051128.j75BSlxY021865@porkchop.devel.redhat.com> Updated Packages: amanda-2.4.5-3 -------------- * Sun Jul 31 2005 Florian La Roche - make sure amanda builds with newest rpm eog-2.11.90-1 ------------- * Thu Aug 04 2005 Matthias Clasen 2.11.90-1 - Newer upstream version evince-0.3.2-2 -------------- * Thu Aug 04 2005 Matthias Clasen - 0.3.2-1 - Newer upstream version file-roller-2.11.90-1 --------------------- * Thu Aug 04 2005 Matthias Clasen 2.11.90-1 - New upstream version foomatic-3.0.2-24 ----------------- * Thu Aug 04 2005 Tim Waugh 3.0.2-24 - Updated db to 3.0-20050804. - No longer need hplj5 patch. - Conflicts with system-config-printer before the parser bug was fixed. gedit-1:2.10.4-1 ---------------- * Thu Aug 04 2005 Matthias Clasen - 2.10.4-1 - New upstream version glib2-2.7.6-2 ------------- * Thu Aug 04 2005 Matthias Clasen - 2.7.6-2 - Another attempt to fix atomic ops on s390 gnome-keyring-0.4.3-1 --------------------- * Thu Aug 04 2005 Matthias Clasen 0.4.3-1 - New upstream version * Fri Mar 18 2005 David Zeuthen 0.4.2-1 - New upstream version * Wed Mar 02 2005 Alex Larsson 0.4.1-2 - Rebuild gnome-keyring-manager-2.11.1-1 ------------------------------ * Thu Aug 04 2005 Matthias Clasen 2.11.1-1 - New upstream version gnome-panel-2.11.90-1 --------------------- * Thu Aug 04 2005 Matthias Clasen 2.11.90-1 - New upstream version gnome-system-monitor-2.11.90-1 ------------------------------ * Thu Aug 04 2005 Matthias Clasen 2.11.90-1 - New upstream version gnome-themes-2.11.90-1 ---------------------- * Thu Aug 04 2005 Matthias Clasen - 2.11.90-1 - New upstream version - Clearlooks 0.6.2 * Tue Jun 28 2005 Matthias Clasen - 2.11.3-2 - noarch gnomemeeting-1.2.1-3 -------------------- * Thu Aug 04 2005 Daniel Veillard 1.2.1-3 - rebuilt to get rid of a dependancy problem on ppc64 * Fri Mar 18 2005 Daniel Veillard 1.2.1-2 - Reenabled ppc64 gnopernicus-0.11.3-1 -------------------- * Thu Aug 04 2005 Matthias Clasen 0.11.3-1 - New upstream version gnupg-1.4.2-2 ------------- * Thu Aug 04 2005 Nalin Dahyabhai 1.4.2-2 - pull in David Shaw's fix for key generation in batch mode * Fri Jul 29 2005 Nalin Dahyabhai - change %post to check if the info files are there before attempting to add or remove them from the info index (#91641) * Wed Jul 27 2005 Nalin Dahyabhai 1.4.2-1 - update to 1.4.2 gtk2-2.7.5-1 ------------ * Thu Aug 04 2005 Matthias Clasen - Newer upstream version gtk2-engines-2.6.4-1 -------------------- * Thu Aug 04 2005 Matthias Clasen 2.6.4-1 - New upstream version hsqldb-0:1.80.1-1jpp_1fc ------------------------ * Thu Aug 04 2005 Gary Benson 0:1.80.1-1jpp_1fc - BC-compile. * Wed Aug 03 2005 Gary Benson - Upgrade to 1.8.0.1 (#164072). * Tue Jul 26 2005 Fernando Nasser 0:1.80.1-1jpp - Upgrade to 1.8.0.1 intltool-0.34.1-1 ----------------- * Thu Aug 04 2005 Matthias Clasen - 0.34.1-1 - New upstream version kernel-2.6.12-1.1451_FC5 ------------------------ * Thu Aug 04 2005 Dave Jones - 2.6.13-rc5-git2 libgtop2-2.11.90-1 ------------------ * Thu Aug 04 2005 Matthias Clasen - 2.11.90-1 - New upstream version man-pages-de-0.4-10 ------------------- * Fri Aug 05 2005 Ivana Varekova 0.4-10 - fix bug 141160 - ps 5 man page problem - fix bug 156262 - nfs 5 man page typos openh323-1.15.3-2 ----------------- * Thu Aug 04 2005 Daniel Veillard 1.15.3-2 - rebuilt to try to fix a dependancy problem on ppc64 openoffice.org-1:1.9.122-3.2.0.fc5 ---------------------------------- * Wed Aug 03 2005 Caolan McNamara - 1:1.9.122-3 - ooo#52626# sessionmanagement and vclplug problem - ooo#52786# czech 8bit msword doc import problem - disable internal hsqldb 1.80.1 and use the rawhide system one now that it has been bumped to that version pwlib-1.8.4-2 ------------- * Wed Aug 03 2005 Daniel Veillard 1.8.4-2 - applied a gcc4 compilation fix readahead-1:1.1-1.17 -------------------- * Thu Aug 04 2005 Dave Jones - Integrated changes from Ville Skytt?? (#164872) - Fix inverted logic in readahead_early also. - readahead_early looks useful in more runlevels than just 5. - Sync versioned gcc, firefox and openoffice.org dirs with FC4 updates. smartmontools-1:5.33-1.7 ------------------------ * Thu Aug 04 2005 Karsten Hopp - package all python files star-1.5a54-3 ------------- * Thu Aug 04 2005 Karsten Hopp 1.5a54-3 - remove /usr/bin/tar symlink synaptics-0:0.14.3-3 -------------------- * Thu Aug 04 2005 Paul Nasrat - 0:0.14.3-3 - Enable ppc builds as we have appletouch driver now system-config-date-1.7.99.0-1 ----------------------------- * Thu Aug 04 2005 Nils Philippsen 1.7.99.0 - add and edit NTP servers inline in the list - always display clock left-to-right (#165109) - try to be smart about restrict lines when changing or deleting hosts - include *.pyo files (#165097) - don't remove *.pyc files in %preun because they're in the file list - don't include timetool symlink anymore - don't install firstboot module symlink, this is dealt with in the firstboot package for quite a while * Wed Aug 03 2005 Nils Philippsen - implement --help, catch unrecognized options (#164791) system-config-printer-0.6.139-1 ------------------------------- * Thu Aug 04 2005 Tim Waugh 0.6.139-1 - 0.6.139: - Fixed parser bug. systemtap-0.2.2-2 ----------------- * Thu Aug 04 2005 Roland McGrath - 0.2.2-2 - Rebuilt for FC5. * Wed Aug 03 2005 Martin Hunt - 0.2.2-1 - Add directory /var/cache/systemtap - Add stp_check to /usr/libexec/systemtap * Wed Aug 03 2005 Roland McGrath - 0.2.1-1 - New version 0.2.1, various fixes. udev-063-6 ---------- * Thu Aug 04 2005 Harald Hoyer - 063-6 - compile with pie .. again... (#158935) - fixed typo in echo (#138509) * Tue Aug 02 2005 Harald Hoyer - 063-5 - fixed scsi hotplug replay vino-2.11.90-1 -------------- * Thu Aug 04 2005 Matthias Clasen 2.11.90-1 - New upstream version vsftpd-2.0.3-7 -------------- * Thu Aug 04 2005 Radek Vokal 2.0.3-7 - daemonize with file descriptors (#164998) vte-0.11.14-1 ------------- * Thu Aug 04 2005 Matthias Clasen 0.11.14-1 - New upstream version wireless-tools-1:28-0.pre4.4 ---------------------------- * Fri Aug 05 2005 Florian La Roche - build with current rpm wordtrans-1.1pre13-11 --------------------- * Thu Aug 04 2005 Karsten Hopp 1.1pre13-11 - fix build on a rawhide system xscreensaver-1:4.22-5 --------------------- * Wed Aug 03 2005 Ray Strode 1:4.22-1 - Update to xscreensaver 4.22. * Sun Jun 19 2005 Ray Strode 1:4.21-5 - Add build requires for desktop-file-utils (bug 160980). * Wed May 11 2005 Ray Strode 1:4.21-4 - Allow configuration gui to support hacks with absolute paths (bug 157417). Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390x ---------------------------------------------------------- selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) Broken deps for ppc64 ---------------------------------------------------------- firstboot - 1.3.44-1.noarch requires system-config-display system-config-mouse - 1.2.11-1.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ppc ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) Broken deps for s390 ---------------------------------------------------------- arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 selinux-policy-strict-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 selinux-policy-targeted-sources - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 selinux-policy-targeted - 1.25.3-11.noarch requires kernel >= 0:2.6.11-1.1219 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 From ph18 at cornell.edu Fri Aug 5 13:06:59 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Fri, 05 Aug 2005 09:06:59 -0400 Subject: Thanks for 4KSTACK explanation Message-ID: <42F36473.4070004@cornell.edu> I'd like to thank Dave and a few others for a good explanation of the 4KSTACKS move. Anything that improves reliability for my server apps is welcome. I apologize for being less than tactful sometimes. If I'm critical of RH, it's because I like Linux, Fedora and Red Hat and want to seem them succeed. If I was commited to, say, Suse, FreeBSD or Open Solaris, I'd be making waves on their mailing lists, not this one. Some people are concerned that there's a lot of negative content on this mailing list, and I think that's correct. We've seen arguments that boil on for weeks without resolution. I think the problem, however, is that there isn't a system in place to produce positive propaganda for Linux and Fedora. Red Hat Magazine is pretty good: http://www.redhat.com/magazine/ but http://www.kerneltraffic.org/ is being updated less infrequently than it was and I wish that http://www.kerneltrap.org/ had 3x has much content as it does. I went looking online for information on 4KSTACKS, and by the limitations of current browsing and searching interfaces, I found mostly people complaining about how 4KSTACKS broke this or that, and nothing that made it clear that 4KSTACKS has the real benefits that it does. Fighting a headwind, some Sun employees write good documentation for OpenSolaris in blog entries, such as http://blogs.sun.com/mws/ Sun's blog aggregator incorporates a lot of material that's off topic: http://www.opensolaris.org/os/blogs/ but if it had some editorial effort, I could see it becoming a good system that combines documentation at the user level, kernel developer level, and technical-friendly marketing in one place. LKML is great, but it's like drinking from a firehose for people who have other job responsibilities. There's a lot that can be done to cure the impedance mismatch between the information that's available and the information that linux admins need. Finally, there is an impedance mismatch between Fedora and RHEL -- the connection between them is more intimate than a lot of people admit. I had bad experiences with RHEL 3 on an x86 and had a lot of skepticism about the direction RH was going when the Fedora project started. We was so impressed with FC 3 that we chose RHEL 4 for an x86_64 server we brought online. If it hadn't been for Fedora, we might have switched to a different distribution or OS. (And yes, it's really a miracle that FC and RHEL are as good as they are on a platform as new as x86_64!) With better marketing, ISVs might take Fedora a little more seriously and start testing products on it. We knew well in advance that RHEL 4 was going to be based on FC 3 and ISVs could have had better products qualified for RHEL 4 faster if they'd done beta testing against FC 3. Framing the Fedora discussion from a "half full" rather than "half empty" perspective could help with this. From notting at redhat.com Fri Aug 5 14:46:03 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 5 Aug 2005 10:46:03 -0400 Subject: Bootup delays In-Reply-To: <42F3A176.8050307@zoeloelip.be> References: <42D838EC.1060402@zoeloelip.be> <20050716041039.GB5755@nostromo.devel.redhat.com> <42F3A176.8050307@zoeloelip.be> Message-ID: <20050805144603.GB25860@nostromo.devel.redhat.com> Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: > I finally found the problem. It's caused by the battery acpi module. I > searched for insmod in rc.sysinit and there is only one part that uses > insmod instead of modprobe. When I change this into modprobe my system > boots normal and haldeamon starts. But the battery-applet doesn't work. > I tried to do /sbin/insmod battery.ko and it takes a long time to finish. > Hal crashes when I boot with a new kernel. I now move the battery.ko module out the acpi directory, this way I can boot in a normal way but the battery applet doesn't work of course. > > What should I do now? You can file a kernel bug about the battery driver, although it's probably related to something funky in your BIOS as well. Bill From alan at balclutha.org Fri Aug 5 16:41:29 2005 From: alan at balclutha.org (Alan Milligan) Date: Sat, 06 Aug 2005 02:41:29 +1000 Subject: Thanks for 4KSTACK explanation Message-ID: <42F396B9.8090109@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, May I say that I completely agree with your appraisal of RH/Fedora. Could I just add that there is one other issue of paramount importance: accountability. The community still has no real leverage in change assurance. We do not yet have access to CVS to apply patches ourselves, and despite things being argued on lists etc, there is no control over veto, some of which is explicit, but much of which is implicit in that no action is taken. There is no recourse to arbitration in any case. I do not doubt that RH's control of architectural integrity is not only a good and necessary thing (indeed given the source of funding, it is only right), but I am not at all convinced the correct balance has been achieved. Unfortunately for us, this represents our greatest business risk. Distributions such as Ubuntu, where third-party derivatives is a core strategic component presently offer others much more influence in the finished product. The Fedora community needs to address this because RPM is still the packaging system par-excellence in my opinion. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC85a4CfroLk4EZpkRAll+AJ0anI1rV5C7D7/zQoyYtLGeZk+c7gCggx20 bm9WaR+7lIffyEDNZv9P+B8= =yWLS -----END PGP SIGNATURE----- From jkeating at j2solutions.net Fri Aug 5 16:51:50 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 05 Aug 2005 09:51:50 -0700 Subject: Thanks for 4KSTACK explanation In-Reply-To: <42F396B9.8090109@balclutha.org> References: <42F396B9.8090109@balclutha.org> Message-ID: <1123260711.11730.44.camel@prometheus.gamehouse.com> On Sat, 2005-08-06 at 02:41 +1000, Alan Milligan wrote: > The community still has no real leverage in change assurance. We do not > yet have access to CVS to apply patches ourselves, and despite things > being argued on lists etc, there is no control over veto, some of which > is explicit, but much of which is implicit in that no action is taken. > > There is no recourse to arbitration in any case. > > I do not doubt that RH's control of architectural integrity is not only > a good and necessary thing (indeed given the source of funding, it is > only right), but I am not at all convinced the correct balance has been > achieved. > > Unfortunately for us, this represents our greatest business risk. > Distributions such as Ubuntu, where third-party derivatives is a core > strategic component presently offer others much more influence in the > finished product. > > The Fedora community needs to address this because RPM is still the > packaging system par-excellence in my opinion. The things you speak of are not likely to change under the current RH guard. However with the formation of the Fedora Foundation, a 3rd party non-profit org to manage Fedora a lot of these things may change. Please stay tuned for further information about the Fedora Foundation. I do believe there will be some announcements at Linux World Conference and Expo next week in San Francisco. If you're going to be around the area, stop by the Fedora booth and see us. http://www.fedoraproject.org/wiki/LinuxWorldSF2005 -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From davej at redhat.com Fri Aug 5 17:02:09 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 5 Aug 2005 13:02:09 -0400 Subject: Bootup delays In-Reply-To: <20050805144603.GB25860@nostromo.devel.redhat.com> References: <42D838EC.1060402@zoeloelip.be> <20050716041039.GB5755@nostromo.devel.redhat.com> <42F3A176.8050307@zoeloelip.be> <20050805144603.GB25860@nostromo.devel.redhat.com> Message-ID: <20050805170209.GH2241@redhat.com> On Fri, Aug 05, 2005 at 10:46:03AM -0400, Bill Nottingham wrote: > Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: > > I finally found the problem. It's caused by the battery acpi module. I > > searched for insmod in rc.sysinit and there is only one part that uses > > insmod instead of modprobe. When I change this into modprobe my system > > boots normal and haldeamon starts. But the battery-applet doesn't work. > > I tried to do /sbin/insmod battery.ko and it takes a long time to finish. > > Hal crashes when I boot with a new kernel. I now move the battery.ko module out the acpi directory, this way I can boot in a normal way but the battery applet doesn't work of course. > > > > What should I do now? > > You can file a kernel bug about the battery driver, although it's probably > related to something funky in your BIOS as well. There are a number of kernel bugs open on the acpi battery stuff already. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=165150 Chances are this is a dupe of one of them. Dave From vonbrand at inf.utfsm.cl Fri Aug 5 18:33:10 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Fri, 05 Aug 2005 14:33:10 -0400 Subject: Thanks for 4KSTACK explanation In-Reply-To: Your message of "Fri, 05 Aug 2005 09:51:50 MST." <1123260711.11730.44.camel@prometheus.gamehouse.com> Message-ID: <200508051833.j75IXA90027473@laptop11.inf.utfsm.cl> Jesse Keating wrote: > On Sat, 2005-08-06 at 02:41 +1000, Alan Milligan wrote: > > The community still has no real leverage in change assurance. We do not > > yet have access to CVS to apply patches ourselves, and despite things > > being argued on lists etc, there is no control over veto, some of which > > is explicit, but much of which is implicit in that no action is taken. [...] > The things you speak of are not likely to change under the current RH > guard. But this is open source! You are free to fork off to your heart's content. If you hit it right, your branch might even become mainstream... -- 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 jkeating at j2solutions.net Fri Aug 5 18:44:42 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 05 Aug 2005 11:44:42 -0700 Subject: Thanks for 4KSTACK explanation In-Reply-To: <200508051833.j75IXA90027473@laptop11.inf.utfsm.cl> References: <200508051833.j75IXA90027473@laptop11.inf.utfsm.cl> Message-ID: <1123267482.11730.61.camel@prometheus.gamehouse.com> On Fri, 2005-08-05 at 14:33 -0400, Horst von Brand wrote: > But this is open source! You are free to fork off to your heart's > content. If you hit it right, your branch might even become > mainstream... Um, I'm not sure how this relates to the thread.... -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From ph18 at cornell.edu Fri Aug 5 19:02:10 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Fri, 5 Aug 2005 15:02:10 -0400 (EDT) Subject: Thanks for 4KSTACK explanation In-Reply-To: <1123267482.11730.61.camel@prometheus.gamehouse.com> References: <200508051833.j75IXA90027473@laptop11.inf.utfsm.cl> <1123267482.11730.61.camel@prometheus.gamehouse.com> Message-ID: <1357.128.84.103.66.1123268530.squirrel@128.84.103.66> > On Fri, 2005-08-05 at 14:33 -0400, Horst von Brand wrote: >> But this is open source! You are free to fork off to your heart's >> content. If you hit it right, your branch might even become >> mainstream... > > Um, I'm not sure how this relates to the thread.... > That if someone really hates Gnome, and wants to make a distro based on Fedora with just KDE and, say, a /usr/games directory with games that are fun and really work, you can do that. From bart.vanbrabant at zoeloelip.be Sat Aug 6 03:25:40 2005 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Fri, 05 Aug 2005 23:25:40 -0400 Subject: Bootup delays In-Reply-To: <20050805170209.GH2241@redhat.com> References: <42D838EC.1060402@zoeloelip.be> <20050716041039.GB5755@nostromo.devel.redhat.com> <42F3A176.8050307@zoeloelip.be> <20050805144603.GB25860@nostromo.devel.redhat.com> <20050805170209.GH2241@redhat.com> Message-ID: <42F42DB4.7040802@zoeloelip.be> Dave Jones wrote: >On Fri, Aug 05, 2005 at 10:46:03AM -0400, Bill Nottingham wrote: > > Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: > > > I finally found the problem. It's caused by the battery acpi module. I > > > searched for insmod in rc.sysinit and there is only one part that uses > > > insmod instead of modprobe. When I change this into modprobe my system > > > boots normal and haldeamon starts. But the battery-applet doesn't work. > > > I tried to do /sbin/insmod battery.ko and it takes a long time to finish. > > > Hal crashes when I boot with a new kernel. I now move the battery.ko module out the acpi directory, this way I can boot in a normal way but the battery applet doesn't work of course. > > > > > > What should I do now? > > > > You can file a kernel bug about the battery driver, although it's probably > > related to something funky in your BIOS as well. > >There are a number of kernel bugs open on the acpi battery stuff >already. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=165150 > >Chances are this is a dupe of one of them. > > Dave > > > Ok. But must of them are quite old. Mine only appeared after kernel 1426 which I think is post 2.6.13-rc2. I don't know how to search for changes in the kernel source. I'm not familiar with git. I search the kernel changelog but I can't find anything about the battery module. If you need more information, just let me know. Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bart.vanbrabant at zoeloelip.be Sat Aug 6 05:39:46 2005 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Sat, 06 Aug 2005 01:39:46 -0400 Subject: Bootup delays In-Reply-To: <42F42DB4.7040802@zoeloelip.be> References: <42D838EC.1060402@zoeloelip.be> <20050716041039.GB5755@nostromo.devel.redhat.com> <42F3A176.8050307@zoeloelip.be> <20050805144603.GB25860@nostromo.devel.redhat.com> <20050805170209.GH2241@redhat.com> <42F42DB4.7040802@zoeloelip.be> Message-ID: <42F44D22.10202@zoeloelip.be> Bart Vanbrabant wrote: >Dave Jones wrote: > > > >>On Fri, Aug 05, 2005 at 10:46:03AM -0400, Bill Nottingham wrote: >> >> >>>Bart Vanbrabant (bart.vanbrabant at zoeloelip.be) said: >>> >>> >>>>I finally found the problem. It's caused by the battery acpi module. I >>>>searched for insmod in rc.sysinit and there is only one part that uses >>>>insmod instead of modprobe. When I change this into modprobe my system >>>>boots normal and haldeamon starts. But the battery-applet doesn't work. >>>>I tried to do /sbin/insmod battery.ko and it takes a long time to finish. >>>>Hal crashes when I boot with a new kernel. I now move the battery.ko module out the acpi directory, this way I can boot in a normal way but the battery applet doesn't work of course. >>>> >>>>What should I do now? >>>> >>>> >>>You can file a kernel bug about the battery driver, although it's probably >>>related to something funky in your BIOS as well. >>> >>> >>There are a number of kernel bugs open on the acpi battery stuff >>already. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=165150 >> >>Chances are this is a dupe of one of them. >> >> Dave >> >> >> >> >> >Ok. But must of them are quite old. Mine only appeared after kernel 1426 >which I think is post 2.6.13-rc2. I don't know how to search for changes >in the kernel source. I'm not familiar with git. I search the kernel >changelog but I can't find anything about the battery module. >If you need more information, just let me know. > >Bart > > > rc5-git3 solved the problem. The 1451 version from rawhide fixed it. Thanks for the help Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bbbush.yuan at gmail.com Sat Aug 6 03:36:09 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 6 Aug 2005 11:36:09 +0800 Subject: How can I use boot.iso to install fedora if the network is fast but often breaks? Message-ID: <76e72f800508052036242b6669@mail.gmail.com> Hi, I want to install a minimal fedora from rawhide so I downloaded boot.iso from ftp. Following the instructions, it began to retrieving stage2.img. I install it on VMware (an evaluation copy), so I can see the transfer status in the status bar. The transfer stopped after some time, but the Anaconda installer is not started. I think this is because our network is not so good, and the stage2.img is not downloaded completely. Can we have a daily built rescue CD which includes stage2.img? That would make things easier. I have to install fedora 4 use its rescue CD, because of the network issue above. Besides this problem I also noticed that different boot.iso can only match the exact version of stage2.img. I have to download it again and again these days :( If debian users can install their systems using any version of boot CD, why cannot we have one... -- bbbush ^_^ From buildsys at redhat.com Sat Aug 6 11:20:16 2005 From: buildsys at redhat.com (Build System) Date: Sat, 6 Aug 2005 07:20:16 -0400 Subject: rawhide report: 20050806 changes Message-ID: <200508061120.j76BKGmg008453@porkchop.devel.redhat.com> New package kasumi An anthy dictionary management tool. Updated Packages: ORBit2-2.12.2-1 --------------- * Fri Aug 05 2005 Matthias Clasen 2.12.2-1 - Update to 2.12.2 file-4.14-3 ----------- * Fri Aug 05 2005 Radek Vokal - 4.14-3 - mime for 3ds files removed, conflicts with text files (#165165) * Fri Jul 22 2005 Radek Vokal - 4.14-2 - fixed mime types recognition (#163866) * Thu Jul 14 2005 Radek Vokal - 4.14-1 - sync with upstream, patch clean-up glib2-2.7.6-3 ------------- * Fri Aug 05 2005 Matthias Clasen - 2.7.6-3 - Fix C++ guards in gstdio.h gnome-applets-1:2.11.2-1 ------------------------ * Fri Aug 05 2005 Matthias Clasen 1:2.11.2-2 - New upstream version gnome-desktop-2.11.90-1 ----------------------- * Fri Aug 05 2005 Matthias Clasen - 2.11.90-1 - Update to 2.11.90 gnome-games-1:2.11.3-1 ---------------------- * Fri Aug 05 2005 Matthias Clasen 1:2.11.3-1 - New upstream version gnome-speech-0.3.7-1 -------------------- * Fri Aug 05 2005 Matthias Clasen 0.3.7-1 - New upstream version gnome-utils-1:2.11.90-1 ----------------------- * Fri Aug 05 2005 Matthias Clasen 1:2.11.90-1 - Update to gnome-utils 2.11.90, gcalctool 5.6.25, zenity 2.11.90 jwhois-3.2.3-2 -------------- * Fri Aug 05 2005 Miloslav Trmac - 3.2.3-2 - Don't die on SIGPIPE if a browser is not present, improve the error message (#165149) kernel-2.6.12-1.1452_FC5 ------------------------ * Fri Aug 05 2005 Dave Jones - 2.6.13-rc5-git3 libbonobo-2.10.0-1 ------------------ * Fri Aug 05 2005 Matthias Clasen 2.10.0-1 - New upstream version * Wed Feb 09 2005 Matthias Clasen 2.8.1-1 - Update to 2.8.1 * Tue Sep 28 2004 Mark McLoughlin 2.8.0-2 - Add patch to make bonobo-activation notice epiphany being installed. Bug #117790 libbonoboui-2.10.0-1 -------------------- * Fri Aug 05 2005 Matthias Clasen 2.10.0-1 - New upstream version libsepol-1.7.10-1 ----------------- * Fri Aug 05 2005 Dan Walsh 1.7.10-1 - Upgrade to latest from NSA * Merged patch to move module read/write code from libsemanage to libsepol from Jason Tang (Tresys). man-pages-cs-0.16-5 ------------------- * Fri Aug 05 2005 Ivana Varekova 0.16-5 - remove lastlog man page (man page is removed to shadow-utils) metacity-2.11.1-1 ----------------- * Fri Aug 05 2005 Matthias Clasen 2.11.1-1 - New upstream version mkinitrd-4.2.19-1 ----------------- * Fri Aug 05 2005 Peter Jones - 4.2.19-1 - Fix yaboot stanza placement with a patch from dwmw2 (#142346) nautilus-cd-burner-2.11.5-1 --------------------------- * Fri Aug 05 2005 Matthias Clasen - 2.11.5-1 - New upstream version scim-hangul-0.2.0-3.fc5 ----------------------- selinux-policy-strict-1.25.3-13 ------------------------------- * Fri Aug 05 2005 Dan Walsh 1.25.3-13 - Allow cvs to use kerberos - Allow sasauthd to use mysql * Tue Aug 02 2005 Dan Walsh 1.25.3-12 - Bump for FC4 selinux-policy-targeted-1.25.3-13 --------------------------------- * Fri Aug 05 2005 Dan Walsh 1.25.3-13 - Allow cvs to use kerberos - Allow sasauthd to use mysql * Tue Aug 02 2005 Dan Walsh 1.25.3-12 - Bump for FC4 shadow-utils-2:4.0.11.1-1 ------------------------- * Fri Aug 05 2005 Peter Vrabec 2:4.0.11.1-1 - upgrade system-config-netboot-0.1.24-1_FC5 ---------------------------------- * Fri Aug 05 2005 Jason Vas Dias 0.1.24-1 - fix bug 164776: don't write empty 'ks=' string in pxeboot.py Fix network install parameters: Instead of just writing unused 'ks.cfg' file, specify loader 'method=' and 'ip=' arguments if no kickstart file given. tcsh-6.14-5 ----------- * Fri Aug 05 2005 Miloslav Trmac - 6.14-5 - Fix EOF handling in $< (#165095, patch by s_h_o_ at hotmail.co.jp) Broken deps for ia64 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) Broken deps for i386 ---------------------------------------------------------- cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 Broken deps for s390x ---------------------------------------------------------- selinux-policy-targeted-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 selinux-policy-strict-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 selinux-policy-targeted - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 selinux-policy-strict - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) Broken deps for s390 ---------------------------------------------------------- nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-targeted-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 selinux-policy-targeted - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-strict-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 selinux-policy-strict - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 Broken deps for x86_64 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- ppc64-utils - 0.7-9.ppc64 requires yaboot firstboot - 1.3.44-1.noarch requires system-config-display gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-mouse - 1.2.11-1.noarch requires pyxf86config control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) From kyrre at solution-forge.net Sat Aug 6 22:26:35 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 07 Aug 2005 00:26:35 +0200 Subject: gnome-user-share In-Reply-To: <1121647580.2769.75.camel@yoda.loki.me> References: <1121647580.2769.75.camel@yoda.loki.me> Message-ID: <1123367186.3355.152.camel@localhost.localdomain> man, 18.07.2005 kl. 02.46 skrev Jesse Keating: > I've started a new thread because this discussion was going to get lost > in the 200+ message thread-o-doom. > > So so far we have the introduction of gnome-user-share, which uses an > http process dynamically bound to a port running as the user to share > stuff in a ~/Public file to the world w/out auth. It sounds like > gnome-user-auth will go into core. The restrictions have been put > forth: > > * Functionality is provided by a package and removed by a package, w/out > core deps. > > * Functionality is controlled by a gconf entry which an admin can set to > mandatory off (or just remove the package) > > > Some ideas that have floated for this package include: > > * Functionality disabled until a file is placed in ~/Public prompting > for a dialog box informing the user that the share is now active, with a > link to more help in this. > > * Gnome-panel icon to show state of sharing with a timeout value to stop > the share (configurable) > > * Integration with network-manager to enable/disable the share on > specific networks > > Thoughts? Any kind of service discovery (akin to bonjour/windows SMB), so that other people would be easily able to find your share? And for those who hasn't got a autodiscovering client, it should be really easy to find the correct address of the sharing computers display. What about file uploads - making it possible for other people to upload data to your disk? (WebDAW perhaps?) Sharing other folders than the standard one? Making it possible to choose protocols at will - not only Apache/HTTP? How will it intereact with people who use workstations with NFS mounted homes? Somehow i have a feeling that this is extremely fitting for dynamic workgroup configurations (laptops etc) and home/small office withot servers or tech skill... Kyrre From roland at redhat.com Sat Aug 6 22:36:01 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 6 Aug 2005 15:36:01 -0700 (PDT) Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) Message-ID: <20050806223601.AD95C1809B2@magilla.sf.frob.com> If there was a mention of this change, I overlooked it. The addition of -Wall to the $RPM_OPT_FLAGS value has some unintended consequences. This broke my latest elfutils build until I worked around it. The CFLAGS given to configure, i.e. what's in %optflags, is usually appended to the package makefiles' own list of flags. As gcc processes its command line, the later flags override the earlier ones. This is the right thing e.g. when a package makefile uses -O and we override it to -O2 and so on. When a package uses -W* flags already itself, it may use some -Wno-* flags in its standard setting when some of the warnings are over-eager for some of its code. For example, elfutils uses -Wall -Werror (and some more warning options) on every file, but appends -Wno-format for a few files where gcc's format checking is not smart enough to know what is really OK. With the new redhat-rpm-config setting of %optflags including -Wall, we wind up with -Wall -Werror -Wno-format -Wall -Wp,-D_FORTIFY_SOURCE=2 ... and the second -Wall overrides the -Wno-format that overrode part of the effect of the first -Wall. Since it uses -Werror, the additional spurious warnings break the build. There is an argument to be made that the upstream package is broken if you cannot use "configure CFLAGS=-Wall". But, folks should be aware of this change and how it might explain sudden differences in the builds of packages that worked before Monday. For today's elfutils build, I am using this: RPM_OPT_FLAGS=${RPM_OPT_FLAGS/-Wall/} %configure CFLAGS="$RPM_OPT_FLAGS" Thanks, Roland From nmiell at comcast.net Sat Aug 6 23:08:02 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 06 Aug 2005 16:08:02 -0700 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <20050806223601.AD95C1809B2@magilla.sf.frob.com> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> Message-ID: <1123369682.2833.2.camel@localhost.localdomain> On Sat, 2005-08-06 at 15:36 -0700, Roland McGrath wrote: > There is an argument to be made that the upstream package is broken if you > cannot use "configure CFLAGS=-Wall". But, folks should be aware of this > change and how it might explain sudden differences in the builds of > packages that worked before Monday. > I'd argue that any upstream package which includes -Werror by default is broken, considering how often gcc warnings change. -- Nicholas Miell From roland at redhat.com Sat Aug 6 23:27:54 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 6 Aug 2005 16:27:54 -0700 (PDT) Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: Nicholas Miell's message of Saturday, 6 August 2005 16:08:02 -0700 <1123369682.2833.2.camel@localhost.localdomain> Message-ID: <20050806232754.EB2441809B2@magilla.sf.frob.com> > I'd argue that any upstream package which includes -Werror by default is > broken, considering how often gcc warnings change. I see that argument. Some packages are like elfutils and intended only to build on the latest gcc version, and update frequently to track it. Whatever their rationale and the wisdom of it or lack thereof, that's the way they are upstream. We should come to a decision about the preferred way to deal with these in Fedora packaging, be it to remove their -Werror or whatever else. The addition of -Wall created a problem that we didn't have before, so I brought it up. Thanks, Roland From drepper at redhat.com Sat Aug 6 23:55:12 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 06 Aug 2005 16:55:12 -0700 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <1123369682.2833.2.camel@localhost.localdomain> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> Message-ID: <42F54DE0.2090800@redhat.com> Nicholas Miell wrote: > I'd argue that any upstream package which includes -Werror by default is > broken, considering how often gcc warnings change. And I argue that we apparently must come to a state where -Werror is enabled automatically. The current state, aggravated by adding -Wall, is that warnings are ignored. The result: bugs the compiler finds are no fixed. I even found one case where the _FORTIFY_SOURCE magic found a buffer overflow and the maintainer hasn't seen it. It is crucial that packages are changed to have zero warnings. Otherwise these bugs remain unnoticed since people think warnings are OK and don't care. The "apparent" part is that using -Werror is the only way to do this. Without enforcement people _think_ there are more important things to do than fixing warnings. Yes, it might mean that an update to a new gcc version means required changes. But guess what? Whenever a warning pops up there is likely a good reason for it and it is worthwhile spending time on it. Just like all these signed vs unsigned warnings in gcc 4. They almost all the time warrant looking at the code. -- ? 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 nmiell at comcast.net Sun Aug 7 00:31:13 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 06 Aug 2005 17:31:13 -0700 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <42F54DE0.2090800@redhat.com> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> Message-ID: <1123374673.2833.7.camel@localhost.localdomain> On Sat, 2005-08-06 at 16:55 -0700, Ulrich Drepper wrote: > Nicholas Miell wrote: > > I'd argue that any upstream package which includes -Werror by default is > > broken, considering how often gcc warnings change. > > And I argue that we apparently must come to a state where -Werror is > enabled automatically. The current state, aggravated by adding -Wall, > is that warnings are ignored. The result: bugs the compiler finds are > no fixed. I even found one case where the _FORTIFY_SOURCE magic found a > buffer overflow and the maintainer hasn't seen it. > > It is crucial that packages are changed to have zero warnings. > Otherwise these bugs remain unnoticed since people think warnings are OK > and don't care. The "apparent" part is that using -Werror is the only > way to do this. Without enforcement people _think_ there are more > important things to do than fixing warnings. > > Yes, it might mean that an update to a new gcc version means required > changes. But guess what? Whenever a warning pops up there is likely a > good reason for it and it is worthwhile spending time on it. Just like > all these signed vs unsigned warnings in gcc 4. They almost all the > time warrant looking at the code. Nothing stops you from doing internal builds with -Werror and then fixing all the warnings before you make a release. However, when you ship software that won't compile, your end users are either going to remove -Werror and rebuild or they're going to switch to something that works out-of-the-metaphorical-box. You've gained nothing. -- Nicholas Miell From drepper at redhat.com Sun Aug 7 02:26:49 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 06 Aug 2005 19:26:49 -0700 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <1123374673.2833.7.camel@localhost.localdomain> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> <1123374673.2833.7.camel@localhost.localdomain> Message-ID: <42F57169.6020608@redhat.com> Nicholas Miell wrote: > Nothing stops you from doing internal builds with -Werror and then > fixing all the warnings before you make a release. You don't get it. The people who need to use -Werror are all those people who rebuild code. This includes all the package maintainers but also all everybody who makes changes. Those are all the people doing rebuilds since otherwise they'd simply use the binary packages which are provided. -- ? 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 nmiell at comcast.net Sun Aug 7 02:54:11 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Sat, 06 Aug 2005 19:54:11 -0700 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <42F57169.6020608@redhat.com> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> <1123374673.2833.7.camel@localhost.localdomain> <42F57169.6020608@redhat.com> Message-ID: <1123383251.2833.16.camel@localhost.localdomain> On Sat, 2005-08-06 at 19:26 -0700, Ulrich Drepper wrote: > Nicholas Miell wrote: > > Nothing stops you from doing internal builds with -Werror and then > > fixing all the warnings before you make a release. > > You don't get it. The people who need to use -Werror are all those > people who rebuild code. This includes all the package maintainers but > also all everybody who makes changes. Those are all the people doing > rebuilds since otherwise they'd simply use the binary packages which are > provided. > In my experience, binary packages are the exception rather than the rule (especially in impoverished RPM land). Open source projects may include a somewhat recent binary tarball for one architecture, but those projects seem to be in the minority. Most of the people who end up unpacking a tarball and building it are end users who aren't interested in making any changes (beyond removing -Werror when necessary). A more sensible approach would be to include -Werror in CVS/SVN/etc. any development snapshots, but remove it for official release tarballs (which, obviously, aren't targeted towards developers). -- Nicholas Miell From jakub at redhat.com Sun Aug 7 04:55:55 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Sun, 7 Aug 2005 00:55:55 -0400 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <20050806223601.AD95C1809B2@magilla.sf.frob.com> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> Message-ID: <20050807045555.GR30077@devserv.devel.redhat.com> On Sat, Aug 06, 2005 at 03:36:01PM -0700, Roland McGrath wrote: > If there was a mention of this change, I overlooked it. > > The addition of -Wall to the $RPM_OPT_FLAGS value has some unintended > consequences. This broke my latest elfutils build until I worked around it. I'd say we should only add -Wall if -Werror is not used, because if -Werror is used, usually the package Makefiles play games with enabling and disabling some warnings. For this we could use specs file as suggested by Roland earlier: %rename cc1 cc1rhorig *cc1: %{!Wall:%{!Werror:-Wall}} %(cc1rhorig) and use -specs=/usr/lib/rpm/redhat/specs in %{optflags}. Some warnings like -Wpointer-sign are quite questionable and hit insane amount of code... Jakub From enrico.scholz at informatik.tu-chemnitz.de Sun Aug 7 08:56:50 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 07 Aug 2005 10:56:50 +0200 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <42F54DE0.2090800@redhat.com> (Ulrich Drepper's message of "Sat, 06 Aug 2005 16:55:12 -0700") References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> Message-ID: <877jeyjfal.fsf@kosh.bigo.ensc.de> drepper at redhat.com (Ulrich Drepper) writes: >> I'd argue that any upstream package which includes -Werror by default >> is broken, considering how often gcc warnings change. > > And I argue that we apparently must come to a state where -Werror is > enabled automatically. I would really like to use it, but existing APIs (SUSv3) do not support warning free development. E.g. 'dlsym()' returns an object pointer, but often a function pointer is wanted. I do not know a way to write | #include | | int main() | { | void (*foo)() = dlsym(0, "foo"); | void (*bar)() = (void (*)())dlsym(0, "bar"); | | foo(); | bar(); | } warning-free: | $ gcc -ldl -Wall -pedantic -W -Werror -std=c99 dlsym.c | cc1: warnings being treated as errors | dlsym.c: In function 'main': | dlsym.c:5: warning: ISO C forbids initialization between function pointer and 'void *' | dlsym.c:6: warning: ISO C forbids conversion of object pointer to function pointer type Or, I maintain a library which provides some deprecated functions and gives out warnings at link-time when they are used. The same project has some legacy tools (used by some people) which are triggering exactly these warnings. Enforcing '-Werror' would make it either impossible to mark obsolete functions (bad for developers), or to build legacy tools (bad for some users). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From leonard at den.ottolander.nl Sun Aug 7 10:51:19 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 07 Aug 2005 12:51:19 +0200 Subject: ioctl's and USB drives Message-ID: <1123411879.6037.42.camel@athlon.localdomain> Hi, I noticed hdparm doesn't work well on external USB drives. Try a hdparm -I /dev/sda and see it fail with a "HDIO_DRIVE_CMD(identify) failed: Invalid argument". (I notice this on both a 2.4 and 2.6 kernel and with hdparm-6.1.) My question is whether this is a shortcoming in the usb-storage driver, or because of some shortcoming in the firmware of the external drive (case). Or is it because the usb-storage driver uses emulated SCSI and this is why these commands fail? I would like to get these commands to work so I can password protect these drives with the new security commands introduced in hdparm. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From buildsys at redhat.com Sun Aug 7 11:24:42 2005 From: buildsys at redhat.com (Build System) Date: Sun, 7 Aug 2005 07:24:42 -0400 Subject: rawhide report: 20050807 changes Message-ID: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> New package scim-qtimm SCIM input method module for Qt Updated Packages: elfutils-0.112-1 ---------------- * Sat Aug 06 2005 Roland McGrath - 0.112-1 - update to 0.112 - elfcmp: some more relaxation. - elflint: many more tests, especially regarding to symbol versioning. - libelf: Add elfXX_offscn and gelf_offscn. - libasm: asm_begin interface changes. - libebl: Add three new interfaces to directly access machine, class, and data encoding information. kernel-2.6.12-1.1455_FC5 ------------------------ * Sat Aug 06 2005 Dave Jones - 2.6.13-rc5-git4 openoffice.org-1:1.9.122-4.2.0.fc5 ---------------------------------- * Fri Aug 05 2005 Caolan McNamara - 1:1.9.122-4 - session management and workspace restore corrections - add openoffice.org-1.9.112.oooXXXXX.exception.package.patch for rh#165197# thunderbird-0:1.0.6-3 --------------------- * Sat Aug 06 2005 Christopher Aillon 1.0.6-3 - Add patch to make file chooser dialog modal * Fri Jul 22 2005 Christopher Aillon 1.0.6-2 - Update to 1.0.6 Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for i386 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 Broken deps for s390 ---------------------------------------------------------- initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-strict-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 selinux-policy-strict - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 selinux-policy-targeted - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-targeted-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 Broken deps for ia64 ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) firstboot - 1.3.44-1.noarch requires system-config-display ppc64-utils - 0.7-9.ppc64 requires yaboot system-config-mouse - 1.2.11-1.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) Broken deps for s390x ---------------------------------------------------------- nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 selinux-policy-targeted-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 selinux-policy-strict - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) From drepper at redhat.com Sun Aug 7 15:33:34 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 07 Aug 2005 08:33:34 -0700 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <877jeyjfal.fsf@kosh.bigo.ensc.de> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> <877jeyjfal.fsf@kosh.bigo.ensc.de> Message-ID: <42F629CE.5070107@redhat.com> Enrico Scholz wrote: > | $ gcc -ldl -Wall -pedantic -W -Werror -std=c99 dlsym.c Nobody suggested using -pedantic, certainly I didn't. That's a completely useless option and I really would like for it to be removed. Just like -ansi. > Or, I maintain a library which provides some deprecated functions and > gives out warnings at link-time when they are used. The same project has > some legacy tools (used by some people) which are triggering exactly > these warnings. Enforcing '-Werror' would make it either impossible to > mark obsolete functions (bad for developers), or to build legacy tools > (bad for some users). First of all, warnings by the linker are not covered by -Werror. Second, there are -Wno-* parameters which can and should be added after the -Wall to avoid some warnings _for specific files_. It's just a matter of setting the Makefiles up to make this easily possible. The elfutils makefiles do just that. -- ? 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 otaylor at redhat.com Sun Aug 7 19:44:52 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 07 Aug 2005 15:44:52 -0400 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <42F54DE0.2090800@redhat.com> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> Message-ID: <1123443892.10026.32.camel@localhost.localdomain> On Sat, 2005-08-06 at 16:55 -0700, Ulrich Drepper wrote: > Nicholas Miell wrote: > > I'd argue that any upstream package which includes -Werror by default is > > broken, considering how often gcc warnings change. > > And I argue that we apparently must come to a state where -Werror is > enabled automatically. The current state, aggravated by adding -Wall, > is that warnings are ignored. The result: bugs the compiler finds are > no fixed. I even found one case where the _FORTIFY_SOURCE magic found a > buffer overflow and the maintainer hasn't seen it. > > It is crucial that packages are changed to have zero warnings. > Otherwise these bugs remain unnoticed since people think warnings are OK > and don't care. The "apparent" part is that using -Werror is the only > way to do this. Without enforcement people _think_ there are more > important things to do than fixing warnings. -Werror here seems like an unnecessarily blunt tool; there are plenty of warnings (unused variable warnings for example) that *do not* typically indicate real breakage, and having to patch around them in spec files would be wasting the package maintainer's time. Remember, on some packages we have only very small influence on the upstream maintainers and its not always easy to convince a maintainer to work around a false-positive warning, so we could have very large patch sets for some packages to suppress warnings. On the other hand, there are some warnings that almost always indicate serious problems (the warning you get when passing an int * to something that takes a long * on a 64-bit machine, for example.) We should easily be able to scan build logs for warnings with either a white-list or a black-list and fail builds based on that. Regards, Owen -------------- 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 rodd at clarkson.id.au Mon Aug 8 00:41:49 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 08 Aug 2005 10:41:49 +1000 Subject: rawhide report: 20050807 changes In-Reply-To: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> Message-ID: <1123461710.3522.3.camel@localhost.localdomain> On Sun, 2005-08-07 at 07:24 -0400, Build System wrote: > kernel-2.6.12-1.1455_FC5 > ------------------------ > * Sat Aug 06 2005 Dave Jones > - 2.6.13-rc5-git4 A warning about not being able to find my sound card driver appears and says to have a look in dmesg. dmesg reports: snd_intel8x0: Unknown parameter `' snd_intel8x0: Unknown parameter `' snd_intel8x0: Unknown parameter `' and lspci shows: [rodd at localhost ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation NV41.8 [GeForce Go 6800] (rev a2) 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3) 03:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08) 03:01.2 Class 0805: Ricoh Co Ltd SD Card reader (rev 17) 03:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG MiniPCI Adapter (rev 05) I didn't get to try kernel-2.6.12-1.1452_FC5 but sound worked fine before this. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From fedora at camperquake.de Mon Aug 8 00:44:05 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 8 Aug 2005 02:44:05 +0200 Subject: "umount: / is busy" Message-ID: <20050808024405.1135aa5f@nausicaa.camperquake.de> Hi. Sometimes, after a "yum upgrade", I get a message on shutdown saying that / is busy and can not be unmounted, leading to a filesystem check on the next reboot (or better: a journal replay). So far I have not been able to figure out what exactly causes this. My first thought was that a package used a loop mounted file system for something and forgot to umount it, but, having unloaded the loop driver manually before reboot, this can not be the solution. Anyone else seeing this or having an idea? -- The Thread went ACPI and couldn't resume. -- Florian Laws, dasr From davej at redhat.com Mon Aug 8 03:11:12 2005 From: davej at redhat.com (Dave Jones) Date: Sun, 7 Aug 2005 23:11:12 -0400 Subject: rawhide report: 20050807 changes In-Reply-To: <1123461710.3522.3.camel@localhost.localdomain> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> Message-ID: <20050808031112.GB5844@redhat.com> On Mon, Aug 08, 2005 at 10:41:49AM +1000, Rodd Clarkson wrote: > On Sun, 2005-08-07 at 07:24 -0400, Build System wrote: > > > kernel-2.6.12-1.1455_FC5 > > ------------------------ > > * Sat Aug 06 2005 Dave Jones > > - 2.6.13-rc5-git4 > > A warning about not being able to find my sound card driver appears and > says to have a look in dmesg. > > dmesg reports: > > snd_intel8x0: Unknown parameter `' > snd_intel8x0: Unknown parameter `' > snd_intel8x0: Unknown parameter `' Ok, I dropped the patch which reverted a check added upstream circa 2.6.11, which does that when it finds an obsolete module parameter, hoping that things had improved to the point we didn't need it any more. Whilst it may be fine for new installs, this is likely to screw things up on upgrades. *sigh*. I'll re-add it for the next build. (Though it probably won't make tomorrows build). Dave From rodd at clarkson.id.au Mon Aug 8 03:19:16 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 08 Aug 2005 13:19:16 +1000 Subject: rawhide report: 20050807 changes In-Reply-To: <20050808031112.GB5844@redhat.com> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> Message-ID: <1123471156.2970.1.camel@localhost.localdomain> On Sun, 2005-08-07 at 23:11 -0400, Dave Jones wrote: > On Mon, Aug 08, 2005 at 10:41:49AM +1000, Rodd Clarkson wrote: > > On Sun, 2005-08-07 at 07:24 -0400, Build System wrote: > > > > > kernel-2.6.12-1.1455_FC5 > > > ------------------------ > > > * Sat Aug 06 2005 Dave Jones > > > - 2.6.13-rc5-git4 > > > > A warning about not being able to find my sound card driver appears and > > says to have a look in dmesg. > > > > dmesg reports: > > > > snd_intel8x0: Unknown parameter `' > > snd_intel8x0: Unknown parameter `' > > snd_intel8x0: Unknown parameter `' > > Ok, I dropped the patch which reverted a check added upstream > circa 2.6.11, which does that when it finds an obsolete > module parameter, hoping that things had improved to the point > we didn't need it any more. > > Whilst it may be fine for new installs, this is likely to > screw things up on upgrades. *sigh*. > I'll re-add it for the next build. (Though it probably > won't make tomorrows build). Dave, Given that we're in a development cycyle, is this something that can be fixed with changes to settings on the system, or is it simply better to fix with a patch? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From davej at redhat.com Mon Aug 8 04:38:41 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 8 Aug 2005 00:38:41 -0400 Subject: rawhide report: 20050807 changes In-Reply-To: <1123471156.2970.1.camel@localhost.localdomain> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> Message-ID: <20050808043841.GC5844@redhat.com> On Mon, Aug 08, 2005 at 01:19:16PM +1000, Rodd Clarkson wrote: > Given that we're in a development cycyle, is this something that can be > fixed with changes to settings on the system, or is it simply better to > fix with a patch? Actually, thinking about it, lets hold off for a while, and try and figure out _which_ parameters its whining about. The fact that it reports the unknown param as `' is disconcerting. ISTR that this change fell over if it met a modprobe.conf with spaces at the end of a line. Can you check that yours hasn't got any ? If that doesn't make the errors go away, post your /etc/modprobe.conf, and I'll check the drivers to see which (if any) of the params went away. Dave From florin at andrei.myip.org Mon Aug 8 06:21:16 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 07 Aug 2005 23:21:16 -0700 Subject: "umount: / is busy" In-Reply-To: <20050808024405.1135aa5f@nausicaa.camperquake.de> References: <20050808024405.1135aa5f@nausicaa.camperquake.de> Message-ID: <1123482076.3286.9.camel@rivendell.home.local> On Mon, 2005-08-08 at 02:44 +0200, Ralf Ertzinger wrote: > > Sometimes, after a "yum upgrade", I get a message on shutdown saying that > / is busy and can not be unmounted, leading to a filesystem check on the > next reboot (or better: a journal replay). So far I have not been able to > figure out what exactly causes this. I noticed that it seems to always happen when upgrading glibc, but perhaps other packages too can trigger it. It is the reason why I pretty much always do "sync" before "reboot", "halt" or "poweroff". It would be nice if "sync" was included in the system scripts, right before doing umount. -- Florin Andrei http://florin.myip.org/ From dragoran at feuerpokemon.de Mon Aug 8 07:25:58 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 08 Aug 2005 09:25:58 +0200 Subject: ioctl's and USB drives In-Reply-To: <1123411879.6037.42.camel@athlon.localdomain> References: <1123411879.6037.42.camel@athlon.localdomain> Message-ID: <42F70906.70805@feuerpokemon.de> Leonard den Ottolander wrote: >Hi, > >I noticed hdparm doesn't work well on external USB drives. Try a hdparm >-I /dev/sda and see it fail with a "HDIO_DRIVE_CMD(identify) failed: >Invalid argument". (I notice this on both a 2.4 and 2.6 kernel and with >hdparm-6.1.) > >My question is whether this is a shortcoming in the usb-storage driver, >or because of some shortcoming in the firmware of the external drive >(case). Or is it because the usb-storage driver uses emulated SCSI and >this is why these commands fail? > >I would like to get these commands to work so I can password protect >these drives with the new security commands introduced in hdparm. > >Leonard. > > > hdparm -I only works on IDE devices on my sata drive it does not work (/dev/sda1) but on the IDE drive (/dev/hda) it does. From veillard at redhat.com Mon Aug 8 08:07:55 2005 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 8 Aug 2005 04:07:55 -0400 Subject: addition of -Wall to default flags (redhat-rpm-config-8.0.38-1) In-Reply-To: <42F57169.6020608@redhat.com> References: <20050806223601.AD95C1809B2@magilla.sf.frob.com> <1123369682.2833.2.camel@localhost.localdomain> <42F54DE0.2090800@redhat.com> <1123374673.2833.7.camel@localhost.localdomain> <42F57169.6020608@redhat.com> Message-ID: <20050808080755.GN21787@redhat.com> On Sat, Aug 06, 2005 at 07:26:49PM -0700, Ulrich Drepper wrote: > Nicholas Miell wrote: > > Nothing stops you from doing internal builds with -Werror and then > > fixing all the warnings before you make a release. > > You don't get it. The people who need to use -Werror are all those > people who rebuild code. This includes all the package maintainers but > also all everybody who makes changes. Those are all the people doing > rebuilds since otherwise they'd simply use the binary packages which are > provided. Then what you really need to do is make -Wall the default for gcc ! There is only so much the packagers can do over the packages, this is OSS the key to success is to tap on the masses of people looking at the problem, not on a limited few who usually are not in charge. Get the message back upstream, enable -Wall as the default gcc option is the only sensible methodology, why on earth are you hiding those informations if you think they are so crucially important that they should lead to build errors here. -Wall -Werror on Red Hat built will generate a tension between Red Hat packagers and upstream, on the other hand -Wall activated by default will bring the problem back directly to the source in most cases (I assume an overhelming majority of the Fedora packages are built with gcc upstream). What you are aiming at sounds right, but my point is that your solution is not the most effective, and is likely to just miss its real target. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From arjanv at redhat.com Mon Aug 8 08:09:09 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 08 Aug 2005 10:09:09 +0200 Subject: rawhide report: 20050807 changes In-Reply-To: <20050808043841.GC5844@redhat.com> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> <20050808043841.GC5844@redhat.com> Message-ID: <1123488549.3245.25.camel@laptopd505.fenrus.org> On Mon, 2005-08-08 at 00:38 -0400, Dave Jones wrote: > > The fact that it reports the unknown param as `' is disconcerting. > ISTR that this change fell over if it met a modprobe.conf with > spaces at the end of a line. Can you check that yours hasn't > got any ? If that doesn't make the errors go away, post your > /etc/modprobe.conf, and I'll check the drivers to see which (if any) > of the params went away. kudzu has a script to rename kernel modules in modprobe.conf if they change name that the kernel spec calls... maybe we should teach that script to remove trailing whitespace as well ;) -------------- 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 Aug 8 11:26:11 2005 From: buildsys at redhat.com (Build System) Date: Mon, 8 Aug 2005 07:26:11 -0400 Subject: rawhide report: 20050808 changes Message-ID: <200508081126.j78BQB6h004033@porkchop.devel.redhat.com> Updated Packages: gnutls-1.2.6-1 -------------- * Sun Aug 07 2005 Tomas Mraz 1.2.6-1 - upgrade to newest upstream (rebuild of dependencies necessary) kernel-2.6.12-1.1456_FC5 ------------------------ * Sun Aug 07 2005 Dave Jones - 2.6.13-rc6 x86info-1:1.14-1.12 ------------------- * Sun Aug 07 2005 Dave Jones - Update to upstream 1.14 (now builds on x86-64) Broken deps for ppc ---------------------------------------------------------- evolution-data-server - 1.3.6.1-1.ppc requires libgnutls.so.11 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 lftp - 3.2.1-1.ppc requires libgnutls.so.11(GNUTLS_REL_1_0_9) lftp - 3.2.1-1.ppc requires libgnutls.so.11 evolution-connector - 2.3.6-2.ppc requires libgnutls.so.11 evolution-webcal - 2.3.90-1.ppc requires libgnutls.so.11 evolution - 2.3.6.1-3.ppc requires libgnutls.so.11 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 xmlsec1-gnutls - 1.2.8-2.ppc requires libgnutls.so.11(GNUTLS_REL_1_0_9) xmlsec1-gnutls - 1.2.8-2.ppc requires libgnutls.so.11 libsoup - 2.2.3-4.ppc requires libgnutls.so.11(GNUTLS_REL_1_0_9) libsoup - 2.2.3-4.ppc requires libgnutls.so.11 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 xmlsec1-gnutls - 1.2.8-2.i386 requires libgnutls.so.11(GNUTLS_REL_1_0_9) xmlsec1-gnutls - 1.2.8-2.i386 requires libgnutls.so.11 evolution-webcal - 2.3.90-1.i386 requires libgnutls.so.11 evolution-data-server - 1.3.6.1-1.i386 requires libgnutls.so.11 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 libsoup - 2.2.3-4.i386 requires libgnutls.so.11(GNUTLS_REL_1_0_9) libsoup - 2.2.3-4.i386 requires libgnutls.so.11 lftp - 3.2.1-1.i386 requires libgnutls.so.11(GNUTLS_REL_1_0_9) lftp - 3.2.1-1.i386 requires libgnutls.so.11 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 evolution-connector - 2.3.6-2.i386 requires libgnutls.so.11 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 evolution - 2.3.6.1-3.i386 requires libgnutls.so.11 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) evolution-connector - 2.3.6-2.ia64 requires libgnutls.so.11()(64bit) xmlsec1-gnutls - 1.2.8-2.ia64 requires libgnutls.so.11()(64bit) xmlsec1-gnutls - 1.2.8-2.ia64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) evolution-webcal - 2.3.90-1.ia64 requires libgnutls.so.11()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) evolution-data-server - 1.3.6.1-1.ia64 requires libgnutls.so.11()(64bit) lftp - 3.2.1-1.ia64 requires libgnutls.so.11()(64bit) lftp - 3.2.1-1.ia64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) libsoup - 2.2.3-4.ia64 requires libgnutls.so.11()(64bit) libsoup - 2.2.3-4.ia64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) evolution - 2.3.6.1-3.ia64 requires libgnutls.so.11()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 libsoup - 2.2.3-4.i386 requires libgnutls.so.11(GNUTLS_REL_1_0_9) libsoup - 2.2.3-4.i386 requires libgnutls.so.11 xmlsec1-gnutls - 1.2.8-2.x86_64 requires libgnutls.so.11()(64bit) xmlsec1-gnutls - 1.2.8-2.x86_64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) lftp - 3.2.1-1.x86_64 requires libgnutls.so.11()(64bit) lftp - 3.2.1-1.x86_64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 evolution-connector - 2.3.6-2.x86_64 requires libgnutls.so.11()(64bit) evolution - 2.3.6.1-3.x86_64 requires libgnutls.so.11()(64bit) cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 evolution-webcal - 2.3.90-1.x86_64 requires libgnutls.so.11()(64bit) libsoup - 2.2.3-4.x86_64 requires libgnutls.so.11()(64bit) libsoup - 2.2.3-4.x86_64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) evolution-data-server - 1.3.6.1-1.x86_64 requires libgnutls.so.11()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 xmlsec1-gnutls - 1.2.8-2.ppc64 requires libgnutls.so.11()(64bit) xmlsec1-gnutls - 1.2.8-2.ppc64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) firstboot - 1.3.44-1.noarch requires system-config-display lftp - 3.2.1-1.ppc64 requires libgnutls.so.11()(64bit) lftp - 3.2.1-1.ppc64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) libsoup - 2.2.3-4.ppc64 requires libgnutls.so.11()(64bit) libsoup - 2.2.3-4.ppc64 requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) Broken deps for s390 ---------------------------------------------------------- selinux-policy-targeted - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 libsoup - 2.2.3-4.s390 requires libgnutls.so.11(GNUTLS_REL_1_0_9) libsoup - 2.2.3-4.s390 requires libgnutls.so.11 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 lftp - 3.2.1-1.s390 requires libgnutls.so.11(GNUTLS_REL_1_0_9) lftp - 3.2.1-1.s390 requires libgnutls.so.11 selinux-policy-strict-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 evolution - 2.3.6.1-3.s390 requires libgnutls.so.11 evolution-data-server - 1.3.6.1-1.s390 requires libgnutls.so.11 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 xmlsec1-gnutls - 1.2.8-2.s390 requires libgnutls.so.11(GNUTLS_REL_1_0_9) xmlsec1-gnutls - 1.2.8-2.s390 requires libgnutls.so.11 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 evolution-webcal - 2.3.90-1.s390 requires libgnutls.so.11 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 evolution-connector - 2.3.6-2.s390 requires libgnutls.so.11 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 Broken deps for s390x ---------------------------------------------------------- initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 selinux-policy-strict-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 libsoup - 2.2.3-4.s390x requires libgnutls.so.11()(64bit) libsoup - 2.2.3-4.s390x requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 lftp - 3.2.1-1.s390x requires libgnutls.so.11()(64bit) lftp - 3.2.1-1.s390x requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) evolution-webcal - 2.3.90-1.s390x requires libgnutls.so.11()(64bit) evolution-connector - 2.3.6-2.s390x requires libgnutls.so.11()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) selinux-policy-targeted-sources - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 selinux-policy-strict - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 xmlsec1-gnutls - 1.2.8-2.s390x requires libgnutls.so.11()(64bit) xmlsec1-gnutls - 1.2.8-2.s390x requires libgnutls.so.11(GNUTLS_REL_1_0_9)(64bit) evolution - 2.3.6.1-3.s390x requires libgnutls.so.11()(64bit) quota - 1:3.12-6.s390x requires kernel >= 0:2.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 evolution-data-server - 1.3.6.1-1.s390x requires libgnutls.so.11()(64bit) hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 libsoup - 2.2.3-4.s390 requires libgnutls.so.11(GNUTLS_REL_1_0_9) libsoup - 2.2.3-4.s390 requires libgnutls.so.11 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.3-13.noarch requires kernel >= 0:2.6.11-1.1219 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) From fedora at camperquake.de Mon Aug 8 12:29:37 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 8 Aug 2005 14:29:37 +0200 Subject: "umount: / is busy" In-Reply-To: <1123482076.3286.9.camel@rivendell.home.local> References: <20050808024405.1135aa5f@nausicaa.camperquake.de> <1123482076.3286.9.camel@rivendell.home.local> Message-ID: <20050808142937.6f8629e2@nausicaa.camperquake.de> Hi. Florin Andrei wrote: > It is the reason why I pretty much always do "sync" before "reboot", > "halt" or "poweroff". > It would be nice if "sync" was included in the system scripts, right > before doing umount. I was under the impression that umounting a partition means that sync is called implicitly. You have to free your dirty buffers before removing the medium... -- Angie chalks another Blue, mother smiles, she did it too... -- Marillion, "Garden Party" From russell at coker.com.au Mon Aug 8 12:51:02 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 8 Aug 2005 22:51:02 +1000 Subject: "umount: / is busy" In-Reply-To: <1123482076.3286.9.camel@rivendell.home.local> References: <20050808024405.1135aa5f@nausicaa.camperquake.de> <1123482076.3286.9.camel@rivendell.home.local> Message-ID: <200508082251.06399.russell@coker.com.au> On Monday 08 August 2005 16:21, Florin Andrei wrote: > On Mon, 2005-08-08 at 02:44 +0200, Ralf Ertzinger wrote: > > Sometimes, after a "yum upgrade", I get a message on shutdown saying that > > / is busy and can not be unmounted, leading to a filesystem check on the > > next reboot (or better: a journal replay). So far I have not been able to > > figure out what exactly causes this. > > I noticed that it seems to always happen when upgrading glibc, but > perhaps other packages too can trigger it. > > It is the reason why I pretty much always do "sync" before "reboot", > "halt" or "poweroff". > It would be nice if "sync" was included in the system scripts, right > before doing umount. Below is the relevant section from the source of /sbin/shutdown. halt also calls sync() so there's no need for scripts to do such things. sync(); fprintf(stderr, "shutdown: turning off swap\r\n"); spawn(0, "swapoff", "-a", NULL); fprintf(stderr, "shutdown: unmounting all file systems\r\n"); spawn(0, "umount", "-a", NULL); /* We're done, halt or reboot now. */ if (do_halt) { fprintf(stderr, "The system is halted. Press CTRL-ALT-DEL or turn off power\r\n"); init_reboot(BMAGIC_HALT); exit(0); } fprintf(stderr, "Please stand by while rebooting the system.\r\n"); init_reboot(BMAGIC_REBOOT); exit(0); -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rodd at clarkson.id.au Mon Aug 8 12:52:33 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 08 Aug 2005 22:52:33 +1000 Subject: rawhide report: 20050807 changes In-Reply-To: <20050808043841.GC5844@redhat.com> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> <20050808043841.GC5844@redhat.com> Message-ID: <1123505554.2968.4.camel@localhost.localdomain> On Mon, 2005-08-08 at 00:38 -0400, Dave Jones wrote: > On Mon, Aug 08, 2005 at 01:19:16PM +1000, Rodd Clarkson wrote: > > > Given that we're in a development cycyle, is this something that can be > > fixed with changes to settings on the system, or is it simply better to > > fix with a patch? > > Actually, thinking about it, lets hold off for a while, and try > and figure out _which_ parameters its whining about. > The fact that it reports the unknown param as `' is disconcerting. > ISTR that this change fell over if it met a modprobe.conf with > spaces at the end of a line. Can you check that yours hasn't > got any ? If that doesn't make the errors go away, post your > /etc/modprobe.conf, and I'll check the drivers to see which (if any) > of the params went away. Okay, I updated to the current kernel (just to be sure) and the problem was still there. This is (if course) kernel-2.6.12-1.1456_FC5 I then edited /etc/modprobe.conf and (surprise, surprise) there were a couple of spaces after the following lines: options snd-card-0 index=0 options snd-intel8x0 index=0 I've cut and paste this in, so the spaces are still there. I removed these spaces and rebooted. The problem is now gone and sound is working. I've attached the modprobe.conf file (prechanges) so that you can have a better look at it (if it helps) thanks for you help on this. Rodd -- "It's a fine line between denial and faith. It's much better on my side" -------------- next part -------------- alias eth0 b44 alias scsi_hostadapter ata_piix alias eth1 ipw2200 alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 options snd-intel8x0 index=0 remove snd-intel8x0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0 alias usb-controller ehci-hcd alias usb-controller1 uhci-hcd alias ieee1394-controller ohci1394 alias char-major-195* nvidia From rodd at clarkson.id.au Mon Aug 8 12:56:02 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 08 Aug 2005 22:56:02 +1000 Subject: rawhide report: 20050806 changes In-Reply-To: <200508061120.j76BKGmg008453@porkchop.devel.redhat.com> References: <200508061120.j76BKGmg008453@porkchop.devel.redhat.com> Message-ID: <1123505762.2968.7.camel@localhost.localdomain> > metacity-2.11.1-1 > ----------------- > * Fri Aug 05 2005 Matthias Clasen 2.11.1-1 > - New upstream version Anyone noticed that the current version of metacity seems a little unstable. Every now and then all the windows end up on the one workspace and the window borders disappear and then all is back to normal (which is pretty much how metacity dies some times). Am I the only one noticing this? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From janina at rednote.net Mon Aug 8 15:29:38 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 8 Aug 2005 11:29:38 -0400 Subject: Bug 124248 Fix -- Revisited In-Reply-To: <1116876711.4292.28.camel@bree.local.net> References: <20050523193026.GA12493@rednote.net> <1116876711.4292.28.camel@bree.local.net> Message-ID: <20050808152938.GE15540@rednote.net> I (and several others) have been using telnet to install FC4. Very nice. However, there's one capibility that used to be there which is no longer there in the newly fixed telnet feature. In the old days (up until FC2), we could use ctrl-z to suspend telnet and access an ash shell. This no longer works. The ctrl-z suspend was particularly valuable for tweaks to the newly installed system before a reboot, especially for "eyes-free" users who are not being served by First Boot (and our inability to escape out of First Boot). I guess our "first boot" was the ctrl-z suspend functionality! Should this be a new bug? A reopen of the old bug? Thanks. Jeremy Katz writes: > On Mon, 2005-05-23 at 15:30 -0400, Janina Sajka wrote: > > I understand the telnet bug fix is now in CVS, so can this fix please > > make FC4? > > It should make it. anaconda has a few other changes which need to go in > and since I haven't branched yet, this will get in as well > Very cool. It will really help. Sorry for the messy post earlier today. I really shouldn't try to two three things at once. > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. Jeremy Katz writes: > On Mon, 2005-05-23 at 15:30 -0400, Janina Sajka wrote: > > I understand the telnet bug fix is now in CVS, so can this fix please > > make FC4? > > It should make it. anaconda has a few other changes which need to go in > and since I haven't branched yet, this will get in as well > Very cool. It will really help. Sorry for the messy post earlier today. I really shouldn't try to two three things at once. > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From greenrd at greenrd.org Mon Aug 8 17:04:19 2005 From: greenrd at greenrd.org (Robin Green) Date: Mon, 08 Aug 2005 18:04:19 +0100 Subject: Current devel kernel - possible security hole References: <1123238145.28662.25.camel@localhost> Message-ID: On Fri, 05 Aug 2005 11:35:45 +0100, Paul wrote: > I have a small mono application which uses threading. Somehow, I managed > to run the application and kill the desktop, but was then able to > access, as a standard user, and both read and write to anywhere on my > hard drive. > > I can reproduce the problem with the same application, but not with same > code using C or C++. How weird! Some questions: - Did you have to log in again or was this on an existing shell or nautilus? - Did you use ps to check the real/effective uids of the process(es) that are accessing forbidden files? I would post this to bugzilla to make sure it doesn't get lost. -- Robin From buildsys at redhat.com Tue Aug 9 11:33:37 2005 From: buildsys at redhat.com (Build System) Date: Tue, 9 Aug 2005 07:33:37 -0400 Subject: rawhide report: 20050809 changes Message-ID: <200508091133.j79BXbk7013955@porkchop.devel.redhat.com> New package scim-pinyin Smart Pinyin IMEngine for Smart Common Input Method platform Updated Packages: audit-1.0.2-1 ------------- * Mon Aug 08 2005 Steve Grubb 1.0.2-1 - Make sure error packets get eaten. - Fix a few error messages in auditctl - Fix handling of unsupported watches when reading rules from file in auditctl bash-3.0-33 ----------- * Mon Aug 08 2005 Tim Waugh 3.0-33 - Fixed multibyte IFS handling for invalid input (bug #165243). * Mon Aug 08 2005 Tim Waugh 3.0-32 - Fixed 'LC_ALL=C export LC_ALL' behaviour (bug #165249). * Thu Jun 23 2005 Tim Waugh - Added ulimit support for RLIMIT_NICE and RLIMIT_RTPRIO (bug #157049). bluez-hcidump-1.24-1 -------------------- * Mon Aug 08 2005 David Woodhouse 1.24-1 - update to bluez-hcidump 1.24 - require bluez-libs 1.18 bluez-libs-2.19-1 ----------------- * Mon Aug 08 2005 David Woodhouse 2.19-1 - Update to bluez-libs 2.19 bluez-utils-2.19-1 ------------------ * Mon Aug 08 2005 David Woodhouse 2.19-1 - Update to bluez-utils 2.19 dia-1:0.94-12 ------------- * Fri Apr 08 2005 Caolan McNamara - rh#165337# crash on >= 1000% xoom * Thu Apr 07 2005 Caolan McNamara - rh#154087# non existing links * Fri Mar 25 2005 Florian La Roche - add PreReq: for scrollkeeper-update evolution-2.3.6.1-5 ------------------- * Mon Aug 08 2005 Tomas Mraz - 2.3.6.1-5 - rebuild with new gnutls * Tue Aug 02 2005 David Malcolm - 2.3.6.1-4 - Added patch to show correct mimetype for OpenOffice.org files when guessing type for attachments with mimetype "application/octet-stream" (#164957) evolution-connector-2.3.6-3 --------------------------- * Mon Aug 08 2005 Tomas Mraz - 2.3.6-3 - rebuild with new gnutls evolution-data-server-1.3.6.1-2 ------------------------------- * Mon Aug 08 2005 Tomas Mraz - 1.3.6.1-2 - rebuild with new gnutls evolution-webcal-2.3.90-2 ------------------------- * Mon Aug 08 2005 Tomas Mraz - 2.3.90-2 - rebuild with new gnutls gcc-4.0.1-7 ----------- * Mon Aug 08 2005 Jakub Jelinek 4.0.1-7 - update from CVS - PRs c++/23191, c/22311, c/22458, fortran/22010, libfortran/23178, middle-end/21291, middle-end/21529, middle-end/21728, middle-end/21964, target/18582, target/20621, target/20673, target/21723, tree-optimization/19899, tree-optimization/23192 - check -fstack-protector* canary even before doing tail calls (Richard Henderson, PR middle-end/23221) - use DWARF3 DW_CFA_offset_extended_sf instead of obsolete DW_CFA_GNU_negative_offset_extended in libffi handwritten assembly on ppc (#165039) glibc-2.3.90-8 -------------- * Mon Aug 08 2005 Jakub Jelinek 2.3.90-8 - update from CVS - nscd persistent database verifier (#164001) - cleanup _FORTIFY_SOURCE bits/*.h headers (#165000) - handle EINTR in sigwait properly - make sure poor man's stack guard randomization keeps first byte 0 even on big-endian 32-bit arches - fix {elf,nptl}/tst-stackguard1 - obsolete linuxthreads-devel in glibc-devel joram-0:4.1.5-1jpp_5fc ---------------------- * Mon Aug 08 2005 Gary Benson 0:4.1.5-1jpp_5fc - Add jonas resource adaptor. kdeaccessibility-1:3.4.2-1 -------------------------- * Mon Aug 08 2005 Than Ngo 1:3.4.2-1 - update to 3.4.2 kdeadmin-7:3.4.2-1 ------------------ * Mon Aug 08 2005 Than Ngo 7:3.4.2-1 - update to 3.4.2 * Mon Jul 18 2005 Than Ngo 7:3.4.1-2 - enable kuser #161051 kdegames-6:3.4.2-1 ------------------ * Mon Aug 08 2005 Than Ngo 6:3.4.2-1 - update to 3.4.2 kdesdk-3.4.2-1 -------------- * Mon Aug 08 2005 Than Ngo 3.4.2-1 - update to 3.4.2 kernel-2.6.12-1.1464_FC5 ------------------------ * Tue Aug 09 2005 Dave Jones - Improve the spinlock debugging panic code. (Worse case, users can now boot with 'dontpanic') - Add new patch to deal with the 'white space at eol of modprobe.conf' bug. (This one doesn't ignore obsolete parameters). * Mon Aug 08 2005 Dave Jones - Various specfile cleanup. - dropped dead patches, renamed some patches, updated package conflicts: - Improve megaraid compatiblity hack. (Now the legacy driver doesn't claim support for the drivers that the newer driver supports). - Disable building of sk98lin driver. (Use sk98 instead). lftp-3.2.1-2 ------------ * Mon Aug 08 2005 Tomas Mraz - 3.2.1-2 - rebuild with new gnutls libsoup-2.2.3-5 --------------- * Mon Aug 08 2005 Tomas Mraz - 2.2.3-5 - rebuild with new gnutls man-pages-2.07-1 ---------------- * Mon Aug 08 2005 Ivana Varekova 2.07-1 - update to 2.07 * Mon Jul 04 2005 Jiri Ryska 2.05-1 - update to 2.05 - atanh(3) fix - issue(5) fix - ldd(1) fix - removed man1p/{compress,uncompress,renice}.1p * Mon Apr 04 2005 Jiri Ryska 1.67-7 - io_setup() and io_destroy() pages now refers to header file - fixed types for struct shmid_ds in shmget(2) and shmctl(2) - fixed pages for readv(2) and writev(2) netpbm-10.28-5 -------------- * Tue Aug 09 2005 Jindrich Novy 10.28-5 - fix CAN-2005-2471, unsafe gs calls from pstopnm (#165355) openoffice.org-1:1.9.123-1.2.0.fc5 ---------------------------------- * Mon Aug 08 2005 Caolan McNamara - 1:1.9.123-1 - use system beanshell - drop integrated workspace.cmcfixes12 - drop integrated ooo51736.xsltproc.evenwithjava.patch - drop integrated ooo51745.cpputools.patch - drop integrated ooo51755.scp2.parallel.patch - drop integrated ooo51774.rsc.parallel.patch selinux-policy-strict-1.25.3-14 ------------------------------- * Mon Aug 08 2005 Dan Walsh 1.25.3-14 - Allow passwd to read sysctl - Fix fsadm for zip drives selinux-policy-targeted-1.25.3-14 --------------------------------- * Mon Aug 08 2005 Dan Walsh 1.25.3-14 - Allow passwd to read sysctl - Fix fsadm for zip drives shadow-utils-2:4.0.11.1-3 ------------------------- * Mon Aug 08 2005 Peter Vrabec 2:4.0.11.1-3 - provide getspnam.3 man page(#162476) - fix useradd man page(#97131) * Mon Aug 08 2005 Peter Vrabec 2:4.0.11.1-2 - do not copy files from skel directory if home directory already exist (#89591,#80242) system-config-bind-4.0.0-26_FC5 ------------------------------- * Mon Aug 08 2005 Jason Vas Dias - 4.0.0-22 - fix bug 165292: missing 'key' keyword in ACL named keys - workaround ISC bug 15195: named cannot handle multiple keys in rndc.key * Fri Jul 29 2005 Jason Vas Dias - 4.0.0-21 - fix bug 164245: generate desktop file from translations in .po files - fix bug 164613, 164611: translated string typos - further fix for bug 158438: sentence splitting * Mon Jul 25 2005 Jason Vas Dias - 4.0.0-20 - fix bug 164129: DNS.py 'declartation' -> 'declaration' - fix bug 163937: NamedConfOptions 'Name of ke.' -> 'Name of key.' - fix bug 158438: avoid sentence splitting in translatable messages tetex-3.0-5 ----------- * Thu Aug 04 2005 Jindrich Novy 3.0-5 - run texhash in post, postun phase for the doc subpackage (#165070) - rebuilt (#165104) * Thu Jul 21 2005 Jindrich Novy - fix texdoctk bindings to fit FC (#162442) - fix some usages of uninitialized variables (#162413) * Mon Jul 18 2005 Jindrich Novy - inform user about perl-Tk dependency when using texdoctk (#162441) vnc-4.1.1-15 ------------ * Mon Aug 08 2005 Tim Waugh 4.1.1-15 - Fixed xorg-x11 build (__SSP__ gets set by -fstack-protector). - Fixed desktop file again (bug #63689). xmlsec1-1.2.8-3 --------------- * Mon Aug 08 2005 1.2.8-3 - rebuilt with new gnutls - nspr has been split to a separate package xmlto-0.0.18-9 -------------- * Mon Aug 08 2005 Tim Waugh 0.0.18-9 - Fixed quoting in scripts (bug #165338). Broken deps for x86_64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- system-config-keyboard - 1.2.6-2.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config firstboot - 1.3.44-1.noarch requires system-config-display gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390 ---------------------------------------------------------- gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-strict - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 selinux-policy-strict-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 dhcp - 11:3.0.3-1.s390 requires kernel >= 0:2.2.18 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 selinux-policy-targeted - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 Broken deps for s390x ---------------------------------------------------------- sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) selinux-policy-targeted - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 libpcap - 14:0.9.3-2.s390 requires kernel >= 0:2.2.0 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 hal - 0.5.3-2.s390 requires kernel >= 0:2.6.11 selinux-policy-strict - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.3-2.s390x requires kernel >= 0:2.6.11 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 dhcp - 11:3.0.3-1.s390x requires kernel >= 0:2.2.18 libpcap - 14:0.9.3-2.s390x requires kernel >= 0:2.2.0 selinux-policy-strict-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) quota - 1:3.12-6.s390x requires kernel >= 0:2.4 selinux-policy-targeted-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 From naoki at valuecommerce.com Tue Aug 9 02:41:17 2005 From: naoki at valuecommerce.com (Naoki) Date: Tue, 09 Aug 2005 11:41:17 +0900 Subject: Package names and capitalization. Why? Message-ID: <1123555277.16771.97.camel@dragon.sys.intra> Hi y'all, Is there any (good) reason for having uppercase characters in RPM file names? If not, how about a policy against it? As a pretty basic example why it wouldn't seem to be a "good thing" we have packages called Gconf* and *gconf* which just makes it that little bit more annoying to deal with. Here is the full list of packages with uppercase chars from the devel tree.. 4Suite-1.0-9.b1.i386.rpm Canna-3.7p3-13.i386.rpm Canna-devel-3.7p3-13.i386.rpm Canna-libs-3.7p3-13.i386.rpm ElectricFence-2.2.2-20.i386.rpm GConf-1.0.9-17.i386.rpm GConf-devel-1.0.9-17.i386.rpm GConf2-2.11.90-1.i386.rpm GConf2-devel-2.11.90-1.i386.rpm GFS-6.1.0-3.i386.rpm GFS-kernel-2.6.11.8-20050601...> GFS-kernel-2.6.11.8-20050601...> GFS-kernel-smp-2.6.11.8-20050..> GFS-kernel-xen0-2.6.11.8-2005..> GFS-kernel-xenU-2.6.11.8-2005..> GFS-kernheaders-2.6.11.8-2005..> GFS-kernheaders-2.6.11.8-2005..> Guppi-0.40.3-23.i386.rpm Guppi-devel-0.40.3-23.i386.rpm HelixPlayer-1.0.5-1.i386.rpm ImageMagick-6.2.2.0-4.i386.rpm ImageMagick-c++-6.2.2.0-4.i38..> ImageMagick-c++-devel-6.2.2.0..> ImageMagick-devel-6.2.2.0-4.i..> ImageMagick-perl-6.2.2.0-4.i3..> MAKEDEV-3.19-4.i386.rpm MyODBC-2.50.39-24.i386.rpm MySQL-python-1.2.0-2.i386.rpm NetworkManager-0.4-34.cvs2005..> NetworkManager-devel-0.4-34.c..> NetworkManager-glib-0.4-34.cv..> NetworkManager-gnome-0.4-34.c..> ORBit-0.5.17-15.i386.rpm ORBit-devel-0.5.17-15.i386.rpm ORBit2-2.12.2-1.i386.rpm ORBit2-devel-2.12.2-1.i386.rpm OpenIPMI-1.4.14-5.i386.rpm OpenIPMI-devel-1.4.14-5.i386.rpm OpenIPMI-libs-1.4.14-5.i386.rpm OpenIPMI-tools-1.4.14-5.i386.rpm PyQt-3.14.1-1.i386.rpm PyQt-devel-3.14.1-1.i386.rpm PyQt-examples-3.14.1-1.i386.rpm PyXML-0.8.4-3.i386.rpm Pyrex-0.9.3-1.noarch.rpm SDL-1.2.8-3.2.i386.rpm SDL-devel-1.2.8-3.2.i386.rpm SysVinit-2.85-40.i386.rpm Xaw3d-1.5E-4.i386.rpm Xaw3d-devel-1.5E-4.i386.rpm Xaw3d is great and all but does it deserve a capital letter over xorg-x11 ? From breeze at smsonline.com Mon Aug 8 21:47:37 2005 From: breeze at smsonline.com (Bill Rees) Date: Mon, 08 Aug 2005 14:47:37 -0700 Subject: printer install packages ignore pkg selection during install Message-ID: <42F7D2F9.6000503@smsonline.com> Hi all I've noticed that during FC4 install if I decide to manually chose packages to install that deselecting printer support seems to be ignored. I still get those packages installed. Not only those packages but drivers and printer fonts from other packages as well. Has anyone else had problems such as these? I certainly would like printer support to refrain from installing itself when I deselect those packages but haven't found any magic incantation to accomplish this. Ideas folks? bill From leonard at den.ottolander.nl Mon Aug 8 21:19:01 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 08 Aug 2005 23:19:01 +0200 Subject: ioctl's and USB drives In-Reply-To: <42F70906.70805@feuerpokemon.de> References: <1123411879.6037.42.camel@athlon.localdomain> <42F70906.70805@feuerpokemon.de> Message-ID: <1123535941.6039.5.camel@athlon.localdomain> Hi Dragoran, On Mon, 2005-08-08 at 09:25, dragoran wrote: > Leonard den Ottolander wrote: > >I noticed hdparm doesn't work well on external USB drives. Try a hdparm > >-I /dev/sda and see it fail with a "HDIO_DRIVE_CMD(identify) failed: > >Invalid argument". (I notice this on both a 2.4 and 2.6 kernel and with > >hdparm-6.1.) > > > >My question is whether this is a shortcoming in the usb-storage driver, > >or because of some shortcoming in the firmware of the external drive > >(case). Or is it because the usb-storage driver uses emulated SCSI and > >this is why these commands fail? > hdparm -I only works on IDE devices on my sata drive it does not work > (/dev/sda1) but on the IDE drive (/dev/hda) it does. So I assume it's the SCSI layer that is dropping these commands. Is there a way to work around this by patching hdparm or do I have to hack the kernel SCSI (emulation) layer to be able to send these commands? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From katzj at redhat.com Mon Aug 8 18:45:51 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 Aug 2005 14:45:51 -0400 Subject: rawhide report: 20050807 changes In-Reply-To: <1123488549.3245.25.camel@laptopd505.fenrus.org> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> <20050808043841.GC5844@redhat.com> <1123488549.3245.25.camel@laptopd505.fenrus.org> Message-ID: <42F7A85F.6090004@redhat.com> Arjan van de Ven wrote: > On Mon, 2005-08-08 at 00:38 -0400, Dave Jones wrote: >>The fact that it reports the unknown param as `' is disconcerting. >>ISTR that this change fell over if it met a modprobe.conf with >>spaces at the end of a line. Can you check that yours hasn't >>got any ? If that doesn't make the errors go away, post your >>/etc/modprobe.conf, and I'll check the drivers to see which (if any) >>of the params went away. > > kudzu has a script to rename kernel modules in modprobe.conf if they > change name that the kernel spec calls... maybe we should teach that > script to remove trailing whitespace as well ;) This only runs when you install a new kernel, so it's probably not the right answer :-) On the other hand, having module-init-tools do some cleanup if that's what the kernel expects might make sense. Jeremy From davej at redhat.com Mon Aug 8 18:38:15 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 8 Aug 2005 14:38:15 -0400 Subject: rawhide report: 20050807 changes In-Reply-To: <1123488549.3245.25.camel@laptopd505.fenrus.org> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> <20050808043841.GC5844@redhat.com> <1123488549.3245.25.camel@laptopd505.fenrus.org> Message-ID: <20050808183815.GC26182@redhat.com> On Mon, Aug 08, 2005 at 10:09:09AM +0200, Arjan van de Ven wrote: > On Mon, 2005-08-08 at 00:38 -0400, Dave Jones wrote: > > > > The fact that it reports the unknown param as `' is disconcerting. > > ISTR that this change fell over if it met a modprobe.conf with > > spaces at the end of a line. Can you check that yours hasn't > > got any ? If that doesn't make the errors go away, post your > > /etc/modprobe.conf, and I'll check the drivers to see which (if any) > > of the params went away. > > kudzu has a script to rename kernel modules in modprobe.conf if they > change name that the kernel spec calls... maybe we should teach that > script to remove trailing whitespace as well ;) In this case I think the kernel really is being far too anal about its checking. We could (and probably should) fix up kudzu to do as you suggest, but if someone hand edits their modprobe.conf, it's very easy for something like this to creep back in[*], and cause much headscratching to both user, and me when "my sounds stopped working" turns up in bugzilla again. Dave [*] Judging by the amount of trailing whitespace I see in the kernel sources, there must be at least one commonly used editor out there which performs such braindamage just by moving the cursor to the end of the line. From monpetitbeurre at gmail.com Mon Aug 8 21:04:25 2005 From: monpetitbeurre at gmail.com (Nic) Date: Mon, 8 Aug 2005 16:04:25 -0500 Subject: Stateless linux and an idea of mine for SMALL networks without servers Message-ID: Disclaimer: I hope that this is the right mailing list, but I really wanted to reach developers would can say if it's feasible and what to use for that. Anyway, I was fighting the usual problems with networks and came up with the following dream to make my life easier as a network admin. Basically I am tired of fixing things, of worrying if a hard disk will die, of having to deal with data access, backup etc... I was thinking this through by looking at how most of my coworkers, friends, and small offices use their PCs in day-to-day operations and applying that work flow to a solution. Before, somebody screams, this means little or moderate daily data generation so that, basically, a laptop drive could hold the entire company's data. (This may require email-purge rules and other things like that). Anyway here it is: Basically, I suggest that (almost) all PCs in the network be laptops with the exact same image. Furthermore, they replicate their HD continuously (with possibly some delay). This certainly applies to the user data and application. It may not be necessary for the OS I am not sure of the technology to use here, but I thought something deriving from the P-to-P technology, some distributed file system, some database replication technology or even freenet could be a good base. Since every laptop will contain ALL the data for the whole network, every laptop uses hardware encryption at the hard disk level using an external dongle/card/whatever to limit the risk when a laptop is lost or stolen. Additionally, every login ALSO uses a dongle/card for access to their account. This makes it (almost) impossible for somebody stealing a laptop to get access to the whole data. Additionally, it makes it (alomst) impossible for somebody to fet to other people's data. If a system dies, you just get a new one and sync it up. However, one main idea is that you always have EVERYTHING you need right where you are, no matter WHERE you are. Also, there is no UPS to worry about. Communication between PCs could be implemented using VPN/IPSec or whatever other protected mechanism. Internet access would have to be "sandboxed", but UNIX based OSes allow for that easily. That's the gist of it. A lot of things can be configured in many ways, but the whole point here is to simplify people's life. Look at it from a disaster recovery: a lot of people bring their laptop home. Even if the company's building burns down as well as a few employees homes, one surviving laptop is enough to bring the business back online. Pros: * seamless company disaster recovery * seamless personal computer loss recovery (you lose everything since the last sync) * you can use ANY laptop and find YOUR own environment and files * no central server/single point of failure * no UPS except for the internet firewall (this comes from the PCs being laptops) Cons: * sync across a lot of PCs might be tricky and needs to be tuned. Maybe randonly select one as master like the SMB Master browser election works? * each laptop needs to have enough space for the whole company's data * maybe not appropriate for disk intensive applications (video capture...) I wanted to post it here for other people to use if they think it's a good idea. (and also to preempt any proprietary company from saying "me first") It seems that Windows Vista is coming with some automatic synchronization across two PCs so, that's one step towards it, but we have different goals. I posted this somewhere and somebody pointed me toward stateless linux and it seems pretty cool and close to what I was thinking of. I'll look smoe more into it, but does anybody see this as useful for VERY SMALL networks? (I already got bashed by enterprise admins sneernig at people who don't want a rack server, so if that's your intent, just reply "me too"). Feel free to comment (I know people will). Nick From arjanv at redhat.com Mon Aug 8 18:45:18 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 8 Aug 2005 20:45:18 +0200 Subject: rawhide report: 20050807 changes In-Reply-To: <20050808183815.GC26182@redhat.com> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> <20050808043841.GC5844@redhat.com> <1123488549.3245.25.camel@laptopd505.fenrus.org> <20050808183815.GC26182@redhat.com> Message-ID: <20050808184518.GA5139@devserv.devel.redhat.com> On Mon, Aug 08, 2005 at 02:38:15PM -0400, Dave Jones wrote: > On Mon, Aug 08, 2005 at 10:09:09AM +0200, Arjan van de Ven wrote: > > On Mon, 2005-08-08 at 00:38 -0400, Dave Jones wrote: > > > > > > The fact that it reports the unknown param as `' is disconcerting. > > > ISTR that this change fell over if it met a modprobe.conf with > > > spaces at the end of a line. Can you check that yours hasn't > > > got any ? If that doesn't make the errors go away, post your > > > /etc/modprobe.conf, and I'll check the drivers to see which (if any) > > > of the params went away. > > > > kudzu has a script to rename kernel modules in modprobe.conf if they > > change name that the kernel spec calls... maybe we should teach that > > script to remove trailing whitespace as well ;) > > In this case I think the kernel really is being far too anal about > its checking. No argument there. "Be liberal in what you accept", esp if it's whitespace > We could (and probably should) fix up kudzu to do as > you suggest, but if someone hand edits their modprobe.conf, but sanatizing the modprobe.conf is probably a good idea as well; things will keep comming back otherwise (also if Rusty listened to his hamster too much and decides to not agree with you this is the only solution) From rodd at clarkson.id.au Tue Aug 9 12:18:04 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 09 Aug 2005 22:18:04 +1000 Subject: Package names and capitalization. Why? In-Reply-To: <1123555277.16771.97.camel@dragon.sys.intra> References: <1123555277.16771.97.camel@dragon.sys.intra> Message-ID: <1123589884.2968.27.camel@localhost.localdomain> On Tue, 2005-08-09 at 11:41 +0900, Naoki wrote: > Hi y'all, > > Is there any (good) reason for having uppercase characters in RPM file > names? If not, how about a policy against it? > > As a pretty basic example why it wouldn't seem to be a "good thing" we > have packages called Gconf* and *gconf* which just makes it that little > bit more annoying to deal with. This was discussed about 3 months ago, so check the archives. As a run down on the discussion. Fedora follows (where possible) the name given by the up-stream developer. It's not the business of Fedora to deal with changes to someone elses name for something. Most people would prefer that capitals weren't used for names. Have a look at the archives. R. -- "It's a fine line between denial and faith. It's much better on my side" From jos at xos.nl Tue Aug 9 13:45:08 2005 From: jos at xos.nl (Jos Vos) Date: Tue, 9 Aug 2005 15:45:08 +0200 Subject: Package names and capitalization. Why? In-Reply-To: <1123555277.16771.97.camel@dragon.sys.intra>; from naoki@valuecommerce.com on Tue, Aug 09, 2005 at 11:41:17AM +0900 References: <1123555277.16771.97.camel@dragon.sys.intra> Message-ID: <20050809154508.B11040@xos037.xos.nl> On Tue, Aug 09, 2005 at 11:41:17AM +0900, Naoki wrote: > Is there any (good) reason for having uppercase characters in RPM file > names? If not, how about a policy against it? I think the uppercase chars are usually taken over if the package name is explicitly written that way in all appearances, so when the tar-file is calles FooBar-1.0.tar.gz, the name always appears capitalized that way in documentation/web pages, etc. I'm pretty sure this "rule of thumb" does not apply to one or more of the capatilized packages you gave, but this is what I remember from earlier discussions. Maybe this is somewhere written done, maybe it's not. > Xaw3d is great and all but does it deserve a capital letter over > xorg-x11 ? Well, XFree86 had two capitals ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From davej at redhat.com Tue Aug 9 16:23:44 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 9 Aug 2005 12:23:44 -0400 Subject: rawhide report: 20050807 changes In-Reply-To: <42F7A85F.6090004@redhat.com> References: <200508071124.j77BOg2k017410@porkchop.devel.redhat.com> <1123461710.3522.3.camel@localhost.localdomain> <20050808031112.GB5844@redhat.com> <1123471156.2970.1.camel@localhost.localdomain> <20050808043841.GC5844@redhat.com> <1123488549.3245.25.camel@laptopd505.fenrus.org> <42F7A85F.6090004@redhat.com> Message-ID: <20050809162344.GJ5844@redhat.com> On Mon, Aug 08, 2005 at 02:45:51PM -0400, Jeremy Katz wrote: > Arjan van de Ven wrote: > >On Mon, 2005-08-08 at 00:38 -0400, Dave Jones wrote: > >>The fact that it reports the unknown param as `' is disconcerting. > >>ISTR that this change fell over if it met a modprobe.conf with > >>spaces at the end of a line. Can you check that yours hasn't > >>got any ? If that doesn't make the errors go away, post your > >>/etc/modprobe.conf, and I'll check the drivers to see which (if any) > >>of the params went away. > > > >kudzu has a script to rename kernel modules in modprobe.conf if they > >change name that the kernel spec calls... maybe we should teach that > >script to remove trailing whitespace as well ;) > > This only runs when you install a new kernel, so it's probably not the > right answer :-) > > On the other hand, having module-init-tools do some cleanup if that's > what the kernel expects might make sense. Rusty fixed this up yesterday, (in a better way than my 'drop the patch that broke it' approach). The next kernels that go out will ignore the whitespace, and continue to warn about obsolete parameters. Dave From jlayton at redhat.com Tue Aug 9 18:38:05 2005 From: jlayton at redhat.com (Jeff Layton) Date: Tue, 09 Aug 2005 14:38:05 -0400 Subject: ioctl's and USB drives In-Reply-To: <1123535941.6039.5.camel@athlon.localdomain> References: <1123411879.6037.42.camel@athlon.localdomain> <42F70906.70805@feuerpokemon.de> <1123535941.6039.5.camel@athlon.localdomain> Message-ID: <1123612685.4989.16.camel@barsoom.rdu.redhat.com> On Mon, 2005-08-08 at 23:19 +0200, Leonard den Ottolander wrote: > > So I assume it's the SCSI layer that is dropping these commands. Is > there a way to work around this by patching hdparm or do I have to hack > the kernel SCSI (emulation) layer to be able to send these commands? > > Leonard. This may or may not work, depending on your hardware. You have a controller that does USB storage -> IDE translation. There's no guarantee that this translator will pass the appropriate ioctl() stuff to the actual IDE controller/drive. Then again, it might... :-) -- Jeff Layton From kyrre at solution-forge.net Tue Aug 9 19:27:12 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 09 Aug 2005 21:27:12 +0200 Subject: NetworkManager and nm-aplet placement Message-ID: <1123615631.4248.6.camel@localhost.localdomain> Why is nm-applet placed in /usr/libexec? It took me quite a while to find it and run it, as it isn't in $PATH... Kyrre From johnp at redhat.com Tue Aug 9 19:57:21 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 09 Aug 2005 15:57:21 -0400 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123615631.4248.6.camel@localhost.localdomain> References: <1123615631.4248.6.camel@localhost.localdomain> Message-ID: <1123617441.16965.60.camel@remedyz.boston.redhat.com> On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > Why is nm-applet placed in /usr/libexec? It took me quite a while to > find it and run it, as it isn't in $PATH... > > Kyrre Because NetworkManagerInfo is supposed to spawn it. -- John (J5) Palmieri From dcbw at redhat.com Tue Aug 9 19:57:36 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 09 Aug 2005 15:57:36 -0400 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123615631.4248.6.camel@localhost.localdomain> References: <1123615631.4248.6.camel@localhost.localdomain> Message-ID: <1123617456.11868.15.camel@dcbw.boston.redhat.com> On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > Why is nm-applet placed in /usr/libexec? It took me quite a while to > find it and run it, as it isn't in $PATH... Originally it was actually an applet, like /usr/libexec/battstat-applet-2, that should only get run by gnome-session, not directly. Which is still pretty much the case, its not meant to be hand-run after its been added to your session. It's debatable whether or not it should continue to live in /usr/libexec now though, since its not a panel applet any more, but a notification icon. Dan From kyrre at solution-forge.net Tue Aug 9 20:51:37 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 09 Aug 2005 22:51:37 +0200 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123617441.16965.60.camel@remedyz.boston.redhat.com> References: <1123615631.4248.6.camel@localhost.localdomain> <1123617441.16965.60.camel@remedyz.boston.redhat.com> Message-ID: <1123620697.4248.15.camel@localhost.localdomain> tir, 09.08.2005 kl. 21.57 skrev John (J5) Palmieri: > On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > > Why is nm-applet placed in /usr/libexec? It took me quite a while to > > find it and run it, as it isn't in $PATH... > > > > Kyrre > > Because NetworkManagerInfo is supposed to spawn it. > > -- > John (J5) Palmieri I don't have NetworkManagerInfo on my system (anymore). ... From dcbw at redhat.com Tue Aug 9 20:56:09 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 09 Aug 2005 16:56:09 -0400 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123620697.4248.15.camel@localhost.localdomain> References: <1123615631.4248.6.camel@localhost.localdomain> <1123617441.16965.60.camel@remedyz.boston.redhat.com> <1123620697.4248.15.camel@localhost.localdomain> Message-ID: <1123620969.11868.20.camel@dcbw.boston.redhat.com> On Tue, 2005-08-09 at 22:51 +0200, Kyrre Ness Sjobak wrote: > tir, 09.08.2005 kl. 21.57 skrev John (J5) Palmieri: > > On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > > > Why is nm-applet placed in /usr/libexec? It took me quite a while to > > > find it and run it, as it isn't in $PATH... > > > > > > Kyrre > > > > Because NetworkManagerInfo is supposed to spawn it. > > > > -- > > John (J5) Palmieri > > I don't have NetworkManagerInfo on my system (anymore). ... Yeah, nm-applet is the new NetworkManagerInfo actually (with 0.4x that is). Dan From leonard at den.ottolander.nl Tue Aug 9 20:59:15 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 09 Aug 2005 22:59:15 +0200 Subject: ioctl's and USB drives (and just plain ATA) In-Reply-To: <1123612685.4989.16.camel@barsoom.rdu.redhat.com> References: <1123411879.6037.42.camel@athlon.localdomain> <42F70906.70805@feuerpokemon.de> <1123535941.6039.5.camel@athlon.localdomain> <1123612685.4989.16.camel@barsoom.rdu.redhat.com> Message-ID: <1123621154.6036.50.camel@athlon.localdomain> Hi Jeff, On Tue, 2005-08-09 at 20:38, Jeff Layton wrote: > This may or may not work, depending on your hardware. You have a > controller that does USB storage -> IDE translation. There's no > guarantee that this translator will pass the appropriate ioctl() stuff > to the actual IDE controller/drive. > > Then again, it might... :-) Back to square one :-s . Anyway, if the SCSI emulation layer is dropping these commands it doesn't really matter if the USB device gets the translation right. Is there a way to work around the SCSI emulation layer so these commands at least get passed to the device? Related question: If I want to use TASKFILE ioctls with a 2.4 kernel do I need to configure the kernel with CONFIG_IDE_TASK_IOCTL or CONFIG_IDE_TASKFILE_IO? I saw some comment that suggest the latter, but I somehow get the impression that is about a different IDE interface and not about just sending raw TASKFILE ioctls which I need to implement/improve the ATA security features in hdparm. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From markmc at redhat.com Tue Aug 9 21:55:03 2005 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 09 Aug 2005 22:55:03 +0100 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123617456.11868.15.camel@dcbw.boston.redhat.com> References: <1123615631.4248.6.camel@localhost.localdomain> <1123617456.11868.15.camel@dcbw.boston.redhat.com> Message-ID: <1123624504.3419.143.camel@blaa> On Tue, 2005-08-09 at 15:57 -0400, Dan Williams wrote: > On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > > Why is nm-applet placed in /usr/libexec? It took me quite a while to > > find it and run it, as it isn't in $PATH... > > Originally it was actually an applet, > like /usr/libexec/battstat-applet-2, that should only get run by > gnome-session, not directly. bonobo-activation-server is what runs panel applets, at gnome-panel's behest. > Which is still pretty much the case, its > not meant to be hand-run after its been added to your session. It's > debatable whether or not it should continue to live in /usr/libexec now > though, since its not a panel applet any more, but a notification icon. In order to get it in the session in the first place, you need to run it (either from the menus with a .desktop file or from the command line) so it should prolly be in /usr/bin. Cheers, Mark. From kyrre at solution-forge.net Wed Aug 10 16:20:18 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 10 Aug 2005 18:20:18 +0200 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123620969.11868.20.camel@dcbw.boston.redhat.com> References: <1123615631.4248.6.camel@localhost.localdomain> <1123617441.16965.60.camel@remedyz.boston.redhat.com> <1123620697.4248.15.camel@localhost.localdomain> <1123620969.11868.20.camel@dcbw.boston.redhat.com> Message-ID: <1123690818.3364.11.camel@localhost.localdomain> tir, 09.08.2005 kl. 22.56 skrev Dan Williams: > On Tue, 2005-08-09 at 22:51 +0200, Kyrre Ness Sjobak wrote: > > tir, 09.08.2005 kl. 21.57 skrev John (J5) Palmieri: > > > On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > > > > Why is nm-applet placed in /usr/libexec? It took me quite a while to > > > > find it and run it, as it isn't in $PATH... > > > > > > > > Kyrre > > > > > > Because NetworkManagerInfo is supposed to spawn it. > > > > > > -- > > > John (J5) Palmieri > > > > I don't have NetworkManagerInfo on my system (anymore). ... > > Yeah, nm-applet is the new NetworkManagerInfo actually (with 0.4x that > is). > > Dan And it works really, really great. Some small polishing/added features, but it looks *really* nice and is beyond usefull allready. From buildsys at redhat.com Wed Aug 10 16:26:51 2005 From: buildsys at redhat.com (Build System) Date: Wed, 10 Aug 2005 12:26:51 -0400 Subject: rawhide report: 20050810 changes Message-ID: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> Updated Packages: control-center-1:2.11.90-2 -------------------------- * Tue Aug 09 2005 David Malcolm - 1:2.11.90-2 - rebuild (against new evolution-data-server-devel) dhcp-11:3.0.3-2 --------------- * Tue Aug 09 2005 Jeremy Katz - 11:3.0.3-2 - don't explicitly require 2.2 era kernel, it's fairly overkill at this point epiphany-1.7.4-1 ---------------- * Tue Aug 09 2005 Christopher Aillon - 1.7.4-1 - Update to 1.7.4 evolution-2.3.7-1 ----------------- * Tue Aug 09 2005 David Malcolm - 2.3.7-1 - 2.3.7 - Bump evolution-data-server requirement from 1.3.6 to 1.3.7 - Bump gtkhtml3 requirement from 3.6.2 to 3.7.6 * Mon Aug 08 2005 Tomas Mraz - 2.3.6.1-5 - rebuild with new gnutls * Tue Aug 02 2005 David Malcolm - 2.3.6.1-4 - Added patch to show correct mimetype for OpenOffice.org files when guessing type for attachments with mimetype "application/octet-stream" (#164957) evolution-connector-2.3.7-1 --------------------------- * Tue Aug 09 2005 David Malcolm - 2.3.7-1 - 2.3.7 - Bump evolution requirement from 2.3.5.1 to 2.3.7 - Bump libsoup requirement from 2.2.2 to 2.2.5 - Remove ximian-connector-2.0.4-fix-sync-callback.patch; a slightly modified version of this is now in the upstream tarball (#139393) evolution-data-server-1.3.7-1 ----------------------------- * Tue Aug 09 2005 David Malcolm - 1.3.7-1 - 1.3.7 evolution-webcal-2.3.91-1 ------------------------- * Tue Aug 09 2005 David Malcolm - 2.3.91-1 - 2.3.91 file-4.14-4 ----------- * Tue Aug 09 2005 Radek Vokal - 4.14-4 - mime for mpeg and aac files fixed (#165323) gaim-1:1.4.0-7.fc5 ------------------ * Tue Aug 09 2005 Jeremy Katz - 1:1.4.0-7 - rebuild for new evolution-data-server gamin-0.1.5-1 ------------- * Tue Aug 09 2005 Daniel Veillard 0.1.5-1 - Improvement of configuration, system wide configuration files and per filesystem type default - Rewrite of the inotify back-end, reduce resources usage, tuning in case of busy resources - Documentation updates - Changes to compile inotify back-end on various architectures - Debugging output improvements ghostscript-8.15-0.rc3.7 ------------------------ * Tue Aug 09 2005 Tim Waugh 8.15-0.rc3.7 - Install adobe/acro5 CMaps (bug #165428). gnome-session-2.11.91-1 ----------------------- * Tue Aug 09 2005 Ray Strode - 2.11.91-1 - Update to upstream version 2.11.91 (fixes bug 165357). - drop some patches gnome-utils-1:2.11.91-1 ----------------------- * Tue Aug 09 2005 Ray Strode 1:2.11.91-1 - Update to gnome-utils 2.11.91, gcalctool 5.6.26, zenity 2.11.90 gnomemeeting-1.2.1-4 -------------------- * Tue Aug 09 2005 David Malcolm - 1.2.1-4 - rebuild gnupg-1.4.2-3 ------------- * Tue Aug 09 2005 Nalin Dahyabhai 1.4.2-3 - don't override libexecdir any more; we don't need to (#165462) gtkhtml3-3.7.6-1 ---------------- * Tue Aug 09 2005 David Malcolm - 3.7.6-1 - 3.7.6 gtksourceview-1.3.91-1 ---------------------- * Mon Aug 08 2005 Ray Strode - 1.3.91-1 - Update to upstream version 1.3.91 * Wed Aug 03 2005 Ray Strode - 1.2.1-1 - Update to upstream version 1.2.1 hal-0.5.3-3 ----------- * Tue Aug 09 2005 Jeremy Katz - 0.5.3-3 - make kernel version requirement a conflicts instead hwdata-0.164-1 -------------- * Tue Aug 09 2005 Jeremy Katz - 0.164-1 - migrate sk98lin -> skge * Sat Jul 30 2005 Bill Nottingham - migrate mpt module names (#161420) - remove pcitable entries for drivers in modules.pcimap - switch lone remaining 'Server' entry - that can't work right * Tue Jul 26 2005 Bill Nottingham - add Daytek monitor (#164339) kdeaddons-3.4.2-1 ----------------- * Tue Aug 09 2005 Than Ngo 3.4.2-1 - update to 3.4.2 kdeartwork-3.4.2-1 ------------------ * Tue Aug 09 2005 Than Ngo 3.4.2-1 - update to 3.4.2 kdebindings-3.4.2-1 ------------------- * Tue Aug 09 2005 Than Ngo 3.4.2-1 - update to 3.4.2 kernel-2.6.12-1.1469_FC5 ------------------------ libgnome-2.11.2-1 ----------------- * Tue Aug 09 2005 Ray Strode - 2.11.2-1 - Newer upstream version * Mon Jul 11 2005 Matthias Clasen - 2.11.1-1 - Newer upstream version * Wed Apr 13 2005 John (J5) Palmieri - 2.10.0-3 - Change the default icon theme back to Clearlooks as the Clearlooks icon theme will now inherit from Bluecurve libgnomeui-2.11.2-1 ------------------- * Tue Aug 09 2005 Ray Strode - 2.11.2-1 - Newer upstream version libsoup-2.2.5-1 --------------- * Tue Aug 09 2005 David Malcolm - 2.2.5-1 - 2.2.5 - Removed gnome-bug-306877-soup-connection-ntlm.c.patch (#160071) as this is now in upstream tarball libwnck-2.11.91-1 ----------------- * Tue Aug 09 2005 Ray Strode 2.11.91-1 - New upstream version metacity-2.11.2-1 ----------------- * Tue Aug 09 2005 Ray Strode 2.11.2-1 - Update to 2.11.2 (fixes bug 163745) pkgconfig-1:0.18.1-4 -------------------- * Tue Aug 09 2005 Matthias Clasen 1:0.18.1-4 - Fix a segfault which curiously hits only bigendian platforms redhat-artwork-0.126-1 ---------------------- * Tue Aug 09 2005 John (J5) Palmieri 0.126-1 - upgrade to 0.126 which adds diana's new dnd cursors and fixes the jittering animated cursor bug rhnlib-1.8-6.p24.11 ------------------- * Tue Aug 09 2005 Mihai Ibanescu 1.8-6.p23.11 - Fixed #165481 (setting socket timeouts causes uncaught SSL exceptions) - Fixed #165087 (added .pyo files to package) system-config-bind-4.0.0-28_FC5 ------------------------------- * Tue Aug 09 2005 Jason Vas Dias - 4.0.0-28 - fix bug 165445: relax restriction on no address records for origin system-config-printer-0.6.140-1 ------------------------------- * Tue Aug 09 2005 Tim Waugh 0.6.140-1 - 0.6.140: - Fixed parser bug properly (bug #165328). tcpdump-14:3.9.3-3 ------------------ * Tue Aug 09 2005 Jeremy Katz - 14:3.9.3-3 - remove explicit kernel dep for libpcap too vim-1:6.3.086-1 --------------- * Tue Aug 09 2005 Karsten Hopp 6.3.086-1 - update to patchlevel 86 vsftpd-2.0.3-8 -------------- * Tue Aug 09 2005 Radek Vokal 2.0.3-8 - removed additional cmd line for ftp (#165083) xpdf-1:3.00-23 -------------- * Tue Aug 09 2005 Than Ngo 3.00-23 - apply patch to fix xpdf DoS, CAN-2005-2097 #163918 * Mon Jul 25 2005 Than Ngo 3.00-22 - fix allocation size 64bit architectures yaboot-1.3.13-0.5 ----------------- * Tue Aug 09 2005 David Woodhouse - 1.3.13-0.5 - Fix Pegasos partition hack * Tue Aug 09 2005 David Woodhouse - 1.3.13-0.4 - Make default boot after timeout work again - Pegasos disagrees about partition numbering Broken deps for i386 ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 usermode-gtk - 1.80-2.i386 requires libwnck-1.so.17 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnome-system-monitor - 2.11.90-1.i386 requires libwnck-1.so.17 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-panel - 2.11.90-1.i386 requires libwnck-1.so.17 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gok - 1.0.5-2.i386 requires libwnck-1.so.17 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-applets - 1:2.11.2-1.i386 requires libwnck-1.so.17 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dasher - 3.2.15-2.i386 requires libwnck-1.so.17 Broken deps for s390 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 usermode-gtk - 1.80-2.s390 requires libwnck-1.so.17 selinux-policy-strict-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 selinux-policy-targeted-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 dasher - 3.2.15-2.s390 requires libwnck-1.so.17 nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 gnome-system-monitor - 2.11.90-1.s390 requires libwnck-1.so.17 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 gnome-applets - 1:2.11.2-1.s390 requires libwnck-1.so.17 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 gnome-panel - 2.11.90-1.s390 requires libwnck-1.so.17 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 gok - 1.0.5-2.s390 requires libwnck-1.so.17 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-strict - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 usermode-gtk - 1.80-2.ppc requires libwnck-1.so.17 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 dasher - 3.2.15-2.ppc requires libwnck-1.so.17 gnome-panel - 2.11.90-1.ppc requires libwnck-1.so.17 gnome-system-monitor - 2.11.90-1.ppc requires libwnck-1.so.17 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-applets - 1:2.11.2-1.ppc requires libwnck-1.so.17 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gok - 1.0.5-2.ppc requires libwnck-1.so.17 Broken deps for ppc64 ---------------------------------------------------------- evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config control-center - 1:2.10.1-6.ppc64 requires libgnome-menu.so.0()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-panel - 2.11.90-1.ppc64 requires libwnck-1.so.17()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config firstboot - 1.3.44-1.noarch requires system-config-display cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 usermode-gtk - 1.80-2.ppc64 requires libwnck-1.so.17()(64bit) gnome-applets - 1:2.11.2-1.ppc64 requires libwnck-1.so.17()(64bit) gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) gok - 1.0.5-2.ppc64 requires libwnck-1.so.17()(64bit) dasher - 3.2.15-2.ppc64 requires libwnck-1.so.17()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot gnome-system-monitor - 2.11.90-1.ppc64 requires libwnck-1.so.17()(64bit) Broken deps for ia64 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs gok - 1.0.5-2.ia64 requires libwnck-1.so.17()(64bit) usermode-gtk - 1.80-2.ia64 requires libwnck-1.so.17()(64bit) gnome-panel - 2.11.90-1.ia64 requires libwnck-1.so.17()(64bit) gnome-applets - 1:2.11.2-1.ia64 requires libwnck-1.so.17()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) dasher - 3.2.15-2.ia64 requires libwnck-1.so.17()(64bit) gnome-system-monitor - 2.11.90-1.ia64 requires libwnck-1.so.17()(64bit) Broken deps for x86_64 ---------------------------------------------------------- gok - 1.0.5-2.x86_64 requires libwnck-1.so.17()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 usermode-gtk - 1.80-2.x86_64 requires libwnck-1.so.17()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-system-monitor - 2.11.90-1.x86_64 requires libwnck-1.so.17()(64bit) gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-applets - 1:2.11.2-1.x86_64 requires libwnck-1.so.17()(64bit) gnome-panel - 2.11.90-1.x86_64 requires libwnck-1.so.17()(64bit) GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dasher - 3.2.15-2.x86_64 requires libwnck-1.so.17()(64bit) gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) Broken deps for s390x ---------------------------------------------------------- sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 dasher - 3.2.15-2.s390x requires libwnck-1.so.17()(64bit) prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 gnome-panel - 2.11.90-1.s390x requires libwnck-1.so.17()(64bit) gok - 1.0.5-2.s390x requires libwnck-1.so.17()(64bit) gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) selinux-policy-targeted-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 usermode-gtk - 1.80-2.s390x requires libwnck-1.so.17()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) selinux-policy-strict - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 gnome-system-monitor - 2.11.90-1.s390x requires libwnck-1.so.17()(64bit) gnome-applets - 1:2.11.2-1.s390x requires libwnck-1.so.17()(64bit) selinux-policy-targeted - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) From leonard at den.ottolander.nl Wed Aug 10 21:10:14 2005 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 10 Aug 2005 23:10:14 +0200 Subject: IDE_DRIVE_TASK_OUT dropped in 2.6.12? Message-ID: <1123708213.6001.37.camel@athlon.localdomain> Hi, Is there a kernel hacker (or anybody with insight in the matter) that could tell me why the IDE_DRIVE_TASK_OUT ioctl has been dropped? What should I use instead to issue PIO data ATA security commands? See http://www.linuxhq.com/kernel/v2.6/12/Documentation/ioctl/hdio.txt - IDE_DRIVE_TASK_OUT + IDE_DRIVE_TASK_OUT unimplemented Leonard. -- mount -t life -o ro /dev/dna /genetic/research From rodd at clarkson.id.au Wed Aug 10 21:15:23 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 11 Aug 2005 07:15:23 +1000 Subject: rawhide report: 20050810 changes In-Reply-To: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> Message-ID: <1123708523.2968.3.camel@localhost.localdomain> Just in passing, on i386 most people will probably be able to install with: yum --exclude=libwnck\* update On Wed, 2005-08-10 at 12:26 -0400, Build System wrote: > gamin-0.1.5-1 > ------------- > * Tue Aug 09 2005 Daniel Veillard 0.1.5-1 > - Improvement of configuration, system wide configuration files and > per filesystem type default > - Rewrite of the inotify back-end, reduce resources usage, tuning in > case of busy resources > - Documentation updates > - Changes to compile inotify back-end on various architectures > - Debugging output improvements Does this mean that inotify is now in the kernel? And if so, why is inotify so important? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From fedora at camperquake.de Wed Aug 10 21:17:42 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 10 Aug 2005 23:17:42 +0200 Subject: rawhide report: 20050810 changes In-Reply-To: <1123708523.2968.3.camel@localhost.localdomain> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> Message-ID: <20050810211742.GA24049@ryoko.camperquake.de> On Thu, Aug 11, 2005 at 07:15:23AM +1000, Rodd Clarkson wrote: > Does this mean that inotify is now in the kernel? And if so, why is > inotify so important? As far as I have figured, because dnotify sucks for directories. From rodd at clarkson.id.au Wed Aug 10 21:19:43 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 11 Aug 2005 07:19:43 +1000 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123690818.3364.11.camel@localhost.localdomain> References: <1123615631.4248.6.camel@localhost.localdomain> <1123617441.16965.60.camel@remedyz.boston.redhat.com> <1123620697.4248.15.camel@localhost.localdomain> <1123620969.11868.20.camel@dcbw.boston.redhat.com> <1123690818.3364.11.camel@localhost.localdomain> Message-ID: <1123708784.2968.8.camel@localhost.localdomain> On Wed, 2005-08-10 at 18:20 +0200, Kyrre Ness Sjobak wrote: > tir, 09.08.2005 kl. 22.56 skrev Dan Williams: > > On Tue, 2005-08-09 at 22:51 +0200, Kyrre Ness Sjobak wrote: > > > tir, 09.08.2005 kl. 21.57 skrev John (J5) Palmieri: > > > > On Tue, 2005-08-09 at 21:27 +0200, Kyrre Ness Sjobak wrote: > > > > > Why is nm-applet placed in /usr/libexec? It took me quite a while to > > > > > find it and run it, as it isn't in $PATH... > > > > > > > > > > Kyrre > > > > > > > > Because NetworkManagerInfo is supposed to spawn it. > > > > > > > > -- > > > > John (J5) Palmieri > > > > > > I don't have NetworkManagerInfo on my system (anymore). ... > > > > Yeah, nm-applet is the new NetworkManagerInfo actually (with 0.4x that > > is). > > > > Dan > > And it works really, really great. Some small polishing/added features, > but it looks *really* nice and is beyond usefull allready. Although it might be nice if it was mentioned in the documentation somewhere and it took a little looking to find for me to (after NetworkManagerInfo disappeared) I've really happy with how NetworkManager is working, and how well it works. My only complaint is that it prompts me for my keychain password when connecting to wireless routers that don't need a password, so I have to type my password in regardless (and each time it starts now because I did connect to a wireless router with WEP and used the keychain to store it). See bug: http://bugzilla.gnome.org/show_bug.cgi?id=312128 Well done Dan. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From arghil at tlen.pl Wed Aug 10 21:29:20 2005 From: arghil at tlen.pl (=?utf-8?q?Jaros=C5=82aw_Jan_Pyszny?=) Date: Wed, 10 Aug 2005 23:29:20 +0200 Subject: ViM from update for FC3 - GTK2 version Message-ID: <200508102329.33062.arghil@tlen.pl> Hi, VIM 6.3.086-0.fc3 (X11) requires GTK2 >=2.6 but in FC3 is GTK2 2.4.x? Best regards Jarek -- 8 \\|||// Jarosaw Jan Pyszny b (o|o) Linux admin/program devel ("Vitae,non scholae,discimus") i --\_/-- Linux user: #96704 (http://counter.li.org) t =->komputer(y) - daj zna? je?eli chcesz si? pozby?<-= -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: From david at fubar.dk Wed Aug 10 21:43:06 2005 From: david at fubar.dk (David Zeuthen) Date: Wed, 10 Aug 2005 17:43:06 -0400 Subject: NetworkManager and nm-aplet placement In-Reply-To: <1123708784.2968.8.camel@localhost.localdomain> References: <1123615631.4248.6.camel@localhost.localdomain> <1123617441.16965.60.camel@remedyz.boston.redhat.com> <1123620697.4248.15.camel@localhost.localdomain> <1123620969.11868.20.camel@dcbw.boston.redhat.com> <1123690818.3364.11.camel@localhost.localdomain> <1123708784.2968.8.camel@localhost.localdomain> Message-ID: <1123710186.2830.13.camel@daxter.boston.redhat.com> On Thu, 2005-08-11 at 07:19 +1000, Rodd Clarkson wrote: > I've really happy with how NetworkManager is working, and how well it > works. My only complaint is that it prompts me for my keychain password > when connecting to wireless routers that don't need a password, so I > have to type my password in regardless (and each time it starts now > because I did connect to a wireless router with WEP and used the > keychain to store it). See bug: > http://bugzilla.gnome.org/show_bug.cgi?id=312128 It's always a good idea to file bugs upstream, however this one is best dealt with in Fedora since it's so dependent on the OS. The bug in Fedora is this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125682 This really ought to be fixed for FC5. Cheers, David From karsten at redhat.com Wed Aug 10 21:56:34 2005 From: karsten at redhat.com (Karsten Hopp) Date: Wed, 10 Aug 2005 23:56:34 +0200 Subject: ViM from update for FC3 - GTK2 version In-Reply-To: <200508102329.33062.arghil@tlen.pl> References: <200508102329.33062.arghil@tlen.pl> Message-ID: <20050810215634.GA16260@redhat.com> On Wed, Aug 10, 2005 at 11:29:20PM +0200, Jaros?aw Jan Pyszny wrote: > Hi, > VIM 6.3.086-0.fc3 (X11) requires GTK2 >=2.6 > but in FC3 is GTK2 2.4.x? > > Best regards > Jarek Crap... That's why I try to avoid those explicit Requires, they tend to come back with a vengeance... Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From veillard at redhat.com Wed Aug 10 22:19:00 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 10 Aug 2005 18:19:00 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: <1123708523.2968.3.camel@localhost.localdomain> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> Message-ID: <20050810221900.GF21787@redhat.com> On Thu, Aug 11, 2005 at 07:15:23AM +1000, Rodd Clarkson wrote: > > gamin-0.1.5-1 > > ------------- > > * Tue Aug 09 2005 Daniel Veillard 0.1.5-1 > > - Improvement of configuration, system wide configuration files and > > per filesystem type default > > - Rewrite of the inotify back-end, reduce resources usage, tuning in > > case of busy resources > > - Documentation updates > > - Changes to compile inotify back-end on various architectures > > - Debugging output improvements > > Does this mean that inotify is now in the kernel? I don't think so, davej is the ultimate person to answer when this will hit us, but I expect it will be in Fedora Core 5, so ... > And if so, why is inotify so important? Because dnotify has an awful lot of shortcoming. inotify support is compiled in but it will fallback to dnotify if inotify not supported by teh kernel. This release also provide system wide configuration files and the ability to configure the behaviour on a per system type case instead of specific paths, i.e. it allows more generic rules. I will add default system configuration files in further versions of the package, at the moment best is to follow the documentation if you need special tuning: http://www.gnome.org/~veillard/gamin/config.html Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Wed Aug 10 22:28:36 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 10 Aug 2005 18:28:36 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: <20050810211742.GA24049@ryoko.camperquake.de> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> <20050810211742.GA24049@ryoko.camperquake.de> Message-ID: <20050810222836.GG21787@redhat.com> On Wed, Aug 10, 2005 at 11:17:42PM +0200, Ralf Ertzinger wrote: > On Thu, Aug 11, 2005 at 07:15:23AM +1000, Rodd Clarkson wrote: > > > Does this mean that inotify is now in the kernel? And if so, why is > > inotify so important? > > As far as I have figured, because dnotify sucks for directories. s/ for directories// dnotify can only watch directories ! Yeah if you want to watch /tmp/mylog you get an event to process each time anything changes in /tmp for example. dnotify_sucks++ the counter is pretty high at that point... that far from being the only issue. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From bbbush.yuan at gmail.com Thu Aug 11 04:50:57 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Thu, 11 Aug 2005 12:50:57 +0800 Subject: rawhide report: 20050809 changes In-Reply-To: <200508091133.j79BXbk7013955@porkchop.devel.redhat.com> References: <200508091133.j79BXbk7013955@porkchop.devel.redhat.com> Message-ID: <76e72f8005081021507c8f0701@mail.gmail.com> 2005/8/9, Build System : > New package scim-pinyin > Smart Pinyin IMEngine for Smart Common Input Method platform > > There is no version info for new packages in the report, why? -- bbbush ^_^ From davej at redhat.com Thu Aug 11 05:13:53 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 11 Aug 2005 01:13:53 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: <20050810221900.GF21787@redhat.com> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> <20050810221900.GF21787@redhat.com> Message-ID: <20050811051353.GB9867@redhat.com> On Wed, Aug 10, 2005 at 06:19:00PM -0400, Daniel Veillard wrote: > On Thu, Aug 11, 2005 at 07:15:23AM +1000, Rodd Clarkson wrote: > > > - Rewrite of the inotify back-end, reduce resources usage, tuning in > > > > Does this mean that inotify is now in the kernel? > > I don't think so, davej is the ultimate person to answer when this will > hit us, but I expect it will be in Fedora Core 5, so ... It will definitly appear in FC5. I'll likely backport 2.6.13 to FC4 a little while after it gets released, and *maybe* to FC3 too. The big problem I'm facing right now with retrofitting old releases with new kernels is that it breaks various random bits of userspace each time, and its a mad scramble to get updates pushed out. By the time we're on top of the situation, upstream is ready to push out a new release. Over time, I want to spend *less* time having to worry about the n-2 release, doing only updates for really critical bugs. Rebasing the n-1 release creates more than enough work as it is. We seem to gain almost as many (if not more) new bugs as we close older bugs by rebasing, so it's not a magic bullet. Cherry picking from ~4000 csets per release to backport to FC3 isn't going to be fun either, so it's likely I'll just backport the latest 2.6.x.y release back to the older kernels. Dave From naoki at valuecommerce.com Thu Aug 11 08:41:15 2005 From: naoki at valuecommerce.com (Naoki) Date: Thu, 11 Aug 2005 17:41:15 +0900 Subject: OCFS2 and GFS. Message-ID: <1123749675.28078.182.camel@dragon.sys.intra> Hi all, Was checking this out : http://lxer.com/module/newswire/view/41239/index.html it's just a little bit of Oracle marketing about how great OCFS2 is and how great Oracle is for releasing it to the community. But I was thinking what the point of OCFS2 is when we have GFS. Mr Morton seems to like it but what are the advantages to GFS which is seemingly been around longer? The are both POSIX which is nice. From veillard at redhat.com Thu Aug 11 09:19:11 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 11 Aug 2005 05:19:11 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: <20050811051353.GB9867@redhat.com> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> <20050810221900.GF21787@redhat.com> <20050811051353.GB9867@redhat.com> Message-ID: <20050811091910.GI21787@redhat.com> On Thu, Aug 11, 2005 at 01:13:53AM -0400, Dave Jones wrote: > On Wed, Aug 10, 2005 at 06:19:00PM -0400, Daniel Veillard wrote: > > On Thu, Aug 11, 2005 at 07:15:23AM +1000, Rodd Clarkson wrote: > > > > - Rewrite of the inotify back-end, reduce resources usage, tuning in > > > > > > Does this mean that inotify is now in the kernel? > > > > I don't think so, davej is the ultimate person to answer when this will > > hit us, but I expect it will be in Fedora Core 5, so ... > > It will definitly appear in FC5. I'll likely backport 2.6.13 to FC4 > a little while after it gets released, and *maybe* to FC3 too. Hum, I didn't expect to push more gamin updates to FC3, for FC3 my main goal was to fix the last perceived desktop bugs related to dnotify/gamin. > Over time, I want to spend *less* time having to worry about the n-2 release, > doing only updates for really critical bugs. Rebasing the n-1 release my perspective too :-) > creates more than enough work as it is. We seem to gain almost as many > (if not more) new bugs as we close older bugs by rebasing, so it's not > a magic bullet. > > Cherry picking from ~4000 csets per release to backport to FC3 isn't > going to be fun either, so it's likely I'll just backport the latest > 2.6.x.y release back to the older kernels. thanks, Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From buildsys at redhat.com Thu Aug 11 12:32:12 2005 From: buildsys at redhat.com (Build System) Date: Thu, 11 Aug 2005 08:32:12 -0400 Subject: rawhide report: 20050811 changes Message-ID: <200508111232.j7BCWCvx009753@porkchop.devel.redhat.com> Updated Packages: checkpolicy-1.25.5-1 -------------------- * Wed Aug 10 2005 Dan Walsh 1.25.5-1 - Update to NSA Release * Fixed call to hierarchy checking code to pass the right policydb. * Merged patch to update dismod for the relocation of the module read/write code from libsemanage to libsepol, and to enable build of test subdirectory from Jason Tang (Tresys). control-center-1:2.11.91-1 -------------------------- * Wed Aug 10 2005 Ray Strode - 1:2.11.91-1 - New upstream version - Patch out buildreq for e-d-s (bug 165493) dasher-3.2.15-3 --------------- * Wed Aug 10 2005 3.2.15-3 - Rebuild diffstat-1.38-4 --------------- * Wed Aug 10 2005 Tim Waugh 1.38-4 - Handle .Z files (bug #165507). gcc-4.0.1-8 ----------- * Wed Aug 10 2005 Jakub Jelinek 4.0.1-8 - update from CVS - PRs middle-end/21894, middle-end/22439, target/23309, c++/20646, c++/22508, libffi/21819, libfortran/22143, libfortran/23154, rtl-optimization/23241 - fix x86 libffi with -fstack-protector - fix hoisting to basic blocks ending with possibly throwing call whose some hard register arg setups have been CSEd out (Dale Johannesen, #163195, PR rtl-optimization/23299) - use DW_OP_fbreg where possible (#165514) - prefer var tracking gathered locations even if they are the same throughout the whole function (#165514) gettext-0.14.5-1 ---------------- * Thu Aug 11 2005 Leon Ho - updated to 0.14.5 - Add cvs as Requires for gettext-devel gnome-panel-2.11.91-2 --------------------- * Wed Aug 10 2005 Mark McLoughlin 2.11.91-2 - Fix "Adjust Date & Time" (#165586) * Wed Aug 10 2005 Mark McLoughlin 2.11.91-1 - Update to 2.11.91 * Wed Aug 10 2005 Mark McLoughlin 2.11.90-2 - Bump gtk2 req to 2.7.1 - Remove bogus/stale reqs: libxslt-devel, startup-notification-devel, gnome-keyring, libpng-devel, fontconfig-devel, libtool, automake, autoconf ... gnome-system-monitor-2.11.91-1 ------------------------------ * Wed Aug 10 2005 Ray Strode 2.11.91-1 - New upstream version gnome-vfs2-2.11.90-2 -------------------- * Wed Aug 10 2005 David Zeuthen 2.11.90-2 - Disable a few patches that are upstream/irrelavant - Add patch to detect mounts from drives we cannot poll * Fri Aug 05 2005 Matthias Clasen 2.11.90-1 - New upstream version - Remove patches and sources for the desktop method, since we don't have start-here in the UI anymore. gok-1.0.5-3 ----------- * Wed Aug 10 2005 Matthias Clasen 1.0.5-3 - Rebuilt iproute-2.6.13-1 ---------------- * Thu Aug 11 2005 Radek Vokal 2.6.13-1 - update to snapshot for 2.6.13+ kernel libsepol-1.7.11-1 ----------------- * Wed Aug 10 2005 Dan Walsh 1.7.11-1 - Upgrade to latest from NSA * Fix range_trans_clone to map the type values properly. pygtk2-2.7.3-1 -------------- * Wed Aug 10 2005 - 2.7.3-1 - Update to 2.7.3 * Wed Aug 10 2005 - 2.7.2-1 - Update to 2.7.2 qt-1:3.3.4-20 ------------- * Wed Aug 10 2005 Than Ngo 1:3.3.4-20 - apply missing patches * Wed Aug 10 2005 Than Ngo 1:3.3.4-19 - apply patch to fix wrong K menu width, #165510 * Mon Aug 01 2005 Than Ngo 1:3.3.4-18 - add visibility patch scim-1.4.1-1 ------------ * Thu Aug 11 2005 Jens Petersen - 1.4.1-1 - update to 1.4.1 bugfix release - source scim-qtimm script if present from scim xinput script * Mon Aug 01 2005 Jens Petersen - 1.4.0-3 - bring back the xinput alternatives settings for now - quote the postun readlink test (wcalee at myrealbox.com, #164674) * Sat Jul 30 2005 Ryo Dairiki - don't explicitly --disable-ld-version-script since this turns on versioning xscreensaver-1:4.22-6 --------------------- * Wed Aug 10 2005 Ray Strode 1:4.22-6 - Don't call printf in signal handler (might fix 126428) * Wed Aug 03 2005 Ray Strode 1:4.22-5 - Update to xscreensaver 4.22. * Sun Jun 19 2005 Ray Strode 1:4.21-5 - Add build requires for desktop-file-utils (bug 160980). yaboot-1.3.13-0.6 ----------------- * Tue Aug 09 2005 David Woodhouse - 1.3.13-0.6 - Fix handling of prom 'read' method, to make Pegasos serial work Broken deps for i386 ---------------------------------------------------------- usermode-gtk - 1.80-2.i386 requires libwnck-1.so.17 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.i386 requires libnautilus-burn.so.1 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 gnome-applets - 1:2.11.2-1.i386 requires libwnck-1.so.17 gnome-python2-libwnck - 2.10.0-2.1.i386 requires libwnck-1.so.16 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 ppc64-utils - 0.7-9.ppc64 requires yaboot usermode-gtk - 1.80-2.ppc64 requires libwnck-1.so.17()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config system-config-keyboard - 1.2.6-2.noarch requires pyxf86config gnome-applets - 1:2.11.2-1.ppc64 requires libwnck-1.so.17()(64bit) firstboot - 1.3.44-1.noarch requires system-config-display gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc64 requires libwnck-1.so.16()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc64 requires libnautilus-burn.so.1()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) Broken deps for s390 ---------------------------------------------------------- initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 usermode-gtk - 1.80-2.s390 requires libwnck-1.so.17 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 selinux-policy-targeted - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 gnome-applets - 1:2.11.2-1.s390 requires libwnck-1.so.17 selinux-policy-strict - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-targeted-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.x86_64 requires libwnck-1.so.16()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 usermode-gtk - 1.80-2.x86_64 requires libwnck-1.so.17()(64bit) dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.x86_64 requires libnautilus-burn.so.1()(64bit) gnome-applets - 1:2.11.2-1.x86_64 requires libwnck-1.so.17()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390x ---------------------------------------------------------- quota - 1:3.12-6.s390x requires kernel >= 0:2.4 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 usermode-gtk - 1.80-2.s390x requires libwnck-1.so.17()(64bit) selinux-policy-targeted - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 selinux-policy-strict - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 selinux-policy-strict-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.3-14.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 gnome-applets - 1:2.11.2-1.s390x requires libwnck-1.so.17()(64bit) lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-applets - 1:2.11.2-1.ppc requires libwnck-1.so.17 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-libwnck - 2.10.0-2.1.ppc requires libwnck-1.so.16 usermode-gtk - 1.80-2.ppc requires libwnck-1.so.17 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ppc requires libnautilus-burn.so.1 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs gnome-python2-libwnck - 2.10.0-2.1.ia64 requires libwnck-1.so.16()(64bit) gnome-applets - 1:2.11.2-1.ia64 requires libwnck-1.so.17()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.ia64 requires libnautilus-burn.so.1()(64bit) usermode-gtk - 1.80-2.ia64 requires libwnck-1.so.17()(64bit) From ph18 at cornell.edu Thu Aug 11 12:50:44 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 11 Aug 2005 08:50:44 -0400 Subject: OCFS2 and GFS. In-Reply-To: <1123749675.28078.182.camel@dragon.sys.intra> References: <1123749675.28078.182.camel@dragon.sys.intra> Message-ID: <42FB49A4.2040107@cornell.edu> Naoki wrote: >Hi all, > >Was checking this out : >http://lxer.com/module/newswire/view/41239/index.html it's just a >little bit of Oracle marketing about how great OCFS2 is and how great >Oracle is for releasing it to the community. > >But I was thinking what the point of OCFS2 is when we have GFS. > >Mr Morton seems to like it but what are the advantages to GFS which is >seemingly been around longer? > >The are both POSIX which is nice. > > I'd really like to see a global file system that has implementations on multiple platforms: this would be the disruptive technology that would make iSCSI appealing. Once the iSCSI drivers firm up a bit, I'm planning on setting up a storage server that runs GFS over iSCSI: this ought to work well with the other Linux machines at home, but won't work with the other machines in the menagerie -- running Windows, MacOS X, and Solaris. (I'll probably need to run SAMBA and NFS for those guys.) This is a lot to ask for. People who are working on global file systems seem interested in the high-end cluster market, not in the low-end NFS/CIFS/Appletalk killer market. On the other hand, working up from the low-end might help get the momentum that will vanquish the FC mafia at the high end. For instance, I'm planning to build an NFS killer to evaluate GFS (and maybe OCFS2) for use in a future cluster installation at work. From pjones at redhat.com Thu Aug 11 14:47:55 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 11 Aug 2005 10:47:55 -0400 Subject: radeonfb kernel switch no longer works? In-Reply-To: References: Message-ID: <1123771675.4725.16.camel@localhost.localdomain> On Tue, 2005-07-26 at 15:11 -0400, sean wrote: > On amd64 with radeon 8500, dmesg: > > > Bootdata ok (command line is root=/dev/hda5 > video=radeonfb:1024x768-32 at 100) > Linux version 2.6.12-1.1437_FC5 > (bhcompile at crowe.devel.redhat.com) (gcc version 4.0.1 > 20050720 (Red Hat 4.0.1-4)) #1 SMP Mon > Jul 25 18:21:05 EDT 2005 > ............. > > This used to give console output at 1024x768. Even a couple > of weeks ago, maybe. Now I get a vga display. > > Have the kernel switches changed? > > sean You have to load the module, as well, but as far as I know that's always been true. -- Peter From davej at redhat.com Thu Aug 11 17:14:36 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 11 Aug 2005 13:14:36 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: <20050811091910.GI21787@redhat.com> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> <20050810221900.GF21787@redhat.com> <20050811051353.GB9867@redhat.com> <20050811091910.GI21787@redhat.com> Message-ID: <20050811171436.GA9529@redhat.com> On Thu, Aug 11, 2005 at 05:19:11AM -0400, Daniel Veillard wrote: > On Thu, Aug 11, 2005 at 01:13:53AM -0400, Dave Jones wrote: > > On Wed, Aug 10, 2005 at 06:19:00PM -0400, Daniel Veillard wrote: > > > On Thu, Aug 11, 2005 at 07:15:23AM +1000, Rodd Clarkson wrote: > > > > > - Rewrite of the inotify back-end, reduce resources usage, tuning in > > > > > > > > Does this mean that inotify is now in the kernel? > > > > > > I don't think so, davej is the ultimate person to answer when this will > > > hit us, but I expect it will be in Fedora Core 5, so ... > > > > It will definitly appear in FC5. I'll likely backport 2.6.13 to FC4 > > a little while after it gets released, and *maybe* to FC3 too. > > Hum, I didn't expect to push more gamin updates to FC3, for FC3 my > main goal was to fix the last perceived desktop bugs related to > dnotify/gamin. Well, you don't *have* to push an update for FC3 even if inotify does end up in the kernel there. dnotify will continue to work as it always did. Dave From veillard at redhat.com Thu Aug 11 17:26:56 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 11 Aug 2005 13:26:56 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: <20050811171436.GA9529@redhat.com> References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> <1123708523.2968.3.camel@localhost.localdomain> <20050810221900.GF21787@redhat.com> <20050811051353.GB9867@redhat.com> <20050811091910.GI21787@redhat.com> <20050811171436.GA9529@redhat.com> Message-ID: <20050811172655.GF7644@redhat.com> On Thu, Aug 11, 2005 at 01:14:36PM -0400, Dave Jones wrote: > On Thu, Aug 11, 2005 at 05:19:11AM -0400, Daniel Veillard wrote: > > Hum, I didn't expect to push more gamin updates to FC3, for FC3 my > > main goal was to fix the last perceived desktop bugs related to > > dnotify/gamin. > > Well, you don't *have* to push an update for FC3 even if inotify does > end up in the kernel there. dnotify will continue to work as it always did. Sure dnotify will still work, but gamin is compiled with inotify support by default even in FC3 so as soon as an inotify kernel ils pushed the inotify back-end will be used (assuming people who updated their kernel package also updated their gamin package with the final updates). I just hope the guinea p^H^H^H^H^H^H^Hbrave people who test inotify on other distros had actually found the main bugs by last month. I expect so, an inotify based solution really can't be worse than a dnotify based one :-) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From skvidal at phy.duke.edu Thu Aug 11 19:19:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 11 Aug 2005 15:19:24 -0400 Subject: rawhide report: 20050810 changes In-Reply-To: References: <200508101626.j7AGQpix019826@porkchop.devel.redhat.com> Message-ID: <1123787964.8431.21.camel@cutter> > # yum install gnome-applets > Setting up Install Process > > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package gnome-applets.i386 1:2.11.2-1 set to be updated > --> Running transaction check > --> Processing Dependency: libwnck-1.so.17 for package: gnome-applets > --> Finished Dependency Resolution > Error: Missing Dependency: libwnck-1.so.17 is needed by package gnome-applets > > # slocate libwnck-1.so.17 > /usr/lib/libwnck-1.so.17.0.0 > /usr/lib/libwnck-1.so.17 > > > I'm just trying to grasp this, if the dependency is there, why would > this error out, what am I missing? libwnck is being updated - and the gnome-applets in rawhide isn't built for it. -sv From nutello at sweetness.com Thu Aug 11 22:12:38 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Fri, 12 Aug 2005 00:12:38 +0200 Subject: 0700 Perl directories Message-ID: <20050811221238.GR6068@plain.rackshack.net> Try the following command (as root or a regular user): for d in /usr/lib*/perl5; do find $d -perm 700; done or (as a regular user, cleaner): for d in /usr/lib*/perl5; do find $d -printf ""; done Should something be done to prevent this from happening in the future? -- Rudi From fedora at camperquake.de Thu Aug 11 22:18:29 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 12 Aug 2005 00:18:29 +0200 Subject: 0700 Perl directories In-Reply-To: <20050811221238.GR6068@plain.rackshack.net> References: <20050811221238.GR6068@plain.rackshack.net> Message-ID: <20050812001829.51db40ae@nausicaa.camperquake.de> Hi. Rudi Chiarito wrote: > for d in /usr/lib*/perl5; do find $d -perm 700; done Which displays nothing. > or (as a regular user, cleaner): > > for d in /usr/lib*/perl5; do find $d -printf ""; done Which also displays nothing. Two rawhide systems, one older, one current. -- There is no cabal. From fedora at wir-sind-cool.org Thu Aug 11 22:29:37 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 12 Aug 2005 00:29:37 +0200 Subject: 0700 Perl directories In-Reply-To: <20050811221238.GR6068@plain.rackshack.net> References: <20050811221238.GR6068@plain.rackshack.net> Message-ID: <20050812002937.1830f60a.fedora@wir-sind-cool.org> On Fri, 12 Aug 2005 00:12:38 +0200, Rudi Chiarito wrote: > Try the following command (as root or a regular user): > > for d in /usr/lib*/perl5; do find $d -perm 700; done > > or (as a regular user, cleaner): > > for d in /usr/lib*/perl5; do find $d -printf ""; done Both give nothing here. > Should something be done to prevent this from happening in the future? What do you get for those commands? Any Perl module packages, which create unowned directories and hence are affected by a restrictive umask during installation? From nutello at sweetness.com Thu Aug 11 22:36:00 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Fri, 12 Aug 2005 00:36:00 +0200 Subject: 0700 Perl directories In-Reply-To: <20050812001829.51db40ae@nausicaa.camperquake.de> References: <20050811221238.GR6068@plain.rackshack.net> <20050812001829.51db40ae@nausicaa.camperquake.de> Message-ID: <20050811223600.GS6068@plain.rackshack.net> On Fri, Aug 12, 2005 at 12:18:29AM +0200, Ralf Ertzinger wrote: > Which also displays nothing. Argh, that teaches me to post without qualifying further: try it on FC3 systems. I can't test on FC4/Rawhide until later tonight. Is this handled in more recent versions of the RPM scripts? I was seeing errors due to directories not owned by perl-libxml-perl, perl-DateManip, perl-Parse-Yapp and perl-URI. -- Rudi From rodd at clarkson.id.au Fri Aug 12 00:50:41 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 12 Aug 2005 10:50:41 +1000 Subject: Trying to solve performance issues on Rawhide Message-ID: <1123807841.2921.28.camel@localhost.localdomain> Rawhide seems a little jittery of late and I'm wondering whether recent changes to hardware detection is causing issues. As an example, the install phase of yum leaves my mouse very hard to use and sees other processes stammering. Not the experience I'm used to in the past. I've started by trying to address why my modern HDD is running with dma off. Each time I try to set the drive to use dma it fails saying the operation is not permitted. I'm doing the following: [root at localhost ~]# hdparm /dev/hda /dev/hda: multcount = 16 (on) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 65535/16/63, sectors = 195371568, start = 0 [root at localhost ~]# hdparm -d1 /dev/hda /dev/hda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) This in an a brand new dell laptop with a Fujitsu drive that supports UltraDMA. Sorry if this seems like a support questions but I'm unable to try this on older FCs and I'm presuming that it has something to do with hardware changes. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From fedora at wir-sind-cool.org Fri Aug 12 09:02:47 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 12 Aug 2005 11:02:47 +0200 Subject: 0700 Perl directories In-Reply-To: <20050811223600.GS6068@plain.rackshack.net> References: <20050811221238.GR6068@plain.rackshack.net> <20050812001829.51db40ae@nausicaa.camperquake.de> <20050811223600.GS6068@plain.rackshack.net> Message-ID: <20050812110247.6653e88d.fedora@wir-sind-cool.org> On Fri, 12 Aug 2005 00:36:00 +0200, Rudi Chiarito wrote: > On Fri, Aug 12, 2005 at 12:18:29AM +0200, Ralf Ertzinger wrote: > > Which also displays nothing. > > Argh, that teaches me to post without qualifying further: try it on FC3 > systems. I can't test on FC4/Rawhide until later tonight. > > Is this handled in more recent versions of the RPM scripts? Seems so. But I only checked the four you mentioned below. > I was > seeing errors due to directories not owned by perl-libxml-perl, > perl-DateManip, perl-Parse-Yapp and perl-URI. Often caused by autogenerated RPM spec files, where the created list of files is inaccurate and does not include directory entries. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1464_FC5 loadavg: 2.11 2.18 2.03 From alan at redhat.com Fri Aug 12 09:55:42 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 12 Aug 2005 05:55:42 -0400 Subject: Trying to solve performance issues on Rawhide In-Reply-To: <1123807841.2921.28.camel@localhost.localdomain> References: <1123807841.2921.28.camel@localhost.localdomain> Message-ID: <20050812095542.GA23789@devserv.devel.redhat.com> On Fri, Aug 12, 2005 at 10:50:41AM +1000, Rodd Clarkson wrote: > setting using_dma to 1 (on) > HDIO_SET_DMA failed: Operation not permitted > using_dma = 0 (off) > > This in an a brand new dell laptop with a Fujitsu drive that supports > UltraDMA. What does lspci show for your IDE controller. From the above it may just not be supported yet. From avi at argo.co.il Fri Aug 12 12:01:54 2005 From: avi at argo.co.il (Avi Kivity) Date: Fri, 12 Aug 2005 15:01:54 +0300 Subject: bugzilla down? Message-ID: <42FC8FB2.2030306@argo.co.il> a few steps into entering a new bug one is greeted with internal server errors, reproducably. can someone take a look? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From buildsys at redhat.com Fri Aug 12 12:25:07 2005 From: buildsys at redhat.com (Build System) Date: Fri, 12 Aug 2005 08:25:07 -0400 Subject: rawhide report: 20050812 changes Message-ID: <200508121225.j7CCP73E002632@porkchop.devel.redhat.com> Updated Packages: MyODBC-2.50.39-25 ----------------- * Thu Aug 11 2005 Tom Lane 2.50.39-25 - Back-port upstream fix for bug #165257. NetworkManager-0.4-35.cvs20050811 --------------------------------- * Thu Aug 11 2005 Dan Williams - 0.4.35.cvs20050811 - Update to latest CVS o Use DHCP server address as gateway address if the DHCP server doesn't give us a gateway address #rh165698# o Fixes to the applet (Robert Love) o Better caching of information in the applet (Bill Moss) o Generate automatic suggested Ad-Hoc network name from machine's hostname (Robert Love) o Update all network information on successfull connect, not just authentication method booty-0.55-1 ------------ * Thu Aug 11 2005 Peter Jones 0.55-1 - ppc "Pegasos" platform support * Fri Jul 01 2005 Peter Jones 0.54-1 - fix more missing sx8 checks - no more tabs in python code - ppc raid1 booting - minor silo.conf bug fix checkpolicy-1.25.8-1 -------------------- * Thu Aug 11 2005 Dan Walsh 1.25.8-1 - Update to NSA Release * Updated checkpolicy and dispol for the new avtab format. Converted users of ebitmaps to new inline operators. Note: The binary policy format version has been incremented to version 20 as a result of these changes. To build a policy for a kernel that does not yet include these changes, use the -c 19 option to checkpolicy. * Merged patch to prohibit use of "self" as a type name from Jason Tang (Tresys). * Merged patch to fix dismod compilation from Joshua Brindle (Tresys). gaim-1:1.5.0-1.fc5 ------------------ * Thu Aug 11 2005 Warren Togami - 1:1.5.0-1 - 1.5.0 security and bug fixes CAN-2005-2370 Gadu-Gadu memory alignment bug CAN-2005-2102 AIM/ICQ non-UTF-8 Filename Crash CAN-2005-2103 AIM/ICQ away message buffer overflow gnome-applets-1:2.11.91-2 ------------------------- * Thu Aug 11 2005 Ray Strode 1:2.11.91-2 - disable scrollkeeper database updates - add omf files to package list - require gnome-utils for gucharmap/charpick integration * Wed Aug 10 2005 Ray Strode 1:2.11.91-1 - New upstream version gnome-python2-extras-2.11.4-5 ----------------------------- * Thu Aug 11 2005 Jeremy Katz - 2.11.4-5 - add -totem subpackage - nuke mozembed docs on ppc64 * Tue Aug 09 2005 Jeremy Katz - 2.11.4-2 - and fix the build * Tue Aug 09 2005 Jeremy Katz - 2.11.4-1 - bump version and rebuild against current stack gnome-vfs2-2.11.90-3 -------------------- * Thu Aug 11 2005 David Zeuthen 2.11.90-3 - Add system_storage.schemas to SCHEMAS (#165703) hal-0.5.3-4 ----------- * Thu Aug 11 2005 David Zeuthen - 0.5.3-4 - Add patch to make libhal-storage report the right fs usage (#165707) jpilot-0.99.8-0.pre10.1 ----------------------- * Thu Aug 11 2005 Ivana Varekova 0.99.8-0.pre10.1 - new upstream version (0.99.8-pre10) kde-i18n-1:3.4.2-1 ------------------ * Thu Jul 21 2005 Than Ngo 1:3.4.2-1 - 3.4.2 kdeedu-3.4.2-1 -------------- * Wed Aug 10 2005 Than Ngo 3.4.2-1 - update to 3.4.2 kdenetwork-7:3.4.2-1 -------------------- * Thu Aug 11 2005 Than Ngo 7:3.4.2-1 - update to 3.4.2 kdeutils-6:3.4.2-1 ------------------ * Thu Aug 11 2005 Than Ngo 6:3.4.2-1 - update to 3.4.2 kdevelop-9:3.2.2-1 ------------------ * Thu Aug 11 2005 Than Ngo 9:3.2.2-1 - update to 3.2.2 kdewebdev-6:3.4.2-1 ------------------- * Thu Aug 11 2005 Than Ngo 6:3.4.2-1 - update to 3.4.2 krb5-1.4.2-1 ------------ * Thu Aug 11 2005 Nalin Dahyabhai 1.4.2-1 - update to 1.4.2, incorporating the fixes for MIT-KRB5-SA-2005-002 and MIT-KRB5-SA-2005-003 libselinux-1.25.2-1 ------------------- * Thu Aug 11 2005 Dan Walsh 1.25.2-1 - Update from NSA * Merged several fixes for error handling paths in the AVC sidtab, matchpathcon, booleans, context, and get_context_list code from Serge Hallyn (IBM). Bugs found by Coverity. * Removed setupns; migrated to pam. * Merged patches to rename checkPasswdAccess() from Joshua Brindle. Original symbol is temporarily retained for compatibility until all callers are updated. libsepol-1.7.13-1 ----------------- * Thu Aug 11 2005 Dan Walsh 1.7.13-1 - Upgrade to latest from NSA * Improved memory use by SELinux by both reducing the avtab node size and reducing the number of avtab nodes (by not expanding attributes in TE rules when possible). Added expand_avtab and expand_cond_av_list functions for use by assertion checker, hierarchy checker, compatibility code, and dispol. Added new inline ebitmap operators and converted existing users of ebitmaps to the new operators for greater efficiency. Note: The binary policy format version has been incremented to version 20 as a result of these changes. * Thu Aug 11 2005 Dan Walsh 1.7.12-1 - Upgrade to latest from NSA * Fixed bug in constraint_node_clone handling of name sets. patch-2.5.4-25 -------------- * Thu Aug 11 2005 Tim Waugh 2.5.4-25 - Fixed CRLF detection (bug #154283). * Wed May 04 2005 Tim Waugh 2.5.4-24 - Reverted last change (bug #154283, bug #156762). * Fri Apr 29 2005 Tim Waugh 2.5.4-23 - Applied patch from Toshio Kuratomi to avoid problems with DOS-format newlines (bug #154283). perl-3:5.8.6-16 --------------- * Tue Aug 09 2005 Jose Pedro Oliveira - 3:5.8.6-16 - Reformatted the specfile. - Added the Source0 URL. - Dropped the MANIFEST.all file for the perl package. - Dropped the MANIFEST.suidperl file for the suidperl subpackage. * Wed May 18 2005 Warren Togami - 3:5.8.6-15 - remove unused /tmp/MANIFEST.all (#151801) * Tue May 17 2005 Warren Togami - 3:5.8.6-14 - CGI.pm 3.10 fixes mod_perl problems (#158036) selinux-policy-strict-1.25.4-1 ------------------------------ * Thu Aug 11 2005 Dan Walsh 1.25.4-1 -Update to latest from NSA * Merged small patches from Russell Coker for the restorecon, kudzu, lvm, radvd, and spamassasin policies. * Added fs_use_trans rule for mqueue from Mark Gebhart to support the work he has done on providing SELinux support for mqueue. * Merged a patch from Dan Walsh. Removes the user_can_mount tunable. Adds disable_evolution_trans and disable_thunderbird_trans booleans. Adds the nscd_client_domain attribute to insmod_t. Removes the user_ping boolean from targeted policy. Adds hugetlbfs, inotifyfs, and mqueue filesystems to genfs_contexts. Adds the isakmp_port for vpnc. Creates the pptp daemon domain. Allows getty to run sbin_t for pppd. Allows initrc to write to default_t for booting. Allows Hotplug_t sys_rawio for prism54 card at boot. Other minor fixes. selinux-policy-targeted-1.25.4-1 -------------------------------- * Thu Aug 11 2005 Dan Walsh 1.25.4-1 -Update to latest from NSA * Merged small patches from Russell Coker for the restorecon, kudzu, lvm, radvd, and spamassasin policies. * Added fs_use_trans rule for mqueue from Mark Gebhart to support the work he has done on providing SELinux support for mqueue. * Merged a patch from Dan Walsh. Removes the user_can_mount tunable. Adds disable_evolution_trans and disable_thunderbird_trans booleans. Adds the nscd_client_domain attribute to insmod_t. Removes the user_ping boolean from targeted policy. Adds hugetlbfs, inotifyfs, and mqueue filesystems to genfs_contexts. Adds the isakmp_port for vpnc. Creates the pptp daemon domain. Allows getty to run sbin_t for pppd. Allows initrc to write to default_t for booting. Allows Hotplug_t sys_rawio for prism54 card at boot. Other minor fixes. system-config-netboot-0.1.26-1_FC5 ---------------------------------- * Thu Aug 11 2005 Jason Vas Dias 0.1.26-1 - fix bug 165772 : read-only root filesystem reported as mounted with "rw" option It appears that the initscripts package of RHEL-4 requires a "READONLY=yes" option in /etc/sysconfig/init in the client root for rc.sysinit not to attempt to mount it read-write. - fix bug 165735 : diskless clients cannot cope with no DNS PTR record for their IP address It was possible for multiple clients who were unable to determine their host name to mount the same snapshot directory - this is now impossible; If clients are unable to determine their host name and have empty SNAPSHOT settings, the IP address is used for the snapshot directory. It is also now possible to set the hostname and domainname without DNS by the DHCP server supplying the host-name option. - fix bug 165730: prevent kernel*-2.6.9-12.2.EL getting an Oops when 'host' is run system-config-printer-0.6.141-1 ------------------------------- * Thu Aug 11 2005 Tim Waugh 0.6.141-1 - 0.6.141: - Clear the foomatic cache in the %post scriptlet (bug #165556). traceroute-1.4a12-27 -------------------- * Thu Aug 11 2005 Radek Vokal 1.4a12-27 - fixed packet size for icmp checksum (#164466) - small buffer-overflow fixies usermode-1.80-4 --------------- * Thu Aug 11 2005 Ray Strode 1.80-4 - rebuild * Tue Jul 12 2005 Jindrich Novy 1.80-3 - rebuild again because of libwnck change vnc-4.1.1-16 ------------ * Thu Aug 11 2005 Tim Waugh 4.1.1-16 - Added -nohttpd option to vncserver, based on patch from bug #161288. - Included -nohttpd, -nolisten tcp, and -localhost options in example sysconfig file (bug #165334). xpdf-1:3.00-24 -------------- * Thu Aug 11 2005 Than Ngo 3.00-24 - change Kochi fonts to Sazanami fonts #165678 yaboot-1.3.13-0.8 ----------------- * Thu Aug 11 2005 David Woodhouse - 1.3.13-0.8 - Allow mntpoint to be more than one directory into the partition as long as magicboot and nvram are not being used. * Thu Aug 11 2005 David Woodhouse - 1.3.13-0.7 - Fix error in swraid2 patch -- don't dereference NULL pointer. Broken deps for i386 ---------------------------------------------------------- cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 Broken deps for x86_64 ---------------------------------------------------------- cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390x ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) nfs-utils - 1.0.7-12.s390x requires kernel >= 0:2.2.14 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390x requires kernel >= 0:2.4.10 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 lvm2 - 2.01.14-1.0.s390x requires kernel >= 0:2.6 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-totem - 2.11.4-5.ppc64 requires mozilla >= 0:1.7.3 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 ppc64-utils - 0.7-9.ppc64 requires yaboot firstboot - 1.3.44-1.noarch requires system-config-display evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390 ---------------------------------------------------------- gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 selinux-policy-strict - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 selinux-policy-strict-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-targeted - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 From fedora at wir-sind-cool.org Fri Aug 12 14:24:40 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 12 Aug 2005 16:24:40 +0200 Subject: gnome-python2-extras Re: rawhide report: 20050812 changes In-Reply-To: <200508121225.j7CCP73E002632@porkchop.devel.redhat.com> References: <200508121225.j7CCP73E002632@porkchop.devel.redhat.com> Message-ID: <20050812162440.37cf5840.fedora@wir-sind-cool.org> On Fri, 12 Aug 2005 08:25:07 -0400, Build System wrote: > gnome-python2-extras-2.11.4-5 > ----------------------------- > * Thu Aug 11 2005 Jeremy Katz - 2.11.4-5 > - add -totem subpackage > - nuke mozembed docs on ppc64 > > * Tue Aug 09 2005 Jeremy Katz - 2.11.4-2 > - and fix the build > > * Tue Aug 09 2005 Jeremy Katz - 2.11.4-1 > - bump version and rebuild against current stack So, there's an update of this package, but still silence in here: https://bugzilla.redhat.com/162403 From rodd at clarkson.id.au Fri Aug 12 15:22:24 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 13 Aug 2005 01:22:24 +1000 Subject: Trying to solve performance issues on Rawhide In-Reply-To: <20050812095542.GA23789@devserv.devel.redhat.com> References: <1123807841.2921.28.camel@localhost.localdomain> <20050812095542.GA23789@devserv.devel.redhat.com> Message-ID: <1123860145.2921.34.camel@localhost.localdomain> On Fri, 2005-08-12 at 05:55 -0400, Alan Cox wrote: > On Fri, Aug 12, 2005 at 10:50:41AM +1000, Rodd Clarkson wrote: > > setting using_dma to 1 (on) > > HDIO_SET_DMA failed: Operation not permitted > > using_dma = 0 (off) > > > > This in an a brand new dell laptop with a Fujitsu drive that supports > > UltraDMA. > > What does lspci show for your IDE controller. From the above it may just not > be supported yet. [rodd at localhost ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation NV41.8 [GeForce Go 6800] (rev a2) 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3) 03:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08) 03:01.2 Class 0805: Ricoh Co Ltd SD Card reader (rev 17) 03:03.0 Network controller: Intel Corporation PRO/Wireless 2915ABG MiniPCI Adapter (rev 05) [rodd at localhost ~]$ Rodd -- "It's a fine line between denial and faith. It's much better on my side" From jpo at di.uminho.pt Fri Aug 12 17:40:38 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Fri, 12 Aug 2005 18:40:38 +0100 Subject: 0700 Perl directories In-Reply-To: <20050811223600.GS6068@plain.rackshack.net> References: <20050811221238.GR6068@plain.rackshack.net> <20050812001829.51db40ae@nausicaa.camperquake.de> <20050811223600.GS6068@plain.rackshack.net> Message-ID: <42FCDF16.2020204@di.uminho.pt> Rudi Chiarito wrote: > On Fri, Aug 12, 2005 at 12:18:29AM +0200, Ralf Ertzinger wrote: > >>Which also displays nothing. > > > Argh, that teaches me to post without qualifying further: try it on FC3 > systems. I can't test on FC4/Rawhide until later tonight. > > Is this handled in more recent versions of the RPM scripts? I was > seeing errors due to directories not owned by perl-libxml-perl, > perl-DateManip, perl-Parse-Yapp and perl-URI. > A lot of FC4 perl modules (unfortunately not all) had their specfiles cleanup. If you still find unowned directories in FC4/Rawhide please bugzilla them. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Sat Aug 13 03:57:24 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 12 Aug 2005 23:57:24 -0400 Subject: tomorrows rawhide kernel. Message-ID: <20050813035724.GA21199@redhat.com> As the rawhide kernel has been pretty boring and uneventful so far, this last day or two, Jeremy Katz and I managed to beat suspend to disk support into shape. The current rawhide kernel (2.6.12-1.1482 and above) now has suspend to disk support enabled using the in-kernel software suspend. At this early stage, play with this at your own risk! Doing the wrong things (or even the right things at the wrong time) can result in irrecoverable data loss. If the above warning hasn't put you off testing, you're probably wondering how to play with this potential datamuncher. 1. Make sure you have a swap partition. (if you have >1, it'll only use the first one, so make sure its at least as big as your RAM). Whilst suspend does evict some non-essential things from memory before it suspends, it can still end up with quite a bit to write out. 2. Make sure the swap partition is enabled. (cat /proc/swaps if you're unsure) 3. echo platform > /sys/power/disk echo disk > /sys/power/state (This will all be done in a much more user friendly way for the FC5 release) 4. Stare at the gobs of info scrolling up the screen. (This will all be cleared up eventually, but for now it's potentially useful for debugging). 5. After a while, your computer should turn itself off. When you turn it back on, the initrd will detect the resume partition and attempt to resume from it. Then presto, you're back where you were. Some caveats noted so far: - Some device drivers don't wake up correctly. So things like your ethernet may need an rmmod/modprobe after resuming, to get things working again until the driver gets fixed. Please report these types of bugs. - *NEVER*, *EVER*, write into /sys/power/resume after you've booted. This is going to have to be made safe at some point. Right now, doing that whilst you've got partitions mounted is a guaranteed way to say goodbye to some files. The good news, is that this is the only way I've found so far to corrupt data. - If you suspend and then don't go back into the same kernel, you won't be able to resume and your swap won't be initialized. Be sure that you run mkswap on your swap partition before booting back to the swsusp kernel. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165863) - Swap that's referenced with LABEL= in /etc/fstab doesn't currently work for resume. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165864) - We haven't tried doing this with X running :) It's likely to work better if you switch to a tty first. - Swap on RAID devices *should* work, but is untested so far. - Changing hardware (adding/removing PCI cards/CPUs etc) is going to bring you a world of pain. swsusp does detect some of the simpler cases and will refuse to resume if the amount of RAM differs etc, but some others won't be detected. In particular things like USB could be problematic. - If you suspend and then want to boot normally (ie, without resuming), add "noresume" to your boot command line. Finally, hopefully this will work out, and we'll get whatever bugs turn up squished quickly. However at this point, there's no guarantee that this will make it into FC5. It all depends on user feedback. So test, and report any bugs in bugzilla. And if by some miracle it all works perfectly for you, we'd love to hear success stories too on fedora-devel list. Dave From msalim at cs.indiana.edu Sat Aug 13 06:10:40 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Sat, 13 Aug 2005 01:10:40 -0500 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <1123913440.31859.9.camel@salem> On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > As the rawhide kernel has been pretty boring and uneventful > so far, this last day or two, Jeremy Katz and I managed to > beat suspend to disk support into shape. > [snip] > 1. Make sure you have a swap partition. > (if you have >1, it'll only use the first one, so make sure > its at least as big as your RAM). Whilst suspend does evict > some non-essential things from memory before it suspends, > it can still end up with quite a bit to write out. > Great! It works with swap-on-LVM, I assume? > - *NEVER*, *EVER*, write into /sys/power/resume after you've booted. > This is going to have to be made safe at some point. Right now, doing > that whilst you've got partitions mounted is a guaranteed way to say > goodbye to some files. The good news, is that this is the only > way I've found so far to corrupt data. > Could this be done with unionfs, I wonder? Layer a branch that contains an immutable /sys/power/resume on top of the real /sys. Looking forward to trying this out, - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From rhl-devel-list at lnx.ro Sat Aug 13 06:26:18 2005 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Sat, 13 Aug 2005 09:26:18 +0300 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <1123914378.2554.21.camel@localhost> Warning, rant ahead, take it with a grain of salt :) ?n data de Vi, 12-08-2005 la 23:57 -0400, Dave Jones a scris: > The current rawhide kernel (2.6.12-1.1482 and above) now has > suspend to disk support enabled using the in-kernel software suspend. Did you looked at suspend2 [1] The developer tryes (hard) to integrate it into the main kernel tree. > 1. Make sure you have a swap partition. > (if you have >1, it'll only use the first one, so make sure > its at least as big as your RAM). Whilst suspend does evict > some non-essential things from memory before it suspends, > it can still end up with quite a bit to write out. Why not an swap file or just an regular suspend file? [2] Why not use compression to speed things up alot ? [2] > 3. > echo platform > /sys/power/disk > echo disk > /sys/power/state > > (This will all be done in a much more user friendly way for the FC5 release) See the hibernate script mentioned below. > 4. Stare at the gobs of info scrolling up the screen. > (This will all be cleared up eventually, but for now it's > potentially useful for debugging). Why not have purty text or fb UI ? [2] > - Some device drivers don't wake up correctly. > So things like your ethernet may need an rmmod/modprobe after > resuming, to get things working again until the driver gets fixed. Things like the hibernate script available at [1] could help automate such things. It also supports vanilla swsusp > - We haven't tried doing this with X running :) It's likely to work better if > you switch to a tty first. SwitchToTextMode yes in the conf file of the hibernate script mentioned above. > So test, and report any bugs in bugzilla. And if by some miracle it > all works perfectly for you, we'd love to hear success stories too > on fedora-devel list. Yes it works perfectly for me for a quite a few months using suspend2 :D -- Cioby From rhl-devel-list at lnx.ro Sat Aug 13 06:42:45 2005 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Sat, 13 Aug 2005 09:42:45 +0300 Subject: tomorrows rawhide kernel. In-Reply-To: <1123914378.2554.21.camel@localhost> References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> Message-ID: <1123915365.2554.27.camel@localhost> ?n data de S?, 13-08-2005 la 09:26 +0300, Dumitru Ciobarcianu a scris: > Warning, rant ahead, take it with a grain of salt :) > > ?n data de Vi, 12-08-2005 la 23:57 -0400, Dave Jones a scris: > > The current rawhide kernel (2.6.12-1.1482 and above) now has > > suspend to disk support enabled using the in-kernel software suspend. > > Did you looked at suspend2 [1] > The developer tryes (hard) to integrate it into the main kernel tree. > > > 1. Make sure you have a swap partition. > > (if you have >1, it'll only use the first one, so make sure > > its at least as big as your RAM). Whilst suspend does evict > > some non-essential things from memory before it suspends, > > it can still end up with quite a bit to write out. > > Why not an swap file or just an regular suspend file? [2] > Why not use compression to speed things up alot ? [2] > > > > 3. > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > > > (This will all be done in a much more user friendly way for the FC5 release) > > See the hibernate script mentioned below. > > > 4. Stare at the gobs of info scrolling up the screen. > > (This will all be cleared up eventually, but for now it's > > potentially useful for debugging). > > Why not have purty text or fb UI ? [2] > > > - Some device drivers don't wake up correctly. > > So things like your ethernet may need an rmmod/modprobe after > > resuming, to get things working again until the driver gets fixed. > > Things like the hibernate script available at [1] could help automate > such things. It also supports vanilla swsusp > > > - We haven't tried doing this with X running :) It's likely to work better if > > you switch to a tty first. > > SwitchToTextMode yes > in the conf file of the hibernate script mentioned above. > > > So test, and report any bugs in bugzilla. And if by some miracle it > > all works perfectly for you, we'd love to hear success stories too > > on fedora-devel list. > > Yes it works perfectly for me for a quite a few months using suspend2 :D > Ugh, silly me, I forgot: [1] is http://www.suspend2.net [2] is http://www.suspend2.net/features -- Cioby From buildsys at redhat.com Sat Aug 13 11:26:04 2005 From: buildsys at redhat.com (Build System) Date: Sat, 13 Aug 2005 07:26:04 -0400 Subject: rawhide report: 20050813 changes Message-ID: <200508131126.j7DBQ4K5027852@porkchop.devel.redhat.com> Updated Packages: OpenIPMI-1.4.14-7 ----------------- * Fri Aug 12 2005 Phil Knirsch 1.4.14-7 - Fixed the unwanted output of failed module loading of the initscript. Behaves now like all our other initscripts (#165476) * Fri Aug 05 2005 Phil Knirsch 1.4.14-6 - Fixed build problem on 64bit machines docbook-style-xsl-1.69.1-1 -------------------------- * Fri Aug 12 2005 Tim Waugh 1.69.1-1 - 1.69.1. ghostscript-8.15-0.rc4.1 ------------------------ * Fri Aug 12 2005 Tim Waugh 8.15-0.rc4.1 - 8.15rc4. - Fixed lips4v driver (bug #165713). iputils-20020927-25 ------------------- * Fri Aug 12 2005 Radek Vokal 20020927-25 - fixed arping timeout (#165715) kernel-2.6.12-1.1482_FC5 ------------------------ * Fri Aug 12 2005 Dave Jones - 2.6.13-rc6-git4 - Bump mkinitrd dependancy. * Thu Aug 11 2005 Dave Jones - 2.6.13-rc6-git3 * Thu Aug 11 2005 David Woodhouse - Enable ISDN and CONFIG_SERIAL_8250_CONSOLE for PPC32 mkinitrd-4.2.20-1 ----------------- * Fri Aug 12 2005 Jeremy Katz - 4.2.20-1 - fix a buglet in root vg finding - support resume with swsusp net-snmp-5.2.1.2-2 ------------------ * Fri Aug 12 2005 Radek Vokal - 5.2.1.2-2 - fix for s390x counter32 overflow (sachinp at in.ibm.com) pm-utils-0.04-1 --------------- * Fri Aug 12 2005 Jeremy Katz - 0.04-1 - add pm-hibernate system-config-netboot-0.1.26-2 ------------------------------ valgrind-1:3.0.0-3 ------------------ * Fri Aug 12 2005 Jakub Jelinek 3.0.0-3 - fix amd64 handling of cwtd instruction - fix amd64 handling of e.g. sarb $0x4,val(%rip) - speedup amd64 insn decoding * Fri Aug 12 2005 Jakub Jelinek 3.0.0-2 - lower x86_64 stage2 base from 112TB down to 450GB, so that valgrind works even on 2.4.x kernels. Still way better than 1.75GB that stock valgrind allows * Fri Aug 12 2005 Jakub Jelinek 3.0.0-1 - upgrade to 3.0.0 - x86_64 support - temporarily obsolete valgrind-callgrind, as it has not been ported yet Broken deps for i386 ---------------------------------------------------------- cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 gnome-python2-totem - 2.11.4-5.ppc64 requires mozilla >= 0:1.7.3 evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) firstboot - 1.3.44-1.noarch requires system-config-display cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-mouse - 1.2.11-1.noarch requires pyxf86config system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 ppc64-utils - 0.7-9.ppc64 requires yaboot Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390x ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) Broken deps for s390 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-strict-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 From pbrobinson at gmail.com Sat Aug 13 11:54:51 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 13 Aug 2005 12:54:51 +0100 Subject: tomorrows rawhide kernel. In-Reply-To: <1123914378.2554.21.camel@localhost> References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> Message-ID: <5256d0b0508130454163ce04@mail.gmail.com> > Warning, rant ahead, take it with a grain of salt :) > > ?n data de Vi, 12-08-2005 la 23:57 -0400, Dave Jones a scris: > > The current rawhide kernel (2.6.12-1.1482 and above) now has > > suspend to disk support enabled using the in-kernel software suspend. > > Did you looked at suspend2 [1] > The developer tryes (hard) to integrate it into the main kernel tree. I think you'll find its the usual answer of its not integrated into the kernel hence its not in Fedora. Although from the notes from the kernel summit it should be in merged into the kernel in some form before too long. Pete From kyrre at solution-forge.net Sat Aug 13 15:15:31 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 13 Aug 2005 17:15:31 +0200 Subject: Kernel/iptables conflict Message-ID: <1123946131.3355.3.camel@localhost.localdomain> During yum update i have a conflict "kernel conflicts with iptables < 1.3.2-1", preventing me from updating the kernel. Has anybody else seen this? I would very much like to test a new kernel, since the last one to install have no working ACPI suspend (older ones do), in order to test if it was only a build mistake etc. Kyrre From davej at redhat.com Sat Aug 13 16:24:40 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 12:24:40 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1123913440.31859.9.camel@salem> References: <20050813035724.GA21199@redhat.com> <1123913440.31859.9.camel@salem> Message-ID: <20050813162440.GB24903@redhat.com> On Sat, Aug 13, 2005 at 01:10:40AM -0500, Michel Alexandre Salim wrote: > On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > > As the rawhide kernel has been pretty boring and uneventful > > so far, this last day or two, Jeremy Katz and I managed to > > beat suspend to disk support into shape. > > > [snip] > > > 1. Make sure you have a swap partition. > > (if you have >1, it'll only use the first one, so make sure > > its at least as big as your RAM). Whilst suspend does evict > > some non-essential things from memory before it suspends, > > it can still end up with quite a bit to write out. > > > Great! It works with swap-on-LVM, I assume? Worked for me :-) > > - *NEVER*, *EVER*, write into /sys/power/resume after you've booted. > > This is going to have to be made safe at some point. Right now, doing > > that whilst you've got partitions mounted is a guaranteed way to say > > goodbye to some files. The good news, is that this is the only > > way I've found so far to corrupt data. > > > Could this be done with unionfs, I wonder? Layer a branch that contains > an immutable /sys/power/resume on top of the real /sys. Actually, this should be a non-issue 99% of the time. Once you've booted, the resume partition will be turned back into a swap partition, so echoing anything there will try to resume, and then fail gracefully (at least it should). The only case this can still corrupt data is if you boot with init=/bin/bash and have stuff mounted, and theres a valid resume partition in your swap. That's a special case that I'm not sure how to protect against, so that may just be a "dont do that" case. Dave From davej at redhat.com Sat Aug 13 16:28:58 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 12:28:58 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1123914378.2554.21.camel@localhost> References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> Message-ID: <20050813162858.GC24903@redhat.com> On Sat, Aug 13, 2005 at 09:26:18AM +0300, Dumitru Ciobarcianu wrote: > > Warning, rant ahead, take it with a grain of salt :) > > ?n data de Vi, 12-08-2005 la 23:57 -0400, Dave Jones a scris: > > The current rawhide kernel (2.6.12-1.1482 and above) now has > > suspend to disk support enabled using the in-kernel software suspend. > > Did you looked at suspend2 [1] > The developer tryes (hard) to integrate it into the main kernel tree. I'm aware of it, and bits of it will make their way into the upstream tree slowly and surely. I'm adverse to carrying large patches like this in the Fedora kernel, especially when it deviates away slightly from upstream functionality. It's the sort of thing that gets us flamed to a crisp when people try to use a kernel.org kernel on Fedora, and then find that functionality x doesn't work with our userland. Thankfully those days should be behind us now. > > 1. Make sure you have a swap partition. > > (if you have >1, it'll only use the first one, so make sure > > its at least as big as your RAM). Whilst suspend does evict > > some non-essential things from memory before it suspends, > > it can still end up with quite a bit to write out. > > Why not an swap file or just an regular suspend file? [2] I never tested swapfiles, but it *should* work. > Why not use compression to speed things up alot ? [2] When suspend2 bits get merged to the tree, we'll have this, not before. > > echo platform > /sys/power/disk > > echo disk > /sys/power/state > > > > (This will all be done in a much more user friendly way for the FC5 release) > > See the hibernate script mentioned below. There's one in the pm-utils package, however for now, I'd like people to try without it, as it blanks the screen during resume. If it then locks up, we have no idea what happened. During the early debugging phase, we'll need as much info as possible. > > 4. Stare at the gobs of info scrolling up the screen. > > (This will all be cleared up eventually, but for now it's > > potentially useful for debugging). > > Why not have purty text or fb UI ? [2] one step at a time. Dave From davej at redhat.com Sat Aug 13 16:32:26 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 12:32:26 -0400 Subject: rawhide report: 20050702 changes In-Reply-To: References: <200507021108.j62B8Jd5008890@porkchop.devel.redhat.com> <20050717203540.GC32622@redhat.com> Message-ID: <20050813163226.GE24903@redhat.com> On Sat, Aug 13, 2005 at 10:29:18AM -0500, Justin Conover wrote: > > Rik was working on an update to a newer upstream Xen snapshot > > last week, but this week is pretty much going to be nothing > > but kernel-summit/OLS activities, so I wouldn't expect it > > to start working for at least another week or so. > Any word from Rik? I would like to get back to some Xen testing on my > rawhide box's when I can. One of the problems with rawhide & xen is that upstream only ever has patches against the latest stable release (ie, 2.6.12), and with rawhide on 2.6.13-rc6 right now, that's a pretty big delta. I think Rik's current plan is to get the latest upstream drop working against the FC4 kernel before forward porting, as there are some issues with the latest Xen changes and exec-shield. Dave From sundaram at redhat.com Sat Aug 13 16:43:00 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 13 Aug 2005 22:13:00 +0530 Subject: Migration from Windows Message-ID: <42FE2314.9010807@redhat.com> Hi Has anyone looked into packaging openmover (http://openmoveover.sourceforge.net/) . Looks like a combination of this and a patch to the installer to auto mount FAT drives as someone posted earlier in the list would be useful atleast as a partial solution. Since NTFS stuff is off limits*, we will have to look at other options besides that regards Rahul http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-why-no-mp3 From davej at redhat.com Sat Aug 13 17:18:07 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 13:18:07 -0400 Subject: rawhide report: 20050813 changes In-Reply-To: References: <200508131126.j7DBQ4K5027852@porkchop.devel.redhat.com> Message-ID: <20050813171807.GB26633@redhat.com> On Sat, Aug 13, 2005 at 12:08:01PM -0500, Justin Conover wrote: > Swap on RAID devices *should* work, but is untested so far. > > I tested this on a box with a softraid/lvm "aic7xxx" controller and > recieved a kernel panic. I just followed these steps > > echo platform > /sys/power/disk > echo disk > /sys/power/state > > Should I have done something different? > > grep swap /etc/fstab > /dev/VolGroup00/LogVol01 swap swap defaults 0 0 > > Would you like the output on screen from kernel panic? Yes please, drop it in bugzilla, and I'll take a look (but probably not before monday) Thanks for testing. Dave From sundaram at redhat.com Sat Aug 13 17:19:56 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 13 Aug 2005 22:49:56 +0530 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <42FE2BBC.6080301@redhat.com> Dave Jones wrote: >As the rawhide kernel has been pretty boring and uneventful >so far, this last day or two, Jeremy Katz and I managed to >beat suspend to disk support into shape. > >The current rawhide kernel (2.6.12-1.1482 and above) now has >suspend to disk support enabled using the in-kernel software suspend. >At this early stage, play with this at your own risk! Doing the wrong >things (or even the right things at the wrong time) can result in >irrecoverable data loss. > checked this out Doesnt work on an SMP 1482 kernel. Works great on an UP one. What information do you require to debug this? regards Rahul From davej at redhat.com Sat Aug 13 17:26:56 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 13:26:56 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <42FE2BBC.6080301@redhat.com> References: <20050813035724.GA21199@redhat.com> <42FE2BBC.6080301@redhat.com> Message-ID: <20050813172656.GC26633@redhat.com> On Sat, Aug 13, 2005 at 10:49:56PM +0530, Rahul Sundaram wrote: > Dave Jones wrote: > > >As the rawhide kernel has been pretty boring and uneventful > >so far, this last day or two, Jeremy Katz and I managed to > >beat suspend to disk support into shape. > > > >The current rawhide kernel (2.6.12-1.1482 and above) now has > >suspend to disk support enabled using the in-kernel software suspend. > >At this early stage, play with this at your own risk! Doing the wrong > >things (or even the right things at the wrong time) can result in > >irrecoverable data loss. > > > > checked this out > > Doesnt work on an SMP 1482 kernel. Works great on an UP one. What > information do you require to debug this? define 'doesnt work' :-) does it just lock up? at what stage? what hardware is in the box? try unloading some drivers before you do the suspend. (the pm-hibernate script will do this for you, but if you do it by hand, you should be able to narrow down which driver is causing the pain). Jeremy and I did try an SMP kernel once, and it didn't work for us either, but we didn't investigate it further. File a bug on it, with as much info as possible, and we'll see if we can get it figured out. With the advent of HT & dual-core CPUs that will inevitably end up in laptops at some point, we have to make sure that SMP works too. Dave From davej at redhat.com Sat Aug 13 17:30:36 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 13:30:36 -0400 Subject: rawhide report: 20050813 changes In-Reply-To: References: <200508131126.j7DBQ4K5027852@porkchop.devel.redhat.com> <20050813171807.GB26633@redhat.com> Message-ID: <20050813173036.GD26633@redhat.com> On Sat, Aug 13, 2005 at 12:27:03PM -0500, Justin Conover wrote: > On 8/13/05, Dave Jones wrote: > > On Sat, Aug 13, 2005 at 12:08:01PM -0500, Justin Conover wrote: > > > > > Swap on RAID devices *should* work, but is untested so far. > > > > > > I tested this on a box with a softraid/lvm "aic7xxx" controller and > > > recieved a kernel panic. I just followed these steps > > > > > > echo platform > /sys/power/disk > > > echo disk > /sys/power/state > > > > > > Should I have done something different? > > > > > > grep swap /etc/fstab > > > /dev/VolGroup00/LogVol01 swap swap defaults 0 0 > > > > > > Would you like the output on screen from kernel panic? > > > > Yes please, drop it in bugzilla, and I'll take a look > > (but probably not before monday) > > > > Thanks for testing. > > > > Dave > > > You know, this might sound stupid but I'm not actually sure if this > box supports apic/apm, what ever the suspend is using. I really > didn't see any options in the BIOS It shouldn't need too much help from the BIOS. Of course the more help the BIOS does give us the better. If you've got stuff in /proc/acpi/ (any x86 box built in the last 5 years will have it) then you should be fine. Dave From davej at redhat.com Sat Aug 13 17:36:37 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 13:36:37 -0400 Subject: Kernel/iptables conflict In-Reply-To: <1123946131.3355.3.camel@localhost.localdomain> References: <1123946131.3355.3.camel@localhost.localdomain> Message-ID: <20050813173637.GE26633@redhat.com> On Sat, Aug 13, 2005 at 05:15:31PM +0200, Kyrre Ness Sjobak wrote: > During yum update i have a conflict "kernel conflicts with iptables < > 1.3.2-1", preventing me from updating the kernel. Has anybody else seen > this? The latest iptables in rawhide is 1.3.2-1, I don't see the problem? If you're trying to use this kernel on an older release, you'll need to pull in a bunch of userspace updates too. Ok, The iptables dependancy isn't that big a deal, but things like mkinitrd, initscripts, possibly pcmciautils, udev and a bunch of other things will need changes. > I would very much like to test a new kernel, since the last one to > install have no working ACPI suspend (older ones do), in order to test > if it was only a build mistake etc. You mean suspend to ram? I've not heard of that breaking recently. Dave From davej at redhat.com Sat Aug 13 17:53:32 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 13:53:32 -0400 Subject: rawhide report: 20050813 changes In-Reply-To: References: <200508131126.j7DBQ4K5027852@porkchop.devel.redhat.com> <20050813171807.GB26633@redhat.com> <20050813173036.GD26633@redhat.com> Message-ID: <20050813175332.GF26633@redhat.com> On Sat, Aug 13, 2005 at 12:46:04PM -0500, Justin Conover wrote: > On 8/13/05, Dave Jones wrote: > > On Sat, Aug 13, 2005 at 12:27:03PM -0500, Justin Conover wrote: > Ok, cat /proc/acpi/processor/CPU0/info does return > > acpi id: 1 > power management: yes > > I'll drop the output in bugzilla, should this be reported in > rawhide/kernels\mkinitrd or a different category? file it against fedora devel, kernel. Dave From sundaram at redhat.com Sat Aug 13 18:07:41 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 13 Aug 2005 23:37:41 +0530 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813172656.GC26633@redhat.com> References: <20050813035724.GA21199@redhat.com> <42FE2BBC.6080301@redhat.com> <20050813172656.GC26633@redhat.com> Message-ID: <42FE36ED.9070700@redhat.com> Dave Jones wrote: >On Sat, Aug 13, 2005 at 10:49:56PM +0530, Rahul Sundaram wrote: > > Dave Jones wrote: > > > > >As the rawhide kernel has been pretty boring and uneventful > > >so far, this last day or two, Jeremy Katz and I managed to > > >beat suspend to disk support into shape. > > > > > >The current rawhide kernel (2.6.12-1.1482 and above) now has > > >suspend to disk support enabled using the in-kernel software suspend. > > >At this early stage, play with this at your own risk! Doing the wrong > > >things (or even the right things at the wrong time) can result in > > >irrecoverable data loss. > > > > > > > checked this out > > > > Doesnt work on an SMP 1482 kernel. Works great on an UP one. What > > information do you require to debug this? > >define 'doesnt work' :-) >does it just lock up? at what stage? what hardware is in the box? > > Filed a report : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165894 regards Rahul From sundaram at redhat.com Sat Aug 13 18:59:16 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 14 Aug 2005 00:29:16 +0530 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <42FE4304.9030102@redhat.com> Dave Jones wrote: >As the rawhide kernel has been pretty boring and uneventful >so far, this last day or two, Jeremy Katz and I managed to >beat suspend to disk support into shape. > >The current rawhide kernel (2.6.12-1.1482 and above) now has >suspend to disk support enabled using the in-kernel software suspend. >At this early stage, play with this at your own risk! Doing the wrong >things (or even the right things at the wrong time) can result in >irrecoverable data loss. > >If the above warning hasn't put you off testing, you're probably >wondering how to play with this potential datamuncher. > >1. Make sure you have a swap partition. >(if you have >1, it'll only use the first one, so make sure > its at least as big as your RAM). Whilst suspend does evict > some non-essential things from memory before it suspends, > it can still end up with quite a bit to write out. > >2. Make sure the swap partition is enabled. >(cat /proc/swaps if you're unsure) > >3. >echo platform > /sys/power/disk >echo disk > /sys/power/state > >(This will all be done in a much more user friendly way for the FC5 release) > >4. Stare at the gobs of info scrolling up the screen. >(This will all be cleared up eventually, but for now it's >potentially useful for debugging). > >5. After a while, your computer should turn itself off. >When you turn it back on, the initrd will detect the resume >partition and attempt to resume from it. > >Then presto, you're back where you were. > > > >Some caveats noted so far: > >- Some device drivers don't wake up correctly. >So things like your ethernet may need an rmmod/modprobe after >resuming, to get things working again until the driver gets fixed. >Please report these types of bugs. > >- *NEVER*, *EVER*, write into /sys/power/resume after you've booted. >This is going to have to be made safe at some point. Right now, doing >that whilst you've got partitions mounted is a guaranteed way to say >goodbye to some files. The good news, is that this is the only >way I've found so far to corrupt data. > >- If you suspend and then don't go back into the same kernel, you won't be > able to resume and your swap won't be initialized. Be sure that you run > mkswap on your swap partition before booting back to the swsusp kernel. > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165863) > >- Swap that's referenced with LABEL= in /etc/fstab doesn't currently work for > resume. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165864) > >- We haven't tried doing this with X running :) It's likely to work better if > you switch to a tty first. > Update: Resuming with GNOME in an UP kernel works as expected in rawhide. regards Rahul From ndbecker2 at gmail.com Sat Aug 13 19:19:01 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 13 Aug 2005 15:19:01 -0400 Subject: tomorrows rawhide kernel. References: <20050813035724.GA21199@redhat.com> Message-ID: Would this kernel be expected to work on an update FC4 environment (current FC4 but no devel)? My Compaq r3000z has never suspended, and I'd like to see if this would do the trick. If it works, will this be pushed to FC4? (please?) From david at fubar.dk Sat Aug 13 20:18:00 2005 From: david at fubar.dk (David Zeuthen) Date: Sat, 13 Aug 2005 16:18:00 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <1123964280.3997.6.camel@daxter.boston.redhat.com> On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > As the rawhide kernel has been pretty boring and uneventful > so far, this last day or two, Jeremy Katz and I managed to > beat suspend to disk support into shape. This works nicely for me on a IBM Thinkpad T41 (even from within X) but not so nice on my 12" Powerbook G4. So, digging into the issue it appears that CONFIG_SOFTWARE_SUSPEND is not set on ppc kernels... I've seem to read somewhere that swsup is supposed to work on ppc (since it's basically all in software), any chance that a) this is true; and b) we can get the same user experience on ppc? Very nice work nonetheless. Thanks. Cheers, David From bernie at develer.com Sat Aug 13 21:43:24 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 13 Aug 2005 23:43:24 +0200 Subject: dbus-qt In-Reply-To: <42E58B22.8070806@develer.com> References: <200503051737.02475.ml-fedora@fathomssen.de> <1110043263.2451.35.camel@localhost.localdomain> <42E45D67.8020702@math.unl.edu> <42E58B22.8070806@develer.com> Message-ID: <42FE697C.7000505@develer.com> Bernardo Innocenti wrote: > Rex Dieter wrote: >>John (J5) Palmieri wrote: >>>On Sat, 2005-03-05 at 11:37, Frederick Alexander Thomssen wrote: >> >>>>once dbus-qt was removed from fedora because there was no use for it. >>>>but now kde 3.4 supports dbus-qt for the media:/ protocol which >>>>indicated if a new device was connected. so there now is a use for >>>>dbus-qt so i think it ought to be included. >>> >>>Does an app in fedora core require it? >> >>k3b (v0.12+), at least, can use it, if available. > > For the record, I've hacked dbus.spec to re-enable > Qt support, updating references to Qt 3.1 to 3.3). > > The resulting dbus-qt subpackage builds and installs > correctly. KDE builds fine against it with a small > configury patch to look for libraries in /usr/lib64 > on x86_64. > > Now I can use media:/ in Konqueror. Looks like a > safe change for fedora-devel. As of today dbus-qt is still disabled in Fedora. The attached patch is enough to get it to build. I've rebuilt KDE from CVS and I can confirm media:/ works and removable devices are correctly detected, but not automounted. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From msalim at cs.indiana.edu Sat Aug 13 22:08:31 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Sat, 13 Aug 2005 17:08:31 -0500 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813162440.GB24903@redhat.com> References: <20050813035724.GA21199@redhat.com> <1123913440.31859.9.camel@salem> <20050813162440.GB24903@redhat.com> Message-ID: <1123970912.3455.8.camel@salem> On Sat, 2005-08-13 at 12:24 -0400, Dave Jones wrote: > On Sat, Aug 13, 2005 at 01:10:40AM -0500, Michel Alexandre Salim wrote: > > On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > > > As the rawhide kernel has been pretty boring and uneventful > > > so far, this last day or two, Jeremy Katz and I managed to > > > beat suspend to disk support into shape. > > > > > [snip] > > Great! It works with swap-on-LVM, I assume? > > Worked for me :-) > Tried it just now and I encountered a kernel panic while suspending from the GNOME desktop, using the x86_64 kernel. Is there a good way to get to the kernel dump, short of hooking up a serial console (no serial port here) or taking a screenshot? (Does the Rawhide kernel ship with LKCD?) The dump is over 1 page long, so the beginning of it will be cut off. On a slightly related topic, both the 2.6.12-1.1398_FC4 kernel from FC4 updates and the new 2.6.12-1.1482_FC5 are very noisy when the optical drive is empty - I get this repeatedly: ATAPI device hdc: Error: Not ready -- (Sense key=0x02) Incompatible medium installed -- (asc=0x30, ascq=0x00) The failed "Read Cd/Dvd Capacity" packet command was: "25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " The original 2.6.11 FC4 kernel was curiously quiet. Logging off to take a screenshot of that pesky panic. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From msalim at cs.indiana.edu Sat Aug 13 22:11:13 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Sat, 13 Aug 2005 17:11:13 -0500 Subject: tomorrows rawhide kernel. In-Reply-To: References: <20050813035724.GA21199@redhat.com> Message-ID: <1123971073.3455.13.camel@salem> On Sat, 2005-08-13 at 15:19 -0400, Neal Becker wrote: > Would this kernel be expected to work on an update FC4 environment (current > FC4 but no devel)? My Compaq r3000z has never suspended, and I'd like to > see if this would do the trick. > You can try doing yum --enablerepo=development install kernel . It'd pull in glibc, initrd, etc. needed by the new kernel, but those should hopefully be stable enough. > If it works, will this be pushed to FC4? (please?) > That'd be nice :) By the way, will be interested to know how it works on your laptop, I have a similar model (HP L2000) with the AMD Turion instead of Athlon 64, and it just panicked on me when suspending. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Sat Aug 13 22:27:58 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sat, 13 Aug 2005 23:27:58 +0100 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <1123972079.4487.4.camel@localhost> Hi, > - We haven't tried doing this with X running :) Works fine on this box. Okay, evolution took a bit longer to fire up, but the compile I was part way through doing just restarted and the binary works okay - so it's thumbs up from this side. TTFN Paul -- "Some people will do anything for a woman in uniform" - The Doctor - Unregenerate (Big Finish audio) From kyrre at solution-forge.net Sat Aug 13 22:28:44 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 14 Aug 2005 00:28:44 +0200 Subject: Kernel/iptables conflict In-Reply-To: <20050813173637.GE26633@redhat.com> References: <1123946131.3355.3.camel@localhost.localdomain> <20050813173637.GE26633@redhat.com> Message-ID: <1123972123.3355.8.camel@localhost.localdomain> l?r, 13.08.2005 kl. 19.36 skrev Dave Jones: > On Sat, Aug 13, 2005 at 05:15:31PM +0200, Kyrre Ness Sjobak wrote: > > During yum update i have a conflict "kernel conflicts with iptables < > > 1.3.2-1", preventing me from updating the kernel. Has anybody else seen > > this? > > The latest iptables in rawhide is 1.3.2-1, I don't see the problem? > If you're trying to use this kernel on an older release, you'll need > to pull in a bunch of userspace updates too. Ok, The iptables dependancy > isn't that big a deal, but things like mkinitrd, initscripts, possibly > pcmciautils, udev and a bunch of other things will need changes. > I just found the bug - there where multiple instances of iptables, system-config-securitylevel(-tui) installed. > > I would very much like to test a new kernel, since the last one to > > install have no working ACPI suspend (older ones do), in order to test > > if it was only a build mistake etc. > > You mean suspend to ram? I've not heard of that breaking recently. There migth be a bug then. I shall install the new kernel and test asap. > > Dave From kyrre at solution-forge.net Sat Aug 13 23:00:51 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 14 Aug 2005 01:00:51 +0200 Subject: Kernel/iptables conflict In-Reply-To: <1123972123.3355.8.camel@localhost.localdomain> References: <1123946131.3355.3.camel@localhost.localdomain> <20050813173637.GE26633@redhat.com> <1123972123.3355.8.camel@localhost.localdomain> Message-ID: <1123974050.3355.12.camel@localhost.localdomain> s?n, 14.08.2005 kl. 00.28 skrev Kyrre Ness Sjobak: > l?r, 13.08.2005 kl. 19.36 skrev Dave Jones: > > On Sat, Aug 13, 2005 at 05:15:31PM +0200, Kyrre Ness Sjobak wrote: > > > During yum update i have a conflict "kernel conflicts with iptables < > > > 1.3.2-1", preventing me from updating the kernel. Has anybody else seen > > > this? > > > > The latest iptables in rawhide is 1.3.2-1, I don't see the problem? > > If you're trying to use this kernel on an older release, you'll need > > to pull in a bunch of userspace updates too. Ok, The iptables dependancy > > isn't that big a deal, but things like mkinitrd, initscripts, possibly > > pcmciautils, udev and a bunch of other things will need changes. > > > > I just found the bug - there where multiple instances of iptables, > system-config-securitylevel(-tui) installed. > > > > I would very much like to test a new kernel, since the last one to > > > install have no working ACPI suspend (older ones do), in order to test > > > if it was only a build mistake etc. > > > > You mean suspend to ram? I've not heard of that breaking recently. > > There migth be a bug then. I shall install the new kernel and test asap. I installed the newest kernel (2.6.12-1.1482_FC5), and it still doesnt work: /proc/acpi/sleep (or any files in /proc/acpi) doesn't exist. So it is a bit hard to put it in suspend :) Nevertheless, the battery meter/charge indicator in the gnome panel works without a hitch... Kyrre From davej at redhat.com Sat Aug 13 23:03:33 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 19:03:33 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1123970912.3455.8.camel@salem> References: <20050813035724.GA21199@redhat.com> <1123913440.31859.9.camel@salem> <20050813162440.GB24903@redhat.com> <1123970912.3455.8.camel@salem> Message-ID: <20050813230333.GA3172@redhat.com> On Sat, Aug 13, 2005 at 05:08:31PM -0500, Michel Alexandre Salim wrote: > On Sat, 2005-08-13 at 12:24 -0400, Dave Jones wrote: > > On Sat, Aug 13, 2005 at 01:10:40AM -0500, Michel Alexandre Salim wrote: > > > On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > > > > As the rawhide kernel has been pretty boring and uneventful > > > > so far, this last day or two, Jeremy Katz and I managed to > > > > beat suspend to disk support into shape. > > > > > > > [snip] > > > Great! It works with swap-on-LVM, I assume? > > > > Worked for me :-) > > > Tried it just now and I encountered a kernel panic while suspending from > the GNOME desktop, using the x86_64 kernel. Switching to console before doing the suspend is advisable. The pm-hibernate script from pmutils will do this automatically. > Is there a good way to get to the kernel dump, short of hooking up a > serial console (no serial port here) or taking a screenshot? (Does the > Rawhide kernel ship with LKCD?) The dump is over 1 page long, so the > beginning of it will be cut off. If you boot with something like vga=791 you'll fit more lines on the screen, so you should be able to capture it all. > On a slightly related topic, both the 2.6.12-1.1398_FC4 kernel from FC4 > updates and the new 2.6.12-1.1482_FC5 are very noisy when the optical > drive is empty - I get this repeatedly: > > ATAPI device hdc: > Error: Not ready -- (Sense key=0x02) > Incompatible medium installed -- (asc=0x30, ascq=0x00) > The failed "Read Cd/Dvd Capacity" packet command was: > "25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " The CD or IDE code has had some kind of accident in 2.6.13rc it seems. I can trivially make it hang the box by feeding it an audio CD. Sadly, its just a total hang rather than something useful. That you get the above msg repeatedly could be something trying to poll the device whilst its empty (probably hal daemon). Why its become so noisy when earlier kernels weren't is a mystery to me right now. Dave From davej at redhat.com Sat Aug 13 23:06:29 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 19:06:29 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: References: <20050813035724.GA21199@redhat.com> Message-ID: <20050813230629.GB3172@redhat.com> On Sat, Aug 13, 2005 at 03:19:01PM -0400, Neal Becker wrote: > Would this kernel be expected to work on an update FC4 environment (current > FC4 but no devel)? My Compaq r3000z has never suspended, and I'd like to > see if this would do the trick. > > If it works, will this be pushed to FC4? (please?) Its very likely this will require a lot of fixing up of various drivers. I'm not going to spend the effort doing that for older kernels, so its doubtful this will end up in FC3/4. Pushing newer kernels to older releases causes lots of headaches as it always seems to need more and more updates for various bits of userspace. Finally, judging by the early reports, its nowhere near stable enough for a release kernel yet. Given that we're at least six months away from FC5 release, there's quite a bit of time to beat it into shape for at least the more common hardware out there. Dave From davej at redhat.com Sat Aug 13 23:08:52 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 19:08:52 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1123964280.3997.6.camel@daxter.boston.redhat.com> References: <20050813035724.GA21199@redhat.com> <1123964280.3997.6.camel@daxter.boston.redhat.com> Message-ID: <20050813230852.GC3172@redhat.com> On Sat, Aug 13, 2005 at 04:18:00PM -0400, David Zeuthen wrote: > On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > > As the rawhide kernel has been pretty boring and uneventful > > so far, this last day or two, Jeremy Katz and I managed to > > beat suspend to disk support into shape. > > This works nicely for me on a IBM Thinkpad T41 (even from within X) but > not so nice on my 12" Powerbook G4. > > So, digging into the issue it appears that CONFIG_SOFTWARE_SUSPEND is > not set on ppc kernels... I've seem to read somewhere that swsup is > supposed to work on ppc (since it's basically all in software), any > chance that a) this is true; and b) we can get the same user experience > on ppc? Interesting, I'm sure I read that it didn't work on ppc. I'll flip it on in the next build. Let me know how it works out. Dave From davej at redhat.com Sat Aug 13 23:11:40 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 13 Aug 2005 19:11:40 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1123972079.4487.4.camel@localhost> References: <20050813035724.GA21199@redhat.com> <1123972079.4487.4.camel@localhost> Message-ID: <20050813231140.GD3172@redhat.com> On Sat, Aug 13, 2005 at 11:27:58PM +0100, Paul F. Johnson wrote: > Hi, > > > - We haven't tried doing this with X running :) > > Works fine on this box. Okay, evolution took a bit longer to fire up, Before it suspends it throws away all the page cache and other non-essential stuff from memory, so that it suspends/resumes quickly, so this is to be expected. > but the compile I was part way through doing just restarted and the > binary works okay - so it's thumbs up from this side. good to hear ;) Dave From msalim at cs.indiana.edu Sun Aug 14 00:41:50 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Sat, 13 Aug 2005 19:41:50 -0500 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813230333.GA3172@redhat.com> References: <20050813035724.GA21199@redhat.com> <1123913440.31859.9.camel@salem> <20050813162440.GB24903@redhat.com> <1123970912.3455.8.camel@salem> <20050813230333.GA3172@redhat.com> Message-ID: <1123980110.3191.7.camel@salem> On Sat, 2005-08-13 at 19:03 -0400, Dave Jones wrote: > > Tried it just now and I encountered a kernel panic while suspending from > > the GNOME desktop, using the x86_64 kernel. > > Switching to console before doing the suspend is advisable. > The pm-hibernate script from pmutils will do this automatically. > It does not make a difference in my case. > If you boot with something like vga=791 you'll fit more lines > on the screen, so you should be able to capture it all. > Surprisingly, this /does/ make a difference. In both cases (well, six - tried it at runlevels 3 (no RHGB, so the ATI proprietary driver never was loaded), 5 (switched to console) and 5 (graphical), the computer never turned itself off, but without vga=791 I get more error messages. See bugzilla #165911: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165911 Wonder what it could be. Note that I always have to pass the option 'no_timer_check' to the kernel, otherwise > 50% CPU is gobbled by hardware and software interrupts and the clock runs super-fast (and processes super-slow) - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From johnp at redhat.com Sun Aug 14 01:51:57 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 13 Aug 2005 21:51:57 -0400 Subject: dbus-qt In-Reply-To: <42FE697C.7000505@develer.com> References: <200503051737.02475.ml-fedora@fathomssen.de> <1110043263.2451.35.camel@localhost.localdomain> <42E45D67.8020702@math.unl.edu> <42E58B22.8070806@develer.com> <42FE697C.7000505@develer.com> Message-ID: <1123984317.5383.25.camel@localhost.localdomain> Will build it in rawhide on monday. On Sat, 2005-08-13 at 23:43 +0200, Bernardo Innocenti wrote: > Bernardo Innocenti wrote: > > > Rex Dieter wrote: > >>John (J5) Palmieri wrote: > >>>On Sat, 2005-03-05 at 11:37, Frederick Alexander Thomssen wrote: > >> > >>>>once dbus-qt was removed from fedora because there was no use for it. > >>>>but now kde 3.4 supports dbus-qt for the media:/ protocol which > >>>>indicated if a new device was connected. so there now is a use for > >>>>dbus-qt so i think it ought to be included. > >>> > >>>Does an app in fedora core require it? > >> > >>k3b (v0.12+), at least, can use it, if available. > > > > For the record, I've hacked dbus.spec to re-enable > > Qt support, updating references to Qt 3.1 to 3.3). > > > > The resulting dbus-qt subpackage builds and installs > > correctly. KDE builds fine against it with a small > > configury patch to look for libraries in /usr/lib64 > > on x86_64. > > > > Now I can use media:/ in Konqueror. Looks like a > > safe change for fedora-devel. > > As of today dbus-qt is still disabled in Fedora. The > attached patch is enough to get it to build. > > I've rebuilt KDE from CVS and I can confirm media:/ works > and removable devices are correctly detected, but not > automounted. > > -- > // Bernardo Innocenti - Develer S.r.l., R&D dept. > \X/ http://www.develer.com/ > -- John (J5) Palmieri From riel at redhat.com Sun Aug 14 04:12:43 2005 From: riel at redhat.com (Rik van Riel) Date: Sun, 14 Aug 2005 00:12:43 -0400 (EDT) Subject: tomorrows rawhide kernel. In-Reply-To: <20050813162858.GC24903@redhat.com> References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> <20050813162858.GC24903@redhat.com> Message-ID: On Sat, 13 Aug 2005, Dave Jones wrote: > > Why not an swap file or just an regular suspend file? [2] > > I never tested swapfiles, but it *should* work. Are you sure? I don't understand how the suspend software would be able to resume from a swapfile without first mounting the root filesystem (which upsets the ext3 journal state in the written out memory). -- All Rights Reversed From davej at redhat.com Sun Aug 14 06:13:59 2005 From: davej at redhat.com (Dave Jones) Date: Sun, 14 Aug 2005 02:13:59 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> <20050813162858.GC24903@redhat.com> Message-ID: <20050814061359.GA5231@redhat.com> On Sun, Aug 14, 2005 at 12:12:43AM -0400, Rik van Riel wrote: > On Sat, 13 Aug 2005, Dave Jones wrote: > > > > Why not an swap file or just an regular suspend file? [2] > > > > I never tested swapfiles, but it *should* work. > > Are you sure? > > I don't understand how the suspend software would be able > to resume from a swapfile without first mounting the root > filesystem (which upsets the ext3 journal state in the > written out memory). Gack. I clearly never thought that through at all :) You're absolutely correct. Dave From bart.vanbrabant at zoeloelip.be Sun Aug 14 07:52:45 2005 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Sun, 14 Aug 2005 09:52:45 +0200 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <42FEF84D.1020204@zoeloelip.be> Dave Jones wrote: >As the rawhide kernel has been pretty boring and uneventful >so far, this last day or two, Jeremy Katz and I managed to >beat suspend to disk support into shape. > >The current rawhide kernel (2.6.12-1.1482 and above) now has >suspend to disk support enabled using the in-kernel software suspend. >At this early stage, play with this at your own risk! Doing the wrong >things (or even the right things at the wrong time) can result in >irrecoverable data loss. > >If the above warning hasn't put you off testing, you're probably >wondering how to play with this potential datamuncher. > >1. Make sure you have a swap partition. >(if you have >1, it'll only use the first one, so make sure > its at least as big as your RAM). Whilst suspend does evict > some non-essential things from memory before it suspends, > it can still end up with quite a bit to write out. > >2. Make sure the swap partition is enabled. >(cat /proc/swaps if you're unsure) > >3. >echo platform > /sys/power/disk >echo disk > /sys/power/state > >(This will all be done in a much more user friendly way for the FC5 release) > >4. Stare at the gobs of info scrolling up the screen. >(This will all be cleared up eventually, but for now it's >potentially useful for debugging). > >5. After a while, your computer should turn itself off. >When you turn it back on, the initrd will detect the resume >partition and attempt to resume from it. > >Then presto, you're back where you were. > > > >Some caveats noted so far: > >- Some device drivers don't wake up correctly. >So things like your ethernet may need an rmmod/modprobe after >resuming, to get things working again until the driver gets fixed. >Please report these types of bugs. > >- *NEVER*, *EVER*, write into /sys/power/resume after you've booted. >This is going to have to be made safe at some point. Right now, doing >that whilst you've got partitions mounted is a guaranteed way to say >goodbye to some files. The good news, is that this is the only >way I've found so far to corrupt data. > >- If you suspend and then don't go back into the same kernel, you won't be > able to resume and your swap won't be initialized. Be sure that you run > mkswap on your swap partition before booting back to the swsusp kernel. > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165863) > >- Swap that's referenced with LABEL= in /etc/fstab doesn't currently work for > resume. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165864) > >- We haven't tried doing this with X running :) It's likely to work better if > you switch to a tty first. > >- Swap on RAID devices *should* work, but is untested so far. > >- Changing hardware (adding/removing PCI cards/CPUs etc) is going to bring >you a world of pain. swsusp does detect some of the simpler cases >and will refuse to resume if the amount of RAM differs etc, but some >others won't be detected. In particular things like USB could be >problematic. > >- If you suspend and then want to boot normally (ie, without resuming), add > "noresume" to your boot command line. > >Finally, hopefully this will work out, and we'll get whatever bugs turn >up squished quickly. However at this point, there's no guarantee that >this will make it into FC5. It all depends on user feedback. >So test, and report any bugs in bugzilla. And if by some miracle it >all works perfectly for you, we'd love to hear success stories too >on fedora-devel list. > > Dave > > > It works on my laptop. An Asus LD5800 with an athlon 64 proc but running x86 fedora. I've suspended twice from gnome, one time without a flaw but the second time my X went crazy. My screen jumped a bit to the right. So the edge of my screen was somewhere on my screen but my mouse wasn't. So I had to guess where I should click. When I just changed my resolution with the utility in preferences my screen was normal for a short period. After I killed X everything worked again. I use driverloader to get my wireless to work. The run a process to be able to configure you're card with you're browser. That process made the kernel panic. When I stop the process it works fine. Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rhl-devel-list at lnx.ro Sun Aug 14 09:29:16 2005 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Sun, 14 Aug 2005 12:29:16 +0300 Subject: tomorrows rawhide kernel. In-Reply-To: References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> <20050813162858.GC24903@redhat.com> Message-ID: <1124011756.2554.32.camel@localhost> ?n data de Du, 14-08-2005 la 00:12 -0400, Rik van Riel a scris: > On Sat, 13 Aug 2005, Dave Jones wrote: > > > > Why not an swap file or just an regular suspend file? [2] > > > > I never tested swapfiles, but it *should* work. > > Are you sure? > > I don't understand how the suspend software would be able > to resume from a swapfile without first mounting the root > filesystem (which upsets the ext3 journal state in the > written out memory). I don't exactly in the know of the innards of suspend2 but this is the source that does exaclty that (suspend to file): http://cioby.lnx.ro/suspend_file.c (taken from the suspend2 patches so you don't have to download the whole tarball). -- Cioby From nman64 at n-man.com Sun Aug 14 10:04:32 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 14 Aug 2005 05:04:32 -0500 Subject: Now Seeking Guinea Pigs (Mentors) Message-ID: <42FF1730.1080405@n-man.com> Following recent discussions, the Mentors page on the wiki was created recently. It did little more than list where potential contributors might go. I have moved that information to the HelpWanted page, cleaned it up, and created new content for the Mentors page. As part of doing so, I have started the list of volunteer mentors on that page. http://fedoraproject.org/wiki/Mentors If you would be willing to mentor new contributors to Fedora, please consider adding yourself to that list. Hopefully, having such an open list will work out. This will be a list that curious contributors can select mentors from. Please be careful and descriptive in your listing. Please keep in mind that if you are bombarded with requests, you are free to remove your name from the list, but we need to try to manage requests to keep that from happening. As the list grows, if you are getting more requests than you can handle, please try to pass requests along to other, less-bombarded mentors rather than unleash your wrath on new contributors. I have posted this message to fedora-devel-list, fedora-extras-list, fedora-marketing-list, and fedora-docs-list. Please don't shoot me, we need all the mentors we can get from every facet of the Project. http://fedoraproject.org/wiki/Mentors -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From buildsys at redhat.com Sun Aug 14 11:25:36 2005 From: buildsys at redhat.com (Build System) Date: Sun, 14 Aug 2005 07:25:36 -0400 Subject: rawhide report: 20050814 changes Message-ID: <200508141125.j7EBPap5017191@porkchop.devel.redhat.com> Updated Packages: booty-0.56-1 ------------ * Sat Aug 13 2005 Peter Jones 0.56-1 - Even more ppc/yaboot fixes. checkpolicy-1.25.8-2 -------------------- * Sat Aug 13 2005 Dan Walsh 1.25.8-2 - Rebuild to get latest libsepol changes elfutils-0.113-2 ---------------- * Sat Aug 13 2005 Roland McGrath - 0.113-2 - update to 0.113 - elflint: relax a bit. Allow version definitions for defined symbols against DSO versions also for symbols in nobits sections. Allow .rodata section to have STRINGS and MERGE flag set. - strip: add some more compatibility with binutils. - libdwfl: bug fixes. - Separate libdw et al into elfutils-libs subpackage. gnome-utils-1:2.11.91-2 ----------------------- * Sat Aug 13 2005 Ray Strode 1:2.11.91-2 - Reenable log viewer (bug 163260) - add buildreqs for flex/bison kernel-2.6.12-1.1483_FC5 ------------------------ * Sat Aug 13 2005 Dave Jones - 2.6.13-rc6-git5 libsepol-1.7.14-1 ----------------- * Sat Aug 13 2005 Dan Walsh 1.7.14-1 - Upgrade to latest from NSA * Fixed empty list test in cond_write_av_list. Bug found by Coverity, reported by Serge Hallyn (IBM). * Merged patch to policydb_write to check errors when writing the type->attribute reverse map from Serge Hallyn (IBM). Bug found by Coverity. * Fixed policydb_destroy to properly handle NULL type_attr_map or attr_type_map. Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ppc64 ---------------------------------------------------------- ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 firstboot - 1.3.44-1.noarch requires system-config-display system-config-keyboard - 1.2.6-2.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) gnome-python2-totem - 2.11.4-5.ppc64 requires mozilla >= 0:1.7.3 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390x ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) Broken deps for s390 ---------------------------------------------------------- selinux-policy-targeted-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 selinux-policy-targeted - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 selinux-policy-strict-sources - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 selinux-policy-strict - 1.25.4-1.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 From dhollis at davehollis.com Sun Aug 14 11:31:59 2005 From: dhollis at davehollis.com (David Hollis) Date: Sun, 14 Aug 2005 07:31:59 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1123964280.3997.6.camel@daxter.boston.redhat.com> References: <20050813035724.GA21199@redhat.com> <1123964280.3997.6.camel@daxter.boston.redhat.com> Message-ID: <1124019119.5356.3.camel@dhollis-lnx.sunera.com> On Sat, 2005-08-13 at 16:18 -0400, David Zeuthen wrote: > On Fri, 2005-08-12 at 23:57 -0400, Dave Jones wrote: > > As the rawhide kernel has been pretty boring and uneventful > > so far, this last day or two, Jeremy Katz and I managed to > > beat suspend to disk support into shape. > > This works nicely for me on a IBM Thinkpad T41 (even from within X) but > not so nice on my 12" Powerbook G4. > Seems to work fine on my IBM Thinkpad T42 as well. X was running, wireless (ipw2200), etc. No USB devices were plugged in at the time. -- 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 wrrhdev at riede.org Sun Aug 14 13:44:06 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sun, 14 Aug 2005 13:44:06 +0000 Subject: tomorrows rawhide kernel. In-Reply-To: <20050814061359.GA5231@redhat.com> (from davej@redhat.com on Sun Aug 14 02:13:59 2005) References: <20050813035724.GA21199@redhat.com> <1123914378.2554.21.camel@localhost> <20050813162858.GC24903@redhat.com> Message-ID: <1124027046l.3920l.5l@serve.riede.org> On 08/14/2005 02:13:59 AM, Dave Jones wrote: > On Sun, Aug 14, 2005 at 12:12:43AM -0400, Rik van Riel wrote: > > On Sat, 13 Aug 2005, Dave Jones wrote: > > > > > > Why not an swap file or just an regular suspend file? [2] > > > > > > I never tested swapfiles, but it *should* work. > > > > Are you sure? > > > > I don't understand how the suspend software would be able > > to resume from a swapfile without first mounting the root > > filesystem (which upsets the ext3 journal state in the > > written out memory). > > Gack. I clearly never thought that through at all :) > You're absolutely correct. Can it do that mount ext2, ro, and avoid that effect? Regards, Willem Riede. From alan at redhat.com Sun Aug 14 18:35:07 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 14 Aug 2005 14:35:07 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813230852.GC3172@redhat.com> References: <20050813035724.GA21199@redhat.com> <1123964280.3997.6.camel@daxter.boston.redhat.com> <20050813230852.GC3172@redhat.com> Message-ID: <20050814183507.GA1642@devserv.devel.redhat.com> On Sat, Aug 13, 2005 at 07:08:52PM -0400, Dave Jones wrote: > Interesting, I'm sure I read that it didn't work on ppc. > I'll flip it on in the next build. Let me know how it works out. Probably as well as on PC - read - you can easily lose all your data. We don't support SATA or SCSI suspend and the PATA suspend/resume code is not complete. So don't suspend unless your box is running on ramdisk only quite honestly, or for "research purposes" From bernie at develer.com Mon Aug 15 01:45:32 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Mon, 15 Aug 2005 03:45:32 +0200 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <42FFF3BC.6080106@develer.com> Dave Jones wrote: > 3. > echo platform > /sys/power/disk > echo disk > /sys/power/state Resuming fails on my x86_64 box. Just after reading memory back from the swap partition, the machine reboots spontaneously and I'm back in the BIOS screen. Also, at suspend time, it seems the USB modules get reloaded just before powering off the system. Is this to be expected? # lspci 00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) 01:00.1 Display controller: ATI Technologies Inc: Unknown device 5940 (rev 01) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From sean.bruno at dsl-only.net Mon Aug 15 05:34:21 2005 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 14 Aug 2005 22:34:21 -0700 Subject: tomorrows rawhide kernel. In-Reply-To: <42FFF3BC.6080106@develer.com> References: <20050813035724.GA21199@redhat.com> <42FFF3BC.6080106@develer.com> Message-ID: <1124084061.3113.9.camel@home-lap> Anyone try this on a Dell Latitude D800, or would you all like me to break my home machine for this purpose? Sean From pbrobinson at gmail.com Mon Aug 15 06:19:28 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 15 Aug 2005 07:19:28 +0100 Subject: tomorrows rawhide kernel. In-Reply-To: <1124084061.3113.9.camel@home-lap> References: <20050813035724.GA21199@redhat.com> <42FFF3BC.6080106@develer.com> <1124084061.3113.9.camel@home-lap> Message-ID: <5256d0b05081423199bd3697@mail.gmail.com> On 8/15/05, Sean Bruno wrote: > Anyone try this on a Dell Latitude D800, or would you all like me to > break my home machine for this purpose? I was thinking of doing this on my D600 (which I think is of similar age/spec just minus the wide screen) so I'd love to here how you go. Pete From paul at all-the-johnsons.co.uk Mon Aug 15 09:39:15 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 15 Aug 2005 10:39:15 +0100 Subject: tomorrows rawhide kernel. In-Reply-To: <20050813035724.GA21199@redhat.com> References: <20050813035724.GA21199@redhat.com> Message-ID: <1124098755.5155.32.camel@localhost> Hi, > As the rawhide kernel has been pretty boring and uneventful > so far, this last day or two, Jeremy Katz and I managed to > beat suspend to disk support into shape. There have been a couple of updates in rawhide since this original announcement. I have suspend enabled on the 1482_FC5 kernel, will this propogate to the newer kernels automatically? TTFN Paul -- "Some people will do anything for a woman in uniform" - The Doctor - Unregenerate (Big Finish audio) From buildsys at redhat.com Mon Aug 15 11:24:16 2005 From: buildsys at redhat.com (Build System) Date: Mon, 15 Aug 2005 07:24:16 -0400 Subject: rawhide report: 20050815 changes Message-ID: <200508151124.j7FBOGh7002572@porkchop.devel.redhat.com> Updated Packages: checkpolicy-1.25.8-3 -------------------- * Sun Aug 14 2005 Dan Walsh 1.25.8-3 - Rebuild to get latest libsepol changes glib2-2.8.0-1 ------------- * Sat Aug 13 2005 Matthias Clasen - 2.8.0-1 - New stable upstream version - Drop patches kdegraphics-7:3.4.2-1 --------------------- * Thu Aug 11 2005 Than Ngo 7:3.4.2-1 - update to 3.4.2 kernel-2.6.12-1.1485_FC5 ------------------------ * Sun Aug 14 2005 Dave Jones - 2.6.13-rc6-git6 libsepol-1.7.15-1 ----------------- * Sun Aug 14 2005 Dan Walsh 1.7.15-1 - Upgrade to latest from NSA * Fixed empty list test in cond_write_av_list. Bug found by Coverity, reported by Serge Hallyn (IBM). * Merged patch to policydb_write to check errors when writing the type->attribute reverse map from Serge Hallyn (IBM). Bug found by Coverity. * Fixed policydb_destroy to properly handle NULL type_attr_map or attr_type_map. qt-1:3.3.4-21 ------------- * Mon Aug 15 2005 Than Ngo 1:3.3.4-21 - fix gcc4 build problem selinux-policy-strict-1.25.4-2 ------------------------------ * Sun Aug 14 2005 Dan Walsh 1.25.4-2 - Support for policy.20 and policy.19 selinux-policy-targeted-1.25.4-2 -------------------------------- * Sun Aug 14 2005 Dan Walsh 1.25.4-2 - Support for policy.20 and policy.19 yaboot-1.3.13-0.9 ----------------- * Sun Aug 14 2005 David Woodhouse - 1.3.13-0.9 - Try harder to allocate malloc region Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.x86_64 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.x86_64 requires kernel-smp = 0:2.6.12-1.1400_FC5 Broken deps for i386 ---------------------------------------------------------- gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel-smp = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1400_FC5xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i586 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.i686 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.i686 requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.i686 requires /lib/modules/2.6.12-1.1400_FC5 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc requires /lib/modules/2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires kernel = 0:2.6.12-1.1400_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.6.ppc requires /lib/modules/2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc requires /lib/modules/2.6.12-1.1400_FC5 Broken deps for s390 ---------------------------------------------------------- nfs-utils - 1.0.7-12.s390 requires kernel >= 0:2.2.14 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-strict - 1.25.4-2.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 selinux-policy-targeted - 1.25.4-2.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.4-2.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-2.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc64 ---------------------------------------------------------- system-config-mouse - 1.2.11-1.noarch requires pyxf86config evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.7.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 firstboot - 1.3.44-1.noarch requires system-config-display gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires kernel = 0:2.6.12-1.1400_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.39.ppc64 requires /lib/modules/2.6.12-1.1400_FC5 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) gnome-python2-totem - 2.11.4-5.ppc64 requires mozilla >= 0:1.7.3 ppc64-utils - 0.7-9.ppc64 requires yaboot Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390x ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) From pknirsch at redhat.com Mon Aug 15 13:28:36 2005 From: pknirsch at redhat.com (Phil Knirsch) Date: Mon, 15 Aug 2005 15:28:36 +0200 Subject: RFP for Extras: Grace Message-ID: <43009884.8050500@redhat.com> Hi folks! I've just stumbled across on of my ancient package requests in bugzilla. It is for Grace, a really nice data plotter similar to gnuplot but a lot more intuitive. Here the link: http://plasma-gate.weizmann.ac.il/Grace/ I played around with it quite a while ago and was really impressed, especially withe the statistics stuff you can do with it. Though i probably won't have time to take care of it i'd just wanted to mention it here so that the request doesn't vanish into oblivion. If someone feels like wanting to pick it up that would be really nice. Thanks, Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From skvidal at phy.duke.edu Mon Aug 15 13:34:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 15 Aug 2005 09:34:40 -0400 Subject: RFP for Extras: Grace In-Reply-To: <43009884.8050500@redhat.com> References: <43009884.8050500@redhat.com> Message-ID: <1124112880.17178.6.camel@cutter> On Mon, 2005-08-15 at 15:28 +0200, Phil Knirsch wrote: > Hi folks! > > I've just stumbled across on of my ancient package requests in bugzilla. > It is for Grace, a really nice data plotter similar to gnuplot but a lot > more intuitive. Here the link: > > http://plasma-gate.weizmann.ac.il/Grace/ > > I played around with it quite a while ago and was really impressed, > especially withe the statistics stuff you can do with it. > > Though i probably won't have time to take care of it i'd just wanted to > mention it here so that the request doesn't vanish into oblivion. If > someone feels like wanting to pick it up that would be really nice. We have a grace package that works with FC4 at duke. SRPM is available here: http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rpm If anyone wants to take that and run it through extras, please do. -sv From ph18 at cornell.edu Mon Aug 15 14:27:16 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 15 Aug 2005 10:27:16 -0400 Subject: RFP for Extras: Grace In-Reply-To: <1124112880.17178.6.camel@cutter> References: <43009884.8050500@redhat.com> <1124112880.17178.6.camel@cutter> Message-ID: <4300A644.1050705@cornell.edu> seth vidal wrote: >We have a grace package that works with FC4 at duke. > >SRPM is available here: > >http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rpm > >If anyone wants to take that and run it through extras, please do. > > Yeah, grace is the best interactive scientific graphing package for UNIX. I used it to do (almost) all the graphs back when I wrote physics papers. From davej at redhat.com Mon Aug 15 15:00:45 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 15 Aug 2005 11:00:45 -0400 Subject: tomorrows rawhide kernel. In-Reply-To: <1124098755.5155.32.camel@localhost> References: <20050813035724.GA21199@redhat.com> <1124098755.5155.32.camel@localhost> Message-ID: <20050815150045.GA11618@redhat.com> On Mon, Aug 15, 2005 at 10:39:15AM +0100, Paul F. Johnson wrote: > Hi, > > > As the rawhide kernel has been pretty boring and uneventful > > so far, this last day or two, Jeremy Katz and I managed to > > beat suspend to disk support into shape. > > There have been a couple of updates in rawhide since this original > announcement. I have suspend enabled on the 1482_FC5 kernel, will this > propogate to the newer kernels automatically? It's still enabled, so it should still work. What won't work is suspending on one kernel, then booting another. That will end up just doing a normal boot. We check the signature in the resume partition before we attempt to resume from it, and if anything mismatches, we abort early on. Dave From d.jacobfeuerborn at conversis.de Mon Aug 15 16:45:34 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 15 Aug 2005 18:45:34 +0200 Subject: gedit segfaults Message-ID: <4300C6AE.5040904@conversis.de> When I start gedit and click "open" the gtk file dialog pops up and then gedit immediately segfaults. I get this ouput in the shell: (gedit:3505): Gtk-CRITICAL **: gtk_file_system_path_is_local: assertion `path != NULL' failed and the following gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208428880 (LWP 3505)] 0x0055935a in ?? () from /lib/libc.so.6 (gdb) backtrace #0 0x0055935a in ?? () from /lib/libc.so.6 #1 0x02eeef8b in shortcut_find_position (impl=0xa19e8f8, path=0xa1e7c68) at gtkfilechooserdefault.c:2063 #2 0x02eef95a in shortcuts_add_bookmarks (impl=0xa19e8f8) at gtkfilechooserdefault.c:1727 #3 0x02ef7655 in gtk_file_chooser_default_set_property (object=0xa19e8f8, prop_id=4099, value=0xbf8ae538, pspec=0xa15fd88) at gtkfilechooserdefault.c:4137 #4 0x0033881e in g_object_set_property () from /usr/lib/libgobject-2.0.so.0 #5 0x02efaef3 in gtk_file_chooser_widget_set_property (object=0xa1e7c66, prop_id=4099, value=0xbf8ae608, pspec=0xa1e7c66) at gtkfilechooserwidget.c:191 #6 0x0033881e in g_object_set_property () from /usr/lib/libgobject-2.0.so.0 #7 0x02eeb513 in gtk_file_chooser_dialog_set_property (object=0xa1e7c66, prop_id=4099, value=0xbf8ae734, pspec=0xa1e7c66) at gtkfilechooserdialog.c:425 #8 0x0033c516 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0 #9 0x0033c79a in g_object_set () from /usr/lib/libgobject-2.0.so.0 #10 0x02ee418c in IA__gtk_file_chooser_set_local_only (chooser=0xa19c388, local_only=169770086) at gtkfilechooser.c:360 #11 0x0807e6e5 in run_file_selector (parent=Variable "parent" is not available. ) at gedit-file-selector-util.c:460 #12 0x08075523 in gedit_file_open (active_child=0xa0bb808) at gedit-file.c:194 #13 0x00b5c165 in bonobo_socket_add_id () from /usr/lib/libbonoboui-2.so.0 ---Type to continue, or q to quit--- #14 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0x031f3696 in bonobo_closure_invoke_va_list () from /usr/lib/libbonobo-2.so.0 #16 0x031f3984 in bonobo_closure_invoke () from /usr/lib/libbonobo-2.so.0 #17 0x00b5e63c in bonobo_ui_component_remove_listener () from /usr/lib/libbonoboui-2.so.0 #18 0x031f46b7 in _ORBIT_skel_small_Bonobo_UIComponent_execVerb () from /usr/lib/libbonobo-2.so.0 #19 0x031998bd in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0 #20 0x031f8316 in Bonobo_UIComponent_execVerb () from /usr/lib/libbonobo-2.so.0 #21 0x00b62a88 in bonobo_ui_engine_ui_event () from /usr/lib/libbonoboui-2.so.0 #22 0x00341bce in g_cclosure_marshal_VOID__POINTER () from /usr/lib/libgobject-2.0.so.0 #23 0x00335565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #24 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #25 0x0034436f in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #26 0x00345820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #27 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #28 0x00b622ad in bonobo_ui_engine_emit_verb_on_w () from /usr/lib/libbonoboui-2.so.0 #29 0x00b6b245 in bonobo_ui_sync_status_new () from /usr/lib/libbonoboui-2.so.0 #30 0x003412d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 ---Type to continue, or q to quit--- #31 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #32 0x003441e3 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #33 0x00345820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #34 0x003483c6 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #35 0x03004d4f in button_clicked (widget=0xa0a0570, button=0xa1e7c66) at gtktoolbutton.c:625 #36 0x003412d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #37 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #38 0x003441e3 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #39 0x00345820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #40 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #41 0x02e789b7 in IA__gtk_button_clicked (button=0xa0a0570) at gtkbutton.c:834 #42 0x02e7a718 in gtk_real_button_released (button=0xa0a0570) at gtkbutton.c:1369 #43 0x003412d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #44 0x00335565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #45 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #46 0x00343e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #47 0x00345820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #48 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #49 0x02e78934 in IA__gtk_button_released (button=0xa0a0570) at gtkbutton.c:826 ---Type to continue, or q to quit--- #50 0x02e79c35 in gtk_button_button_release (widget=0xa1e7c66, event=0xa14bb18) at gtkbutton.c:1262 #51 0x02f528bc in _gtk_marshal_BOOLEAN__BOXED (closure=0xa0823d8, return_value=0xbf8b0030, n_param_values=2, param_values=0xbf8b011c, invocation_hint=0xbf8b001c, marshal_data=0x2e79bf3) at gtkmarshalers.c:83 #52 0x00335565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #53 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #54 0x0034436f in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #55 0x00345593 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #56 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #57 0x0304c059 in gtk_widget_event_internal (widget=0xa0a0570, event=0xa14bb18) at gtkwidget.c:3735 #58 0x02f4fa13 in IA__gtk_propagate_event (widget=0xa0a0570, event=0xa14bb18) at gtkmain.c:2157 #59 0x02f4ff3d in IA__gtk_main_do_event (event=0xa14bb18) at gtkmain.c:1395 #60 0x00a8b95f in gdk_event_dispatch (source=0xa1e7c66, callback=0, user_data=0x0) at gdkevents-x11.c:2291 #61 0x0021c9ce in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #62 0x0021f9e6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #63 0x0021fcd3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #64 0x02f5082f in IA__gtk_main () at gtkmain.c:974 #65 0x080609e9 in main (argc=0, argv=0xbf8b0644) at gedit2.c:435 (gdb) Does anybody else have similar problems? Regards, Dennis From bart.vanbrabant at zoeloelip.be Mon Aug 15 16:52:02 2005 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Mon, 15 Aug 2005 18:52:02 +0200 Subject: gedit segfaults In-Reply-To: <4300C6AE.5040904@conversis.de> References: <4300C6AE.5040904@conversis.de> Message-ID: <4300C832.2@zoeloelip.be> Dennis Jacobfeuerborn wrote: > When I start gedit and click "open" the gtk file dialog pops up and > then gedit immediately segfaults. I get this ouput in the shell: > > (gedit:3505): Gtk-CRITICAL **: gtk_file_system_path_is_local: > assertion `path != NULL' failed > > and the following gdb backtrace: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208428880 (LWP 3505)] > 0x0055935a in ?? () from /lib/libc.so.6 > (gdb) backtrace > #0 0x0055935a in ?? () from /lib/libc.so.6 > #1 0x02eeef8b in shortcut_find_position (impl=0xa19e8f8, path=0xa1e7c68) > at gtkfilechooserdefault.c:2063 > #2 0x02eef95a in shortcuts_add_bookmarks (impl=0xa19e8f8) > at gtkfilechooserdefault.c:1727 > #3 0x02ef7655 in gtk_file_chooser_default_set_property > (object=0xa19e8f8, > prop_id=4099, value=0xbf8ae538, pspec=0xa15fd88) > at gtkfilechooserdefault.c:4137 > #4 0x0033881e in g_object_set_property () from > /usr/lib/libgobject-2.0.so.0 > #5 0x02efaef3 in gtk_file_chooser_widget_set_property (object=0xa1e7c66, > prop_id=4099, value=0xbf8ae608, pspec=0xa1e7c66) > at gtkfilechooserwidget.c:191 > #6 0x0033881e in g_object_set_property () from > /usr/lib/libgobject-2.0.so.0 > #7 0x02eeb513 in gtk_file_chooser_dialog_set_property (object=0xa1e7c66, > prop_id=4099, value=0xbf8ae734, pspec=0xa1e7c66) > at gtkfilechooserdialog.c:425 > #8 0x0033c516 in g_object_set_valist () from > /usr/lib/libgobject-2.0.so.0 > #9 0x0033c79a in g_object_set () from /usr/lib/libgobject-2.0.so.0 > #10 0x02ee418c in IA__gtk_file_chooser_set_local_only (chooser=0xa19c388, > local_only=169770086) at gtkfilechooser.c:360 > #11 0x0807e6e5 in run_file_selector (parent=Variable "parent" is not > available. > ) at gedit-file-selector-util.c:460 > #12 0x08075523 in gedit_file_open (active_child=0xa0bb808) at > gedit-file.c:194 > #13 0x00b5c165 in bonobo_socket_add_id () from > /usr/lib/libbonoboui-2.so.0 > ---Type to continue, or q to quit--- > #14 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #15 0x031f3696 in bonobo_closure_invoke_va_list () > from /usr/lib/libbonobo-2.so.0 > #16 0x031f3984 in bonobo_closure_invoke () from /usr/lib/libbonobo-2.so.0 > #17 0x00b5e63c in bonobo_ui_component_remove_listener () > from /usr/lib/libbonoboui-2.so.0 > #18 0x031f46b7 in _ORBIT_skel_small_Bonobo_UIComponent_execVerb () > from /usr/lib/libbonobo-2.so.0 > #19 0x031998bd in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0 > #20 0x031f8316 in Bonobo_UIComponent_execVerb () from > /usr/lib/libbonobo-2.so.0 > #21 0x00b62a88 in bonobo_ui_engine_ui_event () from > /usr/lib/libbonoboui-2.so.0 > #22 0x00341bce in g_cclosure_marshal_VOID__POINTER () > from /usr/lib/libgobject-2.0.so.0 > #23 0x00335565 in g_cclosure_new_swap () from > /usr/lib/libgobject-2.0.so.0 > #24 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #25 0x0034436f in g_signal_stop_emission () from > /usr/lib/libgobject-2.0.so.0 > #26 0x00345820 in g_signal_emit_valist () from > /usr/lib/libgobject-2.0.so.0 > #27 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #28 0x00b622ad in bonobo_ui_engine_emit_verb_on_w () > from /usr/lib/libbonoboui-2.so.0 > #29 0x00b6b245 in bonobo_ui_sync_status_new () from > /usr/lib/libbonoboui-2.so.0 > #30 0x003412d3 in g_cclosure_marshal_VOID__VOID () > from /usr/lib/libgobject-2.0.so.0 > ---Type to continue, or q to quit--- > #31 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #32 0x003441e3 in g_signal_stop_emission () from > /usr/lib/libgobject-2.0.so.0 > #33 0x00345820 in g_signal_emit_valist () from > /usr/lib/libgobject-2.0.so.0 > #34 0x003483c6 in g_signal_emit_by_name () from > /usr/lib/libgobject-2.0.so.0 > #35 0x03004d4f in button_clicked (widget=0xa0a0570, button=0xa1e7c66) > at gtktoolbutton.c:625 > #36 0x003412d3 in g_cclosure_marshal_VOID__VOID () > from /usr/lib/libgobject-2.0.so.0 > #37 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #38 0x003441e3 in g_signal_stop_emission () from > /usr/lib/libgobject-2.0.so.0 > #39 0x00345820 in g_signal_emit_valist () from > /usr/lib/libgobject-2.0.so.0 > #40 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #41 0x02e789b7 in IA__gtk_button_clicked (button=0xa0a0570) at > gtkbutton.c:834 > #42 0x02e7a718 in gtk_real_button_released (button=0xa0a0570) > at gtkbutton.c:1369 > #43 0x003412d3 in g_cclosure_marshal_VOID__VOID () > from /usr/lib/libgobject-2.0.so.0 > #44 0x00335565 in g_cclosure_new_swap () from > /usr/lib/libgobject-2.0.so.0 > #45 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #46 0x00343e39 in g_signal_stop_emission () from > /usr/lib/libgobject-2.0.so.0 > #47 0x00345820 in g_signal_emit_valist () from > /usr/lib/libgobject-2.0.so.0 > #48 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #49 0x02e78934 in IA__gtk_button_released (button=0xa0a0570) at > gtkbutton.c:826 > ---Type to continue, or q to quit--- > #50 0x02e79c35 in gtk_button_button_release (widget=0xa1e7c66, > event=0xa14bb18) > at gtkbutton.c:1262 > #51 0x02f528bc in _gtk_marshal_BOOLEAN__BOXED (closure=0xa0823d8, > return_value=0xbf8b0030, n_param_values=2, param_values=0xbf8b011c, > invocation_hint=0xbf8b001c, marshal_data=0x2e79bf3) at > gtkmarshalers.c:83 > #52 0x00335565 in g_cclosure_new_swap () from > /usr/lib/libgobject-2.0.so.0 > #53 0x00335b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #54 0x0034436f in g_signal_stop_emission () from > /usr/lib/libgobject-2.0.so.0 > #55 0x00345593 in g_signal_emit_valist () from > /usr/lib/libgobject-2.0.so.0 > #56 0x00345b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #57 0x0304c059 in gtk_widget_event_internal (widget=0xa0a0570, > event=0xa14bb18) > at gtkwidget.c:3735 > #58 0x02f4fa13 in IA__gtk_propagate_event (widget=0xa0a0570, > event=0xa14bb18) > at gtkmain.c:2157 > #59 0x02f4ff3d in IA__gtk_main_do_event (event=0xa14bb18) at > gtkmain.c:1395 > #60 0x00a8b95f in gdk_event_dispatch (source=0xa1e7c66, callback=0, > user_data=0x0) at gdkevents-x11.c:2291 > #61 0x0021c9ce in g_main_context_dispatch () from > /usr/lib/libglib-2.0.so.0 > #62 0x0021f9e6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 > #63 0x0021fcd3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > #64 0x02f5082f in IA__gtk_main () at gtkmain.c:974 > #65 0x080609e9 in main (argc=0, argv=0xbf8b0644) at gedit2.c:435 > (gdb) > > Does anybody else have similar problems? > > Regards, > Dennis > It's already in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165712 -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bernd.bartmann at gmail.com Mon Aug 15 17:19:33 2005 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Mon, 15 Aug 2005 19:19:33 +0200 Subject: Yet again: several missing update announcements Message-ID: <6c18a4f050815101951157715@mail.gmail.com> Hi, is there a problem with the fedora-announce mailing list? Last week several updates for FC3 and FC4 appeared on the mirrors but again some of them were never announced. Since the final release of FC4 the situation got a lot better and I thought the problem is now gone once and for all times but now the trouble is back again. Here is the list of all missing announcement for FC3 and FC4: FC4: released 2005-08-13: gaim-1.5.0-1.fc4 gstreamer-plugins-0.8.8-9 released 2005-08-12: audit-1.0.2-3.FC4 evolution-2.2.3-2.fc4 kdeedu-3.4.2-0.fc4.2 mc-4.6.1a-0.11.FC4 vnc-4.1.1-10.1 released 2005-08-11: evolution-data-server-1.2.3-2.fc4 pygtk2-2.6.2-0.fc4.1 released 2005-08-10: cups-1.1.23-15.1 kdepim-3.4.2-0.fc4.3 metacity-2.10.3-1 netpbm-10.28-1.FC4.2 shadow-utils-4.0.7-10.FC4 xpdf-3.00-20.FC4.2 FC3: released 2005-08-13: gaim-1.5.0-1.fc3 system-config-netboot-0.1.26-1_FC3 released 2005-08-12: evolution-2.0.4-6 kdeedu-3.4.2-0.fc3.2 mc-4.6.1-1.FC3 vim-6.3.086-0.fc3.1 released 2005-08-11: arts-1.4.2-0.fc3.3 released 2005-08-10: arts-1.4.2-0.fc3.2 cups-1.1.22-0.rc1.8.6 kde-i18n-3.4.2-0.fc3.1 kdeaddons-3.4.2-0.fc3.1 kdeadmin-3.4.2-0.fc3.1 kdeartwork-3.4.2-0.fc3.1 kdebase-3.4.2-0.fc3.2 kdebindings-3.4.2-0.fc3.1 kdeedu-3.4.2-0.fc3.1 kdegames-3.4.2-0.fc3.1 kdegraphics-3.4.2-0.fc3.1 kdelibs-3.4.2-0.fc3.2 kdemultimedia-3.4.2-0.fc3.1 kdenetwork-3.4.2-0.fc3.1 kdepim-3.4.2-0.fc3.1 kdesdk-3.4.2-0.fc3.2 kdetoys-3.4.2-0.fc3.1 kdeutils-3.4.2-0.fc3.1 kdevelop-3.2.2-0.fc3.1 kdewebdev-3.4.2-0.fc3.1 koffice-1.4.1-0.FC3.2 netpbm-10.28-1.FC3.2 xpdf-3.00-10.6.FC3 Best regards, Bernd. From lukasz at wsisiz.edu.pl Mon Aug 15 18:09:10 2005 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Mon, 15 Aug 2005 20:09:10 +0200 (CEST) Subject: Duplicates packages on x86_64 Message-ID: Hello I have fresh FC4 instalation on x86_64 machine. I would like to erase some packages, but when I try do: oceanic:~# rpm -e zlib error: "zlib" specifies multiple packages ok, we have packages for both arch: oceanic:~# rpm -q --queryformat "%{ARCH}\n" zlib i386 x86_64 ok, a i can try do done something like this: rpm -e zlib --allmatches - it's works but erase only one packeges, probably for only one arch. After this, I haven't packages on rpm databes oceanic:~# rpm -qa zlib |wc -l 0 but i have binary files on filesystem. How to repair my rpm databes? I have used --allmatches option for some about 200 packages :/ Any sugestion? -- ?T From eric.tanguy at univ-nantes.fr Mon Aug 15 18:44:15 2005 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 15 Aug 2005 20:44:15 +0200 Subject: RFP for Extras: Grace In-Reply-To: <1124112880.17178.6.camel@cutter> References: <43009884.8050500@redhat.com> <1124112880.17178.6.camel@cutter> Message-ID: <1124131455.12203.9.camel@bureau.maison> Le lundi 15 ao?t 2005 ? 09:34 -0400, seth vidal a ?crit : > On Mon, 2005-08-15 at 15:28 +0200, Phil Knirsch wrote: > > Hi folks! > > > > I've just stumbled across on of my ancient package requests in bugzilla. > > It is for Grace, a really nice data plotter similar to gnuplot but a lot > > more intuitive. Here the link: > > > > http://plasma-gate.weizmann.ac.il/Grace/ > > > > I played around with it quite a while ago and was really impressed, > > especially withe the statistics stuff you can do with it. > > > > Though i probably won't have time to take care of it i'd just wanted to > > mention it here so that the request doesn't vanish into oblivion. If > > someone feels like wanting to pick it up that would be really nice. > > We have a grace package that works with FC4 at duke. > > SRPM is available here: > > http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rpm > > If anyone wants to take that and run it through extras, please do. > > -sv > I tried this src package but i need PDFlib-Lite-devel that i can't find in any repo for fc4. could you tell me where to find it ? Thanks -- Eric Tanguy | Nantes, France Key : A4B8368F | Key Server : subkeys.pgp.net Fedora Core release 4 (Stentz) sur athlon kernel 2.6.12-1.1398_FC4 From skvidal at phy.duke.edu Mon Aug 15 19:35:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 15 Aug 2005 15:35:00 -0400 Subject: RFP for Extras: Grace In-Reply-To: <1124131455.12203.9.camel@bureau.maison> References: <43009884.8050500@redhat.com> <1124112880.17178.6.camel@cutter> <1124131455.12203.9.camel@bureau.maison> Message-ID: <1124134500.17178.27.camel@cutter> > > SRPM is available here: > > > > http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rpm > > > > If anyone wants to take that and run it through extras, please do. > > > > -sv > > > I tried this src package but i need PDFlib-Lite-devel that i can't find in any > repo for fc4. could you tell me where to find it ? > Thanks > right here http://linux.duke.edu/~skvidal/RPMS/extras/PDFlib-Lite-6.0.1-0.duke.1.fc4.src.rpm sorry -sv From msalim at cs.indiana.edu Mon Aug 15 20:33:20 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 15 Aug 2005 15:33:20 -0500 Subject: Duplicates packages on x86_64 In-Reply-To: References: Message-ID: <1124138000.4294.2.camel@salem> On Mon, 2005-08-15 at 20:09 +0200, Lukasz Trabinski wrote: > Hello > > I have fresh FC4 instalation on x86_64 machine. I would like to > erase some packages, but when I try do: > > oceanic:~# rpm -e zlib > error: "zlib" specifies multiple packages > > ok, we have packages for both arch: > > oceanic:~# rpm -q --queryformat "%{ARCH}\n" zlib > i386 > x86_64 > Those are not duplicates - RPM supports the installation of side-by-side 'multilib' packages, for backward compatibility with 32-bit programs. Important things such as OpenOffice and HelixPlayer are still 32-bit only, and some people choose to run 32-bit browsers for better plugin supports. To uninstall the 32-bit zlib, for example, you can just rpm -e zlib.i386 .. Hope that helps, and by the way, this is probably more appropriate on fedora-list. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From msalim at cs.indiana.edu Mon Aug 15 20:45:27 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 15 Aug 2005 15:45:27 -0500 Subject: /etc/sysconfig/harddisks deprecated? Message-ID: <1124138727.4294.21.camel@salem> I normally tune my hard drives using /etc/sysconfig/harddisks, back when using FC2, and after a few months of not running Fedora it was quite surprising to me to find the settings not applied (my laptop boots Linux with DMA enabled but IO support set to 16-bits, so the slow-down is noticeable). rpm -q --changelog initscripts | grep hdparm shows that Bill Nottingham removed this in December 2004, so the questions are: 1. Shouldn't hdparm not include /e/s/harddisks anymore? 2. What is the current recommended method to tune hard drives? Thanks, -- - Michel Salim To patch or not to patch: that is the question; Whether 'tis nobler in the mind to suffer The bugs and trojans of outrageous monopolies, Or to take arms against a sea of proprietariness, And by opposing end them? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From dax at gurulabs.com Mon Aug 15 21:37:39 2005 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 15 Aug 2005 15:37:39 -0600 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124138727.4294.21.camel@salem> References: <1124138727.4294.21.camel@salem> Message-ID: <1124141859.3415.30.camel@mentorng.gurulabs.com> On Mon, 2005-08-15 at 15:45 -0500, Michel Alexandre Salim wrote: > I normally tune my hard drives using /etc/sysconfig/harddisks, back when > using FC2, and after a few months of not running Fedora it was quite > surprising to me to find the settings not applied (my laptop boots Linux > with DMA enabled but IO support set to 16-bits, so the slow-down is > noticeable). AFAIK the IO 16 vs 32 bit setting *only* comes into play when DMA is not enabled (i.e when you are in PIO mode). Your question on /etc/sysconfig/harddisks is a good one though. Dax Kelson From alan at redhat.com Mon Aug 15 22:07:32 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 15 Aug 2005 18:07:32 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124141859.3415.30.camel@mentorng.gurulabs.com> References: <1124138727.4294.21.camel@salem> <1124141859.3415.30.camel@mentorng.gurulabs.com> Message-ID: <20050815220732.GC9435@devserv.devel.redhat.com> On Mon, Aug 15, 2005 at 03:37:39PM -0600, Dax Kelson wrote: > AFAIK the IO 16 vs 32 bit setting *only* comes into play when DMA is not > enabled (i.e when you are in PIO mode). Correct and its really "ISA era" stuff From alan at redhat.com Mon Aug 15 22:09:24 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 15 Aug 2005 18:09:24 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124138727.4294.21.camel@salem> References: <1124138727.4294.21.camel@salem> Message-ID: <20050815220924.GE9435@devserv.devel.redhat.com> On Mon, Aug 15, 2005 at 03:45:27PM -0500, Michel Alexandre Salim wrote: > 1. Shouldn't hdparm not include /e/s/harddisks anymore? > 2. What is the current recommended method to tune hard drives? As always #2 is "use the kernel settings". Hdparm is for the "I really know what I am doing" cases. From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 15 22:42:33 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 16 Aug 2005 00:42:33 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050815220924.GE9435@devserv.devel.redhat.com> (Alan Cox's message of "Mon, 15 Aug 2005 18:09:24 -0400") References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> Message-ID: <877jemlt46.fsf@kosh.bigo.ensc.de> alan at redhat.com (Alan Cox) writes: >> 1. Shouldn't hdparm not include /e/s/harddisks anymore? >> 2. What is the current recommended method to tune hard drives? > > ... Hdparm is for the "I really know what I am doing" cases. Not really... E.g. standby timeouts, acoustic management settings or cdrom speeds are for the "I do not exactly know what I am doing" cases also. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From i.pilcher at comcast.net Mon Aug 15 22:42:37 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 15 Aug 2005 17:42:37 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050815220924.GE9435@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> Message-ID: Alan Cox wrote: > As always #2 is "use the kernel settings". Hdparm is for the "I really know > what I am doing" cases. I really know what I'm doing. This doesn't mean I should have to do it manually every time I reboot. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From fedora at camperquake.de Mon Aug 15 22:51:06 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 16 Aug 2005 00:51:06 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> Message-ID: <20050816005106.604acb2f@nausicaa.camperquake.de> Hi. Ian Pilcher wrote: > I really know what I'm doing. This doesn't mean I should have to do it > manually every time I reboot. Stuff it in /etc/rc.local for the time being. -- Anthropomorphism is stalking the streets. From alan at redhat.com Mon Aug 15 23:07:50 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 15 Aug 2005 19:07:50 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> Message-ID: <20050815230750.GA828@devserv.devel.redhat.com> On Mon, Aug 15, 2005 at 05:42:37PM -0500, Ian Pilcher wrote: > >As always #2 is "use the kernel settings". Hdparm is for the "I really know > >what I am doing" cases. > > I really know what I'm doing. This doesn't mean I should have to do it > manually every time I reboot. Thats a matter for user space scripts. I'm just the kernel guy. I am however interested in cases where the kernel defaults are incorrect. Alan From msalim at cs.indiana.edu Mon Aug 15 23:15:23 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 15 Aug 2005 18:15:23 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816005106.604acb2f@nausicaa.camperquake.de> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050816005106.604acb2f@nausicaa.camperquake.de> Message-ID: <1124147724.11850.1.camel@salem> On Tue, 2005-08-16 at 00:51 +0200, Ralf Ertzinger wrote: > Hi. > > Ian Pilcher wrote: > > > I really know what I'm doing. This doesn't mean I should have to do it > > manually every time I reboot. > > Stuff it in /etc/rc.local for the time being. > What would be very nice is if initscripts include an /etc/rc.pre-sysinit that lets you do things before sysinit runs - in case of hdparm, for example. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From msalim at cs.indiana.edu Mon Aug 15 23:17:56 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 15 Aug 2005 18:17:56 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124141859.3415.30.camel@mentorng.gurulabs.com> References: <1124138727.4294.21.camel@salem> <1124141859.3415.30.camel@mentorng.gurulabs.com> Message-ID: <1124147876.11850.3.camel@salem> On Mon, 2005-08-15 at 15:37 -0600, Dax Kelson wrote: > On Mon, 2005-08-15 at 15:45 -0500, Michel Alexandre Salim wrote: > > I normally tune my hard drives using /etc/sysconfig/harddisks, back when > > using FC2, and after a few months of not running Fedora it was quite > > surprising to me to find the settings not applied (my laptop boots Linux > > with DMA enabled but IO support set to 16-bits, so the slow-down is > > noticeable). > > AFAIK the IO 16 vs 32 bit setting *only* comes into play when DMA is not > enabled (i.e when you are in PIO mode). > Ah, OK. Probably why the difference in performance is less than I thought. Thanks, - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From fedora at camperquake.de Mon Aug 15 23:23:05 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 16 Aug 2005 01:23:05 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124147724.11850.1.camel@salem> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050816005106.604acb2f@nausicaa.camperquake.de> <1124147724.11850.1.camel@salem> Message-ID: <20050816012305.7fe0e795@nausicaa.camperquake.de> Hi. Michel Alexandre Salim wrote: > What would be very nice is if initscripts include an /etc/rc.pre-sysinit > that lets you do things before sysinit runs - in case of hdparm, for > example. Not very much is working at that point. How much of /dev is there? -- Im Wald da rauscht der Wasserfalle, wenn's nicht mehr rauscht ist's Wasser alle. From msalim at cs.indiana.edu Mon Aug 15 23:31:44 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 15 Aug 2005 18:31:44 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816012305.7fe0e795@nausicaa.camperquake.de> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050816005106.604acb2f@nausicaa.camperquake.de> <1124147724.11850.1.camel@salem> <20050816012305.7fe0e795@nausicaa.camperquake.de> Message-ID: <1124148705.11850.19.camel@salem> On Tue, 2005-08-16 at 01:23 +0200, Ralf Ertzinger wrote: > Hi. > > Michel Alexandre Salim wrote: > > > What would be very nice is if initscripts include an /etc/rc.pre-sysinit > > that lets you do things before sysinit runs - in case of hdparm, for > > example. > > Not very much is working at that point. How much of /dev is there? > OK, correction: a script that would be called by sysinit just after partitions are mounted? > -- > Im Wald da rauscht der Wasserfalle, > wenn's nicht mehr rauscht ist's Wasser alle. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From alan at redhat.com Mon Aug 15 23:32:21 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 15 Aug 2005 19:32:21 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124147876.11850.3.camel@salem> References: <1124138727.4294.21.camel@salem> <1124141859.3415.30.camel@mentorng.gurulabs.com> <1124147876.11850.3.camel@salem> Message-ID: <20050815233221.GA8205@devserv.devel.redhat.com> On Mon, Aug 15, 2005 at 06:17:56PM -0500, Michel Alexandre Salim wrote: > > AFAIK the IO 16 vs 32 bit setting *only* comes into play when DMA is not > > enabled (i.e when you are in PIO mode). > > > Ah, OK. Probably why the difference in performance is less than I > thought. It should have no effect at all in the PCI world. From jkeating at j2solutions.net Mon Aug 15 23:39:08 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 Aug 2005 16:39:08 -0700 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050815230750.GA828@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> Message-ID: <1124149148.28537.32.camel@prometheus.gamehouse.com> On Mon, 2005-08-15 at 19:07 -0400, Alan Cox wrote: > Thats a matter for user space scripts. I'm just the kernel guy. I am > however > interested in cases where the kernel defaults are incorrect. I have a feeling they are incorrect for my Apple Ibook G3. Bus gets assumed 33mhz which is a tad slow for a modern IDE bus. However I don't really know where to look for the real specs to compare against. Want to help out? -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From msalim at cs.indiana.edu Mon Aug 15 23:40:11 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 15 Aug 2005 18:40:11 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050815233221.GA8205@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <1124141859.3415.30.camel@mentorng.gurulabs.com> <1124147876.11850.3.camel@salem> <20050815233221.GA8205@devserv.devel.redhat.com> Message-ID: <1124149211.11850.21.camel@salem> On Mon, 2005-08-15 at 19:32 -0400, Alan Cox wrote: > On Mon, Aug 15, 2005 at 06:17:56PM -0500, Michel Alexandre Salim wrote: > > > AFAIK the IO 16 vs 32 bit setting *only* comes into play when DMA is not > > > enabled (i.e when you are in PIO mode). > > > > > Ah, OK. Probably why the difference in performance is less than I > > thought. > > It should have no effect at all in the PCI world. > Yep, it's just the normal deviation between runs. Didn't help that I had cpuspeed dynamically clocking my CPU too. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From fedora at camperquake.de Mon Aug 15 23:43:08 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 16 Aug 2005 01:43:08 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124149148.28537.32.camel@prometheus.gamehouse.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> Message-ID: <20050816014308.2155017d@nausicaa.camperquake.de> Hi. Jesse Keating wrote: > I have a feeling they are incorrect for my Apple Ibook G3. Bus gets > assumed 33mhz which is a tad slow for a modern IDE bus. Unless I am mistaken that should be the PCI side. -- "I know that it sucks for the rest of the world that mail transport is built around ASCII and English but you only have your ancestors to blame for losing the wars. :)" -- Kyle Jones From jkeating at j2solutions.net Mon Aug 15 23:54:56 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 Aug 2005 16:54:56 -0700 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816014308.2155017d@nausicaa.camperquake.de> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> Message-ID: <1124150096.28537.37.camel@prometheus.gamehouse.com> On Tue, 2005-08-16 at 01:43 +0200, Ralf Ertzinger wrote: > Unless I am mistaken that should be the PCI side. Perhaps I should clarify. UDMA33 vs UDMA66 or UDMA133. I'm more than likely misusing some of the letters above, but I know the concept I'm trying to get across (: Most CDROMS operate at DMA33, and older (5 years?) drives were DMA66, then DMA100, now DMA133. I half expected my laptop hdd to be at least DMA66, but seems to be stuck at 33. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From fedora at camperquake.de Tue Aug 16 00:01:37 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 16 Aug 2005 02:01:37 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124150096.28537.37.camel@prometheus.gamehouse.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> Message-ID: <20050816020137.154753e5@nausicaa.camperquake.de> Hi. Jesse Keating wrote: > Perhaps I should clarify. UDMA33 vs UDMA66 or UDMA133. Yes, I know that. What exact line are you talking about? This one: "ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx" talks about the PCI bus speed. This one: "hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66)" talks about the IDE bus speed. -- Never try to teach a pig to sing. It wastes your time, and it annoys the pig. From jkeating at j2solutions.net Tue Aug 16 00:11:03 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 Aug 2005 17:11:03 -0700 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816020137.154753e5@nausicaa.camperquake.de> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816020137.154753e5@nausicaa.camperquake.de> Message-ID: <1124151063.28537.50.camel@prometheus.gamehouse.com> On Tue, 2005-08-16 at 02:01 +0200, Ralf Ertzinger wrote: > Yes, I know that. What exact line are you talking about? > > This one: > "ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx" > talks about the PCI bus speed. Ah. The above line is the one that catches my eye. Perhaps I'm not too slow then, which is dissapointing because disk I/O does seem slower in Fedora than in OS X. > This one: > "hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66)" > talks about the IDE bus speed. I will have to see if I can find that line. I'll look tonight. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From i.pilcher at comcast.net Tue Aug 16 01:08:08 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 15 Aug 2005 20:08:08 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050815230750.GA828@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> Message-ID: Alan Cox wrote: > > Thats a matter for user space scripts. I'm just the kernel guy. I am however > interested in cases where the kernel defaults are incorrect. > I've got a bunch of drives that don't automatically get their unmaskirq flag set. Do you consider that incorrect? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From david at fubar.dk Tue Aug 16 01:20:23 2005 From: david at fubar.dk (David Zeuthen) Date: Mon, 15 Aug 2005 21:20:23 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124138727.4294.21.camel@salem> References: <1124138727.4294.21.camel@salem> Message-ID: <1124155223.3078.10.camel@daxter.boston.redhat.com> On Mon, 2005-08-15 at 15:45 -0500, Michel Alexandre Salim wrote: > I normally tune my hard drives using /etc/sysconfig/harddisks, back when > using FC2, and after a few months of not running Fedora it was quite > surprising to me to find the settings not applied (my laptop boots Linux > with DMA enabled but IO support set to 16-bits, so the slow-down is > noticeable). > > rpm -q --changelog initscripts | grep hdparm shows that Bill Nottingham > removed this in December 2004, so the questions are: > > 1. Shouldn't hdparm not include /e/s/harddisks anymore? > 2. What is the current recommended method to tune hard drives? The current plan that we (the Red Hat desktop team) for FC5 involves putting gnome-power-manager in the distribution which includes automating all of this. Simply put, we just want two settings and flip between these for the laptop use case, e.g. when transitioning from running on AC power to running on battery / UPS. This probably involves things like setting harddisk spindown time and not much beyond that. We probably also want to enable/disable laptop-mode stuff during the transitions, but that is another thing. So, I guess I really see no need to provide configuration for these two set of "sane" settings, we should rather spend energy on choosing sane defaults that work for everyone. If someone comes up with a really good reason for tweaking this later on we can always add it. Btw, people with servers should be able to use /etc/rc.local (which runs after e.g. HAL have tuned the harddisks with our "sane" defaults) to tune specific disks using hdparm or whaterver - I don't think it makes sense at all to have configuration files for this; in other words /etc/sysconfig/harddisks sounds like a bad idea to me... David From rodd at clarkson.id.au Tue Aug 16 05:29:24 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 16 Aug 2005 15:29:24 +1000 Subject: Trying to solve performance issues on Rawhide In-Reply-To: <1123860145.2921.34.camel@localhost.localdomain> References: <1123807841.2921.28.camel@localhost.localdomain> <20050812095542.GA23789@devserv.devel.redhat.com> <1123860145.2921.34.camel@localhost.localdomain> Message-ID: <1124170165.3327.8.camel@localhost.localdomain> On Sat, 2005-08-13 at 01:22 +1000, Rodd Clarkson wrote: > On Fri, 2005-08-12 at 05:55 -0400, Alan Cox wrote: > > On Fri, Aug 12, 2005 at 10:50:41AM +1000, Rodd Clarkson wrote: > > > setting using_dma to 1 (on) > > > HDIO_SET_DMA failed: Operation not permitted > > > using_dma = 0 (off) > > > > > > This in an a brand new dell laptop with a Fujitsu drive that supports > > > UltraDMA. > > > > What does lspci show for your IDE controller. From the above it may just not > > be supported yet. > > 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) Okay, and lspci -v says 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) (prog-if 80 [Master]) Subsystem: Dell: Unknown device 0189 Flags: 66Mhz, medium devsel, IRQ 5 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at bfa0 [size=16] Capabilities: I've done a little more research into this and I've found this very interesting page on people with the same problem with me (and what appears to be the same IDE interface. see: http://www.linuxquestions.org/questions/history/340897 Also, on this page and Dell 6000 (which use the same IDE device) ( http://james.jamesandkristin.net/?p=19 ) I found this: ?in /usr/src/linux/include/linux/libata.h change #undef ATA_ENABLE_ATAPI /* define to enable ATAPI support */ to #define ATA_ENABLE_ATAPI /* define to enable ATAPI support */? Is this enough to start getting this issue addressed, or should I lodge a bugzilla, or should I do more research? Obviously with a lot of new laptops (see first link) using this chipset from Intel, this would be a good thing to have fixed in terms of performance (both in FC5 and FC4). Obviously this affects from HDD and CD/DVD performance. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From arjanv at redhat.com Tue Aug 16 05:51:18 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 16 Aug 2005 07:51:18 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124151063.28537.50.camel@prometheus.gamehouse.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816020137.154753e5@nausicaa.camperquake.de> <1124151063.28537.50.camel@prometheus.gamehouse.com> Message-ID: <1124171479.3215.10.camel@laptopd505.fenrus.org> On Mon, 2005-08-15 at 17:11 -0700, Jesse Keating wrote: > On Tue, 2005-08-16 at 02:01 +0200, Ralf Ertzinger wrote: > > Yes, I know that. What exact line are you talking about? > > > > This one: > > "ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx" > > talks about the PCI bus speed. > > Ah. The above line is the one that catches my eye. Perhaps I'm not too > slow then, which is dissapointing because disk I/O does seem slower in > Fedora than in OS X. if you force this to 66 you actually are slowing your system down! -------------- 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 all-the-johnsons.co.uk Tue Aug 16 06:41:18 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 16 Aug 2005 07:41:18 +0100 Subject: Suspend/Restore in the newest kernels Message-ID: <1124174478.18021.1.camel@localhost> Hi, Just a quick question, how do I trigger a sleep & restore with the newest kernels? I'd imagine it's a key combination, but don't know what it is. There is such a thing using battstat, but nothing else I can see. TTFN Paul -- "A lot of football success is in the mind. You must believe you are the best and then make sure that you are. In my time at Liverpool we always said we had the best two teams on Merseyside, Liverpool and Liverpool Reserves." - Bill Shankly -------------- 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 dragoran at feuerpokemon.de Tue Aug 16 07:13:50 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 16 Aug 2005 09:13:50 +0200 Subject: Suspend/Restore in the newest kernels In-Reply-To: <1124174478.18021.1.camel@localhost> References: <1124174478.18021.1.camel@localhost> Message-ID: <4301922E.1090908@feuerpokemon.de> Paul wrote: >Hi, > >Just a quick question, how do I trigger a sleep & restore with the >newest kernels? I'd imagine it's a key combination, but don't know what >it is. > >There is such a thing using battstat, but nothing else I can see. > >TTFN > >Paul > > http://www.redhat.com/archives/fedora-devel-list/2005-August/msg00143.html From thuforuk at yahoo.co.uk Tue Aug 16 07:16:45 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Tue, 16 Aug 2005 08:16:45 +0100 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124155223.3078.10.camel@daxter.boston.redhat.com> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> Message-ID: <430192DD.6080000@yahoo.co.uk> On 08/16/2005 02:20 AM, David Zeuthen wrote: > On Mon, 2005-08-15 at 15:45 -0500, Michel Alexandre Salim wrote: > >>I normally tune my hard drives using /etc/sysconfig/harddisks, back when >>using FC2, and after a few months of not running Fedora it was quite >>surprising to me to find the settings not applied (my laptop boots Linux >>with DMA enabled but IO support set to 16-bits, so the slow-down is >>noticeable). >> >>rpm -q --changelog initscripts | grep hdparm shows that Bill Nottingham >>removed this in December 2004, so the questions are: >> >>1. Shouldn't hdparm not include /e/s/harddisks anymore? >>2. What is the current recommended method to tune hard drives? > > > The current plan that we (the Red Hat desktop team) for FC5 involves > putting gnome-power-manager in the distribution which includes > automating all of this. Simply put, we just want two settings and flip > between these for the laptop use case, e.g. when transitioning from > running on AC power to running on battery / UPS. This probably involves > things like setting harddisk spindown time and not much beyond that. We > probably also want to enable/disable laptop-mode stuff during the > transitions, but that is another thing. What about those who do not use Gnome? Or even KDE for that matter (say they use IceWM instead)? Will it work for them? [This is not fire up another flamewar... No flamewars, please.] Regards, Dariusz ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com From alan at redhat.com Tue Aug 16 10:43:25 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Aug 2005 06:43:25 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816014308.2155017d@nausicaa.camperquake.de> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> Message-ID: <20050816104325.GA19323@devserv.devel.redhat.com> On Tue, Aug 16, 2005 at 01:43:08AM +0200, Ralf Ertzinger wrote: > > I have a feeling they are incorrect for my Apple Ibook G3. Bus gets > > assumed 33mhz which is a tad slow for a modern IDE bus. > > Unless I am mistaken that should be the PCI side. Its the assumed VLB/PCI clocking value. 33MHz is correct for the PCI bus. Cards that do PCI66 actually know about how to handle it themselves, and most later cards have PLLs and other devices so can time the bus and set themselves correctly. From alan at redhat.com Tue Aug 16 10:44:38 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Aug 2005 06:44:38 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124150096.28537.37.camel@prometheus.gamehouse.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> Message-ID: <20050816104438.GB19323@devserv.devel.redhat.com> On Mon, Aug 15, 2005 at 04:54:56PM -0700, Jesse Keating wrote: > years?) drives were DMA66, then DMA100, now DMA133. I half expected my > laptop hdd to be at least DMA66, but seems to be stuck at 33. UDMA66 and higher requires 80 pin cables. Since almost no laptop drive is fast enough to benefit from UDMA66 almost no laptops bother. From alan at redhat.com Tue Aug 16 10:48:50 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Aug 2005 06:48:50 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> Message-ID: <20050816104850.GC19323@devserv.devel.redhat.com> On Mon, Aug 15, 2005 at 08:08:08PM -0500, Ian Pilcher wrote: > I've got a bunch of drives that don't automatically get their unmaskirq > flag set. Do you consider that incorrect? Its currently upstream policy to default that way. Its intentional, I'm not 100% sure its "correct" From pbrobinson at gmail.com Tue Aug 16 11:01:39 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 16 Aug 2005 12:01:39 +0100 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816104438.GB19323@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> Message-ID: <5256d0b05081604012352d92a@mail.gmail.com> > > years?) drives were DMA66, then DMA100, now DMA133. I half expected my > > laptop hdd to be at least DMA66, but seems to be stuck at 33. > > UDMA66 and higher requires 80 pin cables. Since almost no laptop drive is fast > enough to benefit from UDMA66 almost no laptops bother. Most of the current line of laptop drives are ata100 (at least support it), whether the laptop manufacturers actually make use of it is another question. Pete From dwmw2 at infradead.org Tue Aug 16 11:02:32 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 16 Aug 2005 12:02:32 +0100 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050815220924.GE9435@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> Message-ID: <1124190153.4543.106.camel@baythorne.infradead.org> On Mon, 2005-08-15 at 18:09 -0400, Alan Cox wrote: > As always #2 is "use the kernel settings". Hdparm is for the "I really > know what I am doing" cases. My telephone exchange always introduces echo on the line unless I run 'hdparm -u1 /dev/hda'. Are we being overly conservative with that default? 00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 02) hda: ST320011A, ATA DISK drive hda: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100) -- dwmw2 From strange at nsk.no-ip.org Tue Aug 16 11:59:36 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Tue, 16 Aug 2005 12:59:36 +0100 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124155223.3078.10.camel@daxter.boston.redhat.com> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> Message-ID: <20050816115936.GA27210@nsk.no-ip.org> On Mon, Aug 15, 2005 at 09:20:23PM -0400, David Zeuthen wrote: > > Btw, people with servers should be able to use /etc/rc.local (which > runs after e.g. HAL have tuned the harddisks with our "sane" defaults) > to tune specific disks using hdparm or whaterver - I don't think it > makes sense at all to have configuration files for this; in other > words /etc/sysconfig/harddisks sounds like a bad idea to me... /etc/rc.local just isn't good enough. I need to tune my harddisks before mount/fsck (hardware problems). Regards -- lfr 0/0 From paul at city-fan.org Tue Aug 16 12:06:51 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Aug 2005 13:06:51 +0100 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816115936.GA27210@nsk.no-ip.org> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> <20050816115936.GA27210@nsk.no-ip.org> Message-ID: <4301D6DB.9050400@city-fan.org> Luciano Miguel Ferreira Rocha wrote: > On Mon, Aug 15, 2005 at 09:20:23PM -0400, David Zeuthen wrote: > >>Btw, people with servers should be able to use /etc/rc.local (which >>runs after e.g. HAL have tuned the harddisks with our "sane" defaults) >>to tune specific disks using hdparm or whaterver - I don't think it >>makes sense at all to have configuration files for this; in other >>words /etc/sysconfig/harddisks sounds like a bad idea to me... > > > /etc/rc.local just isn't good enough. I need to tune my harddisks before > mount/fsck (hardware problems). Try using /etc/sysconfig/modules/hdparm.modules instead. Paul. From alan at redhat.com Tue Aug 16 12:11:47 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Aug 2005 08:11:47 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124190153.4543.106.camel@baythorne.infradead.org> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <1124190153.4543.106.camel@baythorne.infradead.org> Message-ID: <20050816121147.GA12657@devserv.devel.redhat.com> On Tue, Aug 16, 2005 at 12:02:32PM +0100, David Woodhouse wrote: > On Mon, 2005-08-15 at 18:09 -0400, Alan Cox wrote: > > As always #2 is "use the kernel settings". Hdparm is for the "I really > > know what I am doing" cases. > > My telephone exchange always introduces echo on the line unless I run > 'hdparm -u1 /dev/hda'. Are we being overly conservative with that > default? For most PCI IDE controllers yes I think so. I'd be more caution on RZ1000 or CMD640 but I think a patch to turn irq unmask on by default for the others would be good. Bartlomiej might well accept it if you sent it too From rodd at clarkson.id.au Tue Aug 16 12:39:28 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 16 Aug 2005 22:39:28 +1000 Subject: Idea for packing of FC5 DVD Message-ID: <1124195968.3327.17.camel@localhost.localdomain> I've just spent an evening trying to install FC4 onto a system without a DVD drive when the only copy of FC4 I've got is the DVD edition. Which got me to thinking... How hard would it be to include a script (or application) on DVD versions of FC that would allow you to create the various CD's that FC alternatively comes on. So, taking FC4 for example, the DVD replaces 4 CDs, so the script could be used to produce these CDs from the contents of the DVD. This would be a very attractive way to grab FC. Grab the DVD (which is most cases is fine) and if you need to use the CDs then you can produce them from the DVD rather than having to download them. Thoughts??? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From jos at xos.nl Tue Aug 16 12:52:45 2005 From: jos at xos.nl (Jos Vos) Date: Tue, 16 Aug 2005 14:52:45 +0200 Subject: Idea for packing of FC5 DVD In-Reply-To: <1124195968.3327.17.camel@localhost.localdomain>; from rodd@clarkson.id.au on Tue, Aug 16, 2005 at 10:39:28PM +1000 References: <1124195968.3327.17.camel@localhost.localdomain> Message-ID: <20050816145245.A21660@xos037.xos.nl> Hi, On Tue, Aug 16, 2005 at 10:39:28PM +1000, Rodd Clarkson wrote: > How hard would it be to include a script (or application) on DVD > versions of FC that would allow you to create the various CD's that FC > alternatively comes on. So, taking FC4 for example, the DVD replaces 4 > CDs, so the script could be used to produce these CDs from the contents > of the DVD. > > This would be a very attractive way to grab FC. Grab the DVD (which is > most cases is fine) and if you need to use the CDs then you can produce > them from the DVD rather than having to download them. > > Thoughts??? We are already using such a script for our X/OS Linux (our rebuild of RHEL sources) and the X/OS Linux build process includes code to handle this. We simply provide a very small script (can/should be made much more robust, implantmd5 etc. could be added), which you can see at: http://download.xoslinux.org/pub/xoslinux/4/i386/release/dvdutils/dvd2cd and while we create the CD/DVD images, we put files with the contents and info for each CD in the dvdutils directory. See these files for CD #1 for example: http://download.xoslinux.org/pub/xoslinux/4/i386/release/dvdutils/.discinfo-cd1 http://download.xoslinux.org/pub/xoslinux/4/i386/release/dvdutils/.pathlist-cd1 And this works fine since a year or so! Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From lfarkas at bppiac.hu Tue Aug 16 13:14:20 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 16 Aug 2005 15:14:20 +0200 Subject: a new window workspace placement bug Message-ID: <4301E6AC.3070109@bppiac.hu> hi, i'm just recognize a new 'feature' which rather seems to me a bug. that even if i set 'show window from all workspace' in the window list preferences and 'restore to native wokspace' it's always restore to the current workspace. this is a new bug since it was worked even in the last week. the strange thing i do not find any updates since last week which can cause this behavious. anybody has any solution to this problem? yours. -- Levente "Si vis pacem para bellum!" From jspaleta at gmail.com Tue Aug 16 13:27:17 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 16 Aug 2005 09:27:17 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <4301D6DB.9050400@city-fan.org> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> <20050816115936.GA27210@nsk.no-ip.org> <4301D6DB.9050400@city-fan.org> Message-ID: <604aa79105081606272c421e53@mail.gmail.com> On 8/16/05, Paul Howarth wrote: > Try using /etc/sysconfig/modules/hdparm.modules instead. Is /etc/sysconfig/modules mentioned anywhere outside of the rc.sysinit itself? I'm not seeing it mentioned in /usr/share/doc/initscripts-8.11.1/sysconfig.txt nor anything higher level that a novice admin would reach for. This was introduced in fc4 and was not shipped as part of fc3. I'm just wondering how exactly are admins suppose to be discovering these sorts of additions? Are admins really expected to be reading over the logic in rc.sysinit script with every iteration? The only reference I see to how to use this outside of rc.sysinit is a terse changelog line.. which doesn't indicate anything about the naming constraints for filenames nor anything with regard to when in the linear init process these files will be activated so an admin would still have to read rc.sysinit directly to figure out what to do and whether it fits their needs. /usr/share/doc/initscripts-8.11.1/ChangeLog: load user-defined module scripts from /etc/sysconfig/modules at boot Thats it.. thats the only reference I see on my system and its of course duplicated in the rpm package changelog. Now reading over rc.sysinit isn't particular difficult for an experienced unix administrator.. but a dare say that there is a significant segment of the userbase who are cutting their teeth on the experience of being an 'admin' while running fedora at home are going to be significantly confused when trying to read through rc.sysinit unless they are explicitly told that they need to learn full bash logic syntax before working with admin only level items on a fedora system. You need to know much less about bash scripting to write a short hdparm.modules file that just has the hdparm commands you need in it than it is to follow rc.sysinit. Making the modules file feature syntax only discoverable via rc.sysinit review seems backwards to me. I'm just asking to get a better feel of the learning curve expectations being set for people who are going to admin boxes. I'm not looking to expose this graphically so people can clicky-click their way through esoteric hardware setup.. I just want to make sure that there is a clear understanding as to what admins should "know" before touching the system and to make sure features are exposed in such a way that admins can start from that baseline amount of knowledge and work from that starting point with "reasonable" on-system documentation and references to additional documentation. I have a pretty good idea as to where the expectations lie for the casual user functionality and its clear there is a long term plan to get tools out for that audience that are commiserate with the learning curve expectations for casual users.. but I don't think there is any plan floating about on how to make it easier for a novice admin to work efficiently with the system...especially when new functionality is exposed. For new admin accessible features ( like the addition of sysconfig/modules/ ) that fall outside the casual user audience definition, I don't have any real sense as to what the consensous expectation on what admins need to do to discover new features and what they should do learn how to configure new features. Nor do I see an effort to identify baseline level(s) of knowledge assumed for "admins" when exposing a new feature. In this case it seems rather counterproductive to require an admin to read through the logic in rc.sysinit to discover that files need to be named /etc/sysconfig/modules/*.modules and be executable. The details need to be explained in /usr/share/doc/initscripts-X.Y at the very very least. -jef From prarit at sgi.com Tue Aug 16 14:13:04 2005 From: prarit at sgi.com (Prarit Bhargava) Date: Tue, 16 Aug 2005 10:13:04 -0400 Subject: [PATCH]: Turn on SGI TIOCX driver Message-ID: <20050816141252.17559.456.sendpatchset@prarit.boston.redhat.com> This patch is against the latest nightly rawhide source for ia64. The TIOCX driver enables the TIOCX IO brick type and the SGI_MBCS driver enables FPGA support through the TIOCX driver. Signed-off-by: Prarit Bhargava --- linux-2.6.12/.config 2020-08-16 09:44:57.000000000 -0400 +++ work/.config 2020-08-16 09:47:12.000000000 -0400 @@ -1340,7 +1340,8 @@ CONFIG_N_HDLC=m # CONFIG_SX is not set CONFIG_STALDRV=y CONFIG_SGI_SNSC=y -# CONFIG_SGI_TIOCX is not set +CONFIG_SGI_TIOCX=y +CONFIG_SGI_MBCS=m # # Serial drivers From msalim at cs.indiana.edu Tue Aug 16 14:48:08 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Tue, 16 Aug 2005 09:48:08 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816104438.GB19323@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> Message-ID: <1124203688.4829.1.camel@salem> On Tue, 2005-08-16 at 06:44 -0400, Alan Cox wrote: > On Mon, Aug 15, 2005 at 04:54:56PM -0700, Jesse Keating wrote: > > years?) drives were DMA66, then DMA100, now DMA133. I half expected my > > laptop hdd to be at least DMA66, but seems to be stuck at 33. > > UDMA66 and higher requires 80 pin cables. Since almost no laptop drive is fast > enough to benefit from UDMA66 almost no laptops bother. > Either new laptops do have UDMA, or hdparm is broken: I could do -X69 but -X70 fails, so it seems that -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From msalim at cs.indiana.edu Tue Aug 16 14:51:59 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Tue, 16 Aug 2005 09:51:59 -0500 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124203688.4829.1.camel@salem> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> <1124203688.4829.1.camel@salem> Message-ID: <1124203919.4908.0.camel@salem> On Tue, 2005-08-16 at 09:48 -0500, Michel Alexandre Salim wrote: > On Tue, 2005-08-16 at 06:44 -0400, Alan Cox wrote: > > On Mon, Aug 15, 2005 at 04:54:56PM -0700, Jesse Keating wrote: > > > years?) drives were DMA66, then DMA100, now DMA133. I half expected my > > > laptop hdd to be at least DMA66, but seems to be stuck at 33. > > > > UDMA66 and higher requires 80 pin cables. Since almost no laptop drive is fast > > enough to benefit from UDMA66 almost no laptops bother. > > > Either new laptops do have UDMA, or hdparm is broken: I could do -X69 > but -X70 fails, so it seems that ... that using Evolution from Rawhide to send this might not be prudent. Is UDMA mode 5 different from UDMA66, presumably? - Michel From alan at redhat.com Tue Aug 16 15:01:56 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Aug 2005 11:01:56 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124203919.4908.0.camel@salem> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> <1124203688.4829.1.camel@salem> <1124203919.4908.0.camel@salem> Message-ID: <20050816150156.GA14702@devserv.devel.redhat.com> On Tue, Aug 16, 2005 at 09:51:59AM -0500, Michel Alexandre Salim wrote: > ... that using Evolution from Rawhide to send this might not be prudent. > Is UDMA mode 5 different from UDMA66, presumably? UDMA5 is 100Mhz UDMA6 is 133Mhz (not an official ATA standard) From david at fubar.dk Tue Aug 16 15:12:40 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 16 Aug 2005 11:12:40 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <430192DD.6080000@yahoo.co.uk> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> <430192DD.6080000@yahoo.co.uk> Message-ID: <1124205160.13935.2.camel@daxter.boston.redhat.com> On Tue, 2005-08-16 at 08:16 +0100, Dariusz J. Garbowski wrote: > What about those who do not use Gnome? Or even KDE for that matter (say > they use IceWM instead)? Will it work for them? gnome-power-manager uses the freedesktop.org standard for notification icons so it'll work in any desktop environment that implements a container for these. Examples are XFCE, GNOME and KDE. It's not much different from e.g. NetworkManager... David From ph18 at cornell.edu Tue Aug 16 15:18:34 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 16 Aug 2005 11:18:34 -0400 Subject: "hard core" linux Message-ID: <430203CA.6090807@cornell.edu> I think a lot of the people who have problems with Fedora would be happy to have an alternative ("fork" distribution) to work on. It looks easy to spin a custom distribution -- basically you can unpack the fedora DVD on your web site, remove any RPMs you don't want from the RPMS directory, add any ones that you want, run a few scripts, and then cut your ISOs. All you need is 15 GB or so of free disk space. It would be trivial to develop a distribution that consists of a subset of Fedora Core packages plus packages from Fedora Extras: the advantage here is that users can plug into the existing system for yum, so there's no need to work on security updates, plus users get 100% compatibility with Fedora. It would be easy to address common complaints about Fedora such as "bloat" (Two desktop environments, who knows how many GB of internationalization files), packages that make it difficult to install your own software (OpenOffice). It might be a bit silly, but I'm still missing 'fortune' and the games package that came with Slackware. In the age of BitTorrent, the task of distributing the new distribution would be easy as well: set up a tracker and a few seeds with good connectivity, and the problem is solved. (Actually, that scares me a little -- what if somebody spins a 'black hat linux' with a bad ssh that misrepresents itself as FC and spreads the .torrent file around the net?) This kind of project would make Extras more relevant: people who want to put packages in alternative distributions would have a motivation to get packages into Extras so they can benefit from the update network. Longer-term, it might be interesting to do more of a fork: but the further you diverge from Fedora the more problems you have. For instance, people who want to play mp3's might like a distribution that has no media players and no dependencies on media players -- they can install what they like the way they like it. Trouble is that they might use yum to install some other packages that have dependencies on media players and all hell breaks loose. Open Office creates similar problems: removing OO gives us more flexibility with the web browser, but if someone tries to install OO, it either aborts or the web browser gets borked. One answer is to maintain a parallel tree of rpm files (lots of work, lots of resources), another answer is to make yum (perhaps a forked yum) smart enough to 'overlay' one repository on another: 'Hard Core' might balk at an attempt to install OO from Fedora Core, or overlay it with an OO that has fewer dependencies on it's environment. ------ Many of us can imagine our own personal perfect Fedora-derived distribution, but really the challenge is to think of a coherent mission for an alternative distribution (or series of alternative distributions) that would be compelling to enough people that it could get some momentum. Any ideas? From jkeating at j2solutions.net Tue Aug 16 15:23:40 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 16 Aug 2005 08:23:40 -0700 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124151063.28537.50.camel@prometheus.gamehouse.com> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816020137.154753e5@nausicaa.camperquake.de> <1124151063.28537.50.camel@prometheus.gamehouse.com> Message-ID: <1124205820.15701.22.camel@localhost.localdomain> On Mon, 2005-08-15 at 17:11 -0700, Jesse Keating wrote: > > This one: > > "hdb: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66)" > > talks about the IDE bus speed. > > I will have to see if I can find that line. I'll look tonight. Found the line that concerned me: hda: 58605120 sectors (30005 MB) w/1768KiB Cache, CHS=58140/16/63, UDMA(33) My drive is being set at UDMA(33) but I don't know if apples are at that speed or if something isn't being detected right. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 brugolsky at telemetry-investments.com Tue Aug 16 15:30:13 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 16 Aug 2005 11:30:13 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124205160.13935.2.camel@daxter.boston.redhat.com> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> <430192DD.6080000@yahoo.co.uk> <1124205160.13935.2.camel@daxter.boston.redhat.com> Message-ID: <20050816153013.GG6012@ti64.telemetry-investments.com> On Tue, Aug 16, 2005 at 11:12:40AM -0400, David Zeuthen wrote: > On Tue, 2005-08-16 at 08:16 +0100, Dariusz J. Garbowski wrote: > > What about those who do not use Gnome? Or even KDE for that matter (say > > they use IceWM instead)? Will it work for them? > > gnome-power-manager uses the freedesktop.org standard for notification > icons so it'll work in any desktop environment that implements a > container for these. Examples are XFCE, GNOME and KDE. It's not much > different from e.g. NetworkManager... Please, not like NetworkManager ... the idea of logging in to get the network dynamically configured is *repugnant*. Goodbye real multiuser timesharing system, hello Windows 95. When I turn on my laptop or Zaurus at home or work, I want to just SSH into it, not play around with logins. It seems that this might be addressed eventually -- as an afterthought. :-( Bill Rugolsky From sundaram at redhat.com Tue Aug 16 15:36:11 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 16 Aug 2005 21:06:11 +0530 Subject: "hard core" linux In-Reply-To: <430203CA.6090807@cornell.edu> References: <430203CA.6090807@cornell.edu> Message-ID: <430207EB.3030800@redhat.com> Paul A Houle wrote: > I think a lot of the people who have problems with Fedora would be > happy to have an alternative ("fork" distribution) to work on. It depends on your problems. If you want to say fix bugs, a fork wouldnt be necessary. See http://fedoraproject.org/wiki/BugZappers > > It would be trivial to develop a distribution that consists of a > subset of Fedora Core packages plus packages from Fedora Extras: the > advantage here is that users can plug into the existing system for > yum, so there's no need to work on security updates, plus users get > 100% compatibility with Fedora. It would be easy to address common > complaints about Fedora such as "bloat" (Two desktop environments, > who knows how many GB of internationalization files), packages that > make it difficult to install your own software (OpenOffice). It might > be a bit silly, but I'm still missing 'fortune' and the games package > that came with Slackware. One of the FC5 goals is to trim down Fedora to reasonable default. When Anaconda gets a yum backend would make it easy enough to mix and match what packages you want. Its also a goal of the Live CD project to make it easy to create derivatives which are compatible with Fedora http://fedoraproject.org/wiki/LiveCD > > In the age of BitTorrent, the task of distributing the new > distribution would be easy as well: set up a tracker and a few seeds > with good connectivity, and the problem is solved. > > (Actually, that scares me a little -- what if somebody spins a > 'black hat linux' with a bad ssh that misrepresents itself as FC and > spreads the .torrent file around the net?) Pretty good question. The legal protection against people misrepresenting Fedora is through trade marks http://fedora.redhat.com/about/trademarks/ > This kind of project would make Extras more relevant: people who > want to put packages in alternative distributions would have a > motivation to get packages into Extras so they can benefit from the > update network. I believe with the current work in Anaconda helps a lot in blurring out the differences between core and extras. If someone takes up the project of spinning off Fedora Extras repository into ISO images it pretty much makes it irrelevant whether its in core or extras for a lot of people. > Many of us can imagine our own personal perfect Fedora-derived > distribution, but really the challenge is to think of a coherent > mission for an alternative distribution (or series of alternative > distributions) that would be compelling to enough people that it could > get some momentum. Any ideas? Lets see * KDE or XFCE based Fedora derivative. * Fedora for low end systems * Hardened version of Fedora with strict or MLS policy by default Things like that. It would be interesting if you can work within the frame work of Fedora, get a cvs space and keep it compatible rather than fork it right away but you are free to do that neverthless regards Rahul From ivazquez at ivazquez.net Tue Aug 16 15:44:05 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 16 Aug 2005 11:44:05 -0400 Subject: "hard core" linux In-Reply-To: <430203CA.6090807@cornell.edu> References: <430203CA.6090807@cornell.edu> Message-ID: <1124207045.4453.20.camel@ignacio.lan> On Tue, 2005-08-16 at 11:18 -0400, Paul A Houle wrote: > a lot of very good ideas. I've been considering exactly the same thing, but I don't have the connectivity to seed such a torrent by myself. Does anyone think it would be worth starting such a fork? I'm willing to provide mailing lists if so. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 tadams-lists at myrealbox.com Tue Aug 16 15:52:28 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 16 Aug 2005 09:52:28 -0600 Subject: Open Office Message-ID: <1124207548.2842.6.camel@aurora.localdomain> Is open office planned to be removed from FC5? If not why is the following the situation: openoffice.org-core-1.9.117-3.1.0.fc4 openoffice.org-core-1.9.104-2 I am just trying to follow a little bit of the development as I usually try out test 1, etc. Thanks for a response. Trever Adams From tadams-lists at myrealbox.com Tue Aug 16 15:55:18 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 16 Aug 2005 09:55:18 -0600 Subject: Open Office In-Reply-To: <1124207548.2842.6.camel@aurora.localdomain> References: <1124207548.2842.6.camel@aurora.localdomain> Message-ID: <1124207718.2842.8.camel@aurora.localdomain> Please, disregard. I was looking at an out of date list. Have a good one. Trever Adams On Tue, 2005-08-16 at 09:52 -0600, Trever L. Adams wrote: > Is open office planned to be removed from FC5? If not why is the > following the situation: > > openoffice.org-core-1.9.117-3.1.0.fc4 > openoffice.org-core-1.9.104-2 > > I am just trying to follow a little bit of the development as I usually > try out test 1, etc. > > Thanks for a response. > > Trever Adams From vonbrand at inf.utfsm.cl Tue Aug 16 19:31:15 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 16 Aug 2005 15:31:15 -0400 Subject: Open Office In-Reply-To: Message from "Trever L. Adams" of "Tue, 16 Aug 2005 09:52:28 CST." <1124207548.2842.6.camel@aurora.localdomain> Message-ID: <200508161931.j7GJVFVj019776@laptop11.inf.utfsm.cl> Trever L. Adams wrote: > Is open office planned to be removed from FC5? If not why is the > following the situation: > > openoffice.org-core-1.9.117-3.1.0.fc4 > openoffice.org-core-1.9.104-2 Here (rawhide) I have openoffice.org-core-1.9.124-1.2.0.fc5 -- 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 zaitcev at redhat.com Tue Aug 16 20:01:50 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 16 Aug 2005 13:01:50 -0700 Subject: usbmon and DMA patch Message-ID: <20050816130150.4cd24179.zaitcev@redhat.com> Dave, I came around with the usbmon fix (although it's for i386 only at this time - I would gladly take a patch for x86_64). So, would you please drop the workaround in usb-storage, patch 1402, and apply the attached instead? -- Pete diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/Makefile linux-2.6.13-rc6-lem/drivers/usb/mon/Makefile --- linux-2.6.13-rc6/drivers/usb/mon/Makefile 2005-08-14 20:57:43.000000000 -0700 +++ linux-2.6.13-rc6-lem/drivers/usb/mon/Makefile 2005-08-15 11:25:32.000000000 -0700 @@ -2,7 +2,7 @@ # Makefile for USB Core files and filesystem # -usbmon-objs := mon_main.o mon_stat.o mon_text.o +usbmon-objs := mon_main.o mon_stat.o mon_text.o mon_dma.o # This does not use CONFIG_USB_MON because we want this to use a tristate. obj-$(CONFIG_USB) += usbmon.o diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/mon_dma.c linux-2.6.13-rc6-lem/drivers/usb/mon/mon_dma.c --- linux-2.6.13-rc6/drivers/usb/mon/mon_dma.c 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.6.13-rc6-lem/drivers/usb/mon/mon_dma.c 2005-08-15 16:11:51.000000000 -0700 @@ -0,0 +1,55 @@ +/* + * The USB Monitor, inspired by Dave Harding's USBMon. + * + * mon_dma.c: Library which snoops on DMA areas. + * + * Copyright (C) 2005 Pete Zaitcev (zaitcev at redhat.com) + */ +#include +#include +#include +#include + +#include /* Only needed for declarations in usb_mon.h */ +#include "usb_mon.h" + +#ifdef __i386__ /* CONFIG_ARCH_I386 does not exit */ +#define MON_HAS_UNMAP 1 + +#define phys_to_page(phys) pfn_to_page((phys) >> PAGE_SHIFT) + +char mon_dmapeek(unsigned char *dst, dma_addr_t dma_addr, int len) +{ + struct page *pg; + unsigned long flags; + unsigned char *map; + unsigned char *ptr; + + /* + * On i386, a DMA handle is the "physical" address of a page. + * In other words, the bus address is equal to physical address. + * There is no IOMMU. + */ + pg = phys_to_page(dma_addr); + + /* + * We are called from hardware IRQs in case of callbacks. + * But we can be called from softirq or process context in case + * of submissions. In such case, we need to protect KM_IRQ0. + */ + local_irq_save(flags); + map = kmap_atomic(pg, KM_IRQ0); + ptr = map + (dma_addr & (PAGE_SIZE-1)); + memcpy(dst, ptr, len); + kunmap_atomic(map, KM_IRQ0); + local_irq_restore(flags); + return 0; +} +#endif /* __i386__ */ + +#ifndef MON_HAS_UNMAP +char mon_dmapeek(unsigned char *dst, dma_addr_t dma_addr, int len) +{ + return 'D'; +} +#endif diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/mon_text.c linux-2.6.13-rc6-lem/drivers/usb/mon/mon_text.c --- linux-2.6.13-rc6/drivers/usb/mon/mon_text.c 2005-08-14 20:57:43.000000000 -0700 +++ linux-2.6.13-rc6-lem/drivers/usb/mon/mon_text.c 2005-08-15 11:44:13.000000000 -0700 @@ -91,25 +91,11 @@ static inline char mon_text_get_data(str int len, char ev_type) { int pipe = urb->pipe; - unsigned char *data; - - /* - * The check to see if it's safe to poke at data has an enormous - * number of corner cases, but it seems that the following is - * more or less safe. - * - * We do not even try to look transfer_buffer, because it can - * contain non-NULL garbage in case the upper level promised to - * set DMA for the HCD. - */ - if (urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) - return 'D'; if (len <= 0) return 'L'; - - if ((data = urb->transfer_buffer) == NULL) - return 'Z'; /* '0' would be not as pretty. */ + if (len >= DATA_MAX) + len = DATA_MAX; /* * Bulk is easy to shortcut reliably. @@ -126,8 +112,21 @@ static inline char mon_text_get_data(str } } - if (len >= DATA_MAX) - len = DATA_MAX; + /* + * The check to see if it's safe to poke at data has an enormous + * number of corner cases, but it seems that the following is + * more or less safe. + * + * We do not even try to look transfer_buffer, because it can + * contain non-NULL garbage in case the upper level promised to + * set DMA for the HCD. + */ + if (urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) + return mon_dmapeek(ep->data, urb->transfer_dma, len); + + if (urb->transfer_buffer == NULL) + return 'Z'; /* '0' would be not as pretty. */ + memcpy(ep->data, urb->transfer_buffer, len); return 0; } diff -urpN -X dontdiff linux-2.6.13-rc6/drivers/usb/mon/usb_mon.h linux-2.6.13-rc6-lem/drivers/usb/mon/usb_mon.h --- linux-2.6.13-rc6/drivers/usb/mon/usb_mon.h 2005-06-17 12:48:29.000000000 -0700 +++ linux-2.6.13-rc6-lem/drivers/usb/mon/usb_mon.h 2005-08-15 16:12:42.000000000 -0700 @@ -43,6 +45,10 @@ struct mon_reader { void mon_reader_add(struct mon_bus *mbus, struct mon_reader *r); void mon_reader_del(struct mon_bus *mbus, struct mon_reader *r); +/* + */ +extern char mon_dmapeek(unsigned char *dst, dma_addr_t dma_addr, int len); + extern struct semaphore mon_lock; extern struct file_operations mon_fops_text; From lamont at gurulabs.com Tue Aug 16 20:22:43 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 16 Aug 2005 14:22:43 -0600 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816104438.GB19323@devserv.devel.redhat.com> References: <1124138727.4294.21.camel@salem> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> Message-ID: <200508161422.49976.lamont@gurulabs.com> On Tuesday 16 August 2005 04:44am, Alan Cox wrote: > On Mon, Aug 15, 2005 at 04:54:56PM -0700, Jesse Keating wrote: > > years?) drives were DMA66, then DMA100, now DMA133. I half expected my > > laptop hdd to be at least DMA66, but seems to be stuck at 33. > > UDMA66 and higher requires 80 pin cables. Since almost no laptop drive is > fast enough to benefit from UDMA66 almost no laptops bother. You mean 80 wire cable on a 40-pin connector, right? Or does the connector use pins that are kind of like stereo headphone jacks? I'm not anywhere I can quickly look at such a drive, but I am pretty sure there are still only 40 pins. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- 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 camperquake.de Tue Aug 16 20:26:34 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 16 Aug 2005 22:26:34 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <200508161422.49976.lamont@gurulabs.com> References: <1124138727.4294.21.camel@salem> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> <200508161422.49976.lamont@gurulabs.com> Message-ID: <20050816202634.GB2317@ryoko.camperquake.de> On Tue, Aug 16, 2005 at 02:22:43PM -0600, Lamont R. Peterson wrote: > You mean 80 wire cable on a 40-pin connector, right? Yes. From alan at redhat.com Tue Aug 16 20:37:44 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Aug 2005 16:37:44 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <200508161422.49976.lamont@gurulabs.com> References: <1124138727.4294.21.camel@salem> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816104438.GB19323@devserv.devel.redhat.com> <200508161422.49976.lamont@gurulabs.com> Message-ID: <20050816203744.GA25136@devserv.devel.redhat.com> On Tue, Aug 16, 2005 at 02:22:43PM -0600, Lamont R. Peterson wrote: > You mean 80 wire cable on a 40-pin connector, right? Or does the connector > use pins that are kind of like stereo headphone jacks? I'm not anywhere I I do indeed - its still a 40 pin connector, my error From herrold at owlriver.com Tue Aug 16 20:57:02 2005 From: herrold at owlriver.com (R P Herrold) Date: Tue, 16 Aug 2005 16:57:02 -0400 (EDT) Subject: fedora-d-rh] "hard core" linux In-Reply-To: <430203CA.6090807@cornell.edu> References: <430203CA.6090807@cornell.edu> Message-ID: On Tue, 16 Aug 2005, Paul A Houle wrote: > Many of us can imagine our own personal perfect Fedora-derived > distribution, but really the challenge is to think of a coherent mission for > an alternative distribution (or series of alternative distributions) that > would be compelling to enough people that it could get some momentum. Any > ideas? Have you reviewed http://www.caosity.org/ ? From vonbrand at inf.utfsm.cl Tue Aug 16 21:01:42 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 16 Aug 2005 17:01:42 -0400 Subject: Open Office In-Reply-To: Your message of "Tue, 16 Aug 2005 15:31:15 -0400." <200508161931.j7GJVFVj019776@laptop11.inf.utfsm.cl> Message-ID: <200508162101.j7GL1geg027132@laptop11.inf.utfsm.cl> Horst von Brand wrote: > Trever L. Adams wrote: > > Is open office planned to be removed from FC5? If not why is the > > following the situation: > > > > openoffice.org-core-1.9.117-3.1.0.fc4 > > openoffice.org-core-1.9.104-2 > > Here (rawhide) I have openoffice.org-core-1.9.124-1.2.0.fc5 Sorry, no. Had to go back to 1.9.123-1.2.0.fc5, as today's version just hangs in the splashscreen (with the progress bar something like 1/6 of the way), and calling it again after killing that just does nothing. -- 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 bernie at develer.com Tue Aug 16 21:08:08 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Tue, 16 Aug 2005 23:08:08 +0200 Subject: KDE RedHat project Message-ID: <430255B8.5070600@develer.com> Hello, I've found this YUM repository aiming to replace the original Fedora/RedHat KDE with a complete version (will all important features enabled and lots of extra programs): http://kde-redhat.sourceforge.net/ KDE support in Fedora leaves much to be desired in terms of completeness. Couldn't some of this stuff be merged with Fedora Core and the rest put in Fedora Extras? Except for the few things with license or patent problems, of course. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From wtogami at redhat.com Tue Aug 16 21:12:02 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 16 Aug 2005 11:12:02 -1000 Subject: KDE RedHat project In-Reply-To: <430255B8.5070600@develer.com> References: <430255B8.5070600@develer.com> Message-ID: <430256A2.2060603@redhat.com> Bernardo Innocenti wrote: > Hello, > > I've found this YUM repository aiming to replace the original > Fedora/RedHat KDE with a complete version (will all important > features enabled and lots of extra programs): > > http://kde-redhat.sourceforge.net/ > > KDE support in Fedora leaves much to be desired in terms of > completeness. Couldn't some of this stuff be merged with > Fedora Core and the rest put in Fedora Extras? Except for the > few things with license or patent problems, of course. > Last I asked upstream KDE, many of the license or patent problematic parts of KDE are not easily splittable into tiny loadable modules, thus necessitating rebuilding large parts of KDE in order to enable them. Nothing has stopped those developers from submitting spec patches to FC KDE or additional packages to Extras if they don't have legal problems. Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Tue Aug 16 21:48:47 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 16 Aug 2005 17:48:47 -0400 Subject: fedora-d-rh] "hard core" linux In-Reply-To: References: <430203CA.6090807@cornell.edu> Message-ID: <1124228927.4453.26.camel@ignacio.lan> On Tue, 2005-08-16 at 16:57 -0400, R P Herrold wrote: > On Tue, 16 Aug 2005, Paul A Houle wrote: > > > Many of us can imagine our own personal perfect Fedora-derived > > distribution, but really the challenge is to think of a coherent mission for > > an alternative distribution (or series of alternative distributions) that > > would be compelling to enough people that it could get some momentum. Any > > ideas? > > Have you reviewed http://www.caosity.org/ ? That's not a Fedora fork per se, but a completely separate distro. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 camperquake.de Tue Aug 16 22:08:23 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 17 Aug 2005 00:08:23 +0200 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <1124205820.15701.22.camel@localhost.localdomain> References: <1124138727.4294.21.camel@salem> <20050815220924.GE9435@devserv.devel.redhat.com> <20050815230750.GA828@devserv.devel.redhat.com> <1124149148.28537.32.camel@prometheus.gamehouse.com> <20050816014308.2155017d@nausicaa.camperquake.de> <1124150096.28537.37.camel@prometheus.gamehouse.com> <20050816020137.154753e5@nausicaa.camperquake.de> <1124151063.28537.50.camel@prometheus.gamehouse.com> <1124205820.15701.22.camel@localhost.localdomain> Message-ID: <20050817000823.33e0b14b@nausicaa.camperquake.de> Hi. Jesse Keating wrote: > hda: 58605120 sectors (30005 MB) w/1768KiB Cache, CHS=58140/16/63, > UDMA(33) > > My drive is being set at UDMA(33) but I don't know if apples are at that > speed or if something isn't being detected right. It's the same on my iBook. As was said, UDMA66 and higher needs special cables, which at least notebooks seldom have. I have not found a way to get the UDMA mode used out of OSX. -- I pretend to work. They pretend to pay me. From zaitcev at redhat.com Tue Aug 16 22:10:04 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 16 Aug 2005 15:10:04 -0700 Subject: ioctl's and USB drives (and just plain ATA) In-Reply-To: References: <1123411879.6037.42.camel@athlon.localdomain> <42F70906.70805@feuerpokemon.de> <1123535941.6039.5.camel@athlon.localdomain> <1123612685.4989.16.camel@barsoom.rdu.redhat.com> Message-ID: <20050816151004.34a0aedc.zaitcev@redhat.com> On Tue, 09 Aug 2005 22:59:15 +0200, Leonard den Ottolander wrote: > On Tue, 2005-08-09 at 20:38, Jeff Layton wrote: > Back to square one :-s . Anyway, if the SCSI emulation layer is dropping > these commands it doesn't really matter if the USB device gets the > translation right. Is there a way to work around the SCSI emulation > layer so these commands at least get passed to the device? You seem to assume emulation, which is wrong. The typical USB drive enclosure uses actual SCSI commands, so there is no emulation. It is said that usb-storage emulates SCSI _adapter_, which is true in a way, but is not important. > Related question: If I want to use TASKFILE ioctls with a 2.4 kernel do >[...] > implement/improve the ATA security features in hdparm. Before you plunge into the taskfile, why don't you answer this: do these password commands conform to ATAPI or ATA? Again, you seem to assume ATA, but is this correct? Since ATAPI is SCSI overlaid on top of ATA, it should be a piece of cake to have them working. ATA is more difficult, but let's not go there until we must. And last, why in the world are you talking about 2.4 kernel in a Fedora development list? -- Pete From buildsys at redhat.com Wed Aug 17 11:25:30 2005 From: buildsys at redhat.com (Build System) Date: Wed, 17 Aug 2005 07:25:30 -0400 Subject: rawhide report: 20050817 changes Message-ID: <200508171125.j7HBPUTb032200@porkchop.devel.redhat.com> New package scim-chewing Chewing Chinese input method for SCIM Removed package libpixman Removed package libgal2 Updated Packages: GConf2-2.11.90-2 ---------------- * Tue Aug 16 2005 Ray Strode 2.11.90-2 - rebuild HelixPlayer-1:1.0.5-2 --------------------- * Thu Aug 18 2005 John (J5) Palmieri - 1:1.0.5-2 - Bump and rebuild for cairo ABI change NetworkManager-0.4-36.cvs20050811 --------------------------------- * Tue Aug 16 2005 Dan Williams - 0.4.36.cvs20050811 - Rebuild against new cairo/gtk at-spi-1.6.4-2 -------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt bind-24:9.3.1-10 ---------------- * Tue Aug 16 2005 Jason Vas Dias - 24:9.3.1-10 - Build with D-BUS patch by default; D-BUS support enabled with named -D option - Enable D-BUS for named_sdb also - fix sdb pgsql's zonetodb.c: must use isc_hash_create() before dns_db_create() - update fix for bug 160914 : test for RD=1 and ARCOUNT=0 also before trying next server - fix named.init script to handle named_sdb properly - fix named.init script checkconfig() to handle named '-c' option and make configtest, test, check configcheck synonyms binutils-2.16.91.0.2-3 ---------------------- * Tue Aug 16 2005 Jakub Jelinek 2.16.91.0.2-3 - update to 20050816 CVS - better fix for ld-cdtest - fix symbol version script parsing bug-buddy-1:2.11.1-2 -------------------- * Tue Aug 16 2005 Warren Togami - 2.11.1-2 - rebuild for new cairo cairo-0.9.2-2 ------------- * Tue Aug 16 2005 Kristian H??gsberg - 0.9.2-2 - Rebuild against new freetype to get rid of --rpath in cairo.pc. control-center-1:2.11.91-2 -------------------------- * Tue Aug 16 2005 Warren Togami - 1:2.11.91-2 - rebuild for new cairo dasher-3.2.15-4 --------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt desktop-printing-0.19-2 ----------------------- * Tue Aug 16 2005 Warren Togami - 0.19-2 - rebuild for new cairo dhcdbd-1.8-1 ------------ * Fri Aug 12 2005 Jason Vas Dias 1.8-1 - Allow named user permission to send in /etc/dbus-1/system.d/dhcdbd.conf - Fix bug 163711 addendum: handle non-existence of /etc/sysconfig/network dia-1:0.94-13 ------------- * Sat Apr 16 2005 Caolan McNamara - rebuild for new cairo soname eel2-2.11.91-1 -------------- * Tue Aug 16 2005 Matthias Clasen 2.11.91-1 - New upstream version eog-2.11.90-2 ------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt fonts-chinese-2.15-4 -------------------- * Tue Aug 16 2005 Akira TAGOH - 2.15-4 - Added cidfmap.zh_CN and cidfmap.zh_TW for the latest ghostscript. fonts-japanese-0.20050222-7 --------------------------- * Tue Aug 16 2005 Akira TAGOH - 0.20050222-7 - Added cidfmap.ja for the latest ghostscript. - Removed Kochi fonts. fonts-korean-1.0.11-6 --------------------- * Tue Aug 16 2005 Akira TAGOH - 1.0.11-6 - Added cidfmap.ko for the latest ghostscript. freetype-2.1.9-4 ---------------- * Tue Aug 16 2005 Kristian H??gsberg 2.1.9-4 - Fix freetype-config on 64 bit platforms. gail-1.8.4-2 ------------ * Tue Aug 16 2005 Matthias Clasen 1.8.4-2 - Rebuilt gaim-1:1.5.0-3.fc5 ------------------ gedit-1:2.11.91-1 ----------------- * Tue Aug 16 2005 Matthias Clasen - New upstream version ghostscript-8.15-0.rc4.3 ------------------------ * Tue Aug 16 2005 Tim Waugh 8.15-0.rc4.3 - Rebuilt for new cairo. gimp-2:2.2.8-3 -------------- * Tue Aug 16 2005 Nils Philippsen - rebuild gimp-print-4.2.7-12 ------------------- * Tue Aug 16 2005 Tim Waugh 4.2.7-12 - Rebuilt for new cairo. glade2-2.10.0-2 --------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt gnome-bluetooth-0.5.1-14 ------------------------ * Tue Aug 16 2005 Warren Togami 0.5.1-14 - rebuild for new cairo gnome-desktop-2.11.90-2 ----------------------- * Tue Aug 16 2005 Warren Togami - 2.11.90-2 - rebuild for new cairo gnome-games-1:2.11.4-1 ---------------------- * Tue Aug 16 2005 Matthias Clasen - New upstream version gnome-keyring-0.4.3-2 --------------------- * Tue Aug 16 2005 David Zeuthen 0.4.3-2 - Rebuilt gnome-keyring-manager-2.11.1-2 ------------------------------ * Tue Aug 16 2005 David Zeuthen - Rebuilt gnome-mag-0.12.1-2 ------------------ * Tue Aug 16 2005 Matthias Clasen - Rebuilt gnome-media-2.11.91-1 --------------------- * Tue Aug 16 2005 Warren Togami - 2.11.91-1 - rebuild for new cairo and 2.11.91 gnome-menus-2.11.91-1 --------------------- * Tue Aug 16 2005 Mark McLoughlin 2.11.91-1 - Update to 2.11.91 - Backport patch from HEAD to hopefully fix crasher (rh #165977) gnome-netstatus-2.11.90-2 ------------------------- * Tue Aug 16 2005 Warren Togami - 2.11.90-2 - rebuild for new cairo * Wed Aug 03 2005 Ray Strode - 2.11.90-1 - Update to upstream version 2.11.90 gnome-panel-2.11.91-3 --------------------- * Tue Aug 16 2005 Mark McLoughlin 2.11.91-3 - Rebuild for new cairo gnome-pilot-2.0.13-7.fc5 ------------------------ * Tue Aug 16 2005 David Malcolm - 2.0.13-7.fc5 - rebuild (required by new cairo package) gnome-python2-2.11.3-2 ---------------------- * Thu Aug 18 2005 John (J5) Palmieri - 2.11.3-2 - Bump and rebuild for cairo ABI change * Mon Jul 18 2005 John (J5) Palmieri - 2.11.3 - update to upstream 2.11.3 * Fri Mar 11 2005 John (J5) Palmieri - 2.10.0 - update to 2.10.0 - add a Requires line for gnome-python2-gnomevfs gnome-session-2.11.91-2 ----------------------- * Tue Aug 16 2005 Warren Togami - 2.11.91-2 - rebuild for new cairo gnome-system-monitor-2.11.91-3 ------------------------------ * Tue Aug 16 2005 David Zeuthen - Rebuilt * Thu Aug 11 2005 Ray Strode 2.11.91-2 - rebuilt gnome-terminal-2.11.2-1 ----------------------- * Tue Aug 16 2005 Warren Togami - 2.11.2-1 - rebuild for new cairo and 2.11.2 gnome-utils-1:2.11.91-3 ----------------------- * Tue Aug 16 2005 Warren Togami - 1:2.11.91-3 - rebuild for new cairo gnopernicus-0.11.4-1 -------------------- * Tue Aug 16 2005 Matthias Clasen 0.11.4-1 - New upstream version gok-1.0.5-4 ----------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt gstreamer-plugins-0.8.10-1 -------------------------- * Thu Aug 18 2005 John (J5) Palmieri - 0.8.10-1 - Upgrade to upstream version 0.8.10 - removed backported soundjuicer patch as it is in this release gthumb-2.6.6-2 -------------- * Thu Aug 18 2005 John (J5) Palmieri - 2.6.2-2 - Bump and rebuild for cairo ABI changes gtk2-engines-2.6.4-2 -------------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt gtksourceview-1.3.91-2 ---------------------- * Tue Aug 16 2005 Warren Togami - 1.3.91-2 - rebuild for new cairo iiimf-1:12.2-10 --------------- * Tue Aug 16 2005 Akira TAGOH - 1:12.2-10 - Rebuild jpilot-0.99.8-0.pre10.2 ----------------------- * Tue Aug 16 2005 Warren Togami 0.99.8-0.pre10.1 - rebuild for new cairo kasumi-0.9-3.fc5 ---------------- * Tue Aug 16 2005 Akira TAGOH - 0.9-3.fc5 - Rebuild kernel-2.6.12-1.1488_FC5 ------------------------ * Tue Aug 16 2005 Dave Jones - 2.6.13-rc6-git8 krb5-auth-dialog-0.2-6 ---------------------- * Tue Aug 16 2005 David Zeuthen - Rebuilt libbonoboui-2.10.0-2 -------------------- * Tue Aug 16 2005 Warren Togami - 2.10.0-2 - rebuild for new cairo libglade2-2.5.1-3 ----------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt libgnomecanvas-2.11.1-3 ----------------------- * Tue Aug 16 2005 Warren Togami - 2.11.1-3 - rebuild for new cairo * Tue Aug 16 2005 Matthias Clasen - Rebuilt libgnomeprintui22-2.11.0-2 -------------------------- * Tue Aug 16 2005 Matthias Clasen - Rebuilt libgtop2-2.11.91-1 ------------------ * Tue Aug 16 2005 Matthias Clasen - New upstream version libwnck-2.11.91-2 ----------------- * Tue Aug 16 2005 Warren Togami - 2.11.91-2 - rebuild for new cairo metacity-2.11.2-2 ----------------- * Tue Aug 16 2005 Warren Togami 2.11.2-2 - rebuild for new cairo nautilus-2.11.91-1 ------------------ * Tue Aug 16 2005 Matthias Clasen - New upstream release * Wed Aug 03 2005 Matthias Clasen 2.11.90-1 - New upstream release * Mon Jul 11 2005 Matthias Clasen 2.11.3-1 - Update to 2.11.3 nautilus-cd-burner-2.11.6-1 --------------------------- * Tue Aug 16 2005 Matthias Clasen - New upstream version netpbm-10.29-1 -------------- * Tue Aug 16 2005 Jindrich Novy 10.29-1 - update to 10.29 - drop upstreamed .libpm, .pnmtojpeg, .pbmtolj patches - update .CAN-2005-2471 patch - regenerate man pages nfs-utils-1.0.7-13 ------------------ * Tue Aug 16 2005 Steve Dickson 1.0.7-13 - Changed mountd to use stat64() (bz 165062) openssh-4.1p1-5 --------------- * Tue Aug 16 2005 Tomas Mraz 4.1p1-5 - use x11-ssh-askpass if openssh-askpass-gnome is not installed (#165207) - install ssh-copy-id from contrib (#88707) pilot-link-1:0.12.0-0.pre4.4 ---------------------------- * Tue Aug 16 2005 Than Ngo 0.12.0-0.pre4.4 - apply patch to fix pilot-xfer crash #166037 * Tue Jul 26 2005 Than Ngo 0.12.0-0.pre4.3 - apply patch to fix gcc warnings #164203 pygtk2-2.7.3-2 -------------- * Thu Aug 18 2005 John (J5) Palmieri - 2.7.3-2 - Bump and rebuild for cairo ABI changes redhat-rpm-config-8.0.39-1 -------------------------- * Tue Aug 16 2005 Elliot Lee - 8.0.39-1 - Fix #165416 scim-1.4.2-1 ------------ * Wed Aug 17 2005 Jens Petersen - 1.4.2-1 - 1.4.2 release * Thu Aug 11 2005 Jens Petersen - 1.4.1-1 - update to 1.4.1 bugfix release - source scim-qtimm script if present from scim xinput script * Mon Aug 01 2005 Jens Petersen - 1.4.0-3 - bring back the xinput alternatives settings for now - quote the postun readlink test (wcalee at myrealbox.com, #164674) scim-anthy-0.6.1-1.fc5 ---------------------- * Tue Aug 16 2005 Akira TAGOH - 0.6.1-1.fc5 - New upstream release. * Tue Aug 09 2005 Akira TAGOH - added dist tag in Release. scim-hangul-0.2.0-4.fc5 ----------------------- * Tue Aug 16 2005 Akira TAGOH - 0.2.0-4.fc5 - Rebuild. scim-qtimm-0.9.4-1 ------------------ * Wed Aug 17 2005 Jens Petersen - 0.9.4-1 - update to 0.9.4 selinux-policy-strict-1.25.4-3 ------------------------------ * Tue Aug 16 2005 Dan Walsh 1.25.4-3 - add can_access_pty macro - Add nsswitch_macro for lots of ldap fixes selinux-policy-targeted-1.25.4-3 -------------------------------- * Tue Aug 16 2005 Dan Walsh 1.25.4-3 - add can_access_pty macro - Add nsswitch_macro for lots of ldap fixes spamassassin-3.1.0-0.rc1.fc5 ---------------------------- * Tue Aug 16 2005 Warren Togami - 3.1.0-0.rc1 - 3.1.0-rc1 system-config-services-0.8.26-1 ------------------------------- * Tue Aug 16 2005 Nils Philippsen - 0.8.26 - revamp getting output from external commands (#162884) - package /usr/bin/serviceconf symlink (#165099) usermode-1.81-1 --------------- * Tue Aug 16 2005 Jindrich Novy 1.81-1 - apply SELinux functionality enhancement patch from Dan Walsh - rebuilt because of the new cairo vim-1:6.3.086-2 --------------- * Tue Aug 16 2005 Karsten Hopp 6.3.086-2 - rebuild vte-0.11.14-3.fc5 ----------------- * Tue Aug 16 2005 Warren Togami 0.11.14-3 - make python version automatic * Tue Aug 16 2005 Warren Togami 0.11.14-2 - remove huge and rarely needed devel docs - remove .a because nobody should be using this wireless-tools-1:28-0.pre8.5 ---------------------------- * Wed Aug 17 2005 Dan Williams 28-0.pre8 - Update to 28 pre8 xscreensaver-1:4.22-7 --------------------- * Tue Aug 16 2005 Warren Togami - 1:4.22-7 - rebuild for new cairo yum-2.4.0-1 ----------- * Tue Aug 16 2005 Jeremy Katz - 2.4.0-1 - update to 2.4.0 Broken deps for ppc ---------------------------------------------------------- setools-gui - 2.1.1-1.ppc requires libpixman.so.1 setools-gui - 2.1.1-1.ppc requires libcairo.so.1 gnome-python2-nautilus-cd-burner - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-nautilus-cd-burner - 2.11.4-5.ppc requires libcairo.so.1 gnome-python2-applet - 2.11.4-5.ppc requires libcairo.so.1 gnome-python2-applet - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-libegg - 2.11.4-5.ppc requires libcairo.so.1 gnome-python2-libegg - 2.11.4-5.ppc requires libpixman.so.1 file-roller - 2.11.90-1.ppc requires libpixman.so.1 file-roller - 2.11.90-1.ppc requires libcairo.so.1 libgnomeui - 2.11.2-1.ppc requires libcairo.so.1 libgnomeui - 2.11.2-1.ppc requires libpixman.so.1 gnome-python2-libwnck - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-libwnck - 2.11.4-5.ppc requires libcairo.so.1 scim-tables - 0.5.1-4.ppc requires libpixman.so.1 scim-tables - 0.5.1-4.ppc requires libcairo.so.1 devhelp - 0.10-3.ppc requires libcairo.so.1 devhelp - 0.10-3.ppc requires libpixman.so.1 gnome-python2-gtkspell - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-gtkspell - 2.11.4-5.ppc requires libcairo.so.1 sound-juicer - 2.11.3-1.ppc requires libcairo.so.1 sound-juicer - 2.11.3-1.ppc requires libpixman.so.1 gnomemeeting - 1.2.1-4.ppc requires libcairo.so.1 gnomemeeting - 1.2.1-4.ppc requires libpixman.so.1 yelp - 2.11.1-3.ppc requires libcairo.so.1 yelp - 2.11.1-3.ppc requires libpixman.so.1 evince - 0.3.2-2.ppc requires libcairo.so.1 evince - 0.3.2-2.ppc requires libpixman.so.1 gnome-python2-gtksourceview - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-gtksourceview - 2.11.4-5.ppc requires libcairo.so.1 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 vino - 2.11.90-1.ppc requires libcairo.so.1 vino - 2.11.90-1.ppc requires libpixman.so.1 totem - 1.1.3-1.ppc requires libcairo.so.1 totem - 1.1.3-1.ppc requires libpixman.so.1 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnome-python2-gtkmozembed - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-gtkmozembed - 2.11.4-5.ppc requires libcairo.so.1 gnome-applets - 1:2.11.91-2.ppc requires libcairo.so.1 gnome-applets - 1:2.11.91-2.ppc requires libpixman.so.1 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 libgcj - 4.0.1-8.ppc requires libcairo.so.1 libgcj - 4.0.1-8.ppc requires libpixman.so.1 gnome-python2-gnomeprint - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-gnomeprint - 2.11.4-5.ppc requires libcairo.so.1 gnome-python2-gtkhtml2 - 2.11.4-5.ppc requires libpixman.so.1 gnome-python2-gtkhtml2 - 2.11.4-5.ppc requires libcairo.so.1 gnome-python2-totem - 2.11.4-5.ppc requires libcairo.so.1 gnome-python2-totem - 2.11.4-5.ppc requires libpixman.so.1 evolution - 2.3.7-1.ppc requires libcairo.so.1 evolution - 2.3.7-1.ppc requires libpixman.so.1 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 openoffice.org-core - 1:1.9.124-1.2.0.fc5.ppc requires libcairo.so.1 openoffice.org-core - 1:1.9.124-1.2.0.fc5.ppc requires libpixman.so.1 Broken deps for s390x ---------------------------------------------------------- gnomemeeting - 1.2.1-4.s390x requires libpixman.so.1()(64bit) gnomemeeting - 1.2.1-4.s390x requires libcairo.so.1()(64bit) vino - 2.11.90-1.s390x requires libpixman.so.1()(64bit) vino - 2.11.90-1.s390x requires libcairo.so.1()(64bit) totem - 1.1.3-1.s390x requires libpixman.so.1()(64bit) totem - 1.1.3-1.s390x requires libcairo.so.1()(64bit) scim-tables - 0.5.1-4.s390x requires libpixman.so.1()(64bit) scim-tables - 0.5.1-4.s390x requires libcairo.so.1()(64bit) yelp - 2.11.1-3.s390x requires libpixman.so.1()(64bit) yelp - 2.11.1-3.s390x requires libcairo.so.1()(64bit) devhelp - 0.10-3.s390x requires libpixman.so.1()(64bit) devhelp - 0.10-3.s390x requires libcairo.so.1()(64bit) libgcj - 4.0.1-8.s390x requires libpixman.so.1()(64bit) libgcj - 4.0.1-8.s390x requires libcairo.so.1()(64bit) evince - 0.3.2-2.s390x requires libpixman.so.1()(64bit) evince - 0.3.2-2.s390x requires libcairo.so.1()(64bit) gnome-applets - 1:2.11.91-2.s390x requires libpixman.so.1()(64bit) gnome-applets - 1:2.11.91-2.s390x requires libcairo.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) evolution - 2.3.7-1.s390x requires libpixman.so.1()(64bit) evolution - 2.3.7-1.s390x requires libcairo.so.1()(64bit) file-roller - 2.11.90-1.s390x requires libpixman.so.1()(64bit) file-roller - 2.11.90-1.s390x requires libcairo.so.1()(64bit) libgnomeui - 2.11.2-1.s390x requires libpixman.so.1()(64bit) libgnomeui - 2.11.2-1.s390x requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.s390x requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.s390x requires libpixman.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) Broken deps for s390 ---------------------------------------------------------- gnomemeeting - 1.2.1-4.s390 requires libcairo.so.1 gnomemeeting - 1.2.1-4.s390 requires libpixman.so.1 evolution - 2.3.7-1.s390 requires libcairo.so.1 evolution - 2.3.7-1.s390 requires libpixman.so.1 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 nfs-utils - 1.0.7-13.s390 requires kernel >= 0:2.2.14 yelp - 2.11.1-3.s390 requires libcairo.so.1 yelp - 2.11.1-3.s390 requires libpixman.so.1 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 selinux-policy-strict-sources - 1.25.4-3.noarch requires kernel >= 0:2.6.11-1.1219 devhelp - 0.10-3.s390 requires libcairo.so.1 devhelp - 0.10-3.s390 requires libpixman.so.1 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 file-roller - 2.11.90-1.s390 requires libpixman.so.1 file-roller - 2.11.90-1.s390 requires libcairo.so.1 totem - 1.1.3-1.s390 requires libcairo.so.1 totem - 1.1.3-1.s390 requires libpixman.so.1 evince - 0.3.2-2.s390 requires libcairo.so.1 evince - 0.3.2-2.s390 requires libpixman.so.1 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-targeted - 1.25.4-3.noarch requires kernel >= 0:2.6.11-1.1219 setools-gui - 2.1.1-1.s390 requires libpixman.so.1 setools-gui - 2.1.1-1.s390 requires libcairo.so.1 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 scim-tables - 0.5.1-4.s390 requires libpixman.so.1 scim-tables - 0.5.1-4.s390 requires libcairo.so.1 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 gnome-applets - 1:2.11.91-2.s390 requires libcairo.so.1 gnome-applets - 1:2.11.91-2.s390 requires libpixman.so.1 selinux-policy-strict - 1.25.4-3.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 libgnomeui - 2.11.2-1.s390 requires libcairo.so.1 libgnomeui - 2.11.2-1.s390 requires libpixman.so.1 vino - 2.11.90-1.s390 requires libcairo.so.1 vino - 2.11.90-1.s390 requires libpixman.so.1 selinux-policy-targeted-sources - 1.25.4-3.noarch requires kernel >= 0:2.6.11-1.1219 libgcj - 4.0.1-8.s390 requires libcairo.so.1 libgcj - 4.0.1-8.s390 requires libpixman.so.1 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 Broken deps for ppc64 ---------------------------------------------------------- evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnome-python2-gnomeprint - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-gnomeprint - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) gnome-python2-libegg - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) gnome-python2-libegg - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-totem - 2.11.4-5.ppc64 requires mozilla >= 0:1.7.3 gnome-python2-totem - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-totem - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) gnome-python2-gtkhtml2 - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-gtkhtml2 - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) gnome-python2-gtksourceview - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-gtksourceview - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config sound-juicer - 2.11.3-1.ppc64 requires libpixman.so.1()(64bit) sound-juicer - 2.11.3-1.ppc64 requires libcairo.so.1()(64bit) gnome-applets - 1:2.11.91-2.ppc64 requires libpixman.so.1()(64bit) gnome-applets - 1:2.11.91-2.ppc64 requires libcairo.so.1()(64bit) scim-tables - 0.5.1-4.ppc64 requires libpixman.so.1()(64bit) scim-tables - 0.5.1-4.ppc64 requires libcairo.so.1()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnome-python2-libwnck - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-libwnck - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.ppc64 requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.ppc64 requires libpixman.so.1()(64bit) gnome-python2-gtkspell - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-gtkspell - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) vino - 2.11.90-1.ppc64 requires libpixman.so.1()(64bit) vino - 2.11.90-1.ppc64 requires libcairo.so.1()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot gnome-python2-applet - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) gnome-python2-applet - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.11.4-5.ppc64 requires libpixman.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.11.4-5.ppc64 requires libcairo.so.1()(64bit) libgnomeui - 2.11.2-1.ppc64 requires libpixman.so.1()(64bit) libgnomeui - 2.11.2-1.ppc64 requires libcairo.so.1()(64bit) libgcj - 4.0.1-8.ppc64 requires libpixman.so.1()(64bit) libgcj - 4.0.1-8.ppc64 requires libcairo.so.1()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evince - 0.3.2-2.ppc64 requires libpixman.so.1()(64bit) evince - 0.3.2-2.ppc64 requires libcairo.so.1()(64bit) gnomemeeting - 1.2.1-4.ppc64 requires libpixman.so.1()(64bit) gnomemeeting - 1.2.1-4.ppc64 requires libcairo.so.1()(64bit) totem - 1.1.3-1.ppc64 requires libpixman.so.1()(64bit) totem - 1.1.3-1.ppc64 requires libcairo.so.1()(64bit) firstboot - 1.3.44-1.noarch requires system-config-display file-roller - 2.11.90-1.ppc64 requires libpixman.so.1()(64bit) file-roller - 2.11.90-1.ppc64 requires libcairo.so.1()(64bit) Broken deps for i386 ---------------------------------------------------------- GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnome-python2-libegg - 2.11.4-5.i386 requires libcairo.so.1 gnome-python2-libegg - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-nautilus-cd-burner - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-nautilus-cd-burner - 2.11.4-5.i386 requires libcairo.so.1 gnomemeeting - 1.2.1-4.i386 requires libpixman.so.1 gnomemeeting - 1.2.1-4.i386 requires libcairo.so.1 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 scim-tables - 0.5.1-4.i386 requires libpixman.so.1 scim-tables - 0.5.1-4.i386 requires libcairo.so.1 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 openoffice.org-core - 1:1.9.124-1.2.0.fc5.i386 requires libcairo.so.1 openoffice.org-core - 1:1.9.124-1.2.0.fc5.i386 requires libpixman.so.1 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 vino - 2.11.90-1.i386 requires libcairo.so.1 vino - 2.11.90-1.i386 requires libpixman.so.1 devhelp - 0.10-3.i386 requires libcairo.so.1 devhelp - 0.10-3.i386 requires libpixman.so.1 gnome-python2-gtkspell - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-gtkspell - 2.11.4-5.i386 requires libcairo.so.1 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnome-python2-applet - 2.11.4-5.i386 requires libcairo.so.1 gnome-python2-applet - 2.11.4-5.i386 requires libpixman.so.1 libgcj - 4.0.1-8.i386 requires libcairo.so.1 libgcj - 4.0.1-8.i386 requires libpixman.so.1 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 file-roller - 2.11.90-1.i386 requires libpixman.so.1 file-roller - 2.11.90-1.i386 requires libcairo.so.1 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU evolution - 2.3.7-1.i386 requires libcairo.so.1 evolution - 2.3.7-1.i386 requires libpixman.so.1 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnome-python2-totem - 2.11.4-5.i386 requires libcairo.so.1 gnome-python2-totem - 2.11.4-5.i386 requires libpixman.so.1 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnome-python2-gnomeprint - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-gnomeprint - 2.11.4-5.i386 requires libcairo.so.1 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnome-python2-gtkmozembed - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-gtkmozembed - 2.11.4-5.i386 requires libcairo.so.1 setools-gui - 2.1.1-1.i386 requires libpixman.so.1 setools-gui - 2.1.1-1.i386 requires libcairo.so.1 gnome-applets - 1:2.11.91-2.i386 requires libcairo.so.1 gnome-applets - 1:2.11.91-2.i386 requires libpixman.so.1 sound-juicer - 2.11.3-1.i386 requires libcairo.so.1 sound-juicer - 2.11.3-1.i386 requires libpixman.so.1 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 yelp - 2.11.1-3.i386 requires libcairo.so.1 yelp - 2.11.1-3.i386 requires libpixman.so.1 gnome-python2-libwnck - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-libwnck - 2.11.4-5.i386 requires libcairo.so.1 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 libgnomeui - 2.11.2-1.i386 requires libcairo.so.1 libgnomeui - 2.11.2-1.i386 requires libpixman.so.1 evince - 0.3.2-2.i386 requires libcairo.so.1 evince - 0.3.2-2.i386 requires libpixman.so.1 gnome-python2-gtkhtml2 - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-gtkhtml2 - 2.11.4-5.i386 requires libcairo.so.1 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU totem - 1.1.3-1.i386 requires libcairo.so.1 totem - 1.1.3-1.i386 requires libpixman.so.1 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnome-python2-gtksourceview - 2.11.4-5.i386 requires libpixman.so.1 gnome-python2-gtksourceview - 2.11.4-5.i386 requires libcairo.so.1 Broken deps for ia64 ---------------------------------------------------------- sound-juicer - 2.11.3-1.ia64 requires libpixman.so.1()(64bit) sound-juicer - 2.11.3-1.ia64 requires libcairo.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs gnome-python2-gtkmozembed - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-gtkmozembed - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) file-roller - 2.11.90-1.ia64 requires libpixman.so.1()(64bit) file-roller - 2.11.90-1.ia64 requires libcairo.so.1()(64bit) gnome-python2-gnomeprint - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-gnomeprint - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.ia64 requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.ia64 requires libpixman.so.1()(64bit) scim-tables - 0.5.1-4.ia64 requires libpixman.so.1()(64bit) scim-tables - 0.5.1-4.ia64 requires libcairo.so.1()(64bit) gnome-python2-gtkhtml2 - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-gtkhtml2 - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-python2-libwnck - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-libwnck - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) libgnomeui - 2.11.2-1.ia64 requires libpixman.so.1()(64bit) libgnomeui - 2.11.2-1.ia64 requires libcairo.so.1()(64bit) gnome-python2-applet - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-python2-applet - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) libgcj - 4.0.1-8.ia64 requires libpixman.so.1()(64bit) libgcj - 4.0.1-8.ia64 requires libcairo.so.1()(64bit) evince - 0.3.2-2.ia64 requires libpixman.so.1()(64bit) evince - 0.3.2-2.ia64 requires libcairo.so.1()(64bit) gnome-python2-gtksourceview - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-gtksourceview - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-applets - 1:2.11.91-2.ia64 requires libpixman.so.1()(64bit) gnome-applets - 1:2.11.91-2.ia64 requires libcairo.so.1()(64bit) gnomemeeting - 1.2.1-4.ia64 requires libpixman.so.1()(64bit) gnomemeeting - 1.2.1-4.ia64 requires libcairo.so.1()(64bit) devhelp - 0.10-3.ia64 requires libcairo.so.1()(64bit) devhelp - 0.10-3.ia64 requires libpixman.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-python2-gtkspell - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-gtkspell - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-python2-totem - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) gnome-python2-totem - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-python2-libegg - 2.11.4-5.ia64 requires libcairo.so.1()(64bit) gnome-python2-libegg - 2.11.4-5.ia64 requires libpixman.so.1()(64bit) yelp - 2.11.1-3.ia64 requires libcairo.so.1()(64bit) yelp - 2.11.1-3.ia64 requires libpixman.so.1()(64bit) evolution - 2.3.7-1.ia64 requires libpixman.so.1()(64bit) evolution - 2.3.7-1.ia64 requires libcairo.so.1()(64bit) vino - 2.11.90-1.ia64 requires libpixman.so.1()(64bit) vino - 2.11.90-1.ia64 requires libcairo.so.1()(64bit) totem - 1.1.3-1.ia64 requires libpixman.so.1()(64bit) totem - 1.1.3-1.ia64 requires libcairo.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 libgcj - 4.0.1-8.x86_64 requires libpixman.so.1()(64bit) libgcj - 4.0.1-8.x86_64 requires libcairo.so.1()(64bit) cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 setools-gui - 2.1.1-1.x86_64 requires libcairo.so.1()(64bit) setools-gui - 2.1.1-1.x86_64 requires libpixman.so.1()(64bit) devhelp - 0.10-3.x86_64 requires libpixman.so.1()(64bit) devhelp - 0.10-3.x86_64 requires libcairo.so.1()(64bit) gnome-python2-applet - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnome-python2-applet - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) libgnomeui - 2.11.2-1.x86_64 requires libpixman.so.1()(64bit) libgnomeui - 2.11.2-1.x86_64 requires libcairo.so.1()(64bit) gnome-python2-libwnck - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-libwnck - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 yelp - 2.11.1-3.x86_64 requires libpixman.so.1()(64bit) yelp - 2.11.1-3.x86_64 requires libcairo.so.1()(64bit) libgcj - 4.0.1-8.i386 requires libcairo.so.1 libgcj - 4.0.1-8.i386 requires libpixman.so.1 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnome-python2-gtkspell - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-gtkspell - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) totem - 1.1.3-1.x86_64 requires libpixman.so.1()(64bit) totem - 1.1.3-1.x86_64 requires libcairo.so.1()(64bit) GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 evolution - 2.3.7-1.x86_64 requires libpixman.so.1()(64bit) evolution - 2.3.7-1.x86_64 requires libcairo.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-nautilus-cd-burner - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnome-python2-totem - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-totem - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnome-python2-gtkmozembed - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-gtkmozembed - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnome-python2-libegg - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnome-python2-libegg - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-gnomeprint - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-gnomeprint - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) gnome-python2-gtksourceview - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-gtksourceview - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) sound-juicer - 2.11.3-1.x86_64 requires libpixman.so.1()(64bit) sound-juicer - 2.11.3-1.x86_64 requires libcairo.so.1()(64bit) vino - 2.11.90-1.x86_64 requires libpixman.so.1()(64bit) vino - 2.11.90-1.x86_64 requires libcairo.so.1()(64bit) dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnome-python2-gtkhtml2 - 2.11.4-5.x86_64 requires libpixman.so.1()(64bit) gnome-python2-gtkhtml2 - 2.11.4-5.x86_64 requires libcairo.so.1()(64bit) scim-tables - 0.5.1-4.x86_64 requires libpixman.so.1()(64bit) scim-tables - 0.5.1-4.x86_64 requires libcairo.so.1()(64bit) openoffice.org-core - 1:1.9.124-1.2.0.fc5.i386 requires libcairo.so.1 openoffice.org-core - 1:1.9.124-1.2.0.fc5.i386 requires libpixman.so.1 evince - 0.3.2-2.x86_64 requires libpixman.so.1()(64bit) evince - 0.3.2-2.x86_64 requires libcairo.so.1()(64bit) gnomemeeting - 1.2.1-4.x86_64 requires libpixman.so.1()(64bit) gnomemeeting - 1.2.1-4.x86_64 requires libcairo.so.1()(64bit) file-roller - 2.11.90-1.x86_64 requires libpixman.so.1()(64bit) file-roller - 2.11.90-1.x86_64 requires libcairo.so.1()(64bit) GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnome-applets - 1:2.11.91-2.x86_64 requires libpixman.so.1()(64bit) gnome-applets - 1:2.11.91-2.x86_64 requires libcairo.so.1()(64bit) From kyrre at solution-forge.net Wed Aug 17 11:47:01 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 17 Aug 2005 13:47:01 +0200 Subject: Suspend/Restore in the newest kernels In-Reply-To: <4301922E.1090908@feuerpokemon.de> References: <1124174478.18021.1.camel@localhost> <4301922E.1090908@feuerpokemon.de> Message-ID: <1124279220.3399.1.camel@localhost.localdomain> tir, 16.08.2005 kl. 09.13 skrev dragoran: > Paul wrote: > > >Hi, > > > >Just a quick question, how do I trigger a sleep & restore with the > >newest kernels? I'd imagine it's a key combination, but don't know what > >it is. > > > >There is such a thing using battstat, but nothing else I can see. > > > >TTFN > > > >Paul > > > > > http://www.redhat.com/archives/fedora-devel-list/2005-August/msg00143.html What about: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166097 (if we are talking ACPI suspend/resume) From michel.mengis at epfl.ch Wed Aug 17 12:15:57 2005 From: michel.mengis at epfl.ch (Michel MENGIS) Date: Wed, 17 Aug 2005 14:15:57 +0200 Subject: DVD Burner speed trouble on FC4 Message-ID: <200508171316.j7HDG355002910@mx3.redhat.com> Dear sirs, I?m using a DELL Latitude D810 with a DVD Burner. I installed a FC4 (full installation), and I upgraded it using yum. So I?m running 2.6.12-1.1398-FC4 My DVD Burner is a NEC DVD+-RW ND-6500A. By doing this test: Copy a 2Gb file from the DVD to the harddisk. On windows: 4minutes 3 seconds On linux: 27 minutes. hdparm ?I /dev/hdc tells me that DMA isn?t activated hdparm ?d 1 /dev/hdc tells me that I?m not allowed to activate DMA on the DVD burner Why ? How to bring my DVD to work on linux as on windows ? Best regards, Michel MENGIS__________________________ POSEIDON Project Manager EPFL - DIT - DIT-SB Ecole Polytechnique F?d?rale de Lausanne Swiss Federal Institut of Technology Lausanne Tel: (+41) 021 693 2266 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vherva at viasys.com Wed Aug 17 13:24:04 2005 From: vherva at viasys.com (Ville Herva) Date: Wed, 17 Aug 2005 16:24:04 +0300 Subject: [PATCH] mkinitrd rescue mode Message-ID: <20050817132404.GK21004@viasys.com> Sorry for coming in the discussion this late. I would just like to give one user perspective opinion. Feel free to ignore. First, I think this is a valuable idea. Example: just recently I had problem problem booting an RHEL3 installation with root on LVM, see: http://groups-beta.google.com/group/linux.kernel/browse_thread/thread/45c538b12f6e3c51/2988b9d6415a9396?lnk=st&q=lvm2+vherva&rnum=1&hl=en#2988b9d6415a9396 After 2.6.10-ac8 -> 2.6.12.5 upgrade, the initramfs init script no longer detected the lvm partitions before attempting to mount rootfs. A simple "sleep 5" in the init script between lvm scan and mount "solved" the problem. Why? No idea. This is with the new mkinird package from Fedora. (Why 2.6.x on RHEL3? Unsolved data corruption bugs with the RHEL3 2.4.x kernel and driver support. Long story. Mostly 2.6 works great on RHEL3.) I know this is a bad example, because you will dismiss it ("you're an idiot to run 2.6 on RHEL3 - run stock kernel -> no problem), but this is not the only case where this can happen. An LVM config change, kernel upgrade changes hw detection, etc etc. Anyway, when booting I only got the "mount: error 6 mounting ext3" error. No very helpful. I added debug to the initramfs initscript, but the lvm messages didn't tell much, appeared randomly on screen out of sync, and scrolled out of screen. I didn't have a serial console at hand, and netconsole doesn't work at that phase (would be nice - I did try with statically compiled netconsole and grub command line option, but had no luck - that would probably work if configured correctly, though. For stock installation where netconsole is a module, it might make sense to add the module in the rescue initrd if it is ever implemented.) The rescue cd option doesn't help, since it's the kernel I'm booting that is at failing. In such case a rescue mode would be *very* useful. Peter Jones wrote: > I don't buy that at all. If, as you state below, we're seeing lots of > cases where machines don't boot after upgrades, then there's a bug in > something. Period. Sure this is a bug somewhere. Even if it will be fixed eventually (doubtful), it doesn't help me much when I need to get the server up. To me, it makes sense to be prepared for risks, even if they "shouldn't" happen. My point is that these boot problems *do* happen. This is by far not the only such problem I've seen - LVM for example seems to produce them fairly often. Eventually I get them solved, but it can take hours. I don't call RH about them (if there's a bug I report it, of course), and even if I did I still probably need to get some decent debug information. RH support is not exactly psychic either. A rescue mode with some tools would save a *whole* lot of valuable time in these cases. I hope the "add-in" rescue init cpio idea can be considered, even though it may add some complexity. just my two cents, -- v -- v at iki.fi From i.pilcher at comcast.net Wed Aug 17 14:20:36 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 17 Aug 2005 09:20:36 -0500 Subject: KDE RedHat project In-Reply-To: <430255B8.5070600@develer.com> References: <430255B8.5070600@develer.com> Message-ID: Bernardo Innocenti wrote: > I've found this YUM repository aiming to replace the original > Fedora/RedHat KDE with a complete version (will all important > features enabled and lots of extra programs): I've looked at the web site, but there's not a lot of information there. What important features and extra programs am I missing? -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From sundaram at redhat.com Wed Aug 17 15:18:06 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 17 Aug 2005 20:48:06 +0530 Subject: download directory Message-ID: <4303552E.7060801@redhat.com> Hi I would like to propose a couple of changes to the way download directories are organised currently * Move boot.iso image to ISO folder. Many users do not look into os/images and are unaware that a net installation method exists. * Move Source ISO images into a different directory. Mirrors can choose not to copy them. Many new users end up downloading this instead of the binary ISO images regards Rahul From russell at coker.com.au Wed Aug 17 15:28:41 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 18 Aug 2005 01:28:41 +1000 Subject: "hard core" linux In-Reply-To: <430207EB.3030800@redhat.com> References: <430203CA.6090807@cornell.edu> <430207EB.3030800@redhat.com> Message-ID: <200508180128.45161.russell@coker.com.au> On Wednesday 17 August 2005 01:36, Rahul Sundaram wrote: > * Hardened version of Fedora with strict or MLS policy by default That's been on my todo list for a while. I've got a kickstart configuration that converts the machine to strict policy in the %post so that the first boot does a relabel to the correct context. Doing the same thing with MLS would be quite easy. The next step would be a modification of the 6M isolinux image that is used for booting CDs and a modification of the equivalent image for USB mass storage devices so that a kickstart or NFS/HTTP install can proceed with full strict or MLS policy. Making a new CD1 image to do this would be easy enough technically, but distributing it would be a PITA. I can put a 6M kickstart CD image on my web server with no issue, but a 650M CD1 image would require using bittorrent (not impossible, just more effort). There are a few side projects that I will do as part of this. I am giving a talk to my local LUG on BitTorrent in the near future - hopefully that will get me a decent pool of people willing to use their bandwidth to help me out if I need to distribute CD images. I also plan to write some articles on kickstart as some of the KS things I'm doing are fairly tricky and are mostly undocumented. I may even get around to adding new features to system-config-kickstart to support software RAID-6 and LVM (as a general rule I only do install via kickstart). How much interest is there in these things? If you just want to say "I'm interested" then please use private mail. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From felipe.alfaro at gmail.com Wed Aug 17 15:34:59 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Wed, 17 Aug 2005 17:34:59 +0200 Subject: KDE RedHat project In-Reply-To: References: <430255B8.5070600@develer.com> Message-ID: <6f6293f1050817083424028fa9@mail.gmail.com> > Bernardo Innocenti wrote: > > I've found this YUM repository aiming to replace the original > > Fedora/RedHat KDE with a complete version (will all important > > features enabled and lots of extra programs): > > I've looked at the web site, but there's not a lot of information there. > What important features and extra programs am I missing? Also, I've been unable to locate SRPM files or .spec files for the RPM packages they publish. From stickster at gmail.com Wed Aug 17 15:38:41 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 17 Aug 2005 11:38:41 -0400 Subject: download directory In-Reply-To: <4303552E.7060801@redhat.com> References: <4303552E.7060801@redhat.com> Message-ID: <1124293121.10371.7.camel@localhost.localdomain> On Wed, 2005-08-17 at 20:48 +0530, Rahul Sundaram wrote: > Hi > > I would like to propose a couple of changes to the way download > directories are organised currently > > * Move boot.iso image to ISO folder. Many users do not look into > os/images and are unaware that a net installation method exists. s/Move/Copy/ would make this work better for folks who do use it regularly from its current location. > * Move Source ISO images into a different directory. Mirrors can choose > not to copy them. Many new users end up downloading this instead of the > binary ISO images Do you have numbers to support the claim of "many" here? ;-) Better documentation would go a long way to fixing this problem rather than reorganizing the site. The proposed retooling of the front project pages on f-marketing-l is a major step toward that goal. Maybe a boilerplate README in the ISO folder would also be helpful, since I would think new users haven't yet become cynical about the file name "README." :-) -- 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/ From jos at xos.nl Wed Aug 17 15:42:21 2005 From: jos at xos.nl (Jos Vos) Date: Wed, 17 Aug 2005 17:42:21 +0200 Subject: download directory In-Reply-To: <1124293121.10371.7.camel@localhost.localdomain>; from stickster@gmail.com on Wed, Aug 17, 2005 at 11:38:41AM -0400 References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> Message-ID: <20050817174221.B27031@xos037.xos.nl> On Wed, Aug 17, 2005 at 11:38:41AM -0400, Paul W. Frields wrote: > On Wed, 2005-08-17 at 20:48 +0530, Rahul Sundaram wrote: > > > * Move Source ISO images into a different directory. Mirrors can choose > > not to copy them. Many new users end up downloading this instead of the > > binary ISO images > > Do you have numbers to support the claim of "many" here? ;-) And mirrors choosing to not carry the sources should be discouraged to do so, IMHO. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ivazquez at ivazquez.net Wed Aug 17 15:41:39 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 17 Aug 2005 11:41:39 -0400 Subject: download directory In-Reply-To: <4303552E.7060801@redhat.com> References: <4303552E.7060801@redhat.com> Message-ID: <1124293300.4453.45.camel@ignacio.lan> On Wed, 2005-08-17 at 20:48 +0530, Rahul Sundaram wrote: > I would like to propose a couple of changes to the way download > directories are organised currently > > * Move boot.iso image to ISO folder. Many users do not look into > os/images and are unaware that a net installation method exists. > * Move Source ISO images into a different directory. Mirrors can choose > not to copy them. Many new users end up downloading this instead of the > binary ISO images +1 on both counts. 2 fairly common install problems in the IRC channel are that the netboot image isn't straightforward to get to, and that the person has burned the SRPMS discs instead of the binary discs. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at redhat.com Wed Aug 17 15:45:26 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 17 Aug 2005 21:15:26 +0530 Subject: download directory In-Reply-To: <1124293121.10371.7.camel@localhost.localdomain> References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> Message-ID: <43035B96.6060509@redhat.com> Paul W. Frields wrote: >On Wed, 2005-08-17 at 20:48 +0530, Rahul Sundaram wrote: > > >>Hi >> >>I would like to propose a couple of changes to the way download >>directories are organised currently >> >>* Move boot.iso image to ISO folder. Many users do not look into >>os/images and are unaware that a net installation method exists. >> >> > >s/Move/Copy/ would make this work better for folks who do use it >regularly from its current location. > > Symlink then. > > >>* Move Source ISO images into a different directory. Mirrors can choose >>not to copy them. Many new users end up downloading this instead of the >>binary ISO images >> >> > >Do you have numbers to support the claim of "many" here? ;-) > > No. Not exact numbers but if you sit on #fedora on freenode especially on new releases you can find a considerably large people doing this mistake. Search in fedoraforum.org or in fedora-list for other instances. I appreciate the work being done on the installation guide but end users often (dont ask me how often ;-) ) dont read them. a README does sound like a good idea neverthless but the proposal to move the source images into a different directory has the purpose of making mirroring easier for those who want to skip them assuming that the large majority of end users dont require it regards Rahul From rdieter at math.unl.edu Wed Aug 17 15:46:33 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Aug 2005 10:46:33 -0500 Subject: KDE RedHat project In-Reply-To: References: <430255B8.5070600@develer.com> Message-ID: <43035BD9.104@math.unl.edu> Ian Pilcher wrote: > Bernardo Innocenti wrote: > >> I've found this YUM repository aiming to replace the original >> Fedora/RedHat KDE with a complete version (will all important >> features enabled and lots of extra programs): > > > I've looked at the web site, but there's not a lot of information there. > What important features and extra programs am I missing? It depends greatly on which os release you're using, but mostly adding in dependancies from Extras, livna.org (and a few not in either yet) to get extra features. A short list (off the top of my head) includes: * arts,kdemultimedia: multimedia goodies, since Fedora either legally or ethically(non-opensource) can't/won't. Examples, lame(mp3), libmad(mp3), xine-lib support. (all thanks to livna.org) * kdepim: crypto(gpgme/gpg-agent, see https://bugzilla.redhat.com/bugzilla/136533), gnokii, libmal support * kdelibs,kdegraphics: JPEG2000(jasper), OpenEXR support * kdelibs,kdebase,kdenetwork: mDNSResponder support * kdenetwork: openslp, meanwhile support * kdebase: dbus-qt/hal support -- Rex From rdieter at math.unl.edu Wed Aug 17 15:46:33 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Aug 2005 10:46:33 -0500 Subject: KDE RedHat project In-Reply-To: References: <430255B8.5070600@develer.com> Message-ID: <43035BD9.104@math.unl.edu> Ian Pilcher wrote: > Bernardo Innocenti wrote: > >> I've found this YUM repository aiming to replace the original >> Fedora/RedHat KDE with a complete version (will all important >> features enabled and lots of extra programs): > > > I've looked at the web site, but there's not a lot of information there. > What important features and extra programs am I missing? It depends greatly on which os release you're using, but mostly adding in dependancies from Extras, livna.org (and a few not in either yet) to get extra features. A short list (off the top of my head) includes: * arts,kdemultimedia: multimedia goodies, since Fedora either legally or ethically(non-opensource) can't/won't. Examples, lame(mp3), libmad(mp3), xine-lib support. (all thanks to livna.org) * kdepim: crypto(gpgme/gpg-agent, see https://bugzilla.redhat.com/bugzilla/136533), gnokii, libmal support * kdelibs,kdegraphics: JPEG2000(jasper), OpenEXR support * kdelibs,kdebase,kdenetwork: mDNSResponder support * kdenetwork: openslp, meanwhile support * kdebase: dbus-qt/hal support -- Rex From rdieter at math.unl.edu Wed Aug 17 16:21:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Aug 2005 11:21:56 -0500 Subject: KDE RedHat project In-Reply-To: <6f6293f1050817083424028fa9@mail.gmail.com> References: <430255B8.5070600@develer.com> <6f6293f1050817083424028fa9@mail.gmail.com> Message-ID: <43036424.1070206@math.unl.edu> Felipe Alfaro Solana wrote: >>Bernardo Innocenti wrote: >> >>>I've found this YUM repository aiming to replace the original >>>Fedora/RedHat KDE with a complete version (will all important >>>features enabled and lots of extra programs): >> >>I've looked at the web site, but there's not a lot of information there. >>What important features and extra programs am I missing? > Also, I've been unable to locate SRPM files or .spec files for the RPM > packages they publish. It's all in the yum/apt repo: http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.* -- Rex From loris at cantv.net Wed Aug 17 15:52:35 2005 From: loris at cantv.net (Loris Santamaria) Date: Wed, 17 Aug 2005 11:52:35 -0400 Subject: Modular initrd [was Re: [PATCH] mkinitrd rescue mode] In-Reply-To: <20050817132404.GK21004@viasys.com> References: <20050817132404.GK21004@viasys.com> Message-ID: <1124293954.11253.14.camel@byblos.lgs.com.ve> What about a modular initrd, similar to what is fond in Debian? Recently I had to patch the mkinitrd script to add support for the swsuspend2 patch, and later I had to patch the script again to support the i855resolution utility to properly resume from hibernation. Maybe there could be an /etc/initrd directory with a structure like this: /etc | ---initrd/ | |--bin/ |--modules ---scripts/ | |--10makedev.sh |--20modules.sh |--30raid.sh |--40lvm.sh |--50rescue.sh ---90pivot.sh so one could easily add extra utilities, modules and scripts to that directory structure, and the mkinitrd script could build the initrd based on the contents of the directory. No more mkinitrd patching required. Loris From arjanv at redhat.com Wed Aug 17 16:32:27 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 17 Aug 2005 18:32:27 +0200 Subject: Modular initrd [was Re: [PATCH] mkinitrd rescue mode] In-Reply-To: <1124293954.11253.14.camel@byblos.lgs.com.ve> References: <20050817132404.GK21004@viasys.com> <1124293954.11253.14.camel@byblos.lgs.com.ve> Message-ID: <1124296347.3220.26.camel@laptopd505.fenrus.org> On Wed, 2005-08-17 at 11:52 -0400, Loris Santamaria wrote: > What about a modular initrd, similar to what is fond in Debian? how about something slightly different... 2.6 kernel initrd's are cpio archives. And the kernelm supports catting multiple of these together and the kernel then untars then one after another... soo... all that's needed is having a /boot/initrd.local image that mkinitrd always appends to the initrd it creates.. and inside that image you can do what you want. And then maybe some tool to create that initrd.local from some dir or something. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at redhat.com Wed Aug 17 17:12:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 17 Aug 2005 22:42:47 +0530 Subject: KDE RedHat project In-Reply-To: <43035BD9.104@math.unl.edu> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> Message-ID: <4303700F.4090109@redhat.com> Hi > > It depends greatly on which os release you're using, but mostly adding > in dependancies from Extras, livna.org (and a few not in either yet) > to get extra features. A short list (off the top of my head) includes: > * arts,kdemultimedia: multimedia goodies, since Fedora either legally > or ethically(non-opensource) can't/won't. Examples, lame(mp3), > libmad(mp3), xine-lib support. (all thanks to livna.org) > * kdepim: crypto(gpgme/gpg-agent, see > https://bugzilla.redhat.com/bugzilla/136533), gnokii, libmal support > * kdelibs,kdegraphics: JPEG2000(jasper), OpenEXR support > * kdelibs,kdebase,kdenetwork: mDNSResponder support > * kdenetwork: openslp, meanwhile support > * kdebase: dbus-qt/hal support The Livna repository can continue to provide the restricted components. It would great if you can file a bug report for the rest. regards Rahul From felipe.alfaro at gmail.com Wed Aug 17 18:05:30 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Wed, 17 Aug 2005 20:05:30 +0200 Subject: KDE RedHat project In-Reply-To: <43036424.1070206@math.unl.edu> References: <430255B8.5070600@develer.com> <6f6293f1050817083424028fa9@mail.gmail.com> <43036424.1070206@math.unl.edu> Message-ID: <6f6293f10508171105738cb17c@mail.gmail.com> > > Also, I've been unable to locate SRPM files or .spec files for the RPM > > packages they publish. > > It's all in the yum/apt repo: > http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.* Great. Thanks! From nman64 at n-man.com Wed Aug 17 20:10:31 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Wed, 17 Aug 2005 15:10:31 -0500 Subject: created account in Fedorawiki In-Reply-To: <1124306954.3225.5.camel@NB-Fedora.homenet.local> References: <1124306954.3225.5.camel@NB-Fedora.homenet.local> Message-ID: <430399B7.1090809@n-man.com> Gerold Kassube wrote: >Hi Peter, > >in order of the homepage of fedorawiki >(http://fedoraproject.org/wiki/FrontPage), I'd like to ask you if you >can add me (GeroldKassube) to the add group ... > >Thanks in advance for your patient help > > > Done. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From vherva at vianova.fi Wed Aug 17 20:12:12 2005 From: vherva at vianova.fi (Ville Herva) Date: Wed, 17 Aug 2005 23:12:12 +0300 Subject: Modular initrd [was Re: [PATCH] mkinitrd rescue mode] In-Reply-To: <1124296347.3220.26.camel@laptopd505.fenrus.org> References: <20050817132404.GK21004@viasys.com> <1124293954.11253.14.camel@byblos.lgs.com.ve> <1124296347.3220.26.camel@laptopd505.fenrus.org> Message-ID: <20050817201212.GL21004@viasys.com> On Wed, Aug 17, 2005 at 06:32:27PM +0200, you [Arjan van de Ven] wrote: > On Wed, 2005-08-17 at 11:52 -0400, Loris Santamaria wrote: > > What about a modular initrd, similar to what is fond in Debian? > > how about something slightly different... > > 2.6 kernel initrd's are cpio archives. And the kernelm supports catting > multiple of these together and the kernel then untars then one after > another... > > soo... all that's needed is having a /boot/initrd.local image that > mkinitrd always appends to the initrd it creates.. and inside that image > you can do what you want. > > And then maybe some tool to create that initrd.local from some dir or > something. [I think that was proposed in the thread I rudely revived from the grave. I think there was some uncertainty on whether it actually works, but I gather it *is* supposed to.] Yes, to me that sounds excellent. The baseline initrd init script would probably need some hooks to trigger the add-on functionality, but perhaps that much extra complexity can be tolerated? (Unless the add-on cpio always overwrites the original init script, but I don't think that's a maintanable solution.) -- v -- v at iki.fi From rdieter at math.unl.edu Wed Aug 17 20:14:15 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 17 Aug 2005 15:14:15 -0500 Subject: KDE RedHat project In-Reply-To: <4303700F.4090109@redhat.com> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> Message-ID: <43039A97.7060204@math.unl.edu> Rahul Sundaram wrote: >> It depends greatly on which os release you're using, but mostly adding >> in dependancies from Extras, livna.org (and a few not in either yet) >> to get extra features. A short list (off the top of my head) includes: >> * arts,kdemultimedia: multimedia goodies, since Fedora either legally >> or ethically(non-opensource) can't/won't. Examples, lame(mp3), >> libmad(mp3), xine-lib support. (all thanks to livna.org) >> * kdepim: crypto(gpgme/gpg-agent, see >> https://bugzilla.redhat.com/bugzilla/136533), gnokii, libmal support >> * kdelibs,kdegraphics: JPEG2000(jasper), OpenEXR support >> * kdelibs,kdebase,kdenetwork: mDNSResponder support >> * kdenetwork: openslp, meanwhile support >> * kdebase: dbus-qt/hal support > > > The Livna repository can continue to provide the restricted components. > It would great if you can file a bug report for the rest. Unfortunately, most of these enhancements require a *replacement* package, ie, a new arts, kdepim, kdelibs, kdebase, etc, which neither Extras or Livna can (or wants to) do (for good reason). AFAIK, Livna has a nice (xine-lib'd) kdemultimedia-extras package already. -- Rex From casimiro.barreto at gmail.com Wed Aug 17 20:36:46 2005 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Wed, 17 Aug 2005 17:36:46 -0300 Subject: Dependencies for libpixman are broken in rawhide Message-ID: <43039FDE.60109@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From sundaram at redhat.com Wed Aug 17 20:37:06 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 02:07:06 +0530 Subject: KDE RedHat project In-Reply-To: <43039A97.7060204@math.unl.edu> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> Message-ID: <43039FF2.3090804@redhat.com> Hi > > Unfortunately, most of these enhancements require a *replacement* > package, ie, a new arts, kdepim, kdelibs, kdebase, etc, which neither > Extras or Livna can (or wants to) do (for good reason). Does that mean that enhancements to proprietary components cannot be refactored into sub packages and requires whole scale replacement of the entire KDE set as the kde-redhat project does?. Pardon my ignorance here but that seems pretty unreasonable to me. If thats true then continuing that project seems the only way to provide the functionality. If there are other improvements that can be made in the Fedora KDE packages without introducing proprietary components or would help in refactoring these components into a independant repository, do feel free to report them regards Rahul From wtogami at redhat.com Wed Aug 17 20:45:29 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 17 Aug 2005 10:45:29 -1000 Subject: download directory In-Reply-To: <20050817174221.B27031@xos037.xos.nl> References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> <20050817174221.B27031@xos037.xos.nl> Message-ID: <4303A1E9.8040004@redhat.com> Jos Vos wrote: > On Wed, Aug 17, 2005 at 11:38:41AM -0400, Paul W. Frields wrote: > > >>On Wed, 2005-08-17 at 20:48 +0530, Rahul Sundaram wrote: >> >> >>>* Move Source ISO images into a different directory. Mirrors can choose >>>not to copy them. Many new users end up downloading this instead of the >>>binary ISO images >> >>Do you have numbers to support the claim of "many" here? ;-) > > > And mirrors choosing to not carry the sources should be discouraged > to do so, IMHO. Eh? There is little benefit to *all* mirrors carrying the source when very few people actually need it. As long as the main mirrors with good connectivity have it it is available for those who really want it. Warren Togami wtogami at redhat.com From tadams-lists at myrealbox.com Wed Aug 17 20:51:41 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 17 Aug 2005 14:51:41 -0600 Subject: Dependencies for libpixman are broken in rawhide In-Reply-To: <43039FDE.60109@gmail.com> References: <43039FDE.60109@gmail.com> Message-ID: <1124311901.2727.3.camel@aurora.localdomain> Firefox is also broken due to the changes in pango, gtk and cairo. I imagine they will be fixed up over the next few days. Trever On Wed, 2005-08-17 at 17:36 -0300, Casimiro de Almeida Barreto wrote: > [root at ... ~]# yum --exclude="libquicktime-*" update > Setting up Update Process > Setting up repositories > development 100% |=========================| 1.1 kB From sundaram at redhat.com Wed Aug 17 20:54:29 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 02:24:29 +0530 Subject: Dependencies for libpixman are broken in rawhide In-Reply-To: <1124311901.2727.3.camel@aurora.localdomain> References: <43039FDE.60109@gmail.com> <1124311901.2727.3.camel@aurora.localdomain> Message-ID: <4303A405.2020408@redhat.com> Trever L. Adams wrote: >Firefox is also broken due to the changes in pango, gtk and cairo. I >imagine they will be fixed up over the next few days. > >Trever > Major changes in libraries requires a rebuild on all the dependant packages. It might take sometime. Just ignore them in yum and continue updating for testing. If they arent fixed in a reasonable time, file them in bugzilla. regards Rahul From jspaleta at gmail.com Wed Aug 17 23:37:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 17 Aug 2005 19:37:05 -0400 Subject: download directory In-Reply-To: <4303A1E9.8040004@redhat.com> References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> <20050817174221.B27031@xos037.xos.nl> <4303A1E9.8040004@redhat.com> Message-ID: <604aa7910508171637412b5e84@mail.gmail.com> On 8/17/05, Warren Togami wrote: > Eh? There is little benefit to *all* mirrors carrying the source when > very few people actually need it. As long as the main mirrors with good > connectivity have it it is available for those who really want it. I'm pretty sure there are some rather nitpicky licensing issues for a big chunk of the code in the isos associated with mirrors acting as re-distributors, which become a lot less nitpicky legally if mirrors are encouraged to provide the srpms isos as well. -jef From russell at coker.com.au Thu Aug 18 02:44:51 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 18 Aug 2005 12:44:51 +1000 Subject: "hard core" linux In-Reply-To: <430203CA.6090807@cornell.edu> References: <430203CA.6090807@cornell.edu> Message-ID: <200508181244.54653.russell@coker.com.au> On Wednesday 17 August 2005 01:18, Paul A Houle wrote: > ? ? Longer-term, ?it might be interesting to do more of a fork: ?but the > further you diverge from Fedora the more problems you have. ?For > instance, ?people who want to play mp3's might like a distribution that > has no media players and no dependencies on media players -- they can > install what they like the way they like it. ?Trouble is that they might Due to dependencies I don't think it will be possible to spin a distribution without any of the programs which MAY have MP3 support. You can't produce a distribution with MP3 support and call it Fedora for legal reasons. Probably the best thing to do for someone who wants MP3 support would be to create a derivative distribution "based on Fedora Core" that has the MP3 support compiled in. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jspaleta at gmail.com Thu Aug 18 03:13:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 17 Aug 2005 23:13:39 -0400 Subject: "hard core" linux In-Reply-To: <430207EB.3030800@redhat.com> References: <430203CA.6090807@cornell.edu> <430207EB.3030800@redhat.com> Message-ID: <604aa791050817201369ff068a@mail.gmail.com> On 8/16/05, Rahul Sundaram wrote: > Lets see > > * KDE or XFCE based Fedora derivative. > * Fedora for low end systems > * Hardened version of Fedora with strict or MLS policy by default > > Things like that. It would be interesting if you can work within the > frame work of Fedora, get a cvs space and keep it compatible rather > than fork it right away but you are free to do that neverthless For reference, see an early strawman discussion from Tiemann about "Fedora Collections" https://www.redhat.com/archives/fedora-devel-list/2004-July/msg01325.html There has always been some interest from a number of people to expand the available number of installable "collections" (Core being one such collection) inside the full Fedora package space. Tiemann's strawman is the last comprehensive treaty on the matter that I'm aware of. In my mind its always been a question as to whether or not we really have the community facing infrastructure in place to make a community maintained collection a manageable endeavor as much as its a question of whether or not people in the community are committed to making a go of it. A year ago the answer was a pretty clear no for managable infrastructure... but community facing infrastructure has come a long long way since then. It might be worthwhile to have a good look at Tiemann's old strawman and beat it a bit and see what shakes out. Perhaps Tiemann could be dragged back into the discussion and produce a freshly stuffed strawman if his thoughts on the matter have changed in the last year. As for community interest, there are a couple of usage cases that consistently get some gripes with each release that might make a good test balloon for the first community designed collection inside the Fedora package "universe". The low-end system "collection" would probably make a reasonable trial if there are dedicated community members willing to beat their heads on the problem AND if the community facing infrastructure is ready for the attempt. Its not necessarily going to be easy to do, maintaining a collection that pulls packages from both Core, with its point release model, and extras, with its rolling release model. Not impossible, but it will take some thought and patience the first time through. -jef"rolls a 2d6, makes his dexterity check and casts 'summon Tiemann to discussion' spell doing 1d10+3 damage to all trolls"spaleta From notting at redhat.com Thu Aug 18 05:08:21 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 18 Aug 2005 01:08:21 -0400 Subject: /etc/sysconfig/harddisks deprecated? In-Reply-To: <20050816115936.GA27210@nsk.no-ip.org> References: <1124138727.4294.21.camel@salem> <1124155223.3078.10.camel@daxter.boston.redhat.com> <20050816115936.GA27210@nsk.no-ip.org> Message-ID: <20050818050821.GB31020@nostromo.devel.redhat.com> Luciano Miguel Ferreira Rocha (strange at nsk.no-ip.org) said: > On Mon, Aug 15, 2005 at 09:20:23PM -0400, David Zeuthen wrote: > > > > Btw, people with servers should be able to use /etc/rc.local (which > > runs after e.g. HAL have tuned the harddisks with our "sane" defaults) > > to tune specific disks using hdparm or whaterver - I don't think it > > makes sense at all to have configuration files for this; in other > > words /etc/sysconfig/harddisks sounds like a bad idea to me... > > /etc/rc.local just isn't good enough. I need to tune my harddisks before > mount/fsck (hardware problems). udev rules for your HD that call hdparm. Bill From davej at redhat.com Thu Aug 18 05:36:29 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 18 Aug 2005 01:36:29 -0400 Subject: usbmon and DMA patch In-Reply-To: <20050816130150.4cd24179.zaitcev@redhat.com> References: <20050816130150.4cd24179.zaitcev@redhat.com> Message-ID: <20050818053629.GA7280@redhat.com> On Tue, Aug 16, 2005 at 01:01:50PM -0700, Pete Zaitcev wrote: > Dave, > > I came around with the usbmon fix (although it's for i386 only at this > time - I would gladly take a patch for x86_64). So, would you please > drop the workaround in usb-storage, patch 1402, and apply the attached > instead? Done, will be in tomorrows rawhide if I get it built in time, otherwise, Friday's. Dave From aoliva at redhat.com Thu Aug 18 06:41:40 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 18 Aug 2005 03:41:40 -0300 Subject: download directory In-Reply-To: <4303A1E9.8040004@redhat.com> References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> <20050817174221.B27031@xos037.xos.nl> <4303A1E9.8040004@redhat.com> Message-ID: On Aug 17, 2005, Warren Togami wrote: > Eh? There is little benefit to *all* mirrors carrying the source when > very few people actually need it. Other than for compliance with the GNU GPL, you mean? How would mirrors not carrying the sources satisfy clause 3 of the GPL? They could only refrain from distributing the sources if they got a written offer, per 3b, and were able to offer such written offer for download, per 3c. IANAL, but even if a README file with links to the SRPMS in the main download site were valid as such a written offer, the main download site doesn't carry such a file for mirrors to use as the written offer, so it still wouldn't satisfy the GPL. Perhaps we could add such README files to the directories containing ISOs and SRPMS, so as to relieve mirrors from the requirement of carrying sources of GPLed packages? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From tiemann at redhat.com Thu Aug 18 06:42:16 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 18 Aug 2005 02:42:16 -0400 Subject: "hard core" linux In-Reply-To: <604aa791050817201369ff068a@mail.gmail.com> References: <430203CA.6090807@cornell.edu> <430207EB.3030800@redhat.com> <604aa791050817201369ff068a@mail.gmail.com> Message-ID: <1124347336.1995.1.camel@localhost.localdomain> On Wed, 2005-08-17 at 23:13 -0400, Jeff Spaleta wrote: > Perhaps Tiemann could be dragged back into the discussion and produce > a freshly stuffed strawman if his thoughts on the matter have changed > in the last year. I'd be happy to take another run at the problem. M From rodd at clarkson.id.au Thu Aug 18 09:13:35 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 18 Aug 2005 19:13:35 +1000 Subject: DVD Burner speed trouble on FC4 In-Reply-To: <200508171316.j7HDG355002910@mx3.redhat.com> References: <200508171316.j7HDG355002910@mx3.redhat.com> Message-ID: <1124356415.2864.4.camel@localhost.localdomain> On Wed, 2005-08-17 at 14:15 +0200, Michel MENGIS wrote: > I?m using a DELL Latitude D810 with a DVD Burner. > > I installed a FC4 (full installation), and I upgraded it using yum. So > I?m running 2.6.12-1.1398-FC4 > > > > My DVD Burner is a NEC DVD+-RW ND-6500A. > > > > By doing this test: > > Copy a 2Gb file from the DVD to the harddisk. > > > > On windows: 4minutes 3 seconds > > On linux: 27 minutes. > > > > hdparm ?I /dev/hdc tells me that DMA isn?t activated? > > hdparm ?d 1 /dev/hdc tells me that I?m not allowed to activate DMA on > the DVD burner? > > > > Why ? > > How to bring my DVD to work on linux as on windows ? Michel, try running lspci and see what IDE interface you're using/ I'd guess that it's Intel 82801FBM controller. You might want to CC yourself in on this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166053 I suspect that this is going to affect a whole load of new laptop users as it seems quite a few laptops are using the Intel chipset in question. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Thu Aug 18 09:15:45 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 18 Aug 2005 19:15:45 +1000 Subject: KDE RedHat project In-Reply-To: <43039A97.7060204@math.unl.edu> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> Message-ID: <1124356546.2864.6.camel@localhost.localdomain> On Wed, 2005-08-17 at 15:14 -0500, Rex Dieter wrote: > Rahul Sundaram wrote: > > >> It depends greatly on which os release you're using, but mostly adding > >> in dependancies from Extras, livna.org (and a few not in either yet) > >> to get extra features. A short list (off the top of my head) includes: > >> * arts,kdemultimedia: multimedia goodies, since Fedora either legally > >> or ethically(non-opensource) can't/won't. Examples, lame(mp3), > >> libmad(mp3), xine-lib support. (all thanks to livna.org) > >> * kdepim: crypto(gpgme/gpg-agent, see > >> https://bugzilla.redhat.com/bugzilla/136533), gnokii, libmal support > >> * kdelibs,kdegraphics: JPEG2000(jasper), OpenEXR support > >> * kdelibs,kdebase,kdenetwork: mDNSResponder support > >> * kdenetwork: openslp, meanwhile support > >> * kdebase: dbus-qt/hal support > > > > > > The Livna repository can continue to provide the restricted components. > > It would great if you can file a bug report for the rest. > > Unfortunately, most of these enhancements require a *replacement* > package, ie, a new arts, kdepim, kdelibs, kdebase, etc, which neither > Extras or Livna can (or wants to) do (for good reason). > > AFAIK, Livna has a nice (xine-lib'd) kdemultimedia-extras package already. It was my impression that KDE was going to be moving over to using gstreamer soon. Wouldn't this end up replacing xine-lib? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From fedora at wir-sind-cool.org Thu Aug 18 10:15:12 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 18 Aug 2005 12:15:12 +0200 Subject: KDE RedHat project In-Reply-To: <1124356546.2864.6.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> Message-ID: <20050818121512.72675a27.fedora@wir-sind-cool.org> On Thu, 18 Aug 2005 19:15:45 +1000, Rodd Clarkson wrote: > > AFAIK, Livna has a nice (xine-lib'd) kdemultimedia-extras package already. > > It was my impression that KDE was going to be moving over to using > gstreamer soon. Wouldn't this end up replacing xine-lib? What does it matter? For current FC4, the used KDE version uses a libxine based arts plugin, and the kdemultimedia-extras package from Livna provides that in order to enhance FC4 KDE video players. If a future KDE version changes to a different multimedia backend, well, then hopefully the gstreamer-plugins-extras-nonfree package (or whatever it will be called) will be ready by that time. From rodd at clarkson.id.au Thu Aug 18 10:31:40 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 18 Aug 2005 20:31:40 +1000 Subject: KDE RedHat project In-Reply-To: <20050818121512.72675a27.fedora@wir-sind-cool.org> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> Message-ID: <1124361100.2864.22.camel@localhost.localdomain> On Thu, 2005-08-18 at 12:15 +0200, Michael Schwendt wrote: > On Thu, 18 Aug 2005 19:15:45 +1000, Rodd Clarkson wrote: > > > > AFAIK, Livna has a nice (xine-lib'd) kdemultimedia-extras package already. > > > > It was my impression that KDE was going to be moving over to using > > gstreamer soon. Wouldn't this end up replacing xine-lib? > > What does it matter? For current FC4, the used KDE version uses a libxine > based arts plugin, and the kdemultimedia-extras package from Livna > provides that in order to enhance FC4 KDE video players. > > If a future KDE version changes to a different multimedia backend, well, > then hopefully the gstreamer-plugins-extras-nonfree package (or whatever > it will be called) will be ready by that time. Why it matters is that this thread actually started with someone talking about a yum repo that replaces KDE on Fedora, and discussion was about what was missing in Fedora's KDE that this KDE had. Requests were made be Fedora developers to list the missing features to see if they could be added to Fedora (or whether they were non-free). Someone pointed out that xine-lib (non-free) was missing and I commented that this may not be an issue for newer versions of KDE (in Fedora) because it looks like KDE will be moving to gstreamer. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From dragoran at feuerpokemon.de Thu Aug 18 10:42:21 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 18 Aug 2005 12:42:21 +0200 Subject: KDE RedHat project In-Reply-To: <1124361100.2864.22.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> Message-ID: <4304660D.3030007@feuerpokemon.de> Rodd Clarkson wrote: >On Thu, 2005-08-18 at 12:15 +0200, Michael Schwendt wrote: > > >>On Thu, 18 Aug 2005 19:15:45 +1000, Rodd Clarkson wrote: >> >> >> >>>>AFAIK, Livna has a nice (xine-lib'd) kdemultimedia-extras package already. >>>> >>>> >>>It was my impression that KDE was going to be moving over to using >>>gstreamer soon. Wouldn't this end up replacing xine-lib? >>> >>> >>What does it matter? For current FC4, the used KDE version uses a libxine >>based arts plugin, and the kdemultimedia-extras package from Livna >>provides that in order to enhance FC4 KDE video players. >> >>If a future KDE version changes to a different multimedia backend, well, >>then hopefully the gstreamer-plugins-extras-nonfree package (or whatever >>it will be called) will be ready by that time. >> >> > >Why it matters is that this thread actually started with someone talking >about a yum repo that replaces KDE on Fedora, and discussion was about >what was missing in Fedora's KDE that this KDE had. > >Requests were made be Fedora developers to list the missing features to >see if they could be added to Fedora (or whether they were non-free). >Someone pointed out that xine-lib (non-free) was missing and I commented >that this may not be an issue for newer versions of KDE (in Fedora) >because it looks like KDE will be moving to gstreamer. > > >Rodd > > > > > the dbus-qt/hal stuff? From paul at all-the-johnsons.co.uk Thu Aug 18 10:42:58 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnon) Date: Thu, 18 Aug 2005 11:42:58 +0100 Subject: KDE RedHat project In-Reply-To: <1124361100.2864.22.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> Message-ID: <1124361779.3401.7.camel@localhost.localdomain> Hi, > Someone pointed out that xine-lib (non-free) was missing and I commented > that this may not be an issue for newer versions of KDE (in Fedora) > because it looks like KDE will be moving to gstreamer. And if FC keeps up with this (almost) insane blocking of the likes of libdvd and mp3, they'll be as pointless as totem currently is. Would it be an idea for the likes of the packages FC cannot include in the US to be available in countries where they are allowed, but have it so US people can block them? At least that way, when I (in the UK) install FC, I don't have to go on a hunt for xmms-mp3 and then use freshrpms for xine. It's a real ache to have to go hunting, especially when the likes of SuSE and Mandriva don't put that sort of stopper on things. I can understand the legal point of view and RH having to protect itself against just about anyone who wants to make a quick buck without merit (such as SCO), but going that way can mean that possibly OOo would be removed due to being able to import/export MS proprietary formats. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From sundaram at redhat.com Thu Aug 18 10:54:16 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 16:24:16 +0530 Subject: KDE RedHat project In-Reply-To: <1124361779.3401.7.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> Message-ID: <430468D8.90704@redhat.com> Paul F. Johnon wrote: >Hi, > > > >>Someone pointed out that xine-lib (non-free) was missing and I commented >>that this may not be an issue for newer versions of KDE (in Fedora) >>because it looks like KDE will be moving to gstreamer. >> >> > >And if FC keeps up with this (almost) insane blocking of the likes of >libdvd and mp3, they'll be as pointless as totem currently is. > Read http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-why-no-mp3. Fedora is a completely Free and open source platform. Totem plays all of the open source codecs that gstreamer supports. This has been discussed multiple times previously. You cannot violate laws just because you disagree with the rationale and where it can be fought in a meaningful way it already happens* regards Rahul * *http://tinyurl.com/ce6se* From paul at all-the-johnsons.co.uk Thu Aug 18 10:57:31 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnon) Date: Thu, 18 Aug 2005 11:57:31 +0100 Subject: KDE RedHat project In-Reply-To: <430468D8.90704@redhat.com> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <430468D8.90704@redhat.com> Message-ID: <1124362651.3401.9.camel@localhost.localdomain> Hi, > >And if FC keeps up with this (almost) insane blocking of the likes of > >libdvd and mp3, they'll be as pointless as totem currently is. > > > Read http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-why-no-mp3. > > Fedora is a completely Free and open source platform. Totem plays all > of the open source codecs that gstreamer supports. This has been > discussed multiple times previously. You cannot violate laws just > because you disagree with the rationale and where it can be fought in > a meaningful way it already happens* I never said to break the law - that's just dumb! What I am suggesting is that it should be possible for RH to have something like country specific versions which are closed to those not allowed. Block by IP or something like that. TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From fedora at leemhuis.info Thu Aug 18 11:01:10 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 Aug 2005 13:01:10 +0200 Subject: KDE RedHat project In-Reply-To: <1124361779.3401.7.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> Message-ID: <1124362870.5751.15.camel@thl.ct.heise.de> Am Donnerstag, den 18.08.2005, 11:42 +0100 schrieb Paul F. Johnon: > > Someone pointed out that xine-lib (non-free) was missing and I commented > > that this may not be an issue for newer versions of KDE (in Fedora) > > because it looks like KDE will be moving to gstreamer. > > And if FC keeps up with this (almost) insane blocking of the likes of > libdvd and mp3, they'll be as pointless as totem currently is. > > Would it be an idea for the likes of the packages FC cannot include in > the US to be available in countries where they are allowed, but have it > so US people can block them? At least that way, when I (in the UK) > install FC, I don't have to go on a hunt for xmms-mp3 and then use > freshrpms for xine. I would prefer something like: "Hey, get this super cool Fedora Add-on-CD with Non-Free-Packages from livna.org -- just put it in your drive after installing Fedora and all important Non-Free-Software is going to be installed". > It's a real ache to have to go hunting, especially when the likes of > SuSE and Mandriva don't put that sort of stopper on things. In Suse 9.3 only real-player is able to play MP3 -- you have to hunt for MP3-Support in other Apps (totem, KDE,...) there, too. (Yes, I know, they provide it on their own website -- but installing it is not more complicated than "rpm -ivh livna-release-1.2.3.rpm" and "yum install xmms-mp3 xine mplayer" [or similar commands for other Repos]). CU thl From sundaram at redhat.com Thu Aug 18 11:04:21 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 16:34:21 +0530 Subject: KDE RedHat project In-Reply-To: <1124362651.3401.9.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <430468D8.90704@redhat.com> <1124362651.3401.9.camel@localhost.localdomain> Message-ID: <43046B35.5050708@redhat.com> Paul F. Johnon wrote: >Hi, > > > >>>And if FC keeps up with this (almost) insane blocking of the likes of >>>libdvd and mp3, they'll be as pointless as totem currently is. >>> >>> >>> >>Read http://fedora.redhat.com/docs/release-notes/fc4/errata/#sn-why-no-mp3. >> >>Fedora is a completely Free and open source platform. Totem plays all >>of the open source codecs that gstreamer supports. This has been >>discussed multiple times previously. You cannot violate laws just >>because you disagree with the rationale and where it can be fought in >>a meaningful way it already happens* >> >> > >I never said to break the law - that's just dumb! What I am suggesting >is that it should be possible for RH to have something like country >specific versions which are closed to those not allowed. Block by IP or >something like that. > > I do not know the legal implications of a block by IP method. I am pretty sure this has already been considered by legal. Morever that would mean endorsing a codec or technology that is legally restricted and not completely open source in every region. My opinion is that we should not do that even if we can. Third party repositories can do whatever they want. regards Rahul From sundaram at redhat.com Thu Aug 18 11:05:58 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 16:35:58 +0530 Subject: KDE RedHat project In-Reply-To: <1124362870.5751.15.camel@thl.ct.heise.de> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> Message-ID: <43046B96.3030803@redhat.com> Hi >I would prefer something like: >"Hey, get this super cool Fedora Add-on-CD with Non-Free-Packages from >livna.org -- just put it in your drive after installing Fedora and all >important Non-Free-Software is going to be installed". > > That amounts to contributory infringement and is illegal. regards Rahul From buildsys at redhat.com Thu Aug 18 11:23:54 2005 From: buildsys at redhat.com (Build System) Date: Thu, 18 Aug 2005 07:23:54 -0400 Subject: rawhide report: 20050818 changes Message-ID: <200508181123.j7IBNsrD019673@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.4.1-1 ---------------------- * Wed Aug 17 2005 Dan Williams - 0.4.1 - Update to NetworkManager 0.4.1 devhelp-0.10-5 -------------- * Wed Aug 17 2005 Jeremy Katz - 0.10-5 - fix the build * Wed Aug 17 2005 Ray Strode 0.10.0-4 - rebuild evince-0.3.4-1 -------------- * Wed Aug 17 2005 Kristian H??gsberg 0.3.4-1 - New upstream version again. - Add nautilus property page .so's. - Stop scrollkeeper from doing what it does. * Wed Aug 17 2005 Kristian H??gsberg 0.3.3-2 - Bump release and rebuild. - Require poppler > 0.4.0. * Tue Aug 16 2005 Matthias Clasen - Newer upstream version evolution-2.3.7-3 ----------------- * Tue Aug 16 2005 David Malcolm - 2.3.7-3 - Introduce macro for gnome-pilot dependency, bumping from 2.0.6 to 2.0.13 - Add obsoletion of libgal2/libgal2-devel (dependency was removed in 2.3.6-1); based on the last EVR of the libgal2 package in CVS, 2:2.5.3-2 * Mon Aug 15 2005 David Malcolm - 2.3.7-2 - rebuild * Tue Aug 09 2005 David Malcolm - 2.3.7-1 - 2.3.7 - Bump evolution-data-server requirement from 1.3.6 to 1.3.7 - Bump gtkhtml3 requirement from 3.6.2 to 3.7.6 file-roller-2.11.91-2 --------------------- * Wed Aug 17 2005 David Zeuthen - Disable scrollkeeper until gnome-doc changes are sorted out * Tue Aug 16 2005 Matthias Clasen - New upstream version firstboot-1.3.45-1 ------------------ * Wed Aug 17 2005 Chris Lumens 1.3.45-1 - Don't fail if no ifcfg script exists for a NIC found in modprobe.conf (#164874). - Restore focus after closing dialogs (#143388, #143711). gcc-4.0.1-9 ----------- * Wed Aug 17 2005 Jakub Jelinek 4.0.1-9 - update from CVS - PRs c++/21799, c++/23219, c++/23266, c++/23337, c++/8271, fortran/21432, java/23230, libfortran/23428, libgcj/23353, middle-end/23312, middle-end/23369, target/21841, target/23250, tree-optimization/21105 - fix -dv option handling (#165627) - emit DWARF3 DW_AT_call_file and DW_AT_call_line attributes for inlines (Jim Wilson) - improve debug info for inlined functions (Jim Wilson, PR debug/20268) - rebuilt against new libcairo.so gnome-applets-1:2.11.91-5 ------------------------- * Wed Aug 17 2005 Jeremy Katz - 1:2.11.91-5 - fun with auto* to really get the build working * Wed Aug 17 2005 Jeremy Katz - 1:2.11.91-4 - patch from upstream cvs to fix build with new pango (bgo #313368) * Tue Aug 16 2005 Warren Togami - 1:2.11.91-3 - rebuild for new cairo gnome-menus-2.11.91-2 --------------------- * Thu Aug 18 2005 Mark McLoughlin 2.11.91-2 - Add patch to fix "duplicate entries after upgrade" issue (gnome #313624) gnome-python2-extras-2.11.4-6 ----------------------------- * Wed Aug 17 2005 David Zeuthen - 2.11.4-6 - Rebuilt gnomemeeting-1.2.1-5 -------------------- * Wed Aug 17 2005 Jeremy Katz - 1.2.1-5 - rebuild kdebase-6:3.4.2-2 ----------------- * Wed Aug 17 2005 Than Ngo 3.4.2-2 - enable switching users #166112 kernel-2.6.12-1.1492_FC5 ------------------------ * Thu Aug 18 2005 David Woodhouse - Don't probe 8250 ports on ppc32 unless they're in the device tree - Prevent snd-powermac from oopsing on non-Mac hardware - Audit updates from git tree * Thu Aug 18 2005 Dave Jones - 2.6.13-rc6-git9 - Fix up the 'last item on the boot cmdline gets eaten' bug. - Better workaround for the usbmon DMA deficiency. libgnomeui-2.11.2-2 ------------------- * Tue Aug 16 2005 Warren Togami - 2.11.2-2 - rebuild for new cairo logrotate-3.7.2-2 ----------------- * Wed Aug 17 2005 Peter Vrabec 3.7.2-2 - allow yearly rotations(#134612) man-pages-ja-20050815-1 ----------------------- * Wed Aug 17 2005 Akira TAGOH - 20050815-1 - updates to 20050815. microcode_ctl-1:1.11-1.22 ------------------------- * Wed Aug 17 2005 Dave Jones - Check for device node *after* loading the module. (#157672) nss_ldap-239-1 -------------- * Wed Aug 17 2005 Nalin Dahyabhai 239-1 - update to nss_ldap 239 - provide a libnss_ldap.so link for directly linking with nss_ldap, as glibc does for the modules it provides * Wed Aug 17 2005 Nalin Dahyabhai 234-6 - rebuild * Wed Aug 17 2005 Nalin Dahyabhai 234-5 - update to pam_ldap 180 to get fix for vulnerability from parsing password policy controls which don't contain error numbers (#166164, CAN-2005-2497) openoffice.org-1:1.9.124-3.2.0.fc5 ---------------------------------- * Wed Aug 17 2005 Caolan McNamara - 1:1.9.124-3 - rh#166102# pspfontcache format problem hang on start - rebuild for new cairo * Mon Aug 15 2005 Caolan McNamara - 1:1.9.124-2 - experiment with jakub's suggestion for prelink based optimization intermediate library and binaries pango-1.10.0-1 -------------- * Wed Aug 17 2005 Owen Taylor - 1.10.0-1 - Upgrade to 1.10.0 policycoreutils-1.25.5-2 ------------------------ * Wed Aug 17 2005 Dan Walsh 1.25.5-2 - Change fixfiles to ignore /home directory on updates * Fri Aug 05 2005 Dan Walsh 1.25.5-1 - Update to match NSA * Merged patch to move module read/write code from libsemanage to libsepol from Jason Tang (Tresys). poppler-0.4.0-2 --------------- * Wed Aug 17 2005 Kristian H??gsberg - 0.4.0-2 - Bump release and rebuild. * Wed Aug 17 2005 Marco Pesenti gritti - 0.4.0-1 - Update to 0.4.0 scim-tables-0.5.3-2 ------------------- * Wed Aug 17 2005 Jeremy Katz - 0.5.3-2 - rebuild for new cairo * Wed Aug 17 2005 Jens Petersen - 0.5.3-1 - 0.5.3 release - replace scim-tables-0.5.1-add-hindi.patch with scim-tables-indic.patch - update files lists for new tables (ipa, latex, nepali, wu) - rename {zh,ja,ko} subpackages to {chinese,japanese,korean} selinux-policy-strict-1.25.4-4 ------------------------------ * Wed Aug 17 2005 Dan Walsh 1.25.4-4 - Add more access for amanda - Allow dovecot to create files in mail_spool_t selinux-policy-targeted-1.25.4-4 -------------------------------- * Wed Aug 17 2005 Dan Walsh 1.25.4-4 - Add more access for amanda - Allow dovecot to create files in mail_spool_t setools-2.1.1-3 --------------- * Wed Aug 17 2005 Jeremy Katz - 2.1.1-3 - rebuild against new cairo slocate-2.7-26 -------------- * Tue Aug 09 2005 Miloslav Trmac - 2.7-26 - Skip subtrees with paths longer than 32k (CAN-2005-2499) * Sun Aug 07 2005 Miloslav Trmac - 2.7-25 - Replace sl_fts.[ch] by glibc-derived versions sound-juicer-2.11.91-1 ---------------------- * Wed Aug 17 2005 Matthias Clasen 2.11.91-1 - Newer upstream version system-config-securitylevel-1.6.2-1 ----------------------------------- * Wed Aug 17 2005 Dan Walsh 1.6.2-1 - Fix setenforce call (Currently turning off if enabled system-config-soundcard-1.2.12-5 -------------------------------- * Wed Aug 17 2005 Martin Stransky 1.2.12-5 - modified test button size - added new log entries * Wed Jul 27 2005 Martin Stransky 1.2.12-4 - moved /usr/bin/alsaunmute and /usr/bin/alsacard to /bin - removed default_card (#134317) - added sorting for cards - added HW/SW config switch - added log file (/root/scsound.log) - added dialog for default audio device - set non-blocking mode for aplay * Mon Jul 11 2005 Martin Stransky 1.2.12-3 - using /usr/bin/alsaunmute for unmuting cards tog-pegasus-1:2.4.1-2.FC5 ------------------------- totem-1.1.4-1 ------------- * Thu Aug 18 2005 John (J5) Palmieri - 1.1.4-1 - Update to upstream version 1.1.4 and rebuild - Don't build with nautilus-cd-burner on s390 platforms tvtime-0.99-2 ------------- * Wed Aug 17 2005 Than Ngo 0.99-2 - rebuilt util-linux-2.13-0.2.pre2 ------------------------ * Tue Aug 16 2005 Karel Zak 2.13-0.2.pre2 - /usr/share/misc/getopt/* -move-> /usr/share/doc/util-linux-2.13/getopt-* - the arch command marked as deprecated - removed: elvtune, rescuept and setfdprm - removed: man8/sln.8 (moved to man-pages, see #10601) - removed REDAME.pg and README.reset - .spec file cleanup - added schedutils (commands: chrt, ionice and taskset) * Tue Jul 12 2005 Karel Zak 2.12p-9.7 - fix #159339 - util-linux updates for new audit system - fix #158737 - sfdisk warning for large partitions, gpt - fix #150912 ??? Add ocfs2 support - NULL is better than zero at end of execl() * Thu Jun 16 2005 Karel Zak 2.12p-9.5 - fix #157656 - CRM 546998: Possible bug in vipw, changes permissions of /etc/shadow and /etc/gshadow - fix #159339 - util-linux updates for new audit system (pam_loginuid.so added to util-linux-selinux.pamd) - fix #159418 - sfdisk unusable - crashes immediately on invocation - fix #157674 - sync option on VFAT mount destroys flash drives - fix .spec file /usr/sbin/{hwclock,clock} symlinks vino-2.11.90-2 -------------- * Wed Aug 17 2005 Matthias Clasen 2.11.90-2 - Rebuild xchat-1:2.4.4-3 --------------- * Wed Aug 17 2005 Matthias Clasen 1:2.4.4-3 - Fix a bug that could lead to occasional crashes yaboot-1.3.13-0.10 ------------------ * Wed Aug 17 2005 Paul Nasrat - 1.3.13-0.10 - No colours on unsupported consoles (eg telnet) - Improved pSeries netbooting (Nathan Lynch) yelp-2.11.1-5 ------------- * Wed Aug 17 2005 Jeremy Katz - 2.11.1-5 - rebuild * Wed Aug 17 2005 Ray Strode 2.11.1-4 - rebuild Broken deps for i386 ---------------------------------------------------------- dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390x ---------------------------------------------------------- gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) Broken deps for ppc64 ---------------------------------------------------------- evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 firstboot - 1.3.45-1.noarch requires system-config-display system-config-keyboard - 1.2.6-2.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnome-python2-totem - 2.11.4-6.ppc64 requires mozilla >= 0:1.7.3 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-mouse - 1.2.11-1.noarch requires pyxf86config Broken deps for s390 ---------------------------------------------------------- quota - 1:3.12-6.s390 requires kernel >= 0:2.4 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-13.s390 requires kernel >= 0:2.2.14 selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 From jspaleta at gmail.com Thu Aug 18 11:23:51 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 18 Aug 2005 07:23:51 -0400 Subject: "hard core" linux In-Reply-To: <1124347336.1995.1.camel@localhost.localdomain> References: <430203CA.6090807@cornell.edu> <430207EB.3030800@redhat.com> <604aa791050817201369ff068a@mail.gmail.com> <1124347336.1995.1.camel@localhost.localdomain> Message-ID: <604aa7910508180423142013c6@mail.gmail.com> On 8/18/05, Michael Tiemann wrote: > On Wed, 2005-08-17 at 23:13 -0400, Jeff Spaleta wrote: > > > Perhaps Tiemann could be dragged back into the discussion and produce > > a freshly stuffed strawman if his thoughts on the matter have changed > > in the last year. > > I'd be happy to take another run at the problem. Perhaps it will be best to do a full strawman update once the foundation lands. I'd expect several of the topics in the strawman will be affected by the establishment of the foundation. -jef From fedora at leemhuis.info Thu Aug 18 11:27:25 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 Aug 2005 13:27:25 +0200 Subject: KDE RedHat project In-Reply-To: <43046B96.3030803@redhat.com> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> Message-ID: <1124364445.5751.29.camel@thl.ct.heise.de> Am Donnerstag, den 18.08.2005, 16:35 +0530 schrieb Rahul Sundaram: > Hi > > >I would prefer something like: > >"Hey, get this super cool Fedora Add-on-CD with Non-Free-Packages from > >livna.org -- just put it in your drive after installing Fedora and all > >important Non-Free-Software is going to be installed". > > > > > That amounts to contributory infringement and is illegal. I'm not sure I understand you fully. If Red Hat/Fedora says something like above: Sure, that is illegal. But if some Add-On-Repos would provide such a CD-ISO as add-on in their Repo and if this CD is well known to everyone ("hey, go and get that Fedora-Add-On-CD, without it Fedora is not fully functional") it would solve the problem for most people in the freeworld more easily. CU thl From jspaleta at gmail.com Thu Aug 18 12:29:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 18 Aug 2005 08:29:44 -0400 Subject: KDE RedHat project In-Reply-To: <1124364445.5751.29.camel@thl.ct.heise.de> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> Message-ID: <604aa79105081805291b3e5a01@mail.gmail.com> On 8/18/05, Thorsten Leemhuis wrote: > But if some Add-On-Repos would provide such a CD-ISO as add-on in their > Repo and if this CD is well known to everyone ("hey, go and get that > Fedora-Add-On-CD, without it Fedora is not fully functional") it would > solve the problem for most people in the freeworld more easily. Logic fault: if its well known to everyone there would be no need to point to it by anyone else. Semantics aside and without touching the policy issue that Sundaram brought up about whether its the right policy decision, no... redhat as the managing entity cannot willfully point people to a collection of software they know is infringing..even if its public knowledge by other means. It doesn't matter if this makes logical sense, we are talking about US law here.. logic does not apply. Legal risk is legal risk, the entity who is liable has to evaluate the situation and determine where the line is as to what behavior brings unacceptable risk. Since redhat is the one exposed to the legal liability at the moment as the managing entity, its very difficult to make any compelling argument that second guesses their legal opinion as an outside layperson, simply because our assets are not on the line. -jef"is waiting for someone in the community to offer to indemnify redhat against all liability for contributory infringement"spaleta From ph18 at cornell.edu Thu Aug 18 14:31:03 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 18 Aug 2005 10:31:03 -0400 Subject: "hard core" linux In-Reply-To: <430207EB.3030800@redhat.com> References: <430203CA.6090807@cornell.edu> <430207EB.3030800@redhat.com> Message-ID: <43049BA7.6060906@cornell.edu> Rahul Sundaram wrote: > > Lets see > > * KDE or XFCE based Fedora derivative. Yes, one of the silliest things about RH/Fedora is that it comes with two half-baked desktop environments rather than one complete desktop environment. It would be easiest to make a Gnome-only distribution since there are quite a few packages that are compiled with Gnome bindings. (For instance, last I looked, Ethereal.) On the other hand, I think Gnome lovers are more likely to be happy with Fedora as it is -- so a KDE-based Fedora would have more of a market. XFCE might be more work, but has the bigger gain of being a really simple and lightweight desktop. Personally my feeling about UI are bifurcated. Most of the time I work out of the shell, but use Mozilla and Firefox heavily. I don't use graphical file browsers much, except for certain kind of operations that involve handling lots of files, and even for that I like the old-school text interfaces the best. On the other hand, I have an AMD64 machine at home that's used for web crawling, data mining, gaming and multimedia. For the last two things, I'd really like a much more consumer-oriented interface (like MythTV) that is metadata-oriented, not filesystem oriented. My wife has no trouble playing things with mplayer if she can find them, but I often get called up during the day because she wanted to play something and doesn't know where they are. (MythTV is cool, but it's half-baked and centered around a bunch of functionality I don't use or need) My gaming and multimedia habits revolve around files and formats of questionable legality, so I don't expect Fedora to solve my problems. Yet, I've got the feeling that the desktop paradigm is tired -- if you want me to care about GUI's you're designing, I either want something that's super-streamlined/consumer oriented or something that lets me have a godlike view of the contents of my machine. Either of those involves a metadata-oriented interface instead of a filesystem-oriented approach; everyone in the commerical arena has been promising that for more than a decade, but we're yet to see anything that really works. > * Fedora for low end systems XFCE. It might also be nice to see a server-oriented distribution. One of my complaints about Linux is that its trying to be everything to everybody. Right now people are writing stupid things about how Solaris 10 could be a Linux killer, and they miss the point that the appeal of Solaris 10 is that it does certain things right. If Solaris supported the same garbage hardware Linux supports (open source or binary drivers both,) Solaris would have all the problems Linux has. Similarly, the people who want to run Mac OS X on generic x86 hardware are missing the point. There's something to say for a single-vendor hardware and software stack where everything is qualified to actually work. I've found that kudzu and other desktop-oriented stuff that comes with RHEL causes problems on servers I run. A server distribution definitely doesn't need Gnome and KDE, who knows how many half-baked office programs, all the unfun graphical games and all that. > * Hardened version of Fedora with strict or MLS policy by default > Yeah, SELinux is a wide open frontier. There's definitely a lot of buzz about things like FreeBSD jails and Solaris zones, it would be nice to explore the space of what SELinux can do. From ph18 at cornell.edu Thu Aug 18 14:46:38 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 18 Aug 2005 10:46:38 -0400 Subject: "hard core" linux In-Reply-To: <200508181244.54653.russell@coker.com.au> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> Message-ID: <43049F4E.8090800@cornell.edu> Russell Coker wrote: >Due to dependencies I don't think it will be possible to spin a distribution >without any of the programs which MAY have MP3 support. You can't produce a >distribution with MP3 support and call it Fedora for legal reasons. > > > I don't see why I can't pull out any packages I want, so long as I pull out all the dependencies -- this might involve yanking a lot of desktop stuff, but so what. The only trouble I see is that some people might do a "yum install" of media-player dependent things which would then install the official media players, which may conflict with locally installed media players. >Probably the best thing to do for someone who wants MP3 support would be to >create a derivative distribution "based on Fedora Core" that has the MP3 >support compiled in. > > I don't have a lot of trouble installing the native mplayer rpm's and putting other stuff I want in /usr/local. For instance, rpm --erase xmms and install xmms from source. The trouble I run into is that there are other things that depend on xmms (that I don't really use) and if I rpm --erase --nodeps xmms, I end up having problems when I do yum updates later. If I could do a clean install that didn't include anything that references media players, I can do what I want in the media player space, use yum to maintain software that came with the OS, and nobody gets hurt. A media player-free distribution would also be a good base for someone who wants to make an alternative distribution which has different media players, since dependencies would be cleared. From sundaram at redhat.com Thu Aug 18 14:52:02 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 20:22:02 +0530 Subject: "hard core" linux In-Reply-To: <43049F4E.8090800@cornell.edu> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> <43049F4E.8090800@cornell.edu> Message-ID: <4304A092.6040608@redhat.com> Hi >> > I don't have a lot of trouble installing the native mplayer rpm's > and putting other stuff I want in /usr/local. For instance, rpm > --erase xmms and install xmms from source. The trouble I run into is > that there are other things that depend on xmms (that I don't really > use) and if I rpm --erase --nodeps xmms, I end up having problems > when I do yum updates later. Dont force remove any package. Use yum to remove and a package and all it's deps. yum remove regards Rahul From ph18 at cornell.edu Thu Aug 18 15:31:55 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 18 Aug 2005 11:31:55 -0400 Subject: "hard core" linux In-Reply-To: <4304A092.6040608@redhat.com> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> <43049F4E.8090800@cornell.edu> <4304A092.6040608@redhat.com> Message-ID: <4304A9EB.8050708@cornell.edu> Rahul Sundaram wrote: > Dont force remove any package. Use yum to remove and a package and all > it's deps. yum remove > In the above case you're right, but I've had plenty of times where I've had to make changes to infrastructural stuff in RH which would have made just about everything disappear had I done things the 'right' way. I've never broke my system this way, although it does cause problems with up2date and the like. From sundaram at redhat.com Thu Aug 18 15:38:54 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 18 Aug 2005 21:08:54 +0530 Subject: "hard core" linux In-Reply-To: <4304A9EB.8050708@cornell.edu> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> <43049F4E.8090800@cornell.edu> <4304A092.6040608@redhat.com> <4304A9EB.8050708@cornell.edu> Message-ID: <4304AB8E.8050903@redhat.com> Paul A Houle wrote: > In the above case you're right, but I've had plenty of times where > I've had to make changes to infrastructural stuff in RH which would > have made just about everything disappear had I done things the > 'right' way. I've never broke my system this way, although it does > cause problems with up2date and the like. If the "infrastructural" stuff is overarching dependencies we can split them into sub packages. Lets be specific. What kind of changes is being made. Got any ideas on improve those? regards Rahul From ph18 at cornell.edu Thu Aug 18 16:09:27 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 18 Aug 2005 12:09:27 -0400 Subject: "hard core" linux In-Reply-To: <4304AB8E.8050903@redhat.com> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> <43049F4E.8090800@cornell.edu> <4304A092.6040608@redhat.com> <4304A9EB.8050708@cornell.edu> <4304AB8E.8050903@redhat.com> Message-ID: <4304B2B7.8010502@cornell.edu> Rahul Sundaram wrote: > > If the "infrastructural" stuff is overarching dependencies we can > split them into sub packages. Lets be specific. What kind of changes > is being made. Got any ideas on improve those? > Oh, a lot of this is ancient history. For instance, an RH 9 system that had to be upgraded to a 2.6 kernel and needed to update a lot of userspace stuff, especially modutils. We had a production RHEL 3 server that we had to do the same thing -- I think that the distribution had a largely 2.6-ready userspace, but modutils is critical for having a system that can boot, and the last thing I need is getting it 'upgraded' to something that leaves the machine inoperable. The system that I hacked out xmms on is an FC3 system, I haven't done this on my FC4 installs. My two big beefs are apps that are dependent on media players (more than you might think) and apps that depend on a web browser (shades of "IE is integrated into the operating system") -- in both of these cases I might just want to give up on what comes with the OS and handle them myself in /usr/local. From fedora at wir-sind-cool.org Thu Aug 18 16:12:00 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 18 Aug 2005 18:12:00 +0200 Subject: KDE RedHat project In-Reply-To: <1124361100.2864.22.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> Message-ID: <20050818181200.10dd55b3.fedora@wir-sind-cool.org> On Thu, 18 Aug 2005 20:31:40 +1000, Rodd Clarkson wrote: > On Thu, 2005-08-18 at 12:15 +0200, Michael Schwendt wrote: > > On Thu, 18 Aug 2005 19:15:45 +1000, Rodd Clarkson wrote: > > > > > > AFAIK, Livna has a nice (xine-lib'd) kdemultimedia-extras package already. > > > > > > It was my impression that KDE was going to be moving over to using > > > gstreamer soon. Wouldn't this end up replacing xine-lib? > > > > What does it matter? For current FC4, the used KDE version uses a libxine > > based arts plugin, and the kdemultimedia-extras package from Livna > > provides that in order to enhance FC4 KDE video players. > > > > If a future KDE version changes to a different multimedia backend, well, > > then hopefully the gstreamer-plugins-extras-nonfree package (or whatever > > it will be called) will be ready by that time. > > Why it matters is that this thread actually started with someone talking > about a yum repo that replaces KDE on Fedora, and discussion was about > what was missing in Fedora's KDE that this KDE had. > > Requests were made be Fedora developers to list the missing features to > see if they could be added to Fedora (or whether they were non-free). > Someone pointed out that xine-lib (non-free) was missing and I commented > that this may not be an issue for newer versions of KDE (in Fedora) > because it looks like KDE will be moving to gstreamer. Doesn't change a thing at all. GStreamer in Core is reduced to the free media formats. It can't play MP3, MPEG and others and needs a a non-free plugins package for that. Other functionality in KDE cannot be added via plugins, but must be compiled in. That leads to the requirement of upgrading packages in Core with custom packages provided in a non-free repository. Keeping the custom KDE packages in sync with patches and security-fixes in Core's KDE is rather boring and tiresome. And there are enough users who don't like it when packages from Core are replaced/upgraded by a 3rd party repository. From russell at coker.com.au Thu Aug 18 17:25:24 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 19 Aug 2005 03:25:24 +1000 Subject: "hard core" linux In-Reply-To: <43049F4E.8090800@cornell.edu> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> <43049F4E.8090800@cornell.edu> Message-ID: <200508190325.26974.russell@coker.com.au> On Friday 19 August 2005 00:46, Paul A Houle wrote: > >Due to dependencies I don't think it will be possible to spin a > > distribution without any of the programs which MAY have MP3 support. You > > can't produce a distribution with MP3 support and call it Fedora for > > legal reasons. > > I don't see why I can't pull out any packages I want, so long as I > pull out all the dependencies -- this might involve yanking a lot of > desktop stuff, but so what. Sure, if you are prepared to pull out so much desktop stuff then that's a possibility. I was assuming that you wouldn't want to make such radical changes. > The only trouble I see is that some people might do a "yum install" > of media-player dependent things which would then install the official > media players, which may conflict with locally installed media players. Surely there's a way of preventing that, I don't know enough about rpm dependencies to know how to do it, but it must be possible. > I don't have a lot of trouble installing the native mplayer rpm's > and putting other stuff I want in /usr/local. For instance, rpm > --erase xmms and install xmms from source. The trouble I run into is > that there are other things that depend on xmms (that I don't really > use) and if I rpm --erase --nodeps xmms, I end up having problems when > I do yum updates later. Also if you install tar-balls in /usr/local then you have no way of tracking files and versions which may have security implications if there are SUID or SGID programs. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sean.bruno at dsl-only.net Thu Aug 18 17:40:54 2005 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 18 Aug 2005 10:40:54 -0700 Subject: gcalc broken Bug[161710] Message-ID: <1124386855.14825.1.camel@home-lap> Just curious if anyone is looking into this bug. It has been going on for quite some time and is kind of nasty. I took a stab at trying to track it down, but it is beyond me. Sean From ph18 at cornell.edu Thu Aug 18 18:22:26 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 18 Aug 2005 14:22:26 -0400 Subject: "hard core" linux In-Reply-To: <200508190325.26974.russell@coker.com.au> References: <430203CA.6090807@cornell.edu> <200508181244.54653.russell@coker.com.au> <43049F4E.8090800@cornell.edu> <200508190325.26974.russell@coker.com.au> Message-ID: <4304D1E2.2090500@cornell.edu> Russell Coker wrote: >Sure, if you are prepared to pull out so much desktop stuff then that's a >possibility. I was assuming that you wouldn't want to make such radical >changes. > > > I'll have to try it and see how bad it is. I've got an "everything install" of FC4 that I can do surgery on. If I have to destroy my desktop to excise the media player, then there are too many dependencies -- and it's starting to feel like Microsoft territory, where Microsoft went on for years insisting that it was impossible to sell Windows w/o Windows Media Player. >Surely there's a way of preventing that, I don't know enough about rpm >dependencies to know how to do it, but it must be possible. > > > I'll have to look into that. >Also if you install tar-balls in /usr/local then you have no way of tracking >files and versions which may have security implications if there are SUID or >SGID programs. > > I never install binary tarballs in /usr/local unless there's a reason why I can't build it myself. The configuration management problem for files managed by sysadmins is a general problem. Just the other day me and another sysadmin on a Solaris system were wondering who added a user to /etc/passwd. It wasn't a security problem, but the user who created it didn't go through the right channels to create users. It would be nice to be able to see who did it when. There's tripwire (too slow, too hard to configure) and a number of lightweight imitators. Type-A sysadmins probably like systems like tripwire, but I'd rather have some dnotify-based 'spyware' that keeps track of what I have in /usr/local/ You also take risks running out of rpm -- unless you're willing to make your own rpms (all the same work to compile from source and then some) you have to wait for somebody else to package something as an rpm. For instance, I'd never run the Apache rpm that comes with Fedora/RHEL on a production system because I like to know what's in my Apache... Fedora seems to be a bit fresher, but I doubt that RHEL has updated Apache 2 promptly with every version that comes out -- and I had a rough ride with Apache 2 until 2.0.54. If I had to maintain a large cluster of machines, I might have a different opinion. That said, media players ~are~ pretty dangerous, since they play files that people get off the net -- we've seen exploits against zlib, winamp.... (Although stackguard is going to help and more people will try to hit Win32 than Linux.) From rodd at clarkson.id.au Thu Aug 18 21:10:26 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 19 Aug 2005 07:10:26 +1000 Subject: KDE RedHat project In-Reply-To: <20050818181200.10dd55b3.fedora@wir-sind-cool.org> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <20050818181200.10dd55b3.fedora@wir-sind-cool.org> Message-ID: <1124399426.2864.68.camel@localhost.localdomain> On Thu, 2005-08-18 at 18:12 +0200, Michael Schwendt wrote: > Doesn't change a thing at all. GStreamer in Core is reduced to the free > media formats. It can't play MP3, MPEG and others and needs a a non-free > plugins package for that. > > Other functionality in KDE cannot be added via plugins, but must be > compiled in. That leads to the requirement of upgrading packages in Core > with custom packages provided in a non-free repository. Keeping the custom > KDE packages in sync with patches and security-fixes in Core's KDE is > rather boring and tiresome. And there are enough users who don't like it > when packages from Core are replaced/upgraded by a 3rd party repository. Actually, the beauty of gstreamer is that is not only supports non-free formats, but they can be added as plugins. In fact, gstreamer has done this so nicely that they actually compile free and non-free stuff into two different packages by default so that distros that don't want the non-free stuff included don't have to do anything oher than not use the non-free stuff. If people using fedora core want the non-free stuff, then all they need to do is following the yum repo instructions at gstreamers website and then install it using yum. This works fine making it quite easy to add all the non-free stuff you mention above without the need for a recompile. xine-lib, on the other hand, does need a recompile which makes adding support any codec awkward. However, it's worth noting that gstreamer is working on supporting xine-lib so that it can also play any codecs xine-lib supports. Keep in mind that gstreamer goes way beyond what xine-lib does. xine-lib is really just for playing various codecs. gstreamer is a multimedia framework useful for any application the reads or writes multimedia codecs. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From kyrre at solution-forge.net Thu Aug 18 21:18:12 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 18 Aug 2005 23:18:12 +0200 Subject: Dependencies for libpixman are broken in rawhide In-Reply-To: <1124311901.2727.3.camel@aurora.localdomain> References: <43039FDE.60109@gmail.com> <1124311901.2727.3.camel@aurora.localdomain> Message-ID: <1124399892.4572.8.camel@localhost.localdomain> Would this also be the reason that gnome-panel has seemed unstable the last couple of days? ons, 17.08.2005 kl. 22.51 skrev Trever L. Adams: > Firefox is also broken due to the changes in pango, gtk and cairo. I > imagine they will be fixed up over the next few days. > > Trever > > On Wed, 2005-08-17 at 17:36 -0300, Casimiro de Almeida Barreto wrote: > > [root at ... ~]# yum --exclude="libquicktime-*" update > > Setting up Update Process > > Setting up repositories > > development 100% |=========================| 1.1 kB From vonbrand at inf.utfsm.cl Thu Aug 18 21:42:02 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Thu, 18 Aug 2005 17:42:02 -0400 Subject: "hard core" linux In-Reply-To: Your message of "Thu, 18 Aug 2005 11:31:55 -0400." <4304A9EB.8050708@cornell.edu> Message-ID: <200508182142.j7ILg2R8030575@laptop11.inf.utfsm.cl> Paul A Houle wrote: > Rahul Sundaram wrote: [...] > > Dont force remove any package. Use yum to remove and a package and > > all it's deps. yum remove > In the above case you're right, but I've had plenty of times > where I've had to make changes to infrastructural stuff in RH > which would have made just about everything disappear had I done > things the 'right' way. I've never broke my system this way, > although it does cause problems with up2date and the like. No, it doesn't. Just create the required RPMs and substitute them for whatever you don't like. Don't forget to post your patches, so others will benefit too (and you don't get to do it all over when the official package gets upgraded ;-) -- 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 mhw at wittsend.com Thu Aug 18 21:30:38 2005 From: mhw at wittsend.com (Michael H. Warfield) Date: Thu, 18 Aug 2005 17:30:38 -0400 Subject: Ok... This is amusing... Message-ID: <1124400638.4231.17.camel@canyon.wittsend.com> Yes, what I'm about to describe is a self-inflicted injury (selective updating from development)... Thought someone might find it amusing or, interesting, or worth looking into... So... Because I have requirements for some of the newer features of Evolution (in-line pgp being the major one) I've been updating Evolution and some dependent parts from development, using yum, to get the 2.3.x (was 2.3.6 then 2.3.7 and now 2.3.7-3) tree. It's got its pluses and its minuses and I'm still sorting one out from the other but it fills a need. Couple days ago, I couldn't update because of the libcairo and libpixman stuff... SOP... I know the drill. Wait for a couple of days for the dependencies to settle. Today, I'm able to update Evolution and get a bunch of gnome related updates in the mix... Ok... Cool. So... Now... I restart Firefox. NO CHARACTERS! Almost blank (text free) pages. Images are fine but it's like there is no character set and/or all the typed letters are blank. Sigh... Didn't expect that! Ok... So... What the heck... Updated to Firefox from development. Seemed to go ok and yum insisted on updating nspr (and only nspr) in the processes. Ok... Try it again. Now Firefox won't even load. It gets an error in a gtk library somewhere about a font map symbol not existing Curiously enough... Mozilla looks just fine. Sigh... Removed Firefox and reloaded from FedoraCore Updates Released. Back to text free pages. :-( Of course, it's also a catch-22 that I can't see any dialog boxes to even try to change the fonts. Everything seems to be cool on fonts, it's just Firefox... Very strange... So I'm back on Mozilla until I can figure out where fonts disappeared to in Firefox. Any thoughts? Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Thu Aug 18 21:52:27 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 18 Aug 2005 23:52:27 +0200 Subject: KDE RedHat project In-Reply-To: <1124399426.2864.68.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <43035BD9.104@math.unl.edu> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <20050818181200.10dd55b3.fedora@wir-sind-cool.org> <1124399426.2864.68.camel@localhost.localdomain> Message-ID: <20050818235227.7e2d1f2c.fedora@wir-sind-cool.org> On Fri, 19 Aug 2005 07:10:26 +1000, Rodd Clarkson wrote: > On Thu, 2005-08-18 at 18:12 +0200, Michael Schwendt wrote: > > > Doesn't change a thing at all. GStreamer in Core is reduced to the free > > media formats. It can't play MP3, MPEG and others and needs a a non-free > > plugins package for that. > > > > Other functionality in KDE cannot be added via plugins, but must be > > compiled in. That leads to the requirement of upgrading packages in Core > > with custom packages provided in a non-free repository. Keeping the custom > > KDE packages in sync with patches and security-fixes in Core's KDE is > > rather boring and tiresome. And there are enough users who don't like it > > when packages from Core are replaced/upgraded by a 3rd party repository. > > Actually, the beauty of gstreamer is that is not only supports non-free > formats, but they can be added as plugins. Which is what I wrote above ("non-free plugins package"). > In fact, gstreamer has done this so nicely that they actually compile > free and non-free stuff into two different packages by default so that > distros that don't want the non-free stuff included don't have to do > anything oher than not use the non-free stuff. > > If people using fedora core want the non-free stuff, then all they need > to do is following the yum repo instructions at gstreamers website and > then install it using yum. This works fine making it quite easy to add > all the non-free stuff you mention above without the need for a > recompile. The KDE used for that would be a stripped-down one, however, and at the dangers of repeating myself, you cannot link a KDE app like Juk against a library like libtunepimp if it depends on an mp3 decoder. GStreamer plugins only gives you part of the fun. -- Michael Schwendt Fedora Core release 5 (Development) - Linux 2.6.12-1.1485_FC5 loadavg: 1.00 1.19 1.20 From tadams-lists at myrealbox.com Thu Aug 18 21:56:41 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 18 Aug 2005 15:56:41 -0600 Subject: Dependencies for libpixman are broken in rawhide In-Reply-To: <1124399892.4572.8.camel@localhost.localdomain> References: <43039FDE.60109@gmail.com> <1124311901.2727.3.camel@aurora.localdomain> <1124399892.4572.8.camel@localhost.localdomain> Message-ID: <1124402201.2686.4.camel@aurora.localdomain> That may very well be. Much of the instability disappeared (for me) today with the updates that came out. However, Firefox is still non-functioning. Open Office is now functioning again. Hopefully Firefox will be functioning soon. Trever On Thu, 2005-08-18 at 23:18 +0200, Kyrre Ness Sjobak wrote: > Would this also be the reason that gnome-panel has seemed unstable the > last couple of days? > > ons, 17.08.2005 kl. 22.51 skrev Trever L. Adams: > > Firefox is also broken due to the changes in pango, gtk and cairo. I > > imagine they will be fixed up over the next few days. > > > > Trever > > > > On Wed, 2005-08-17 at 17:36 -0300, Casimiro de Almeida Barreto wrote: > > > [root at ... ~]# yum --exclude="libquicktime-*" update > > > Setting up Update Process > > > Setting up repositories > > > development 100% |=========================| 1.1 kB > -- "Walking on water and developing software to specification are easy as long as both are frozen." --Edward V. Berard From jspaleta at gmail.com Thu Aug 18 22:00:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 18 Aug 2005 18:00:32 -0400 Subject: Ok... This is amusing... In-Reply-To: <1124400638.4231.17.camel@canyon.wittsend.com> References: <1124400638.4231.17.camel@canyon.wittsend.com> Message-ID: <604aa791050818150070364b77@mail.gmail.com> On 8/18/05, Michael H. Warfield wrote: > So... Now... I restart Firefox. NO CHARACTERS! Almost blank (text > free) pages. Images are fine but it's like there is no character set > and/or all the typed letters are blank. Sigh... Didn't expect that! you may need to disable pango support in the /usr/bin/firefox script. look for this snippet: ## ## Set MOZ_ENABLE_PANGO is no longer used because Pango is enabled by default ## you may use MOZ_DISABLE_PANGO=1 to force disabling of pango ## MOZ_DISABLE_PANGO=1 export MOZ_DISABLE_PANGO -jef From mhw at wittsend.com Fri Aug 19 00:21:12 2005 From: mhw at wittsend.com (Michael H. Warfield) Date: Thu, 18 Aug 2005 20:21:12 -0400 Subject: Ok... This is amusing... In-Reply-To: <604aa791050818150070364b77@mail.gmail.com> References: <1124400638.4231.17.camel@canyon.wittsend.com> <604aa791050818150070364b77@mail.gmail.com> Message-ID: <1124410872.7071.1.camel@canyon.wittsend.com> On Thu, 2005-08-18 at 18:00 -0400, Jeff Spaleta wrote: > On 8/18/05, Michael H. Warfield wrote: > > So... Now... I restart Firefox. NO CHARACTERS! Almost blank (text > > free) pages. Images are fine but it's like there is no character set > > and/or all the typed letters are blank. Sigh... Didn't expect that! > you may need to disable pango support in the /usr/bin/firefox script. > look for this snippet: > ## > ## Set MOZ_ENABLE_PANGO is no longer used because Pango is enabled by default > ## you may use MOZ_DISABLE_PANGO=1 to force disabling of pango > ## > MOZ_DISABLE_PANGO=1 > export MOZ_DISABLE_PANGO Bingo! That did it. Firefox back in operation. > > -jef Many thanks! Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Aug 19 01:33:50 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 18 Aug 2005 18:33:50 -0700 Subject: release notes beat writers Message-ID: <1124415230.916.74.camel@erato.phig.org> We're going to be telling you more about how you can easily help make the release notes even better for FC5. In the meantime, we are looking for writers to cover various release notes beats. You can read about this at: http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats If you run across someone who wants to help with FLOSS projects, this is a fantastic way they can help document. If you are a developer lead for one of the beat areas, I would like you to look out for good candidates. Enough technical and community skill are the keys, even someone who is <1 year involved can be savvy enough. Don't worry about the writing itself, that's what editors are for. The work keeps you close to whatever interests you in Fedora. You get to be on the go-to team for all the developers who need a feature or bug documented in the release notes. By breaking these down into writing beats, the work is something that one or more people can do as part of their contribution. Thanks, Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- 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 vonbrand at inf.utfsm.cl Fri Aug 19 01:32:23 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Thu, 18 Aug 2005 21:32:23 -0400 Subject: Ok... This is amusing... In-Reply-To: Your message of "Thu, 18 Aug 2005 20:21:12 -0400." <1124410872.7071.1.camel@canyon.wittsend.com> Message-ID: <200508190132.j7J1WN75004245@laptop11.inf.utfsm.cl> Michael H. Warfield wrote: > On Thu, 2005-08-18 at 18:00 -0400, Jeff Spaleta wrote: > > On 8/18/05, Michael H. Warfield wrote: > > > So... Now... I restart Firefox. NO CHARACTERS! Almost blank (text > > > free) pages. Images are fine but it's like there is no character set > > > and/or all the typed letters are blank. Sigh... Didn't expect that! Here it just crashed silently, without even opening a window. > > you may need to disable pango support in the /usr/bin/firefox script. > > look for this snippet: > > > ## > > ## Set MOZ_ENABLE_PANGO is no longer used because Pango is enabled by default > > ## you may use MOZ_DISABLE_PANGO=1 to force disabling of pango > > ## > > MOZ_DISABLE_PANGO=1 > > export MOZ_DISABLE_PANGO > > Bingo! That did it. Firefox back in operation. Fixed it here too. -- 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 katzj at redhat.com Fri Aug 19 01:39:48 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 18 Aug 2005 21:39:48 -0400 Subject: Ok... This is amusing... In-Reply-To: <200508190132.j7J1WN75004245@laptop11.inf.utfsm.cl> References: <200508190132.j7J1WN75004245@laptop11.inf.utfsm.cl> Message-ID: <1124415588.2955.3.camel@bree.local.net> On Thu, 2005-08-18 at 21:32 -0400, Horst von Brand wrote: > Michael H. Warfield wrote: > > On Thu, 2005-08-18 at 18:00 -0400, Jeff Spaleta wrote: > > > ## Set MOZ_ENABLE_PANGO is no longer used because Pango is enabled by default > > > ## you may use MOZ_DISABLE_PANGO=1 to force disabling of pango > > > ## > > > MOZ_DISABLE_PANGO=1 > > > export MOZ_DISABLE_PANGO > > > > Bingo! That did it. Firefox back in operation. > > Fixed it here too. Note that this is just a workaround... Hopefully have a fixed firefox building on my laptop now. If that works, it should show up in rawhide tomorrow Jeremy From green at redhat.com Fri Aug 19 02:16:39 2005 From: green at redhat.com (Anthony Green) Date: Thu, 18 Aug 2005 19:16:39 -0700 Subject: GCC 4.1 for FC5? Message-ID: <1124417799.3017.5.camel@localhost.localdomain> Are there plans to use GCC 4.1 in FC5 (assuming it ships on schedule)? There's so much java activity in GCC HEAD that this makes a big difference to people debugging applications with FC5 in mind. Thanks, AG From linux at glossolalie.org Fri Aug 19 07:03:55 2005 From: linux at glossolalie.org (Thierry Sayegh) Date: Fri, 19 Aug 2005 08:03:55 +0100 Subject: release notes beat writers In-Reply-To: <1124415230.916.74.camel@erato.phig.org> References: <1124415230.916.74.camel@erato.phig.org> Message-ID: <4305845B.3020502@glossolalie.org> Karsten Wade wrote: > We're going to be telling you more about how you can easily help make > the release notes even better for FC5. > > In the meantime, we are looking for writers to cover various release > notes beats. > > You can read about this at: > > http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats > Wouldn't mind helping the networking side but the tinyurl given is broken. Sends you to a nicwe 404 Not found page ;-( Any pointers Thierry From paul at city-fan.org Fri Aug 19 07:25:29 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 19 Aug 2005 08:25:29 +0100 Subject: release notes beat writers In-Reply-To: <4305845B.3020502@glossolalie.org> References: <1124415230.916.74.camel@erato.phig.org> <4305845B.3020502@glossolalie.org> Message-ID: <1124436330.16837.77.camel@laurel.intra.city-fan.org> On Fri, 2005-08-19 at 08:03 +0100, Thierry Sayegh wrote: > Karsten Wade wrote: > > We're going to be telling you more about how you can easily help make > > the release notes even better for FC5. > > > > In the meantime, we are looking for writers to cover various release > > notes beats. > > > > You can read about this at: > > > > http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats > > > Wouldn't mind helping the networking side but the tinyurl given is > broken. Sends you to a nicwe 404 Not found page ;-( > Any pointers The URL quoted above works for me. Paul. -- Paul Howarth From linux at glossolalie.org Fri Aug 19 07:37:43 2005 From: linux at glossolalie.org (Thierry Sayegh) Date: Fri, 19 Aug 2005 08:37:43 +0100 Subject: release notes beat writers In-Reply-To: <1124436330.16837.77.camel@laurel.intra.city-fan.org> References: <1124415230.916.74.camel@erato.phig.org> <4305845B.3020502@glossolalie.org> <1124436330.16837.77.camel@laurel.intra.city-fan.org> Message-ID: <43058C47.70205@glossolalie.org> Paul Howarth wrote: > The URL quoted above works for me. > > Paul. The above URL does works, it's the tinyurl embedded into into the page under the heading "Filing A Release Note Request" that is broken Sorry, was not quite clear in my previous post cheers Thierry From nman64 at n-man.com Fri Aug 19 08:30:33 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 19 Aug 2005 03:30:33 -0500 Subject: release notes beat writers In-Reply-To: <1124415230.916.74.camel@erato.phig.org> References: <1124415230.916.74.camel@erato.phig.org> Message-ID: <430598A9.7090807@n-man.com> I have corrected the broken link at http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats The tinyurl that was in use before was invalidated by a Bugzilla update. The link now points directly to Bugzilla. I also formatted a few of the other links differently to give the page a slightly cleaner appearance. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nphilipp at redhat.com Fri Aug 19 11:08:24 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 19 Aug 2005 13:08:24 +0200 Subject: download directory In-Reply-To: References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> <20050817174221.B27031@xos037.xos.nl> <4303A1E9.8040004@redhat.com> Message-ID: <1124449705.17519.8.camel@gibraltar.stuttgart.redhat.com> On Thu, 2005-08-18 at 03:41 -0300, Alexandre Oliva wrote: > Perhaps we could add such README files to the directories containing > ISOs and SRPMS, so as to relieve mirrors from the requirement of > carrying sources of GPLed packages? I don't think we can do that, we'd have to retain all Rawhide source package for instance if we were to do that. I'd rather have mirrors pick up sources along with binaries and have no hassle with it afterwards. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From buildsys at redhat.com Fri Aug 19 11:23:15 2005 From: buildsys at redhat.com (Build System) Date: Fri, 19 Aug 2005 07:23:15 -0400 Subject: rawhide report: 20050819 changes Message-ID: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> Updated Packages: anaconda-10.3.0.9-1 ------------------- * Thu Aug 18 2005 Chris Lumens 10.3.0.9-1 - Rebuild for new cairo. - Add support for ksdevice=bootif (Alex Kiernan, #166135). - Fix /dev/tty3 logging problems. - Add support for Pegasos machines (dwmw2, #166103). - Switch to Sazanami font (#166045). - Fix for autopart not in lvm (msw). arptables_jf-0:0.0.8-6 ---------------------- * Thu Aug 18 2005 Florian La Roche - change the requires into a conflicts for "kernel" binutils-2.16.91.0.2-4 ---------------------- * Thu Aug 18 2005 Jakub Jelinek 2.16.91.0.2-4 - install-info also configure.info - update standards.texi from gnulib (#165530) bootparamd-0.17-23.devel ------------------------ * Wed Aug 17 2005 Martin Stransky 0.17-23.devel - added patch for #143032, written by Robert Jelinek (jelinekr at ms.com) - updated a man page file-4.15-1 ----------- * Tue Aug 09 2005 Radek Vokal - 4.15-1 - upgrade to upstream * Tue Aug 09 2005 Radek Vokal - 4.14-4 - mime for mpeg and aac files fixed (#165323) * Fri Aug 05 2005 Radek Vokal - 4.14-3 - mime for 3ds files removed, conflicts with text files (#165165) firefox-1.1-0.2.7.deerpark.alpha2.1 ----------------------------------- * Thu Aug 18 2005 Jeremy Katz - 1.1-0.2.7.deerpark.alpha2.1 - another fix to not use pango_xft gdm-1:2.6.0.8-18 ---------------- * Thu Aug 18 2005 Ray Strode 1:2.6.0.8-18 - rebuild * Wed Aug 10 2005 Ray Strode 1:2.6.0.8-17 - Prune uninstalled languages from language list. gkrellm-2.2.7-2 --------------- * Thu Aug 18 2005 Florian La Roche - the the kernel dep form a Requires: into a Conflicts: gnome-menus-2.11.91-3 --------------------- * Thu Aug 18 2005 Mark McLoughlin 2.11.91-3 - Fix infinite loop in patch for gnome #313624 gtk2-2.8.0-2 ------------ * Mon Aug 15 2005 Matthias Clasen 2.8.0-1 - Newer upstream version * Thu Aug 04 2005 Matthias Clasen - Newer upstream version * Thu Jul 28 2005 Owen Taylor 2.7.4-1 - Update to 2.7.4 kernel-2.6.12-1.1499_FC5 ------------------------ * Thu Aug 18 2005 Dave Jones - 2.6.13-rc6-git10 - Drop a bunch of bogus patches. nfs-utils-1.0.7-14 ------------------ * Thu Aug 18 2005 Florian La Roche - no need to still keep a requirement for kernel-2.2 or newer quota-1:3.12-7 -------------- * Thu Aug 18 2005 Florian La Roche - change the "Requires: kernel" into a "Conflicts:" setools-2.1.1-4 --------------- * Thu Aug 18 2005 Florian La Roche - do not package debug files into the -devel package sysstat-5.0.5-11.fc ------------------- * Thu Aug 18 2005 Florian La Roche - no need to kernel kernel 2.2 or newer anymore system-config-netboot-0.1.28-1 ------------------------------ * Wed Aug 17 2005 Jason Vas Dias 0.1.28-1 - fix bug 166217 : the fixed-size initrd was not big enough for RHEL-4 smp kernel. updateDiskless now creates the initrd first in a directory; its size is then determined and the initrd.img is created with sufficient size. pxeos.py now determines the uncompressed size and pxeboot.py now writes the correct ramdisk_size to the syslinux.cfg file. thunderbird-0:1.0.6-5 --------------------- * Thu Aug 18 2005 Kristian H??gsberg 0:1.0.6-5 - Update firefox-1.0-pango-cairo.patch to also fix xft usage in mozilla/gfx/src/gtk/mozilla-decoder.cpp xpdf-1:3.01-1 ------------- * Thu Aug 18 2005 Than Ngo 3.01-1 - update to 3.01 Broken deps for i386 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc64 ---------------------------------------------------------- evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-mouse - 1.2.11-1.noarch requires pyxf86config gnome-python2-totem - 2.11.4-6.ppc64 requires mozilla >= 0:1.7.3 firstboot - 1.3.45-1.noarch requires system-config-display Broken deps for ppc ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390x ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.s390x requires libwnck-1.so.16()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) Broken deps for s390 ---------------------------------------------------------- gnome-python2-libwnck - 2.10.0-2.1.s390 requires libwnck-1.so.16 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 19 11:56:29 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 19 Aug 2005 13:56:29 +0200 Subject: rawhide report: 20050819 changes In-Reply-To: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> Message-ID: <20050819135629.544ee901@python2> Build System wrote : > * Thu Aug 18 2005 Florian La Roche > - change the requires into a conflicts for "kernel" Just wondering since there have been a few of these today : Isn't it the other way around, i.e. isn't having a requirement better than conflicting *all* older versions for kernels? I'm asking because many people (including me), have been bothered by conflicts on old kernel versions when trying to upgrade from a distribution version to another using apt or yum, as *any* old kernel still installed will break the dependencies. For instance, if you upgrade from a system running FC "N" with kernel 2.6.0 (still installed) to the newer version FC "N+1" with kernel 2.6.10 which includes packages conflicting with kernel < 2.6.5, then things will have to start getting ugly (upgrading by bits, removing the running kernel, removing --justdb etc.) :-( Package requirements for kernels are only "informative" anyway, since multiple kernels can be installed and the package management doesn't depend on which one is currently running... Anyway, usually machines are running the most recent one installed, in which case a requires is fine. Furthermore, conflicts just force users to remove old unused kernels... which doesn't solve the problem and only causes headaches. Some more thoughts? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.22 0.31 0.35 From laroche at redhat.com Fri Aug 19 12:24:27 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 19 Aug 2005 14:24:27 +0200 Subject: rawhide report: 20050819 changes In-Reply-To: <20050819135629.544ee901@python2> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> <20050819135629.544ee901@python2> Message-ID: <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> > Some more thoughts? I'd rather see the requires go away completely, as they anyway don't specify which kernel will actually be running on the machine, so packaging should not try solving something it is not designed todo. greetings, Florian La Roche From paul at city-fan.org Fri Aug 19 12:31:16 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 19 Aug 2005 13:31:16 +0100 Subject: rawhide report: 20050819 changes In-Reply-To: <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> <20050819135629.544ee901@python2> <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> Message-ID: <4305D114.1020403@city-fan.org> Florian La Roche wrote: >>Some more thoughts? > > > I'd rather see the requires go away completely, as they anyway don't > specify which kernel will actually be running on the machine, so > packaging should not try solving something it is not designed todo. Having the Requires: at least ensures that there is a kernel *capable* of running the package installed on the system, and, possibly more importantly, gives a clue to anyone installing the package that they may need a kernel upgrade in order for it to work (if they don't already have a suitable kernel installed). Dropping the requirement may result in additional bug reports from people running older kernels that aren't aware of the kernel version requirement. Are there any advantages in *not* having the Requires:? Paul. From katzj at redhat.com Fri Aug 19 13:03:59 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 19 Aug 2005 09:03:59 -0400 Subject: rawhide report: 20050819 changes In-Reply-To: <4305D114.1020403@city-fan.org> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> <20050819135629.544ee901@python2> <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> <4305D114.1020403@city-fan.org> Message-ID: <1124456639.2955.6.camel@bree.local.net> On Fri, 2005-08-19 at 13:31 +0100, Paul Howarth wrote: > Are there any advantages in *not* having the Requires:? If there aren't requirements on kernel packages, then buildroots don't need to have a kernel available/installed which speeds up the creation time for them. Jeremy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 19 13:14:59 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 19 Aug 2005 15:14:59 +0200 Subject: rawhide report: 20050819 changes In-Reply-To: <1124456639.2955.6.camel@bree.local.net> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> <20050819135629.544ee901@python2> <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> <4305D114.1020403@city-fan.org> <1124456639.2955.6.camel@bree.local.net> Message-ID: <20050819151459.09b06183@python2> Jeremy Katz wrote : > On Fri, 2005-08-19 at 13:31 +0100, Paul Howarth wrote: > > Are there any advantages in *not* having the Requires:? > > If there aren't requirements on kernel packages, then buildroots don't > need to have a kernel available/installed which speeds up the creation > time for them. So we're back to the "missing" feature of rpm that would be : "_If foo is installed_, then require it with this version dependency" These, as well as "suggests" and such have been discussed many time, and the general conclusion is that rpm won't ever be able to do that. At least not without major rewrite/breakage/step-forward. If only it was as easy as "Requires: ?kernel >= 2.6.12" :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.34 1.00 1.20 From laroche at redhat.com Fri Aug 19 13:32:26 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 19 Aug 2005 15:32:26 +0200 Subject: rawhide report: 20050819 changes In-Reply-To: <20050819151459.09b06183@python2> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> <20050819135629.544ee901@python2> <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> <4305D114.1020403@city-fan.org> <1124456639.2955.6.camel@bree.local.net> <20050819151459.09b06183@python2> Message-ID: <20050819133226.GA3792@dudweiler.stuttgart.redhat.com> On Fri, Aug 19, 2005 at 03:14:59PM +0200, Matthias Saou wrote: > Jeremy Katz wrote : > > > On Fri, 2005-08-19 at 13:31 +0100, Paul Howarth wrote: > > > Are there any advantages in *not* having the Requires:? > > > > If there aren't requirements on kernel packages, then buildroots don't > > need to have a kernel available/installed which speeds up the creation > > time for them. > > So we're back to the "missing" feature of rpm that would be : > > "_If foo is installed_, then require it with this version dependency" A review of te packages in question and their runtime behaviour should be enough. In general we wouldn't support running a 2.4 anymore, probably also with packages which don't list this requirement. For a few items during the 2.4 -> 2.6 transition I could see how lvm2 would need a "Requires: kernel >= 2.6", but now we should just put a runtime check into the relevant places and be done. More critical is to support updates from older releases and in that case not listing the requirements for the kernel does help getting things right. Also buildroots or now xen installs might benefit from less data, but we don't optimize for those cases too much in general. They still benefit a little bit. > These, as well as "suggests" and such have been discussed many time, and > the general conclusion is that rpm won't ever be able to do that. At least > not without major rewrite/breakage/step-forward. > > If only it was as easy as "Requires: ?kernel >= 2.6.12" :-( Yeah, we don't optimize for fine-grained deps and I think that is the right decision. Adding those other parts wouldn't be that hard, but then changing all packages to get this right plus also all tools who work ontop of rpmlib would generate more work than we would get benefits from it. Enough other work left where we can improve rpm packages and details of how updates work. greetings, Florian La Roche From lenni at eastweb.ru Fri Aug 19 14:11:34 2005 From: lenni at eastweb.ru (Leonid Novikov) Date: Fri, 19 Aug 2005 18:11:34 +0400 (MSD) Subject: OT: FC mirroring [Was: Re: download directory] In-Reply-To: <4303552E.7060801@redhat.com> References: <4303552E.7060801@redhat.com> Message-ID: <200508182254.02771.lenni@eastweb.ru> Hi, sorry for off-topic. I wanna mirroring FC disribution tree, but my request to ftp at redhat.com still leave without answer. Can anybody from CoreTeam contact with me? -- Leonid Novikov lenni at eastweb.ru http://eastweb.ru/ From aoliva at redhat.com Fri Aug 19 16:43:36 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 19 Aug 2005 13:43:36 -0300 Subject: download directory In-Reply-To: <1124449705.17519.8.camel@gibraltar.stuttgart.redhat.com> References: <4303552E.7060801@redhat.com> <1124293121.10371.7.camel@localhost.localdomain> <20050817174221.B27031@xos037.xos.nl> <4303A1E9.8040004@redhat.com> <1124449705.17519.8.camel@gibraltar.stuttgart.redhat.com> Message-ID: On Aug 19, 2005, Nils Philippsen wrote: > On Thu, 2005-08-18 at 03:41 -0300, Alexandre Oliva wrote: >> Perhaps we could add such README files to the directories containing >> ISOs and SRPMS, so as to relieve mirrors from the requirement of >> carrying sources of GPLed packages? > I don't think we can do that, we'd have to retain all Rawhide source > package for instance if we were to do that. I'd rather have mirrors pick > up sources along with binaries and have no hassle with it afterwards. Oh, for the development tree, sure. I was thinking of releases only when I wrote that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Fri Aug 19 16:48:12 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 19 Aug 2005 13:48:12 -0300 Subject: rawhide report: 20050819 changes In-Reply-To: <20050819151459.09b06183@python2> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> <20050819135629.544ee901@python2> <20050819122427.GA3207@dudweiler.stuttgart.redhat.com> <4305D114.1020403@city-fan.org> <1124456639.2955.6.camel@bree.local.net> <20050819151459.09b06183@python2> Message-ID: On Aug 19, 2005, Matthias Saou wrote: > If only it was as easy as "Requires: ?kernel >= 2.6.12" :-( Isn't this pretty much what Conflicts amounts to? Yeah, there are differences, mostly caused by the fact that the kernel is special and generally isn't upgraded, but rather installed, and it won't start running immediately after the upgrade, but rather only after a reboot. But solving this would require rpm to introduce means to test requirements not only on installed kernels, but also on the running kernel. And those would be useful, since there might be cases in which one really needs to be running a newer kernel to be able to complete the update of another package. Or something :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Fri Aug 19 16:50:47 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 19 Aug 2005 13:50:47 -0300 Subject: rawhide report: 20050818 changes In-Reply-To: References: <200508181123.j7IBNsrD019673@porkchop.devel.redhat.com> Message-ID: On Aug 19, 2005, Justin Conover wrote: > On 8/18/05, Build System wrote: >> evince-0.3.4-1 > Has Evince died for anyone else? Yeah, I added a note about this to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166071 Not sure whether it's related, but it might be. If not, we can always split it into a separate bug report... -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From msalim at cs.indiana.edu Fri Aug 19 18:53:20 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Fri, 19 Aug 2005 13:53:20 -0500 Subject: HelixPlayer and snd-atiixp Message-ID: <1124477600.3015.22.camel@salem> It would seem that the stable builds of Helix and RealPlayer both have problems with the ALSA snd-atiixp driver - the sound would play for a second, stutter and skip, play again, stutter again and so on. The good news is that the daily builds fix this - but for some reason when I play back a Theora video there the colors become messed up. So the question is: is Fedora Core 5 planned to ship with Helix 1.0 or the next stable version? If the former, could whatever changes have been done in the development version to fix the sound problem be backported? Thanks, - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Aug 19 19:08:40 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 19 Aug 2005 21:08:40 +0200 Subject: HelixPlayer and snd-atiixp In-Reply-To: <1124477600.3015.22.camel@salem> References: <1124477600.3015.22.camel@salem> Message-ID: <20050819210840.2b85c1d7@python2> Michel Alexandre Salim wrote : > It would seem that the stable builds of Helix and RealPlayer both have > problems with the ALSA snd-atiixp driver - the sound would play for a > second, stutter and skip, play again, stutter again and so on. > > The good news is that the daily builds fix this - but for some reason > when I play back a Theora video there the colors become messed up. > > So the question is: is Fedora Core 5 planned to ship with Helix 1.0 or > the next stable version? If the former, could whatever changes have been > done in the development version to fix the sound problem be backported? ooooooooooooooh... someone out there actually uses HelixPlayer? :-D Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.18 0.41 0.33 From msalim at cs.indiana.edu Fri Aug 19 20:27:01 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Fri, 19 Aug 2005 15:27:01 -0500 Subject: HelixPlayer and snd-atiixp In-Reply-To: <20050819210840.2b85c1d7@python2> References: <1124477600.3015.22.camel@salem> <20050819210840.2b85c1d7@python2> Message-ID: <1124483221.15060.5.camel@salem> On Fri, 2005-08-19 at 21:08 +0200, Matthias Saou wrote: > Michel Alexandre Salim wrote : > > > It would seem that the stable builds of Helix and RealPlayer both have > > problems with the ALSA snd-atiixp driver - the sound would play for a > > second, stutter and skip, play again, stutter again and so on. > > > > The good news is that the daily builds fix this - but for some reason > > when I play back a Theora video there the colors become messed up. > > > > So the question is: is Fedora Core 5 planned to ship with Helix 1.0 or > > the next stable version? If the former, could whatever changes have been > > done in the development version to fix the sound problem be backported? > > ooooooooooooooh... someone out there actually uses HelixPlayer? :-D > If only to help bugfix RealPlayer, which I need to play BBC Radio streams? (whatever happened to their Ogg Vorbis trials..) Both Rawhide's 1.0.5.757 (experimental) and the latest stable build from HelixCommunity (1.0.6.1112) have the stuttering problem. The latest current build (1.1.0.1188) plays sound alright. All three have color problems playing a Theora video, which funnily the Helix Player from FC4 plays fine. > Matthias > > -- > Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ > Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 > Load : 0.18 0.41 0.33 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From dmalcolm at redhat.com Fri Aug 19 20:29:34 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 19 Aug 2005 16:29:34 -0400 Subject: rawhide report: 20050818 changes In-Reply-To: References: <200508181123.j7IBNsrD019673@porkchop.devel.redhat.com> Message-ID: <1124483374.19251.8.camel@cassandra.boston.redhat.com> On Fri, 2005-08-19 at 10:43 -0500, Justin Conover wrote: > On 8/18/05, Build System wrote: > > > > > > > > Updated Packages: > > > > > > > evince-0.3.4-1 > > -------------- > > * Wed Aug 17 2005 Kristian H?gsberg 0.3.4-1 > > - New upstream version again. > > - Add nautilus property page .so's. > > - Stop scrollkeeper from doing what it does. > > > > * Wed Aug 17 2005 Kristian H?gsberg 0.3.3-2 > > - Bump release and rebuild. > > - Require poppler > 0.4.0. > > > > * Tue Aug 16 2005 Matthias Clasen > > - Newer upstream version > > > > > > Has Evince died for anyone else? > > Every pdf I have tried to open results in > > Error > The Application "evince" has quit unexpectedly. > > evince-0.3.4-1 > > x86_64 box > Fails for me too; I filed it here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166349 From nman64 at n-man.com Fri Aug 19 23:24:38 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 19 Aug 2005 18:24:38 -0500 Subject: Wiki problem in Internet Explorer Message-ID: <43066A36.9020800@n-man.com> While trying to get the FrontPage of the wiki looking a little better, I decided to give it a try in Internet Explorer. What I saw I didn't like. At first, I thought I had done something that IE didn't like, but after investigation (including a bunch of trivial changes) I have determined that the problem more likely lies in the CSS for the default theme. The problem in IE is that some objects such as tables and textareas have a large amount of whitespace above them. I haven't checked many versions of Internet Explorer, but the most recent versions are affected. I would like to advise that the CSS for rightsidebarsmaller (and perhaps others) needs to be checked into. Although most of the visits to fedoraproject.org are probably from Linux viewers, we are also trying to show Windows users to the light. We will have visitors using Internet Explorer, and should try to make sure things look right. Another option would be to set the default theme to sinorca4moin, which does not exhibit the problem. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rodd at clarkson.id.au Fri Aug 19 23:29:07 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 20 Aug 2005 09:29:07 +1000 Subject: HelixPlayer and snd-atiixp In-Reply-To: <20050819210840.2b85c1d7@python2> References: <1124477600.3015.22.camel@salem> <20050819210840.2b85c1d7@python2> Message-ID: <1124494147.2901.3.camel@localhost.localdomain> On Fri, 2005-08-19 at 21:08 +0200, Matthias Saou wrote: > Michel Alexandre Salim wrote : > > > It would seem that the stable builds of Helix and RealPlayer both have > > problems with the ALSA snd-atiixp driver - the sound would play for a > > second, stutter and skip, play again, stutter again and so on. > > > > The good news is that the daily builds fix this - but for some reason > > when I play back a Theora video there the colors become messed up. > > > > So the question is: is Fedora Core 5 planned to ship with Helix 1.0 or > > the next stable version? If the former, could whatever changes have been > > done in the development version to fix the sound problem be backported? > > ooooooooooooooh... someone out there actually uses HelixPlayer? :-D Yeah, I'm with you. I was actually hoping that Fedora might dump Helix as part of Core. Is there anything that Helix does that Totem can't? The only thing I can think of is Helix seems to register itself for protocols it can't handle (Real) and then offers up advertising for RealPlayer when it fails to play the format. Am I missing something, or could we move this to Extras. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From nman64 at n-man.com Fri Aug 19 23:31:55 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 19 Aug 2005 18:31:55 -0500 Subject: HelixPlayer and snd-atiixp In-Reply-To: <1124494147.2901.3.camel@localhost.localdomain> References: <1124477600.3015.22.camel@salem> <20050819210840.2b85c1d7@python2> <1124494147.2901.3.camel@localhost.localdomain> Message-ID: <43066BEB.6000705@n-man.com> Rodd Clarkson wrote: >On Fri, 2005-08-19 at 21:08 +0200, Matthias Saou wrote: > > >>Michel Alexandre Salim wrote : >> >> >> >>>It would seem that the stable builds of Helix and RealPlayer both have >>>problems with the ALSA snd-atiixp driver - the sound would play for a >>>second, stutter and skip, play again, stutter again and so on. >>> >>>The good news is that the daily builds fix this - but for some reason >>>when I play back a Theora video there the colors become messed up. >>> >>>So the question is: is Fedora Core 5 planned to ship with Helix 1.0 or >>>the next stable version? If the former, could whatever changes have been >>>done in the development version to fix the sound problem be backported? >>> >>> >>ooooooooooooooh... someone out there actually uses HelixPlayer? :-D >> >> > >Yeah, I'm with you. > >I was actually hoping that Fedora might dump Helix as part of Core. Is >there anything that Helix does that Totem can't? > >The only thing I can think of is Helix seems to register itself for >protocols it can't handle (Real) and then offers up advertising for >RealPlayer when it fails to play the format. > >Am I missing something, or could we move this to Extras. > > >Rodd > > This has been discussed to death. I think you'll find a lot of agreement, but it isn't moving anywhere. :-( -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From seandarcy2 at gmail.com Sat Aug 20 01:54:16 2005 From: seandarcy2 at gmail.com (sean) Date: Fri, 19 Aug 2005 21:54:16 -0400 Subject: rawhide report: 20050819 changes In-Reply-To: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> Message-ID: Build System wrote: > > > kernel-2.6.12-1.1499_FC5 > ------------------------ > * Thu Aug 18 2005 Dave Jones > - 2.6.13-rc6-git10 > - Drop a bunch of bogus patches. > Something's really wrong with this kernel. On boot cups statup hangs the system. Requires a power down to reboot. Did an interactive startup with cups. Tried to start cups from the terminal; again a complete hang. Got this on syslog: Aug 19 21:36:51 amd64-3000 kernel: parport: PnPBIOS parport detected. Aug 19 21:36:51 amd64-3000 kernel: parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] Aug 19 21:36:51 amd64-3000 kernel: lp0: using parport0 (interrupt-driven). Aug 19 21:36:51 amd64-3000 kernel: lp0: console ready sean From mark at talios.com Sat Aug 20 04:51:12 2005 From: mark at talios.com (Mark Derricutt) Date: Sat, 20 Aug 2005 16:51:12 +1200 Subject: Thunderbird Deer Park Builds Message-ID: <4306B6C0.5000500@talios.com> Hey there, recently rejoined the list... I was wondering if there was any reason that Thunderbird's Deer Park branches wern't being built in Rawhide along with the Firefox Deer Park builds? Cheers, Mark From nman64 at n-man.com Sat Aug 20 04:42:46 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 19 Aug 2005 23:42:46 -0500 Subject: fedoraproject.org Message-ID: <4306B4C6.9020300@n-man.com> I would like to suggest switching the default theme on the wiki to sinorca4moin and making http://fedoraproject.org/ redirect to http://fedoraproject.org/wiki/ . I have been working on reformatting the FrontPage, and, with that theme, it looks great (IMHO) and completely surpasses what is currently at http://fedoraproject.org/ . For the sake of completeness, I have added a link to http://planet.fedoraproject.org/ to the FrontPage, which means it now refers to everything that the current page does. If you take a look at it with the sinorca4moin theme, you can't help but agree. I have even run it by some friends and family who have no interest in Fedora, and they like how it looks. I hope this is a viable option. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Sat Aug 20 05:00:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 20 Aug 2005 01:00:22 -0400 Subject: fedoraproject.org In-Reply-To: <4306B4C6.9020300@n-man.com> References: <4306B4C6.9020300@n-man.com> Message-ID: <1124514022.23700.2.camel@cutter> On Fri, 2005-08-19 at 23:42 -0500, Patrick Barnes wrote: > I would like to suggest switching the default theme on the wiki to > sinorca4moin and making http://fedoraproject.org/ redirect to > http://fedoraproject.org/wiki/ . I have been working on reformatting > the FrontPage, and, with that theme, it looks great (IMHO) and > completely surpasses what is currently at http://fedoraproject.org/ . > For the sake of completeness, I have added a link to > http://planet.fedoraproject.org/ to the FrontPage, which means it now > refers to everything that the current page does. If you take a look at > it with the sinorca4moin theme, you can't help but agree. I have even > run it by some friends and family who have no interest in Fedora, and > they like how it looks. I hope this is a viable option. > We're already working on the web page redesign. Its 'due' on the 25th. Think you could wait a little while longer for what's been worked on? -sv From nman64 at n-man.com Sat Aug 20 05:49:32 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 20 Aug 2005 00:49:32 -0500 Subject: fedoraproject.org In-Reply-To: <1124514022.23700.2.camel@cutter> References: <4306B4C6.9020300@n-man.com> <1124514022.23700.2.camel@cutter> Message-ID: <4306C46C.2000107@n-man.com> seth vidal wrote: >On Fri, 2005-08-19 at 23:42 -0500, Patrick Barnes wrote: > > >>I would like to suggest switching the default theme on the wiki to >>sinorca4moin and making http://fedoraproject.org/ redirect to >>http://fedoraproject.org/wiki/ . I have been working on reformatting >>the FrontPage, and, with that theme, it looks great (IMHO) and >>completely surpasses what is currently at http://fedoraproject.org/ . >>For the sake of completeness, I have added a link to >>http://planet.fedoraproject.org/ to the FrontPage, which means it now >>refers to everything that the current page does. If you take a look at >>it with the sinorca4moin theme, you can't help but agree. I have even >>run it by some friends and family who have no interest in Fedora, and >>they like how it looks. I hope this is a viable option. >> >> >> > >We're already working on the web page redesign. Its 'due' on the 25th. > >Think you could wait a little while longer for what's been worked on? > >-sv > > > > I /suppose/ I can wait a little longer for those changes. I have seen what is at http://fedoraproject.org/mockup/ . If there is more, I can't wait to see it. That was really what clued me in to the sin4orca theme. Still, if the new root-level page is going to be as simple as the current one (as it is in the mockup), you might still consider my suggestion when the time comes. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tadams-lists at myrealbox.com Sat Aug 20 05:52:32 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Fri, 19 Aug 2005 23:52:32 -0600 Subject: rawhide report: 20050819 changes In-Reply-To: References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> Message-ID: <1124517152.2736.2.camel@aurora.localdomain> There are a lot of RTNETLINK errors for some network configurations as well. I imagine the cups hang is related to this. Trever On Fri, 2005-08-19 at 21:54 -0400, sean wrote: > Build System wrote: > > > > > > > kernel-2.6.12-1.1499_FC5 > > ------------------------ > > * Thu Aug 18 2005 Dave Jones > > - 2.6.13-rc6-git10 > > - Drop a bunch of bogus patches. > > > > Something's really wrong with this kernel. > > On boot cups statup hangs the system. Requires a power down > to reboot. > > Did an interactive startup with cups. Tried to start cups > from the terminal; again a complete hang. Got this on syslog: > > Aug 19 21:36:51 amd64-3000 kernel: parport: PnPBIOS parport > detected. > Aug 19 21:36:51 amd64-3000 kernel: parport0: PC-style at > 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] > Aug 19 21:36:51 amd64-3000 kernel: lp0: using parport0 > (interrupt-driven). > Aug 19 21:36:51 amd64-3000 kernel: lp0: console ready > > sean > -- "All that is necessary for the triumph of evil is that enough good men do nothing." -- Edmund Burke From buildsys at redhat.com Sat Aug 20 11:18:05 2005 From: buildsys at redhat.com (Build System) Date: Sat, 20 Aug 2005 07:18:05 -0400 Subject: rawhide report: 20050820 changes Message-ID: <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> Removed package schedutils Removed package schedutils Updated Packages: NetworkManager-0.4.1-2.cvs20050819 ---------------------------------- * Fri Aug 19 2005 Dan Williams - 0.4.1-2.cvs20050819 - Fix occasional hang in NM caused by the applet anaconda-10.3.0.10-1 -------------------- * Fri Aug 19 2005 Paul Nasrat 10.3.0.10-1 - Working towards new backend architecture cairo-0.9.2-3 ------------- * Fri Aug 19 2005 Kristian H??gsberg 0.9.2-3 - Add cairo-0.9.2-dont-hash-null-string.patch to avoid crash when creating a cairo font from a FT_Face. checkpolicy-1.25.11-1 --------------------- * Fri Aug 19 2005 Dan Walsh 1.25.11-1 - Update to NSA Release * Merged use-after-free fix from Serge Hallyn (IBM). Bug found by Coverity. evince-0.3.4-2 -------------- * Fri Aug 19 2005 Kristian H??gsberg 0.3.4-2 - Remove stale autogenerated ev-application-service.h. filesystem-2.3.5-1 ------------------ * Fri Aug 19 2005 Bill Nottingham - 2.3.5-1 - package / (#165797) gdm-1:2.8.0.2-1 --------------- * Fri Aug 19 2005 Ray Strode 1:2.8.0.2-19 - update to 2.8.0.2 - disable early login stuff temporarily gnome-python2-extras-2.11.4-9 ----------------------------- * Fri Aug 19 2005 Jonathan Blandford - 2.11.4-9 - add requires for gtksourceview, #162403 * Fri Aug 19 2005 Jeremy Katz - 2.11.4-8 - totem subpackage shouldn't require mozilla - build again on s390{,x}, but don't do the -nautilus-cdburner subpackage gnome-themes-2.11.91-1 ---------------------- * Fri Aug 19 2005 Matthias Clasen - 2.11.91-1 - New upstream version * Wed Aug 10 2005 Matthias Clasen - 2.11.90-2 - Remove uses of the redmond engine iproute-2.6.13-2 ---------------- * Fri Aug 19 2005 Radek Vokal 2.6.13-2 - upgrade to iproute2-050816 kernel-2.6.12-1.1502_FC5 ------------------------ * Sat Aug 20 2005 Dave Jones - Disable -Os again, to see if some odd bugs 'go away'. * Fri Aug 19 2005 Dave Jones - 2.6.13-rc6-git11 kudzu-1.1.120-1 --------------- * Fri Aug 19 2005 Bill Nottingham 1.1.120-1 - fix macio overzealous snd-powermac probe (#166011, ) - fix overriding of kernel version - allow using that in module_upgrade - remove usb, firewire special cases in pci probing libsepol-1.7.19-1 ----------------- * Fri Aug 19 2005 Dan Walsh 1.7.19-1 - Upgrade to latest from NSA * Changed to treat all type conflicts as fatal errors. * Merged several error handling fixes from Serge Hallyn (IBM). Bugs found by Coverity. openmotif21-2.1.30-17.1 ----------------------- * Fri Aug 19 2005 Thomas Woerner 2.1.30-17.1 - more build fixes and lib64 fixes * Thu Aug 18 2005 Thomas Woerner 2.1.30-17 - build fixes for ppc64 * Wed Aug 03 2005 Karsten Hopp 2.1.30-16 - rebuild with current rpm - remove symlinks sane-backends-1.0.16-1 ---------------------- * Fri Aug 19 2005 Nils Philippsen 1.0.16-1 - version 1.0.16 - remove obsolete docdir patch * Mon Jul 25 2005 Tim Waugh - Fixed libusbscanner comment (bug #162983). xscreensaver-1:4.22-8 --------------------- * Fri Aug 19 2005 Ray Strode 1:4.22-8 - Don't try to use an invalid tree iterator (bug 166299) Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for x86_64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 Broken deps for ppc64 ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config firstboot - 1.3.45-1.noarch requires system-config-display dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) Broken deps for ia64 ---------------------------------------------------------- lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390 ---------------------------------------------------------- selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 From rodd at clarkson.id.au Sat Aug 20 11:31:25 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 20 Aug 2005 21:31:25 +1000 Subject: mouse pointers without points Message-ID: <1124537486.12023.23.camel@localhost.localdomain> Hey hey, There was mention some time back on the list about the new mouse pointer and how the busy mouse pointer doesn't have a point making it quite hard to point at things while it's showing busy. Is this intended to be fixed before FC5? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From laroche at redhat.com Sat Aug 20 12:19:21 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 20 Aug 2005 14:19:21 +0200 Subject: packages not building Message-ID: <20050820121921.GA4910@dudweiler.stuttgart.redhat.com> A simple rebuild test fails for the following packages in the Fedora Core development tree: - avalon-framework (unpacked files) - control-center (pango) - db4 (unpacked files) - dmraid - eclipse (.spec update to newer mozilla version) - evolution-webcal - fedora-release (changed in cvs, but not used from there) - festival - gstreamer - libc-client - openmotiv21 (patch nearly done) - openssl (fix known) - procps (gcc ICE) - pstack (Copyright/License) - python (buffer overflow detected) - python-urlgrabber (unpackaged python files) - rhgb (set-keymap.c:1:24: error: xf86Parser.h: No such file or directory) - rhn-applet - rpm (doesn't build with db4) - samba (unpackaged files) - xen - xfsprogs - xorg-x11 (needs changes for new gcc, vnc patch?) greetings, Florian La Roche From kyrre at solution-forge.net Sat Aug 20 12:31:15 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 20 Aug 2005 14:31:15 +0200 Subject: Thunderbird Deer Park Builds In-Reply-To: <4306B6C0.5000500@talios.com> References: <4306B6C0.5000500@talios.com> Message-ID: <1124541075.3398.2.camel@localhost.localdomain> l?r, 20.08.2005 kl. 06.51 skrev Mark Derricutt: > Hey there, recently rejoined the list... > > I was wondering if there was any reason that Thunderbird's Deer Park > branches wern't being built in Rawhide along with the Firefox Deer Park > builds? > > Cheers, > Mark While speaking of Deer Park - is it now being built with --enable-svg? From kyrre at solution-forge.net Sat Aug 20 12:33:42 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 20 Aug 2005 14:33:42 +0200 Subject: Wiki problem in Internet Explorer In-Reply-To: <43066A36.9020800@n-man.com> References: <43066A36.9020800@n-man.com> Message-ID: <1124541222.3398.5.camel@localhost.localdomain> l?r, 20.08.2005 kl. 01.24 skrev Patrick Barnes: > While trying to get the FrontPage of the wiki looking a little better, I > decided to give it a try in Internet Explorer. What I saw I didn't > like. At first, I thought I had done something that IE didn't like, but > after investigation (including a bunch of trivial changes) I have > determined that the problem more likely lies in the CSS for the default > theme. > > The problem in IE is that some objects such as tables and textareas have > a large amount of whitespace above them. I haven't checked many > versions of Internet Explorer, but the most recent versions are affected. > > I would like to advise that the CSS for rightsidebarsmaller (and perhaps > others) needs to be checked into. Although most of the visits to > fedoraproject.org are probably from Linux viewers, we are also trying to > show Windows users to the light. We will have visitors using Internet > Explorer, and should try to make sure things look right. > > Another option would be to set the default theme to sinorca4moin, which > does not exhibit the problem. > > -- > Patrick "The N-Man" Barnes > nman64 at n-man.com > > www.n-man.com A better solution migth be to use the "ie conditional comment" (a acctually *usefull* proprietary function :) ) in order to serve IE another CSS file than for standards-compliant browsers. ---Kyrre From jspaleta at gmail.com Sat Aug 20 12:37:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 20 Aug 2005 08:37:08 -0400 Subject: mouse pointers without points In-Reply-To: <1124537486.12023.23.camel@localhost.localdomain> References: <1124537486.12023.23.camel@localhost.localdomain> Message-ID: <604aa79105082005376cd05677@mail.gmail.com> On 8/20/05, Rodd Clarkson wrote: > Hey hey, > > There was mention some time back on the list about the new mouse pointer > and how the busy mouse pointer doesn't have a point making it quite hard > to point at things while it's showing busy. > > Is this intended to be fixed before FC5? For reference here's my open bugticket https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163115 -jef From fedora at wir-sind-cool.org Sat Aug 20 13:19:20 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 20 Aug 2005 15:19:20 +0200 Subject: rawhide report: 20050819 changes In-Reply-To: References: <200508191123.j7JBNFJX024499@porkchop.devel.redhat.com> Message-ID: <20050820151920.1744e958.fedora@wir-sind-cool.org> On Fri, 19 Aug 2005 21:54:16 -0400, sean wrote: > > kernel-2.6.12-1.1499_FC5 > > ------------------------ > > * Thu Aug 18 2005 Dave Jones > > - 2.6.13-rc6-git10 > > - Drop a bunch of bogus patches. > > > > Something's really wrong with this kernel. > > On boot cups statup hangs the system. Requires a power down > to reboot. The next kernel update has been released already and contains a changelog comment which might explain these symptoms. 1499 here broke networking quite badly (connection refused for almost everything). So, give the update a try. From jamatos at fc.up.pt Sat Aug 20 15:47:30 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 20 Aug 2005 16:47:30 +0100 Subject: RFP for Extras: Grace In-Reply-To: <1124112880.17178.6.camel@cutter> References: <43009884.8050500@redhat.com> <1124112880.17178.6.camel@cutter> Message-ID: <200508201647.30168.jamatos@fc.up.pt> On Monday 15 August 2005 14:34, seth vidal wrote: > http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rp >m > > If anyone wants to take that and run it through extras, please do. I will take that as a base and I will do some comestic changes required to submit it to extras. One question, what is the appropriate behaviour regarding the Changelog? It does not make much sense to include entries from 1999, but on the other hand I want to acknowledge the work previously done in the spec file. > -sv -- Jos? Ab?lio Matos From seandarcy2 at gmail.com Sat Aug 20 16:11:42 2005 From: seandarcy2 at gmail.com (sean) Date: Sat, 20 Aug 2005 12:11:42 -0400 Subject: file has lost its magic Message-ID: rpm -q file file-4.15-1 file lt-file: could not find any magic files! ls /usr/share/file/ magic magic.mgc magic.mime magic.mime.mgc sean From skvidal at phy.duke.edu Sat Aug 20 16:46:01 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 20 Aug 2005 12:46:01 -0400 Subject: RFP for Extras: Grace In-Reply-To: <200508201647.30168.jamatos@fc.up.pt> References: <43009884.8050500@redhat.com> <1124112880.17178.6.camel@cutter> <200508201647.30168.jamatos@fc.up.pt> Message-ID: <1124556361.23700.14.camel@cutter> On Sat, 2005-08-20 at 16:47 +0100, Jose' Matos wrote: > On Monday 15 August 2005 14:34, seth vidal wrote: > > http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rp > >m > > > > If anyone wants to take that and run it through extras, please do. > > I will take that as a base and I will do some comestic changes required to > submit it to extras. > > One question, what is the appropriate behaviour regarding the Changelog? It > does not make much sense to include entries from 1999, but on the other hand > I want to acknowledge the work previously done in the spec file. > kill the old entries, imo. die die die to old entries. :) -sv From sundaram at redhat.com Sat Aug 20 16:49:59 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 20 Aug 2005 22:19:59 +0530 Subject: RFP for Extras: Grace In-Reply-To: <1124556361.23700.14.camel@cutter> References: <43009884.8050500@redhat.com> <1124112880.17178.6.camel@cutter> <200508201647.30168.jamatos@fc.up.pt> <1124556361.23700.14.camel@cutter> Message-ID: <43075F37.2000309@redhat.com> seth vidal wrote: >On Sat, 2005-08-20 at 16:47 +0100, Jose' Matos wrote: > > >>On Monday 15 August 2005 14:34, seth vidal wrote: >> >> >>>http://linux.duke.edu/~skvidal/RPMS/extras/grace-5.1.18-0.duke.1.fc4.src.rp >>>m >>> >>>If anyone wants to take that and run it through extras, please do. >>> >>> >> I will take that as a base and I will do some comestic changes required to >>submit it to extras. >> >> One question, what is the appropriate behaviour regarding the Changelog? It >>does not make much sense to include entries from 1999, but on the other hand >>I want to acknowledge the work previously done in the spec file. >> >> >> > >kill the old entries, imo. > >die die die to old entries. :) > >-sv > > > Some kind of formal Fedora Extras packaging guideline about killing off old entries from the changelog would be nice to have. regards Rahul From jamatos at fc.up.pt Sat Aug 20 17:35:47 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Sat, 20 Aug 2005 18:35:47 +0100 Subject: RFP for Extras: Grace In-Reply-To: <43075F37.2000309@redhat.com> References: <43009884.8050500@redhat.com> <1124556361.23700.14.camel@cutter> <43075F37.2000309@redhat.com> Message-ID: <200508201835.47241.jamatos@fc.up.pt> On Saturday 20 August 2005 17:49, Rahul Sundaram wrote: > > Some kind of formal Fedora Extras packaging guideline about killing off > old entries from the changelog would be nice to have. FWIW I decided to delete those entries and I give the right attribution in the first entry to the previous maintainers (icon and Seth). > regards > Rahul -- Jos? Ab?lio Matos From msalim at cs.indiana.edu Sat Aug 20 17:39:12 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Sat, 20 Aug 2005 12:39:12 -0500 Subject: rawhide report: 20050820 changes In-Reply-To: <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> References: <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> Message-ID: <1124559552.3767.3.camel@salem> On Sat, 2005-08-20 at 07:18 -0400, Build System wrote: > gdm-1:2.8.0.2-1 > --------------- > * Fri Aug 19 2005 Ray Strode 1:2.8.0.2-19 > - update to 2.8.0.2 > - disable early login stuff temporarily > Anyone else having problem with this? gdm would say 'Booting...' as if it's being started early during the boot process, and when I try to login I get this dialog box: Cannot start the session due to some internal error. OK'ing that gets this in .xsession-errors: /etc/X11/gdm/PreSession/Default: Registering your session with wtmp and utmp /etc/X11/gdm/PreSession/Default: running: /usr/X11R6/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x "/var/gdm/:0.Xservers" -h "" -l ":0" "michel" session_child_run: Could not exec /etc/X11/xdm/Xsession gnome-session - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Sat Aug 20 23:07:47 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sat, 20 Aug 2005 19:07:47 -0400 Subject: rawhide report: 20050820 changes In-Reply-To: Your message of "Sat, 20 Aug 2005 07:18:05 -0400." <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> Message-ID: <200508202307.j7KN7lq8031243@laptop11.inf.utfsm.cl> Build System wrote: > Removed package schedutils > > Removed package schedutils I'm sure it had to go, but killing it twice is just cruelty. -- 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 davej at redhat.com Sun Aug 21 01:29:21 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 20 Aug 2005 21:29:21 -0400 Subject: rawhide report: 20050820 changes In-Reply-To: <200508202307.j7KN7lq8031243@laptop11.inf.utfsm.cl> References: <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> <200508202307.j7KN7lq8031243@laptop11.inf.utfsm.cl> Message-ID: <20050821012921.GA21555@redhat.com> On Sat, Aug 20, 2005 at 07:07:47PM -0400, Horst von Brand wrote: > Build System wrote: > > Removed package schedutils > > > > Removed package schedutils > > I'm sure it had to go, but killing it twice is just cruelty. Heh, it got absorbed into util-linux, so I asked Bill and Jeremy to kill it. They both sent me an ACK, but I didn't realise it'd actually kill it twice :-) Perhaps I should ask again, just to be sure.. Dave From wangzaixiang at gmail.com Sun Aug 21 04:34:01 2005 From: wangzaixiang at gmail.com (=?GB2312?B?zfXU2s/p?=) Date: Sun, 21 Aug 2005 12:34:01 +0800 Subject: Installation Issue Message-ID: <69f3b8db050820213454f18d30@mail.gmail.com> Hi, I am a new guy for the Xen, and When i try to using Xen with Fedora 4, There is some trouble that stop me complete the work. Can you give me some advice? thanks very much. 1. I installed FC4 successfully 2. rpm -i xen-2-20050522.i386.rpm it report that it depend on bridge-utils, libSDL-1.2.so.0 3. then i execute rpm -i bridge-utils-1.0.4-6.i386.rpm it report it depends on libsysfs.so.1 then i dont know how to do next, since i cant find any rpm file matach libSDL, libsysfs.so.1, So can anybody who already installed Xen with FC4 help me? also, the http://www.fedoraproject.org/wiki/FedoraXenQuickstart page say: To run xen, you'll need to install the xen package as well as a xen0 and xenU kernel packages. You'll also need - python-twisted - Using grub as your boot loader 1 - Probably something on the order of 256 MB of RAM with the default setup 2 Then, you should be able to install the xen and kernel-xen0 packages. Once this is done, you should have an entry set up in your grub.conf to boot the xen0 kernel. Now, reboot into your new xen0 kernel 3 Is there any details on how to install xen step by step? as a beginner, i am not sure, where is the xen and kernel-xen0 packages? wangzaixiang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivazquez at ivazquez.net Sun Aug 21 04:45:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 21 Aug 2005 00:45:49 -0400 Subject: Installation Issue In-Reply-To: <69f3b8db050820213454f18d30@mail.gmail.com> References: <69f3b8db050820213454f18d30@mail.gmail.com> Message-ID: <1124599549.3414.17.camel@ignacio.lan> On Sun, 2005-08-21 at 12:34 +0800, ??? wrote: > I am a new guy for the Xen, and When i try to using Xen with Fedora 4, > There is some trouble that stop me complete the work. Can you give me > some advice? thanks very much. http://fedora.redhat.com/docs/yum/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 nman64 at n-man.com Sun Aug 21 04:47:38 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 20 Aug 2005 23:47:38 -0500 Subject: Installation Issue In-Reply-To: <69f3b8db050820213454f18d30@mail.gmail.com> References: <69f3b8db050820213454f18d30@mail.gmail.com> Message-ID: <4308076A.4080501@n-man.com> ??? wrote: > Hi, > > I am a new guy for the Xen, and When i try to using Xen with Fedora 4, > There is some trouble that stop me complete the work. Can you give me > some advice? thanks very much. > > 1. I installed FC4 successfully > 2. rpm -i xen-2-20050522.i386.rpm > it report that it depend on bridge-utils, libSDL-1.2.so.0 > 3. then i execute rpm -i bridge-utils-1.0.4-6.i386.rpm > it report it depends on libsysfs.so.1 > > then i dont know how to do next, since i cant find any rpm file matach > libSDL, libsysfs.so.1, So can anybody who already installed Xen with > FC4 help me? > > also, the http://www.fedoraproject.org/wiki/FedoraXenQuickstart page say: > > To run xen, you'll need to install the xen package as well as a xen0 > and xenU kernel packages. You'll also need > > * > > python-twisted > > * > > Using grub as your boot loader ^1 > > > > * > > Probably something on the order of 256 MB of RAM with the > default setup ^ 2 > > > > Then, you should be able to install the xen and kernel-xen0 packages. > Once this is done, you should have an entry set up in your grub.conf > to boot the xen0 kernel. Now, reboot into your new xen0 kernel ^3 > > > > Is there any details on how to install xen step by step? as a > beginner, i am not sure, where is the xen and kernel-xen0 packages? > > > wangzaixiang For starters, try using the following command to install the package instead. I haven't tested this, so I'm not sure if you will run into problems or not. yum localinstall xen-2-20050522.i386.rpm Hopefully, yum will be able to solve your dependencies and get you going. Really, you should have little use for running rpm directly, as yum will handle most package managing tasks in a better manner. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From arjanv at redhat.com Sun Aug 21 06:47:39 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 21 Aug 2005 08:47:39 +0200 Subject: rawhide report: 20050820 changes In-Reply-To: <20050821012921.GA21555@redhat.com> References: <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> <200508202307.j7KN7lq8031243@laptop11.inf.utfsm.cl> <20050821012921.GA21555@redhat.com> Message-ID: <1124606860.3209.7.camel@laptopd505.fenrus.org> On Sat, 2005-08-20 at 21:29 -0400, Dave Jones wrote: > On Sat, Aug 20, 2005 at 07:07:47PM -0400, Horst von Brand wrote: > > Build System wrote: > > > Removed package schedutils > > > > > > Removed package schedutils > > > > I'm sure it had to go, but killing it twice is just cruelty. > > Heh, it got absorbed into util-linux, so I asked Bill and Jeremy > to kill it. They both sent me an ACK, but I didn't realise it'd > actually kill it twice :-) > > Perhaps I should ask again, just to be sure.. well you turned it into a zombie now.. need lots of garlick and some wooden stakes to get rid of it now. -------------- 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 Aug 21 11:25:04 2005 From: buildsys at redhat.com (Build System) Date: Sun, 21 Aug 2005 07:25:04 -0400 Subject: rawhide report: 20050821 changes Message-ID: <200508211125.j7LBP4Oc027345@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.12-1.1504_FC5 ------------------------ yaboot-1.3.13-0.11 ------------------ * Sat Aug 20 2005 Paul Nasrat - 1.3.13-0.11 - drop netboot patch as mac cds fail to load yaboot.conf Broken deps for ia64 ---------------------------------------------------------- xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 rgmanager - 1.9.31-3.ia64 requires ccs selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390 ---------------------------------------------------------- selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 Broken deps for ppc64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 firstboot - 1.3.45-1.noarch requires system-config-display From aoliva at redhat.com Sun Aug 21 18:13:01 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Aug 2005 15:13:01 -0300 Subject: rawhide report: 20050820 changes In-Reply-To: <1124559552.3767.3.camel@salem> References: <200508201118.j7KBI5Tv004108@porkchop.devel.redhat.com> <1124559552.3767.3.camel@salem> Message-ID: On Aug 20, 2005, Michel Alexandre Salim wrote: > Anyone else having problem with this? gdm would say 'Booting...' as if > it's being started early during the boot process, Yep, it's in bugzilla. > Cannot start the session due to some internal error. In bugzilla also, but a query for gdm won't find it, since it's filed against selinux-policy-targeted. setenforce 0 will work around the problem for the time being. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dwmw2 at infradead.org Sun Aug 21 18:39:08 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 21 Aug 2005 19:39:08 +0100 Subject: HelixPlayer and snd-atiixp In-Reply-To: <1124483221.15060.5.camel@salem> References: <1124477600.3015.22.camel@salem> <20050819210840.2b85c1d7@python2> <1124483221.15060.5.camel@salem> Message-ID: <1124649548.5248.2.camel@baythorne.infradead.org> On Fri, 2005-08-19 at 15:27 -0500, Michel Alexandre Salim wrote: > If only to help bugfix RealPlayer, which I need to play BBC Radio > streams? (whatever happened to their Ogg Vorbis trials..) The RealPlayer libraries also work in Xine. -- dwmw2 From steve at rueb.com Sun Aug 21 19:07:54 2005 From: steve at rueb.com (Steve Bergman) Date: Sun, 21 Aug 2005 14:07:54 -0500 Subject: KDE RedHat project In-Reply-To: <604aa79105081805291b3e5a01@mail.gmail.com> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> Message-ID: <4308D10A.7090903@rueb.com> Jeff Spaleta wrote: >On 8/18/05, Thorsten Leemhuis wrote: > > >>But if some Add-On-Repos would provide such a CD-ISO as add-on in their >>Repo and if this CD is well known to everyone ("hey, go and get that >>Fedora-Add-On-CD, without it Fedora is not fully functional") it would >>solve the problem for most people in the freeworld more easily. >> >> > >Logic fault: >if its well known to everyone there would be no need to point to it by >anyone else. > >Semantics aside and without touching the policy issue that Sundaram >brought up about whether its the right policy decision, no... redhat >as the managing entity cannot willfully point people to a collection >of software they know is infringing..even if its public knowledge by >other means. It doesn't matter if this makes logical sense, we are >talking about US law here.. logic does not apply. Legal risk is legal >risk, the entity who is liable has to evaluate the situation and >determine where the line is as to what behavior brings unacceptable >risk. Since redhat is the one exposed to the legal liability at the >moment as the managing entity, its very difficult to make any >compelling argument that second guesses their legal opinion as an >outside layperson, simply because our assets are not on the line. > >-jef"is waiting for someone in the community to offer to indemnify >redhat against all liability for contributory infringement"spaleta > > > What I keep hearing in this thread is that RedHat's position as the "managing entity" of Fedora is holding Fedora back in the area of multimedia. Don't get me wrong; most Fedora work gets done by people with redhat.com email addresses. But it is true that RedHat represents a nice *central* target for a legal suit, which is just what patent holders like. It's so old-school and comfortable to have some central entity, with money, to attack. How might the promised Fedora Foundation change this? Personally, I'd be happy if the installation offered the ability to add entries to yum.repos.d (a big hurdle for newbies) which was not limited to, but did include Livna, accompanied by the expected stern warnings about respecting your local laws. Adding repositories is not a big deal for us old hands; It's just a PITA, nothing more. But the newbie is already overwhelmed by switching OSes. To them, "Fedora just doesn't support multimedia". All discussions of "feature parity" aside, when's the last time you saw an Ogg Theora stream on Yahoo's site? From alan at redhat.com Sun Aug 21 21:55:11 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 21 Aug 2005 17:55:11 -0400 Subject: KDE RedHat project In-Reply-To: <4308D10A.7090903@rueb.com> References: <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> Message-ID: <20050821215511.GA21170@devserv.devel.redhat.com> On Sun, Aug 21, 2005 at 02:07:54PM -0500, Steve Bergman wrote: > so old-school and comfortable to have some central entity, with money, > to attack. How might the promised Fedora Foundation change this? It won't. > Personally, I'd be happy if the installation offered the ability to add > entries to yum.repos.d (a big hurdle for newbies) which was not limited > to, but did include Livna, accompanied by the expected stern warnings > about respecting your local laws. Americans have strange ideas about their laws and the extent they cover. Sometimes to good effect (eg corruption laws) sometimes to bad. For a US based body to advocate that a non-US citizen exercise their legal rights if those rights conflict with "US law" is an area that requires careful legal thought. Remember that US "freedom of speech" is political speech - so the right to complain about the existing US policies and fight them is protected not the right to tell people how to violate them. Alan From paul at cypherpunks.ca Sun Aug 21 22:23:56 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 22 Aug 2005 00:23:56 +0200 (CEST) Subject: Where to get obsoleted updates? Message-ID: Hi guys, It seems that the Fedora FTP server and mirrors only keep the original rpms and the latest updates to those rpms online. Where does one find the obsoleted updated? In my case, I needed to grab kernel-2.6.11-1.35_FC3.src.rpm and could not find it anymore. Is there a graveyard somewhere that google does not know about? Everything google finds are broken links to places that have updated like the original server, and no longer have the obsoleted rpms. Paul ps. I did find a copy on some obscure site, so my immediate problem is resolved, but shouldn't Fedora keep at least src.rpms from previous updated packages around? From skvidal at phy.duke.edu Mon Aug 22 00:41:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 21 Aug 2005 20:41:36 -0400 Subject: KDE RedHat project In-Reply-To: <20050821215511.GA21170@devserv.devel.redhat.com> References: <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> Message-ID: <1124671296.4780.1.camel@cutter> On Sun, 2005-08-21 at 17:55 -0400, Alan Cox wrote: > On Sun, Aug 21, 2005 at 02:07:54PM -0500, Steve Bergman wrote: > > so old-school and comfortable to have some central entity, with money, > > to attack. How might the promised Fedora Foundation change this? > > It won't. > > > Personally, I'd be happy if the installation offered the ability to add > > entries to yum.repos.d (a big hurdle for newbies) which was not limited > > to, but did include Livna, accompanied by the expected stern warnings > > about respecting your local laws. > > Americans have strange ideas about their laws and the extent they cover. Please be careful with the sweeping generalizations of a class of people simply based nationality. It's not fair and it is not appropriate. Thanks, -sv From skvidal at phy.duke.edu Mon Aug 22 00:43:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 21 Aug 2005 20:43:35 -0400 Subject: KDE RedHat project In-Reply-To: <1124671296.4780.1.camel@cutter> References: <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> <1124671296.4780.1.camel@cutter> Message-ID: <1124671415.4780.3.camel@cutter> On Sun, 2005-08-21 at 20:41 -0400, seth vidal wrote: > On Sun, 2005-08-21 at 17:55 -0400, Alan Cox wrote: > > On Sun, Aug 21, 2005 at 02:07:54PM -0500, Steve Bergman wrote: > > > so old-school and comfortable to have some central entity, with money, > > > to attack. How might the promised Fedora Foundation change this? > > > > It won't. > > > > > Personally, I'd be happy if the installation offered the ability to add > > > entries to yum.repos.d (a big hurdle for newbies) which was not limited > > > to, but did include Livna, accompanied by the expected stern warnings > > > about respecting your local laws. > > > > Americans have strange ideas about their laws and the extent they cover. > > Please be careful with the sweeping generalizations of a class of > people simply based nationality. the word 'on' here ^ -sv From laroche at redhat.com Mon Aug 22 06:04:32 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 22 Aug 2005 08:04:32 +0200 Subject: Where to get obsoleted updates? In-Reply-To: References: Message-ID: <20050822060432.GA3780@dudweiler.stuttgart.redhat.com> > ps. I did find a copy on some obscure site, so my immediate problem is > resolved, but shouldn't Fedora keep at least src.rpms from previous > updated packages around? You can also use the cvs server to get the exact source for those. greetings, Florian La Roche From radekvokal at gmail.com Mon Aug 22 06:46:44 2005 From: radekvokal at gmail.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Mon, 22 Aug 2005 08:46:44 +0200 Subject: file has lost its magic In-Reply-To: References: Message-ID: <1124693204.1796.4.camel@localhost.localdomain> On Sat, 2005-08-20 at 12:11 -0400, sean wrote: > rpm -q file > file-4.15-1 > > file > lt-file: could not find any magic files! > > ls /usr/share/file/ > magic magic.mgc magic.mime magic.mime.mgc > > sean > Strange, what does file -v says? -- Radek Vok?l From alan at redhat.com Mon Aug 22 09:34:17 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 22 Aug 2005 05:34:17 -0400 Subject: KDE RedHat project In-Reply-To: <1124671296.4780.1.camel@cutter> References: <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> <1124671296.4780.1.camel@cutter> Message-ID: <20050822093417.GA23335@devserv.devel.redhat.com> On Sun, Aug 21, 2005 at 08:41:36PM -0400, seth vidal wrote: > > Americans have strange ideas about their laws and the extent they cover. > > Please be careful with the sweeping generalizations of a class of > people simply based nationality. Fair comment I should have said "America has" Alan From nphilipp at redhat.com Mon Aug 22 09:49:06 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 22 Aug 2005 11:49:06 +0200 Subject: KDE RedHat project In-Reply-To: <20050822093417.GA23335@devserv.devel.redhat.com> References: <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> <1124671296.4780.1.camel@cutter> <20050822093417.GA23335@devserv.devel.redhat.com> Message-ID: <1124704146.4229.8.camel@wombat.tiptoe.de> On Mon, 2005-08-22 at 05:34 -0400, Alan Cox wrote: > On Sun, Aug 21, 2005 at 08:41:36PM -0400, seth vidal wrote: > > > Americans have strange ideas about their laws and the extent they cover. > > > > Please be careful with the sweeping generalizations of a class of > > people simply based nationality. > > Fair comment I should have said "America has" Being British you probably should have said "America have ..." because corporations are plural (SCNR ;-)). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From buildsys at redhat.com Mon Aug 22 11:22:12 2005 From: buildsys at redhat.com (Build System) Date: Mon, 22 Aug 2005 07:22:12 -0400 Subject: rawhide report: 20050822 changes Message-ID: <200508221122.j7MBMCBY018383@porkchop.devel.redhat.com> Updated Packages: gaim-1:1.5.0-4.fc5 ------------------ * Sun Aug 21 2005 Peter Jones - 1:1.5.0-4.fc5 - rebuild for new cairo openoffice.org-1:1.9.125-1.2.0.fc5 ---------------------------------- * Wed Aug 17 2005 Caolan McNamara - 1:1.9.125-1 - beta2 - drop integrated workspace.cmcfixes14.patch - drop integrated ooo46585.sunmiscisnotstandard.filter.patch - drop integrated ooo30133.lingucomponent.ukrainean.patch - drop integrated ooo53026.selinux-pipegiveup.desktop.patch Broken deps for i386 ---------------------------------------------------------- dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ia64 ---------------------------------------------------------- selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 rgmanager - 1.9.31-3.ia64 requires ccs pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.ia64 requires kernel >= 0:2.6 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc64 ---------------------------------------------------------- system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 ppc64-utils - 0.7-9.ppc64 requires yaboot firstboot - 1.3.45-1.noarch requires system-config-display system-config-mouse - 1.2.11-1.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 Broken deps for s390 ---------------------------------------------------------- lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 selinux-policy-targeted - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 selinux-policy-strict-sources - 1.25.4-4.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 From i.pilcher at comcast.net Mon Aug 22 13:45:35 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 22 Aug 2005 08:45:35 -0500 Subject: KDE RedHat project In-Reply-To: <20050822093417.GA23335@devserv.devel.redhat.com> References: <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> <1124671296.4780.1.camel@cutter> <20050822093417.GA23335@devserv.devel.redhat.com> Message-ID: Alan Cox wrote: > On Sun, Aug 21, 2005 at 08:41:36PM -0400, seth vidal wrote: > >>>Americans have strange ideas about their laws and the extent they cover. >> >> Please be careful with the sweeping generalizations of a class of >>people simply based nationality. > > > Fair comment I should have said "America has" > How about "American legislators and courts?" -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From ph18 at cornell.edu Mon Aug 22 13:57:35 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 22 Aug 2005 09:57:35 -0400 Subject: KDE RedHat project In-Reply-To: <4308D10A.7090903@rueb.com> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> Message-ID: <4309D9CF.60408@cornell.edu> Steve Bergman wrote: > > Adding repositories is not a big deal for us old hands; It's just a > PITA, nothing more. But the newbie is already overwhelmed by > switching OSes. To them, "Fedora just doesn't support multimedia". > All discussions of "feature parity" aside, when's the last time you > saw an Ogg Theora stream on Yahoo's site? > Yeah, streaming media is the worst of it. Ogg Vorbis is a fine format to "rip, mix and burn", and its what I use for ordinary listening -- even if I'm on Windows. With a good set of headphones (digital USB) I can hear the difference between Ogg @ 200k and the common MP3 @ 128k, and definitely Ogg @ 128k is better than MP3 @ 128k. Recently I noticed that I could tell the difference between listening to the CD and Ogg @ 200k, which pushes for FLAC, a free lossless format that's quite comparable to ALAC and other commercial competitors. I still make 64k MP3's to download to my flash player, but there's nothing like Live365 in Ogg Vorbis land. However, Vorbis is widely supported these days -- years ago I used to argue with an activist friends that the difference between putting an Orbis stream online and no stream at all was infinitesimal, but a year later it was supported by popular media players in Windows. The disturbing development these days are formats like MP3Pro and AAC3 which use Spectral Band Replication to throw out the highs and then reconstruct fake highs from the low. These are particularly attractive if you're aiming for the "beer commercial" sound of modern FM radio and have the audio processing chain to match. The sound is superficially attractive at low bit rates, but is atrocious if you listen carefully -- needless to say, a whole new set of legal barricades has been built against open source implementation of these standards. ----------- I'd argue, however, that "positive propaganda" is the right strategy here too: if RH (and much of the OS community) takes the principled stand of providing a free media stack, it ought to put a little bit of energy into promoting free media formats -- for instance, it would be nice to see a web site promoting the Ogg Vorbis streams that are out there, just as there are sites promoting the SBR heresy... http://www.tuner2.com/ From kyrre at solution-forge.net Mon Aug 22 14:01:25 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 22 Aug 2005 16:01:25 +0200 Subject: Unstable firefox Message-ID: <1124719285.3399.1.camel@localhost.localdomain> Anybody else noticed that firefox crashes every time some dialog box pops up? Is this a known bug soon fixed, or should i report it in rawhide? Kyrre From arnaud.abelard at univ-nantes.fr Mon Aug 22 14:05:37 2005 From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=) Date: Mon, 22 Aug 2005 16:05:37 +0200 Subject: missing kernel-devel-2.6.12-1.1372_FC3smp Message-ID: <4309DBB1.2000406@univ-nantes.fr> i'm currently running kernel-2.6.12-1.1372_FC3smp and the symlink /lib/modules/2.6.12-1.1372_FC3smp/build is pointing to ../../../usr/src/kernels/2.6.12-1.1372_FC3smp-i686/ althought a yum install kernel-source installed kernel-source-2.6.12-1.1372_FC3 and no package kernel-devel-2.6.12-1.1372_FC3smp is available... is that "normal" ? AA. -- Arnaud Ab?lard Administrateur Syst?mes et R?seaux Facult? de Sciences et Techniques Universit? de Nantes From paul at city-fan.org Mon Aug 22 14:10:57 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 22 Aug 2005 15:10:57 +0100 Subject: missing kernel-devel-2.6.12-1.1372_FC3smp In-Reply-To: <4309DBB1.2000406@univ-nantes.fr> References: <4309DBB1.2000406@univ-nantes.fr> Message-ID: <4309DCF1.8080802@city-fan.org> Arnaud Ab?lard wrote: > i'm currently running kernel-2.6.12-1.1372_FC3smp and the symlink > /lib/modules/2.6.12-1.1372_FC3smp/build is pointing to > ../../../usr/src/kernels/2.6.12-1.1372_FC3smp-i686/ althought a yum > install kernel-source installed kernel-source-2.6.12-1.1372_FC3 and no > package kernel-devel-2.6.12-1.1372_FC3smp is available... > > is that "normal" ? Yes. Try this: # yum install kernel-smp-devel Paul. From sundaram at redhat.com Mon Aug 22 14:19:29 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 22 Aug 2005 19:49:29 +0530 Subject: KDE RedHat project In-Reply-To: <4309D9CF.60408@cornell.edu> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <4309D9CF.60408@cornell.edu> Message-ID: <4309DEF1.50904@redhat.com> Hi > > I'd argue, however, that "positive propaganda" is the right > strategy here too: if RH (and much of the OS community) takes the > principled stand of providing a free media stack, it ought to put a > little bit of energy into promoting free media formats -- for > instance, it would be nice to see a web site promoting the Ogg Vorbis > streams that are out there, just as there are sites promoting the SBR > heresy... > > http://www.tuner2.com/ > That does seem like a good idea to me. If you got other areas that we can improve the the promotion of free media formats, do post to the fedora-marketing list. regards Rahyk From jakub at redhat.com Mon Aug 22 14:46:36 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 22 Aug 2005 10:46:36 -0400 Subject: GCC 4.1 for FC5? In-Reply-To: <1124417799.3017.5.camel@localhost.localdomain> References: <1124417799.3017.5.camel@localhost.localdomain> Message-ID: <20050822144636.GU7403@devserv.devel.redhat.com> On Thu, Aug 18, 2005 at 07:16:39PM -0700, Anthony Green wrote: > Are there plans to use GCC 4.1 in FC5 (assuming it ships on schedule)? I think this depends mainly how the schedule for GCC 4.1 shapes up (e.g. Mark's Status Report from yesterday says Stage3 is going to slip) and how stable it will be when we start doing mass rebuild tests with it. IMHO it is too early for the decision about FC5 base compiler version. I certainly hope it will be GCC 4.1, but we should have doors open even for GCC 4.0 if needed. Jakub From caillon at redhat.com Mon Aug 22 14:54:47 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 22 Aug 2005 10:54:47 -0400 Subject: Unstable firefox In-Reply-To: <1124719285.3399.1.camel@localhost.localdomain> References: <1124719285.3399.1.camel@localhost.localdomain> Message-ID: <4309E737.1000907@redhat.com> On 08/22/2005 10:01 AM, Kyrre Ness Sjobak wrote: >Anybody else noticed that firefox crashes every time some dialog box >pops up? > >Is this a known bug soon fixed, or should i report it in rawhide? > > Feel free to report it before coming to the list. There's no shame in filing a duplicate bug report if you make a reasonable attempt to ensure its not already filed (enter "ALL :firefox crash" at the main bugzilla page to see all firefox bugs filed, including the ones that have been resolved, with the word crash in the summary). The worse that can happen is your bug gets marked a duplicate of another. From seanlkml at sympatico.ca Mon Aug 22 16:36:34 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 22 Aug 2005 12:36:34 -0400 (EDT) Subject: KDE RedHat project In-Reply-To: <4308D10A.7090903@rueb.com> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> Message-ID: <52688.10.10.10.28.1124728594.squirrel@linux1> On Sun, August 21, 2005 3:07 pm, Steve Bergman said: > What I keep hearing in this thread is that RedHat's position as the > "managing entity" of Fedora is holding Fedora back in the area of > multimedia. Not really, just not embracing proprietary multimedia formats. It's a question of priorities. > Don't get me wrong; most Fedora work gets done by people with redhat.com > email addresses. But it is true that RedHat represents a nice *central* > target for a legal suit, which is just what patent holders like. It's > so old-school and comfortable to have some central entity, with money, > to attack. How might the promised Fedora Foundation change this? > > Personally, I'd be happy if the installation offered the ability to add > entries to yum.repos.d (a big hurdle for newbies) which was not limited > to, but did include Livna, accompanied by the expected stern warnings > about respecting your local laws. It would be good to make it easier to install yum repo entries; for instance by just clicking on a web page link. The actual links wouldn't have to be provided or even referenced by Fedora. > Adding repositories is not a big deal for us old hands; It's just a > PITA, nothing more. But the newbie is already overwhelmed by switching > OSes. To them, "Fedora just doesn't support multimedia". All > discussions of "feature parity" aside, when's the last time you saw an > Ogg Theora stream on Yahoo's site? There's a bit of a chicken and egg problem here. We need to create a demand for free formats at the same time as creating a supply. Cheers, Sean From jspaleta at gmail.com Mon Aug 22 16:43:26 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 22 Aug 2005 12:43:26 -0400 Subject: KDE RedHat project In-Reply-To: <52688.10.10.10.28.1124728594.squirrel@linux1> References: <430255B8.5070600@develer.com> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <52688.10.10.10.28.1124728594.squirrel@linux1> Message-ID: <604aa79105082209432b7931d0@mail.gmail.com> On 8/22/05, Sean wrote: > It would be good to make it easier to install yum repo entries; for > instance by just clicking on a web page link. The actual links wouldn't > have to be provided or even referenced by Fedora. Create the more general mechanism for installing an rpm via a link, securely.. and you get this feature without any extra effort for repositories that provide reponame-release styled packages that include repo definitions. -jef From green at redhat.com Mon Aug 22 16:59:15 2005 From: green at redhat.com (Anthony Green) Date: Mon, 22 Aug 2005 09:59:15 -0700 Subject: GCC 4.1 for FC5? In-Reply-To: <20050822144636.GU7403@devserv.devel.redhat.com> References: <1124417799.3017.5.camel@localhost.localdomain> <20050822144636.GU7403@devserv.devel.redhat.com> Message-ID: <1124729956.3039.6.camel@localhost.localdomain> On Mon, 2005-08-22 at 10:46 -0400, Jakub Jelinek wrote: > IMHO it is too early for the decision about FC5 base compiler version. > I certainly hope it will be GCC 4.1, but we should have doors open even > for GCC 4.0 if needed. Ok - thanks for the update. gcc41 RPMS would be really useful right now. Then we could create a java-1.4.2-gcj41-compat package and use "alternatives" to select this by default. You wouldn't happen to have something like this handy, would you? AG From dmalcolm at redhat.com Mon Aug 22 18:32:07 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 22 Aug 2005 14:32:07 -0400 Subject: packages not building In-Reply-To: <20050820121921.GA4910@dudweiler.stuttgart.redhat.com> References: <20050820121921.GA4910@dudweiler.stuttgart.redhat.com> Message-ID: <1124735527.9805.5.camel@cassandra.boston.redhat.com> On Sat, 2005-08-20 at 14:19 +0200, Florian La Roche wrote: > A simple rebuild test fails for the following packages in > the Fedora Core development tree: > [snip] > - evolution-webcal What's the problem you're seeing? It builds OK for me. [snip] From steve at rueb.com Mon Aug 22 18:59:32 2005 From: steve at rueb.com (Steve Bergman) Date: Mon, 22 Aug 2005 13:59:32 -0500 Subject: KDE RedHat project In-Reply-To: <20050821215511.GA21170@devserv.devel.redhat.com> References: <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> Message-ID: <430A2094.4050608@rueb.com> Alan Cox wrote: >On Sun, Aug 21, 2005 at 02:07:54PM -0500, Steve Bergman wrote: > > >Americans have strange ideas about their laws and the extent they cover. >Sometimes to good effect (eg corruption laws) sometimes to bad. For a US >based body to advocate that a non-US citizen exercise their legal rights if >those rights conflict with "US law" is an area that requires careful legal >thought. Remember that US "freedom of speech" is political speech - so the >right to complain about the existing US policies and fight them is protected >not the right to tell people how to violate them. > > No argument from me. So could DRM actually help us, here? Could RedHat/Fedora offer country specific versions with some sort of regional DRM in place, so that the rest of the world doesn't have to suffer from shortcomings here in the USA? Of course, with the source being available people could subvert it, but surely, at some point, RedHat should be considered "not responsible". After all, OSS code distributed by RedHat currently could no doubt be modified to do illegal things. On the other hand, there is at least one wireless driver that Andrew can't include in the vanilla kernel because the souce could be modified by the user to violate FCC regulations. BTW, nobody has called me on it, but my original post, upon re-reading, seems more critical of RedHat than was intended. Retroactive appologies for that. -Steve From fedora at wir-sind-cool.org Mon Aug 22 19:06:17 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 22 Aug 2005 21:06:17 +0200 Subject: KDE RedHat project In-Reply-To: <604aa79105082209432b7931d0@mail.gmail.com> References: <430255B8.5070600@develer.com> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <52688.10.10.10.28.1124728594.squirrel@linux1> <604aa79105082209432b7931d0@mail.gmail.com> Message-ID: <20050822210617.4675faa1.fedora@wir-sind-cool.org> On Mon, 22 Aug 2005 12:43:26 -0400, Jeff Spaleta wrote: > > It would be good to make it easier to install yum repo entries; for > > instance by just clicking on a web page link. The actual links wouldn't > > have to be provided or even referenced by Fedora. > > Create the more general mechanism for installing an rpm via a link, > securely.. With emphasis on "_securely_". Just like you don't want to click a link and see an .exe file execute and start downloading and installing something, you don't want automated installation of Yum repositories. _Any_ repository out there could add itself to your configuration with a single click and provide packages which replace Core files. Adding real security in this area requires much more than asking the user for confirmation. For now, adding Yum repo entries with something like "rpm -ivh http://.../foo-release-4-1.noarch.rpm" and letting Yum install the included GPG key should be easy enough even if it implies that some users probably trust some repositories blindly, because those users focus on simplicity instead of security. From jspaleta at gmail.com Mon Aug 22 19:26:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 22 Aug 2005 15:26:08 -0400 Subject: KDE RedHat project In-Reply-To: <20050822210617.4675faa1.fedora@wir-sind-cool.org> References: <430255B8.5070600@develer.com> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <52688.10.10.10.28.1124728594.squirrel@linux1> <604aa79105082209432b7931d0@mail.gmail.com> <20050822210617.4675faa1.fedora@wir-sind-cool.org> Message-ID: <604aa791050822122679f577fc@mail.gmail.com> On 8/22/05, Michael Schwendt wrote: > With emphasis on "_securely_". Yeah.. maybe i didn't stress that enough. The trick is definitely "securely." I don't think I've yet seen any proposals that make clicking on a link to install anything palatable in this regard. -jef From andy at warmcat.com Mon Aug 22 19:36:45 2005 From: andy at warmcat.com (Andy Green) Date: Mon, 22 Aug 2005 20:36:45 +0100 Subject: Make a periphery around the Core In-Reply-To: <4308D10A.7090903@rueb.com> References: <430255B8.5070600@develer.com> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> Message-ID: <200508222036.49051.andy@warmcat.com> On Sunday 21 August 2005 20:07, Steve Bergman wrote: > What I keep hearing in this thread is that RedHat's position as the > "managing entity" of Fedora is holding Fedora back in the area of > multimedia. Redhat being well-funded brings into being the potential for attacks that would otherwise make no sense if it were someone else distributing Fedora. So it seems to me reasonable they keep completely away from anything inviting attack. If Redhat want commercial 'should-really-be-licensed' stuff for Enterprise they license it and it is distributed and paid-for accordingly. So there is no real driver on Redhat to fix this for Fedora from the commercial side. Not moaning about it, just noting it. But of course the development and strong security update work make Fedora attractive to rely on. It always seemed to me that the "Core" part of the name invited the distribution to be built on externally, completely away from Redhat, not in competition but in using Fedora as the 'upstream'. And what do I read about on LWN.... http://www.blagblagblag.org/ ''blag is a fedora core 3 based distribution, reduced to 1 cdrom and supplemented by 200 additional packages.'' The 200 additional packages include mplayer and all the other goodies that become explosive when mixed directly with Redhat's funding. (I have no experience or relationship with blag). So it seems to me the answer to this should be that Redhat go on as they need to and the demand for the other stuff supports one or more wrapped Fedoras that have it, completely outside Redhat and with no support from them other than the general provisioning of Fedora Core. -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seanlkml at sympatico.ca Mon Aug 22 20:00:37 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 22 Aug 2005 16:00:37 -0400 (EDT) Subject: KDE RedHat project In-Reply-To: <20050822210617.4675faa1.fedora@wir-sind-cool.org> References: <430255B8.5070600@develer.com> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <52688.10.10.10.28.1124728594.squirrel@linux1> <604aa79105082209432b7931d0@mail.gmail.com> <20050822210617.4675faa1.fedora@wir-sind-cool.org> Message-ID: <38618.10.10.10.28.1124740837.squirrel@linux1> On Mon, August 22, 2005 3:06 pm, Michael Schwendt said: > With emphasis on "_securely_". > > Just like you don't want to click a link and see an .exe file execute and > start downloading and installing something, you don't want automated > installation of Yum repositories. _Any_ repository out there could add > itself to your configuration with a single click and provide packages > which replace Core files. Adding real security in this area requires much > more than asking the user for confirmation. For now, adding Yum repo > entries with something like "rpm -ivh > http://.../foo-release-4-1.noarch.rpm" > and letting Yum install the included GPG key should be easy enough even if > it implies that some users probably trust some repositories blindly, > because those users focus on simplicity instead of security. Would be nice to avoid the need for the command line. Wouldn't a simple popup having a boilerplate warning and the description extracted from the rpm be sufficient? If not, what else is needed? Remember this is about generic rpm installation of any program, not just rpms containing repo entries. I suppose there should be a more verbose warning message if the rpm isn't signed with a trusted key but beyond that how much more "secure" can you make it? Sean From vonbrand at inf.utfsm.cl Mon Aug 22 20:12:21 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 22 Aug 2005 16:12:21 -0400 Subject: Make a periphery around the Core In-Reply-To: Your message of "Mon, 22 Aug 2005 20:36:45 +0100." <200508222036.49051.andy@warmcat.com> Message-ID: <200508222012.j7MKCLCa006110@laptop11.inf.utfsm.cl> Andy Green wrote: > On Sunday 21 August 2005 20:07, Steve Bergman wrote: > > What I keep hearing in this thread is that RedHat's position as the > > "managing entity" of Fedora is holding Fedora back in the area of > > multimedia. > Redhat being well-funded brings into being the potential for attacks that > would otherwise make no sense if it were someone else distributing > Fedora. So it seems to me reasonable they keep completely away from > anything inviting attack. I'd want to think they keep away from propietary formats (and software with murky legal status) as a matter of principle, not because they might get sued otherwise... -- 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 fedora at wir-sind-cool.org Mon Aug 22 20:39:09 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 22 Aug 2005 22:39:09 +0200 Subject: KDE RedHat project In-Reply-To: <38618.10.10.10.28.1124740837.squirrel@linux1> References: <430255B8.5070600@develer.com> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <52688.10.10.10.28.1124728594.squirrel@linux1> <604aa79105082209432b7931d0@mail.gmail.com> <20050822210617.4675faa1.fedora@wir-sind-cool.org> <38618.10.10.10.28.1124740837.squirrel@linux1> Message-ID: <20050822223909.5c94f636.fedora@wir-sind-cool.org> On Mon, 22 Aug 2005 16:00:37 -0400 (EDT), Sean wrote: > Would be nice to avoid the need for the command line. Wouldn't a simple > popup having a boilerplate warning and the description extracted from the > rpm be sufficient? If not, what else is needed? At least one hurdle that makes it less easy. ;) The simple click-click-click-to-add-a-repository bears just too many risks, because its target group would _not_ verify painstakingly what will be added to the system configuration. > Remember this is about > generic rpm installation of any program, not just rpms containing repo > entries. Clicking onto a local *.rpm file opens the system-install-packages command by default, which in turn prompts the user for the root password. That is easy and dangerous enough. As soon as system-install-packages can access the configured online repositories in order to resolve dependencies, what else do you need? > I suppose there should be a more verbose warning message if the > rpm isn't signed with a trusted key but beyond that how much more "secure" > can you make it? Theoretically, _much_ more secure, e.g. with fully relocatable packages and a user-writable RPM database, so the user can install _some_ packages without needing superuser privileges. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.12-1.1398_FC4 loadavg: 1.02 1.14 0.92 From rodd at clarkson.id.au Mon Aug 22 21:18:59 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 23 Aug 2005 07:18:59 +1000 Subject: OGG support [was Re: KDE RedHat project] In-Reply-To: <4309DEF1.50904@redhat.com> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <4309D9CF.60408@cornell.edu> <4309DEF1.50904@redhat.com> Message-ID: <1124745539.2890.17.camel@localhost.localdomain> On Mon, 2005-08-22 at 19:49 +0530, Rahul Sundaram wrote: > Hi > > > > > I'd argue, however, that "positive propaganda" is the right > > strategy here too: if RH (and much of the OS community) takes the > > principled stand of providing a free media stack, it ought to put a > > little bit of energy into promoting free media formats -- for > > instance, it would be nice to see a web site promoting the Ogg Vorbis > > streams that are out there, just as there are sites promoting the SBR > > heresy... > > > > http://www.tuner2.com/ > > > That does seem like a good idea to me. If you got other areas that we > can improve the the promotion of free media formats, do post to the > fedora-marketing list. I'll tell you what else would be very useful here. A site with simple, easy to follow instructions on how to get OGG formats playing on other platforms, and preferably in these platforms default players. One of the biggest sticking points I've had with getting people to even try OGG formats is getting their platform (usually OS X) to be able to support this format. Having a place where people could be pointed to that tells/shows them what to do and also has the links to the software that need (hopefully in small, easy to download bits) would make it a lot easier to get people to try (and use) vorbis. As and example, I've tried to get my government in Australia to use OGG formats for parliamentary needs, but the sysadmin just tells me it's too hard to install on some platforms and that they will stick with proprietary formats (and no government should use these for information distribution) because people just have these installed on their systems. (Strangely, comments from me that the formats they support aren't even supported by the manufacturers on my system seem to fall on deaf ears). Being able to say to these people, go to this page and follow the simple instructions and you'll be able to use OGG formats would make selling the idea of OGG much, much easier. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From tromey at redhat.com Mon Aug 22 21:23:09 2005 From: tromey at redhat.com (Tom Tromey) Date: 22 Aug 2005 15:23:09 -0600 Subject: GCC 4.1 for FC5? In-Reply-To: <20050822144636.GU7403@devserv.devel.redhat.com> References: <1124417799.3017.5.camel@localhost.localdomain> <20050822144636.GU7403@devserv.devel.redhat.com> Message-ID: >>>>> "Jakub" == Jakub Jelinek writes: Jakub> IMHO it is too early for the decision about FC5 base compiler version. Jakub> I certainly hope it will be GCC 4.1, but we should have doors open even Jakub> for GCC 4.0 if needed. If it is GCC 4.0 then I think we will want to do a backport of all the changes in gcj and libgcj. So, the sooner we know, the better. And, it would be preferable not to have to do this. Tom From steve at rueb.com Mon Aug 22 21:56:05 2005 From: steve at rueb.com (Steve Bergman) Date: Mon, 22 Aug 2005 16:56:05 -0500 Subject: OGG support [was Re: KDE RedHat project] In-Reply-To: <1124745539.2890.17.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <4309D9CF.60408@cornell.edu> <4309DEF1.50904@redhat.com> <1124745539.2890.17.camel@localhost.localdomain> Message-ID: <430A49F5.2060104@rueb.com> Rodd Clarkson wrote: >On Mon, 2005-08-22 at 19:49 +0530, Rahul Sundaram wrote: > > >>Hi >> >> >> >>> I'd argue, however, that "positive propaganda" is the right >>>strategy here too: if RH (and much of the OS community) takes the >>>principled stand of providing a free media stack, it ought to put a >>>little bit of energy into promoting free media formats -- for >>>instance, it would be nice to see a web site promoting the Ogg Vorbis >>>streams that are out there, just as there are sites promoting the SBR >>>heresy... >>> >>>http://www.tuner2.com/ >>> >>> >>> >>That does seem like a good idea to me. If you got other areas that we >>can improve the the promotion of free media formats, do post to the >>fedora-marketing list. >> >> > >I'll tell you what else would be very useful here. > >A site with simple, easy to follow instructions on how to get OGG >formats playing on other platforms, and preferably in these platforms >default players. > > > And simple has to mean trivially simple. Click here, click there (with demo screenshots). No more than five clicks or so. Any more would scare off the target audience, which I will operationally define as the average CompUSA/Best Buy customer (or employee for that matter). This would leave the majority, if successful, with a feeling of accomplishment, and a working ogg player. Anything more difficult would only allow a greater portion of already savvy users of Windows and Mac platforms to make the jump, only to find that "no one provides content in ogg formats". Another text oriented FAQ would only clog things up more than they already are. The users, assuming they were even interested in ogg, have to find the site first. Ideally, it would be linked from the front page of microsoft.com, yahoo.com, google.com, or msn.com. (Excuse me, but I just got an email that says I might have won a million dollars and I need to go read it. It could be important! Gotta go! ;-) -Steve From mwiktowy at gmx.net Mon Aug 22 21:59:41 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Mon, 22 Aug 2005 17:59:41 -0400 Subject: OGG support [was Re: KDE RedHat project] In-Reply-To: <1124745539.2890.17.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <4309D9CF.60408@cornell.edu> <4309DEF1.50904@redhat.com> <1124745539.2890.17.camel@localhost.localdomain> Message-ID: <430A4ACD.9010500@gmx.net> Rodd Clarkson wrote: >Being able to say to these people, go to this page and follow the simple >instructions and you'll be able to use OGG formats would make selling >the idea of OGG much, much easier. > > >Rodd > > I assume here that we are just talking about ogg audio formats here ... This page would be a start: http://www.vorbis.com/software.psp On there is a plethora of ogg compatible software for many platforms. In my experience on Win32, WinAmp plays ogg just fine natively. It has done so for *years*. The only problem is Windows Media Player chokes on ogg. WMP is awful ... unfortunately it is the default player :[ There is a DirectShow plugin that should allow WMP to do ogg but I haven't had much luck with it ... then again, I haven't had much luck with WMP playing much. There also seems to be a Quicktime plugin to do ogg on Win32 and OS X ... that might solve things for our Apple and Windows friends all in one swell foop. /Mike From koneko.em at gmail.com Mon Aug 22 22:59:46 2005 From: koneko.em at gmail.com (Emily Brantley) Date: Mon, 22 Aug 2005 18:59:46 -0400 Subject: OGG support [was Re: KDE RedHat project] In-Reply-To: <1124745539.2890.17.camel@localhost.localdomain> References: <430255B8.5070600@develer.com> <4303700F.4090109@redhat.com> <43039A97.7060204@math.unl.edu> <1124356546.2864.6.camel@localhost.localdomain> <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <4309D9CF.60408@cornell.edu> <4309DEF1.50904@redhat.com> <1124745539.2890.17.camel@localhost.localdomain> Message-ID: <430A58E2.6010709@gmail.com> Rodd Clarkson wrote: > On Mon, 2005-08-22 at 19:49 +0530, Rahul Sundaram wrote: > >>Hi >> >> >>> I'd argue, however, that "positive propaganda" is the right >>>strategy here too: if RH (and much of the OS community) takes the >>>principled stand of providing a free media stack, it ought to put a >>>little bit of energy into promoting free media formats -- for >>>instance, it would be nice to see a web site promoting the Ogg Vorbis >>>streams that are out there, just as there are sites promoting the SBR >>>heresy... >>> >>>http://www.tuner2.com/ >>> >> >>That does seem like a good idea to me. If you got other areas that we >>can improve the the promotion of free media formats, do post to the >>fedora-marketing list. > > > I'll tell you what else would be very useful here. > > A site with simple, easy to follow instructions on how to get OGG > formats playing on other platforms, and preferably in these platforms > default players. > > One of the biggest sticking points I've had with getting people to even > try OGG formats is getting their platform (usually OS X) to be able to > support this format. > > Having a place where people could be pointed to that tells/shows them > what to do and also has the links to the software that need (hopefully > in small, easy to download bits) would make it a lot easier to get > people to try (and use) vorbis. > > As and example, I've tried to get my government in Australia to use OGG > formats for parliamentary needs, but the sysadmin just tells me it's too > hard to install on some platforms and that they will stick with > proprietary formats (and no government should use these for information > distribution) because people just have these installed on their systems. > (Strangely, comments from me that the formats they support aren't even > supported by the manufacturers on my system seem to fall on deaf ears). > > Being able to say to these people, go to this page and follow the simple > instructions and you'll be able to use OGG formats would make selling > the idea of OGG much, much easier. > > > Rodd when somebody isn't able to play a video or audio i've ripped in ogg, i usually point people to this article: http://en.wikipedia.org/wiki/Wikipedia:Media_help it could probably use some improvement (like screenshots and detailed guides). em. -------------- next part -------------- A non-text attachment was scrubbed... Name: koneko.em.vcf Type: text/x-vcard Size: 214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sudoyang at gmail.com Tue Aug 23 01:20:20 2005 From: sudoyang at gmail.com (Fong Vang) Date: Mon, 22 Aug 2005 18:20:20 -0700 Subject: Kickstart BOOT kernel Message-ID: <4f52331f05082218209e23b81@mail.gmail.com> Could someone tell me how the kernel used for kickstart (called the BOOT kernel in RH 9 days) is created? How does one generate this kernel using rpmbuild of the src rpm? I'm just trying to undertstand the differences. Thanks for any help. From arjanv at redhat.com Tue Aug 23 07:12:50 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 23 Aug 2005 09:12:50 +0200 Subject: Kickstart BOOT kernel In-Reply-To: <4f52331f05082218209e23b81@mail.gmail.com> References: <4f52331f05082218209e23b81@mail.gmail.com> Message-ID: <1124781170.3218.6.camel@laptopd505.fenrus.org> On Mon, 2005-08-22 at 18:20 -0700, Fong Vang wrote: > Could someone tell me how the kernel used for kickstart (called the > BOOT kernel in RH 9 days) is created? How does one generate this > kernel using rpmbuild of the src rpm? it's not longer a special kernel, but just the UP kernel -------------- 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 Tue Aug 23 10:39:43 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 23 Aug 2005 06:39:43 -0400 Subject: KDE RedHat project In-Reply-To: <430A2094.4050608@rueb.com> References: <20050818121512.72675a27.fedora@wir-sind-cool.org> <1124361100.2864.22.camel@localhost.localdomain> <1124361779.3401.7.camel@localhost.localdomain> <1124362870.5751.15.camel@thl.ct.heise.de> <43046B96.3030803@redhat.com> <1124364445.5751.29.camel@thl.ct.heise.de> <604aa79105081805291b3e5a01@mail.gmail.com> <4308D10A.7090903@rueb.com> <20050821215511.GA21170@devserv.devel.redhat.com> <430A2094.4050608@rueb.com> Message-ID: <20050823103943.GE25934@devserv.devel.redhat.com> On Mon, Aug 22, 2005 at 01:59:32PM -0500, Steve Bergman wrote: > should be considered "not responsible". After all, OSS code distributed > by RedHat currently could no doubt be modified to do illegal things. On It undoubtedly is by some people just like any other tool. As to DRM question I don't know. From a philosophical point of view its taking away freedoms, but it also has the advantage of making people walk into legal walls they otherwise can't see and thus more aware of the restrictions on them. Right now Fedora is one size fits most jurisdictions. It isn't just US laws that have to be considered. Germany for example has strong rules on 'games that glorify war' (ie violent games). That is one reason bzflag was pushed out to extras. The challenge is to find the right balance between respecting values and rules globally (so people can use Fedora freely all over the world) and not turning into Farenheit 451. > the other hand, there is at least one wireless driver that Andrew can't > include in the vanilla kernel because the souce could be modified by the > user to violate FCC regulations. Its not included (atheros) because the radio end is binary only. Nothing to my understanding stops it being included if open, but the FCC requires the original hardware vendor makes such devices tamperproof and the vendor interpreted this as "not open source". I believe the BSD folks are very close to shipping a reliable reverse engineered pure open source atheros driver. There are a variety of solutions to the problem even for chip vendors (one is providing wireless settings that are signed so the chip only takes vendor provided sets. Alan From pp at ee.oulu.fi Tue Aug 23 13:38:31 2005 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 23 Aug 2005 16:38:31 +0300 Subject: Installing FC4 on a box when FC4 install kernel breaks HOWTO Message-ID: <20050823133831.GA1195@ee.oulu.fi> Since I'm sure there's other people around with fun hardware that just won't work with the FC4 install kernel (Some of our IBM blades, Sun v40z), I'm sure people would appreciate a "I just want to get it running and not mess with rebuilding the entire damn distro with anaconda-runtime, which isn't that well documented anyway" HOWTO :-). Written from a PXE/kickstart point of view, if you want to do CD installs on affected boxes, doing the full anaconda-runtime mess is probably easier. I just wanted something with minimum possible changes to the install tree and have unaffected boxes use the vanilla install images. # Grab buildstamp from FC4 initrd cd /tmp mkdir initrd-fc4 cd initrd-fc4/ umask 022 zcat /tmp/fc4-initrd.img | cpio -i cd .. # Include it into rawhide initrd. Make initrd look for stage3.img instead so the original can be kept for unaffected boxes mkdir initrd-fc4-dev cd initrd-fc4-dev zcat /tmp/rawhide-initrd.img | cpio -i cp .buildstamp .buildstamp.orig cp ../initrd-fc4/.buildstamp . find . | cpio -c -o | sed 's/stage2.img/stage3.img/;s/hdstg2.img/hdstg3.img/;s/netstg2.img/netstg3.img/' | gzip -9 > fc4-rawhide-initrd cd .. # Add modules from rawhide kernel to stage2 mount -o loop stage2-fc4.img /mnt mount -o loop stage2-from-development.img /mnt2 mkdir /tmp/stage2 (cd /mnt; tar cvf - .) | (cd /tmp/stage2; tar xf -) cd /tmp/stage2/modules cp /mnt2/modules/* . cd /tmp mkcramfs stage2 stage3.img (repeat for hdstg2 and netstg2 if required and rinse) PXE boot rawhide kernel & modified initrd for affected boxes and Enjoy (tm) :-). Obviously you'll want an updated kernel getting installed in your kickstart, or the box might not boot afterwards. Would be nice if this was somewhat easier and/or someone actually made (semi-)official updated installer images available ;) From russell at coker.com.au Tue Aug 23 13:49:44 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 23 Aug 2005 23:49:44 +1000 Subject: mv and posix ACLs Message-ID: <200508232349.48082.russell@coker.com.au> getxattr("/mnt/nfs/test", "system.posix_acl_access", 0xbfc96c20, 132) = -1 EOPNOTSUPP (Operation not supported) setxattr("./test", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not supported) Stracing an mv operation shows that the above is performed. Reading coreutils-acl.patch from the coreutils SRPM indicates that the code in acl.c is creating a posix ACL that matches the Unix permissions and trying to apply it. Why does it do this? What is the point of having a POSIX ACL containing the same data as the Unix permissions, it seems that when POSIX ACLs are enabled in the destination file-system it will just waste disk space and CPU time by needlessly duplicating data, and when POSIX ACLs are disabled (the default configuration) it will just waste a small amount of CPU time on the mv operation in trying to set something that can never be set. This seems like a bug to me, but someone has obviously gone to quite a bit of effort to make it do that so there is presumably some reason. What is the reason for desiring this functionality and does it really outweigh the problems? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From seandarcy2 at gmail.com Tue Aug 23 14:44:07 2005 From: seandarcy2 at gmail.com (sean) Date: Tue, 23 Aug 2005 10:44:07 -0400 Subject: why does yum want to upgrade koffice? Message-ID: [root at amd64-3000 development]# rpm -qa | grep koffice koffice-filters-1.4.1-4 koffice-devel-1.4.1-4 koffice-core-1.4.1-4 koffice-kword-1.4.1-4 yum upgrade .......... Added 15 new packages, deleted 0 old in 1.83 seconds Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package koffice-kword.x86_64 0:1.4.1-4.fc4 set to be updated ---> Package koffice-core.x86_64 0:1.4.1-4.fc4 set to be updated ---> Package koffice-filters.x86_64 0:1.4.1-4.fc4 set to be updated ---> Package koffice-devel.x86_64 0:1.4.1-4.fc4 set to be updated --> Running transaction check --> Processing Dependency: libgs.so.7()(64bit) for package: koffice-filters --> Finished Dependency Resolution Error: Missing Dependency: libgs.so.7()(64bit) is needed by package koffice-filters koffice needs to be rebuilt with libgs.so.8. Which I've done. Why does yum keep wanting to upgrade to the extras koffice? One issue: the installed koffice where built --target=i486 ( don't ask). rpm -q koffice-core.i486 koffice-core-1.4.1-4 But, why would yum try to install an x86_64 set? Will it always try to install the preferred target if another target is installed? sean From skvidal at phy.duke.edu Tue Aug 23 14:58:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 23 Aug 2005 10:58:44 -0400 Subject: why does yum want to upgrade koffice? In-Reply-To: References: Message-ID: <1124809124.25024.10.camel@cutter> On Tue, 2005-08-23 at 10:44 -0400, sean wrote: > [root at amd64-3000 development]# rpm -qa | grep koffice > koffice-filters-1.4.1-4 > koffice-devel-1.4.1-4 > koffice-core-1.4.1-4 > koffice-kword-1.4.1-4 > > yum upgrade > .......... > Added 15 new packages, deleted 0 old in 1.83 seconds > Resolving Dependencies > --> Populating transaction set with selected packages. > Please wait. > ---> Package koffice-kword.x86_64 0:1.4.1-4.fc4 set to be > updated > ---> Package koffice-core.x86_64 0:1.4.1-4.fc4 set to be updated > ---> Package koffice-filters.x86_64 0:1.4.1-4.fc4 set to be > updated > ---> Package koffice-devel.x86_64 0:1.4.1-4.fc4 set to be > updated > --> Running transaction check > --> Processing Dependency: libgs.so.7()(64bit) for package: > koffice-filters > --> Finished Dependency Resolution > Error: Missing Dependency: libgs.so.7()(64bit) is needed by > package koffice-filters > > > koffice needs to be rebuilt with libgs.so.8. Which I've > done. Why does yum keep wanting to upgrade to the extras > koffice? > > One issue: the installed koffice where built --target=i486 > ( don't ask). > > rpm -q koffice-core.i486 > koffice-core-1.4.1-4 > > But, why would yum try to install an x86_64 set? Will it > always try to install the preferred target if another target > is installed? b/c the i486 koffice-core doesn't provide a 64bit libgs -sv From sds at tycho.nsa.gov Tue Aug 23 16:04:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 23 Aug 2005 12:04:47 -0400 Subject: mv and posix ACLs In-Reply-To: <200508232349.48082.russell@coker.com.au> References: <200508232349.48082.russell@coker.com.au> Message-ID: <1124813087.7874.93.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-08-23 at 23:49 +1000, Russell Coker wrote: > getxattr("/mnt/nfs/test", "system.posix_acl_access", 0xbfc96c20, 132) = -1 > EOPNOTSUPP (Operation not supported) > setxattr("./test", "system.posix_acl_access", > "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff > \x00\x04\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not > supported) > > Stracing an mv operation shows that the above is performed. Reading > coreutils-acl.patch from the coreutils SRPM indicates that the code in acl.c > is creating a posix ACL that matches the Unix permissions and trying to apply > it. > > Why does it do this? What is the point of having a POSIX ACL containing the > same data as the Unix permissions, it seems that when POSIX ACLs are enabled > in the destination file-system it will just waste disk space and CPU time by > needlessly duplicating data, and when POSIX ACLs are disabled (the default > configuration) it will just waste a small amount of CPU time on the mv > operation in trying to set something that can never be set. > > This seems like a bug to me, but someone has obviously gone to quite a bit of > effort to make it do that so there is presumably some reason. What is the > reason for desiring this functionality and does it really outweigh the > problems? You might want to ask on the acl-devel list to be certain, but consider: - In the absence of an explicit setting of the ACL on an ACL-enabled filesystem, can the new file end up with an ACL based on the parent directory's default ACL that yields a different protection than the original file, as ACLs take precedence over file modes when present? - It appears that the kernel performs a check when setting an ACL to see whether it can be directly represented via a file mode, and if so, stores it as a mode instead of an explicit ACL. This avoids the issue of wasting space at least. -- Stephen Smalley National Security Agency From fedora at camperquake.de Tue Aug 23 17:05:52 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 23 Aug 2005 19:05:52 +0200 Subject: Oddness in gnome-url handler - which package? Message-ID: <20050823170552.GD13332@ryoko.camperquake.de> Hi. I am experiencing some oddness with the gnome-url handler, and I am wondering which package I am to file a bug against. From buildsys at redhat.com Tue Aug 23 17:09:27 2005 From: buildsys at redhat.com (Build System) Date: Tue, 23 Aug 2005 13:09:27 -0400 Subject: rawhide report: 20050823 changes Message-ID: <200508231709.j7NH9RrB001701@porkchop.devel.redhat.com> Updated Packages: audit-1.0.3-1 ------------- * Mon Aug 22 2005 Steve Grubb 1.0.3-1 - adjust file perms of newly created log file in auditd - fix 2 memory leaks and an out of bounds access in auditd - fix case where auditd was closing netlink descriptor too early - fix watch rules not to take field arguments in auditctl - fix bug where inode, devmajor, devminor, exit, and success fields in auditctl rules were not getting the correct value stored bind-24:9.3.1-11 ---------------- * Mon Aug 22 2005 Jason Vas Dias - 24:9.3.1-11 - fix bug 166227: host: don't do default AAAA and MX lookups with '-t a' option bluez-utils-2.19-2 ------------------ * Mon Aug 22 2005 David Woodhouse 2.19-2 - Fix calls to dbus_message_append_args() boost-1.33.0-2 -------------- * Fri Aug 12 2005 Benjamin Kosnik 1.33.0-1 - Update to boost-1.33.0, update SONAME to 2 due to ABI changes. - Simplified PYTHON_VERSION by Philipp Thomas checkpolicy-1.25.11-2 --------------------- * Mon Aug 22 2005 Dan Walsh 1.25.11-2 - Fix mls crash cryptsetup-luks-1.0.1-2 ----------------------- * Mon Aug 22 2005 Karel Zak 1.0.1-2 - fix cryptsetup help for isLuks action cvs-1.11.19-10 -------------- * Tue Aug 23 2005 Martin Stransky 1.11.19-10 - fix for #166366 - CVS temporary file issue * Thu Jul 21 2005 Martin Stransky 1.11.19-9 - add vim-minimal to Requires (#163030) * Mon Apr 18 2005 Martin Stransky 1.11.19-8 - add security fix CAN-2005-0753 (Derek Price) diskdumputils-1.1.9-2 --------------------- * Mon Aug 22 2005 Akira Imamura 1.1.9-2 Updated source package to diskdumputils-1.1.9.tar.gz: - Boot-time "Device not specified in /etc/sysconfig/diskdump" message should not be displayed when swapsavecore is executed by rc.sysinit. BZ #165843 evolution-webcal-2.3.91-3 ------------------------- * Mon Aug 22 2005 David Malcolm - 2.3.91-3 - rebuild ftp-0.17-27 ----------- * Mon Aug 22 2005 Petr Raszyk - 0.17-26 - overflow using 'hash mode' (printing '#' but not reading data from network - #79367) gdm-1:2.8.0.2-2 --------------- * Sat Aug 20 2005 Ray Strode 1:2.8.0.2-2 - hide throbber * Fri Aug 19 2005 Ray Strode 1:2.8.0.2-1 - update to 2.8.0.2 - disable early login stuff temporarily * Thu Aug 18 2005 Ray Strode 1:2.6.0.8-18 - rebuild glib2-2.8.1-1 ------------- * Tue Aug 23 2005 Matthias Clasen - 2.8.1-1 - New upstream version - Drop patches glibc-2.3.90-9 -------------- * Mon Aug 22 2005 Jakub Jelinek 2.3.90-9 - update from CVS - fix resolving over TCP (#161181, #165802) - on ia64 don't abort on unhandled math function exception codes (#165693) gnome-menus-2.11.92-1 --------------------- * Mon Aug 22 2005 Mark McLoughlin 2.11.92-1 - Update to 2.11.92 gnome-panel-2.11.92-1 --------------------- * Mon Aug 22 2005 Mark McLoughlin 2.11.92-1 - Update to 2.11.92. gnome-themes-2.11.91-2 ---------------------- * Mon Aug 22 2005 Matthias Clasen - 2.11.91-2 - Remove conflicting files initscripts-8.12-1 ------------------ * Mon Aug 22 2005 Bill Nottingham 8.12-1 - ifup-eth: fix interface renaming (#158774) - rc.sysinit: use modprobe, not insmod (#159120, ) - remove workaround for the fonts-not-initialized-on-secondary-consoles problem (fixed in 2.6.12-rc4 and later) - setsysfont: correctly bracket systfontacm (#159706) - rc.sysinit: always use udevsend, even if no modules (#160987) - ifdown-aliases: add 'cd' to the proper dir (#161170) - add diskdump restore support (), conflict with appropriate diskdumputils - rc.sysinit: dmraid/multipath support - remove LVM1 support - init.d/functions: handle odd quoting in args (#161316, ) - ifup-wireless: set rate in quotes (#163123) - handle lvm & fsck for network block devices (#148764, ) - initlog: fix invalid free calls, (#165033), (#163973,) - sysconfig.txt: remove hdparm docs, since the code isn't there (#162962) - updated translations: ms, ja, ko, et, zh_CN, zh_TW, sr, ar * Tue May 10 2005 Bill Nottingham 8.11-1 - fix mis-bringup of interfaces due to accidentally matched HWADDR (a.k.a. ONBOOT=no not working) (#153669, #157252) - support automatic relabeling later if rebooted w/o SELinux () - rc.sysinit: fix fixfiles invocation (#157182) - btmp should be 0600 (#156900) - translation updates: fr, bg, ru, mk, pa, es * Fri Apr 29 2005 Bill Nottingham 8.10-1 - fix hang on stale GDM sockets (#156355) kernel-2.6.12-1.1505_FC5 ------------------------ * Mon Aug 22 2005 Dave Jones - 2.6.13-rc6-git13 kudzu-1.1.121-1 --------------- * Mon Aug 22 2005 Bill Nottingham 1.1.121-1 - make sure kernel version is always initialized (fixes python bindings) make-1:3.80-8 ------------- * Mon Aug 22 2005 Jakub Jelinek 3.80-8 - make sure errno for error reporting is not lost accross _() calls - report EOF on read pipe differently from read returning < 0 reporting policycoreutils-1.25.5-3 ------------------------ * Mon Aug 22 2005 Dan Walsh 1.25.5-3 - Fix fixfiles to call sort -u followed by sort -d. qt-1:3.3.4-22 ------------- * Mon Aug 22 2005 Than Ngo 1:3.3.4-22 - apply upstream patch to fix kmail folder selector #166430 redhat-artwork-0.127-1 ---------------------- * Mon Aug 22 2005 John (J5) Palmieri 0.127-1 - upgrade to 0.127 - Adds new optical disc device icons (Bug #165750) - Adds directories to index.theme for caching (Bug #166272) - Changes busy cursor to point to the left_ptr_watch cursor selinux-policy-strict-1.25.4-5 ------------------------------ * Mon Aug 22 2005 Dan Walsh 1.25.4-5 - Add capifs - Add roundup policy - fix gdm selinux-policy-targeted-1.25.4-5 -------------------------------- * Mon Aug 22 2005 Dan Walsh 1.25.4-5 - Add capifs - Add roundup policy - fix gdm * Wed Aug 17 2005 Dan Walsh 1.25.4-4.1 - Trying out postfix.te slang-1.4.9-18 -------------- * Thu Aug 18 2005 Petr Raszyk - 1.4.9-18 - Patch to resolve the problem with displaying the 'x' character in the latin2 mode (#139127) syslinux-3.09.90-2 ------------------ * Mon Aug 22 2005 Peter Jones - 3.09.90-2 - Update to 3.10-pre19 system-config-netboot-0.1.30-1_FC5 ---------------------------------- * Fri Aug 19 2005 Jason Vas Dias 0.1.30-1 - fix bug 166018 : disklessrc's findhardware was grep-ping for PCI vendor:device IDs in the pcitable; it now uses /lib/modules/$kernel/modules.pcimap instead. * Thu Aug 18 2005 Jason Vas Dias 0.1.28-1 - fix bug 166217 : the fixed-size initrd was not big enough for RHEL-4 smp kernel. updateDiskless now creates the initrd first in a directory; its size is then determined and the initrd.img is created with sufficient size. pxeos.py now determines the uncompressed size and pxeboot.py now writes the correct ramdisk_size to the syslinux.cfg file. * Thu Aug 11 2005 Jason Vas Dias 0.1.26-1 - fix bug 165772 : read-only root filesystem reported as mounted with "rw" option It appears that the initscripts package of RHEL-4 requires a "READONLY=yes" option in /etc/sysconfig/init in the client root for rc.sysinit not to attempt to mount it read-write. - fix bug 165735 : diskless clients cannot cope with no DNS PTR record for their IP address It was possible for multiple clients who were unable to determine their host name to mount the same snapshot directory - this is now impossible; If clients are unable to determine their host name and have empty SNAPSHOT settings, the IP address is used for the snapshot directory. It is also now possible to set the hostname and domainname without DNS by the DHCP server supplying the host-name option. - fix bug 165730: prevent kernel*-2.6.9-12.2.EL getting an Oops when 'host' is run system-config-securitylevel-1.6.3-1 ----------------------------------- * Mon Aug 22 2005 Dan Walsh 1.6.3-1 - Fix location of self.dirty default flag Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 kdeedu - 3.4.2-1.i386 requires libboost_python.so.1 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for x86_64 ---------------------------------------------------------- cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 kdeedu - 3.4.2-1.x86_64 requires libboost_python.so.1()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 Broken deps for s390x ---------------------------------------------------------- kdeedu - 3.4.2-1.s390x requires libboost_python.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 kdeedu - 3.4.2-1.ppc requires libboost_python.so.1 Broken deps for ia64 ---------------------------------------------------------- kdeedu - 3.4.2-1.ia64 requires libboost_python.so.1()(64bit) lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 rgmanager - 1.9.31-3.ia64 requires ccs gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 initscripts - 8.12-1.ia64 requires kernel >= 0:2.6.12 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 Broken deps for ppc64 ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config system-config-mouse - 1.2.11-1.noarch requires pyxf86config firstboot - 1.3.45-1.noarch requires system-config-display kdeedu - 3.4.2-1.ppc64 requires libboost_python.so.1()(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 ppc64-utils - 0.7-9.ppc64 requires yaboot cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390 ---------------------------------------------------------- lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 kdeedu - 3.4.2-1.s390 requires libboost_python.so.1 initscripts - 8.12-1.s390 requires kernel >= 0:2.6.12 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 From rdieter at math.unl.edu Tue Aug 23 18:39:40 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 23 Aug 2005 13:39:40 -0500 Subject: why does yum want to upgrade koffice? In-Reply-To: <1124809124.25024.10.camel@cutter> References: <1124809124.25024.10.camel@cutter> Message-ID: <430B6D6C.2080504@math.unl.edu> seth vidal wrote: > On Tue, 2005-08-23 at 10:44 -0400, sean wrote: >>rpm -q koffice-core.i486 >>koffice-core-1.4.1-4 >> >>But, why would yum try to install an x86_64 set? Will it >>always try to install the preferred target if another target >>is installed? > > > b/c the i486 koffice-core doesn't provide a 64bit libgs ??? AFAIK, ghostscript provides libgs (or should). -- Rex From skvidal at phy.duke.edu Tue Aug 23 19:02:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 23 Aug 2005 15:02:39 -0400 Subject: why does yum want to upgrade koffice? In-Reply-To: <430B6D6C.2080504@math.unl.edu> References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> Message-ID: <1124823759.25024.37.camel@cutter> On Tue, 2005-08-23 at 13:39 -0500, Rex Dieter wrote: > seth vidal wrote: > > On Tue, 2005-08-23 at 10:44 -0400, sean wrote: > > >>rpm -q koffice-core.i486 > >>koffice-core-1.4.1-4 > >> > >>But, why would yum try to install an x86_64 set? Will it > >>always try to install the preferred target if another target > >>is installed? > > > > > > b/c the i486 koffice-core doesn't provide a 64bit libgs > > ??? AFAIK, ghostscript provides libgs (or should). > the (64bit) is the interesting part there. -sv From seandarcy2 at gmail.com Tue Aug 23 21:18:33 2005 From: seandarcy2 at gmail.com (sean) Date: Tue, 23 Aug 2005 17:18:33 -0400 Subject: why does yum want to upgrade koffice? In-Reply-To: <1124823759.25024.37.camel@cutter> References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> <1124823759.25024.37.camel@cutter> Message-ID: seth vidal wrote: > On Tue, 2005-08-23 at 13:39 -0500, Rex Dieter wrote: > >>seth vidal wrote: >> >>>On Tue, 2005-08-23 at 10:44 -0400, sean wrote: >> >>>>rpm -q koffice-core.i486 >>>>koffice-core-1.4.1-4 >>>> >>>>But, why would yum try to install an x86_64 set? Will it >>>>always try to install the preferred target if another target >>>>is installed? >>> >>> >>>b/c the i486 koffice-core doesn't provide a 64bit libgs >> >>??? AFAIK, ghostscript provides libgs (or should). >> > > > > the (64bit) is the interesting part there. > > -sv > > libgs is supplied by ghostscript. koffice from extras won't install because libgs.so.7 isn't installed. It isn't installed because ghostscript-8.15-0.rc4.3 installs libgs.so.8. locate libgs.so /usr/lib64/libgs.so.8 /usr/lib64/libgs.so /usr/lib64/libgs.so.8.15 That why I rebuilt koffice myself. sean From bojan at rexursive.com Tue Aug 23 23:01:33 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 24 Aug 2005 09:01:33 +1000 Subject: Suspend2 Message-ID: <20050824090133.9csy51j1y8oo4wg4@imp.rexursive.com> Looks like Suspend2 (http://www.suspend2.net/) is headed for the mm and then mainline kernel (finally!). It's been working rather good for a while now and it would be great if FC5 kernels had it once the release hits the mirrors. I'm guessing most notebook (even desktop) users would welcome it. There are already excellent examples of those patches inside FC3/FC4/FC5 kernels as well as related stuff like mkinitrd, sysinit etc. here: http://mhensler.de/swsusp/ Would Fedora kernel maintainers be willing to roll Suspend2 into the development kernels? -- Bojan From sundaram at redhat.com Tue Aug 23 23:06:20 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 24 Aug 2005 04:36:20 +0530 Subject: Suspend2 In-Reply-To: <20050824090133.9csy51j1y8oo4wg4@imp.rexursive.com> References: <20050824090133.9csy51j1y8oo4wg4@imp.rexursive.com> Message-ID: <430BABEC.6040201@redhat.com> Bojan Smojver wrote: >Looks like Suspend2 (http://www.suspend2.net/) is headed for the mm and >then mainline kernel (finally!). It's been working rather good for a >while now and it would be great if FC5 kernels had it once the release >hits the mirrors. I'm guessing most notebook (even desktop) users would >welcome it. > >There are already excellent examples of those patches inside FC3/FC4/FC5 >kernels as well as related stuff like mkinitrd, sysinit etc. here: > >http://mhensler.de/swsusp/ > >Would Fedora kernel maintainers be willing to roll Suspend2 into the >development kernels? > > > I am pretty sure when it hits mainline kernel, it will be included in the development tree. If there are additional enhancements that can done in user space or in integration efforts, feel free to file them as enhancements when it reaches rawhide regards Rahul From bojan at rexursive.com Tue Aug 23 23:32:27 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 24 Aug 2005 09:32:27 +1000 Subject: Suspend2 In-Reply-To: <430BABEC.6040201@redhat.com> References: <20050824090133.9csy51j1y8oo4wg4@imp.rexursive.com> <430BABEC.6040201@redhat.com> Message-ID: <20050824093227.yv0q8oytc0kskcsw@imp.rexursive.com> Quoting Rahul Sundaram : > I am pretty sure when it hits mainline kernel, it will be included in > the development tree. I'm sure that'll be the case. However, I wanted to do a bit of preemptive testing and bug fixing here, given the popularity of FC. I'm guessing this functionality is compiled out in current FC kernels due to bugs in mainline suspend code, so suspend2 could fill that hole. I hope I'm not the only person running FC on a notebook... If you guys get this code into FC development kernels, more people will test it, more bugs will be reported and everyone will end up happier (I'm an eternal optimist, what can I do :-). Of course, if it turns out that this thing is still more trouble than it's worth before the release of FC5, it can simply be dropped. Is my convincing working or should I go and cry in the corner for a while? ;-) > If there are additional enhancements that can done in user space or > in integration efforts, feel free to file them as enhancements when > it reaches rawhide OK. -- Bojan From sundaram at redhat.com Tue Aug 23 23:43:01 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 24 Aug 2005 05:13:01 +0530 Subject: Suspend2 In-Reply-To: <20050824093227.yv0q8oytc0kskcsw@imp.rexursive.com> References: <20050824090133.9csy51j1y8oo4wg4@imp.rexursive.com> <430BABEC.6040201@redhat.com> <20050824093227.yv0q8oytc0kskcsw@imp.rexursive.com> Message-ID: <430BB485.20505@redhat.com> Bojan Smojver wrote: > Quoting Rahul Sundaram : > >> I am pretty sure when it hits mainline kernel, it will be included in >> the development tree. > > > I'm sure that'll be the case. However, I wanted to do a bit of > preemptive testing and bug fixing here, given the popularity of FC. I'm > guessing this functionality is compiled out in current FC kernels due to > bugs in mainline suspend code, so suspend2 could fill that hole. I hope > I'm not the only person running FC on a notebook... Note that some work has gone into enabling the current mainline suspend code to work properly in the recent rawhide kernels. https://www.redhat.com/archives/fedora-devel-list/2005-August/msg00143.html So you can test it out on your notebook and see if you can be happy with that. The -mm kernel as I am sure you are already aware is a soft development tree for the current 2.6.x kernels. Patches that ends in there has a reasonable oppurtunity of hitting mainline soon but also has a chance of being pulled out if it turns out to be sour . So I would wait till it reaches mainline and then rawhide before jumping up in excitement to test it regards Rahul From dwmw2 at infradead.org Tue Aug 23 23:43:55 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 24 Aug 2005 00:43:55 +0100 Subject: Installing FC4 on a box when FC4 install kernel breaks HOWTO In-Reply-To: <20050823133831.GA1195@ee.oulu.fi> References: <20050823133831.GA1195@ee.oulu.fi> Message-ID: <1124840635.5248.84.camel@baythorne.infradead.org> On Tue, 2005-08-23 at 16:38 +0300, Pekka Pietikainen wrote: > Would be nice if this was somewhat easier and/or someone actually made > (semi-)official updated installer images available ;) That seems more complex than just updating the distro using anaconda-runtime. For building ftp://zeniv.uk.linux.org/pub/people/dwmw2/fc4-pegasos (which ought to be installable on Pegasos II and possibly also 32-bit CHRP) I just made sure the FC4 erratum kernel was fixed, then pulled in _all_ the updates and built a new tree. That saves a few hours of 'yum update' after the installation is complete, too. > -- dwmw2 From bojan at rexursive.com Tue Aug 23 23:59:13 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 24 Aug 2005 09:59:13 +1000 Subject: Suspend2 In-Reply-To: <430BB485.20505@redhat.com> References: <20050824090133.9csy51j1y8oo4wg4@imp.rexursive.com> <430BABEC.6040201@redhat.com> <20050824093227.yv0q8oytc0kskcsw@imp.rexursive.com> <430BB485.20505@redhat.com> Message-ID: <20050824095913.f8k5dcv3gkgw440w@imp.rexursive.com> Quoting Rahul Sundaram : > Note that some work has gone into enabling the current mainline > suspend code to work properly in the recent rawhide kernels. > https://www.redhat.com/archives/fedora-devel-list/2005-August/msg00143.html > So you can test it out on your notebook and see if you can be happy > with that. OK. I tried the original suspend code before and it wasn't very good (slow, panics, disk corruption etc.), but I'll give this one a go. Who knows, maybe it'll be better this time. I read (some of) the thread you pointed to and I see that Dave Jones actually had another (very reasonable) explanation for not using suspend2 in current Rawhide kernels, which has to do with deviation from the vanilla kernels. I understand that, makes perfect sense. Oh well, I guess I'll have to roll my own for a while. Then again, stranger things were known happen, so maybe suspend2 code filters through mm and mainline in FC5 time (ah, that optimist side again :-). -- Bojan From zaitcev at redhat.com Tue Aug 23 23:59:30 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 23 Aug 2005 16:59:30 -0700 Subject: udev and pcmcia Message-ID: <20050823165930.4f17cdab.zaitcev@redhat.com> Hi, Harald: I found that PCMCIA does not work on Rawhide with pcmciautils on my test laptop. The problem is that /sbin/pcmcia-socket-startup is not run. This happens when module yenta-socket is built statically into kernel, which is how stock Fedora kernels are built. If yenta-socket is loaded as a module, /sbin/udevsend gets an event, and udev runs pcmcia-socket-startup because of a rule in /etc/udev/rules.d/pcmcia.rules: SUBSYSTEM="pcmcia_socket" RUN+="/sbin/pcmcia-socket-startup" So, the question is: how do I make udev to run pcmcia-socket-startup on boot if /sys/class/pcmcia_socket/ is not empty? Can I run custom scripts on startup of udev? Or should I run this from /etc/rc.d/init.d/pcmcia? Running this program twice appears to be harmless, so if udev is restarted it should be no problem. -- Pete From tadams-lists at myrealbox.com Wed Aug 24 04:17:35 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 23 Aug 2005 22:17:35 -0600 Subject: Kernel issues Message-ID: <1124857055.11846.0.camel@aurora.localdomain> During the FC4 development cycle I mistakenly asked for 2.6.12 to be included because it "had" the ip_conntrack for ipv6. This was based on something I read. It turns out the person was misquoting. The USAGI project was promising this for a patch for 2.6.12. It was never included at least to my knowledge. My wish list for FC5 includes the following: TARPIT target for IPTABLES (I think it is already included). connlimit (and friends) matching for the kernel, this exists in documentation but has not yet made the mainstream kernel. Help should be given to get it there and it should be included. ip6_conntrack (or whatever it's name is) should be given similar help and should be included. Other than that, most of my wishes are ready being addressed. I do think these are very important for both desktop and server/firewall machines. Thank you, Trever Adams -- "I conceive that a great part of the miseries of mankind are brought upon them by the false estimates they have made of the value of things." -- Benjamin Franklin From mk at crc.dk Wed Aug 24 10:14:57 2005 From: mk at crc.dk (Mogens Kjaer) Date: Wed, 24 Aug 2005 12:14:57 +0200 Subject: Installing FC4 on a box when FC4 install kernel breaks HOWTO In-Reply-To: <1124840635.5248.84.camel@baythorne.infradead.org> References: <20050823133831.GA1195@ee.oulu.fi> <1124840635.5248.84.camel@baythorne.infradead.org> Message-ID: <430C48A1.2070003@crc.dk> David Woodhouse wrote: > On Tue, 2005-08-23 at 16:38 +0300, Pekka Pietikainen wrote: > >>Would be nice if this was somewhat easier and/or someone actually made >>(semi-)official updated installer images available ;) > > > That seems more complex than just updating the distro using > anaconda-runtime. > > For building ftp://zeniv.uk.linux.org/pub/people/dwmw2/fc4-pegasos > (which ought to be installable on Pegasos II and possibly also 32-bit > CHRP) I just made sure the FC4 erratum kernel was fixed, then pulled in > _all_ the updates and built a new tree. That saves a few hours of 'yum > update' after the installation is complete, too. > I've tried rebuilding FC4 with the latest patches. It works reasonable, however, the installer often stops during the partitioning when the new partition table is written to disk. Anyone else seen this problem? Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From tdiehl at rogueind.com Wed Aug 24 10:47:35 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 24 Aug 2005 06:47:35 -0400 (EDT) Subject: samba 3.0.20 rpms Message-ID: Hi all, Can anyone tell me if there are any plans to update the rawhide samba rpms to 3.0.20 anytime soon? Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From symbiont at berlios.de Wed Aug 24 11:15:06 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 24 Aug 2005 19:15:06 +0800 Subject: udev and pcmcia In-Reply-To: <20050823165930.4f17cdab.zaitcev@redhat.com> References: <20050823165930.4f17cdab.zaitcev@redhat.com> Message-ID: <200508241915.07690.symbiont@berlios.de> On Wednesday 24 August 2005 07:59, Pete Zaitcev wrote: > This happens when module yenta-socket is built statically into > kernel, which is how stock Fedora kernels are built. Not here. Unless I'm missing something. [root at kubik log]# lsmod |grep yenta yenta_socket 21449 4 rsrc_nonstatic 12737 1 yenta_socket pcmcia_core 50909 5 orinoco_cs,pcnet_cs,pcmcia,yenta_socket,rsrc_nonstatic [root at kubik log]# uname -r 2.6.12-1.1398_FC4 [root at kubik log]# locate yenta_socket.ko /lib/modules/2.6.12-1.1398_FC4/kernel/drivers/pcmcia/yenta_socket.ko -- -jeff From fenlason at redhat.com Wed Aug 24 14:08:53 2005 From: fenlason at redhat.com (Jay Fenlason) Date: Wed, 24 Aug 2005 10:08:53 -0400 Subject: samba 3.0.20 rpms In-Reply-To: References: Message-ID: <20050824140853.GA27815@redhat.com> On Wed, Aug 24, 2005 at 06:47:35AM -0400, Tom Diehl wrote: > Hi all, > > Can anyone tell me if there are any plans to update the rawhide samba rpms to > 3.0.20 anytime soon? I'm working on it. I made the mistake (:-) of looking at the warnings generated by gcc4 and I'm busy fixing some bugs. -- JF From tdiehl at rogueind.com Wed Aug 24 15:18:45 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 24 Aug 2005 11:18:45 -0400 (EDT) Subject: samba 3.0.20 rpms In-Reply-To: <20050824140853.GA27815@redhat.com> References: <20050824140853.GA27815@redhat.com> Message-ID: On Wed, 24 Aug 2005, Jay Fenlason wrote: > On Wed, Aug 24, 2005 at 06:47:35AM -0400, Tom Diehl wrote: > > Hi all, > > > > Can anyone tell me if there are any plans to update the rawhide samba rpms to > > 3.0.20 anytime soon? > > I'm working on it. I made the mistake (:-) of looking at the warnings > generated by gcc4 and I'm busy fixing some bugs. That is always a good thing. :-) Since you are building it is there any chance of getting "--with-shared-modules=idmap_rid" added to the compile options as requested in http://bugzilla.redhat.com/bugzilla/156810 ?? Thanks for the info. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From buildsys at redhat.com Wed Aug 24 16:30:34 2005 From: buildsys at redhat.com (Build System) Date: Wed, 24 Aug 2005 12:30:34 -0400 Subject: rawhide report: 20050824 changes Message-ID: <200508241630.j7OGUY8G019913@porkchop.devel.redhat.com> Updated Packages: alsa-utils-1.0.9rf-5 -------------------- * Tue Aug 23 2005 Martin Stransky 1.0.9-5 - unmute External Amplifier by default (#166153) boost-1.33.0-3 -------------- * Tue Aug 23 2005 Benjamin Kosnik 1.33.0-3 - Create doc package again. - Parts of the above by Neal Becker . dbus-0.36-1 ----------- * Tue Aug 23 2005 John (J5) Palmieri - 0.36-1 - Upgrade to dbus-0.36 - Split modules that go into lib64/python2.4/site-packages/dbus and those that go into /usr/lib/python2.4/site-packages/dbus (they differ on 64bit) - Renable Qt bindings since packages in core can use them dhcp-11:3.0.3-3 --------------- * Tue Aug 23 2005 Jason Vas Dias - 11:3.0.3-3 - fix bug 160655: strip trailing '\0' bytes from text options before append - fix gcc4 compiler warnings ; now compiles with -Werror - add RPM_OPT_FLAGS to link as suggested in gcc man-page on '-pie' option - change ISC version string to 'V3.0.3-RedHat' at request of ISC * Tue Aug 09 2005 Jeremy Katz - 11:3.0.3-2 - don't explicitly require 2.2 era kernel, it's fairly overkill at this point * Fri Jul 29 2005 Jason Vas Dias 11:3.0.3-1 - Upgrade to upstream version 3.0.3 - Don't apply the 'default boot file server' patch: legacy dhcp behaviour broke RFC 2131, which requires that the siaddr field only be non-zero if the next-server or tftp-server-name options are specified. - Try removing the 1-5 second wait on dhclient startup altogether. - fix bug 163367: supply default configuration file for dhcpd eclipse-cdt-1:3.0.0_fc-1 ------------------------ * Tue Aug 23 2005 Andrew Overholt 3.0.0_fc-1 - Import new upstream version (3.0). epiphany-1.7.5-1 ---------------- * Tue Aug 23 2005 Christopher Aillon - 1.7.5-1 - Update to 1.7.5 evolution-2.3.8-1 ----------------- * Tue Aug 23 2005 David Malcolm - 2.3.8-1 - 2.3.8 - add -Werror-implicit-function-declaration to CFLAGS and a patch to fix the problems arising (patch 110) * Tue Aug 16 2005 David Malcolm - 2.3.7-3 - Introduce macro for gnome-pilot dependency, bumping from 2.0.6 to 2.0.13 - Add obsoletion of libgal2/libgal2-devel (dependency was removed in 2.3.6-1); based on the last EVR of the libgal2 package in CVS, 2:2.5.3-2 * Mon Aug 15 2005 David Malcolm - 2.3.7-2 - rebuild evolution-data-server-1.3.8-3 ----------------------------- * Tue Aug 23 2005 David Malcolm - 1.3.8-3 - Updated patch 102 to fix further implicit function declarations * Tue Aug 23 2005 David Malcolm - 1.3.8-2 - added patch (103) to fix problem with configuration macros in libical's vsnprintf.c * Tue Aug 23 2005 David Malcolm - 1.3.8-1 - 1.3.8 - Add -Werror-implicit-function-declaration to CFLAGS, to avoid 64-bit issues and add patch to fix these where they occur (patch 102) gcc-4.0.1-10 ------------ * Mon Aug 22 2005 Jakub Jelinek 4.0.1-10 - update from CVS - PRs c++/22233, c++/23089, c/18715, c/21562, fortran/23065, java/17845, java/21436, libfortran/15266, libgcj/21074, libgcj/21943, middle-end/20624, rtl-optimization/21254 - fix DW_AT_frame_base attribute computation and handling of locations based on the frame base (Richard Henderson, #165514) - backport HEAD -fstack-protector fixes and documentation additions - fix __builtin_*_chk miscompilation (PR middle-end/23484) gtkhtml3-3.7.7-1 ---------------- * Tue Aug 23 2005 David Malcolm - 3.7.7-1 - 3.7.7 initscripts-8.12-2 ------------------ * Wed Aug 24 2005 Bill Nottingham 8.12-2 - rebuild against fixed kudzu (#166602) libsemanage-1.1.3-1 ------------------- libsepol-1.7.20-1 ----------------- * Tue Aug 23 2005 Dan Walsh 1.7.20-1 - Upgrade to latest from NSA * Merged more fixes for resource leaks on error paths from Serge Hallyn (IBM). Bugs found by Coverity. libsoup-2.2.6.1-1 ----------------- * Tue Aug 23 2005 David Malcolm - 2.2.6.1-1 - 2.2.6.1 man-pages-2.07-2 ---------------- * Tue Aug 23 2005 Ivana Varekova 2.07-2 - add sln.8 man page (bug 10601) * Mon Aug 08 2005 Ivana Varekova 2.07-1 - update to 2.07 * Mon Jul 04 2005 Jiri Ryska 2.05-1 - update to 2.05 - atanh(3) fix - issue(5) fix - ldd(1) fix - removed man1p/{compress,uncompress,renice}.1p mysql-4.1.12-3 -------------- * Tue Aug 23 2005 Tom Lane 4.1.12-3 - Use politically correct patch name. openssl-0.9.7f-9 ---------------- * Tue Aug 23 2005 Tomas Mraz 0.9.7f-9 - add *.so.soversion as symlinks in /lib (#165264) - remove unpackaged symlinks (#159595) - fixes from upstream (constant time fixes for DSA, bn assembler div on ppc arch, initialize memory on realloc) * Thu Aug 11 2005 Phil Knirsch 0.9.7f-8 - Updated ICA engine IBM patch to latest upstream version. * Thu May 19 2005 Tomas Mraz 0.9.7f-7 - fix CAN-2005-0109 - use constant time/memory access mod_exp so bits of private key aren't leaked by cache eviction (#157631) - a few more fixes from upstream 0.9.7g policycoreutils-1.25.6-1 ------------------------ * Tue Aug 23 2005 Dan Walsh 1.25.6-1 - Update to match NSA * Merged fixes for semodule_link and sestatus from Serge Hallyn (IBM). Bugs found by Coverity. pygtk2-2.7.3-3 -------------- * Tue Aug 23 2005 John (J5) Palmieri - 2.7.3-3 - Add a BuildRequires on python-numeric so that Numeric python support is added - Add a Requires on python-numeric as well redhat-artwork-0.128-1 ---------------------- * Tue Aug 23 2005 John (J5) Palmieri 0.128-1 - upgrade to 0.128 - Adds entrys to the index.theme to decribe the newly added directories system-config-securitylevel-1.6.4-1 ----------------------------------- * Tue Aug 23 2005 Chris Lumens 1.6.4-1 - Fix checking for the -f flag in lokkit (markmc, #166568). - Sync up order of enable/disable options between UI and what gets written to the file (#166390). xen-2-20050823.2 ---------------- * Tue Aug 23 2005 Rik van Riel 2-20050823 - upgrade to today's Xen snapshot - disable -fstack-protector for Xen hypervisor * Mon Aug 15 2005 Rik van Riel 2-20050726 - upgrade to a known-working newer Xen, now that execshield works again Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 kdeedu - 3.4.2-1.ppc requires libboost_python.so.1 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ppc64 ---------------------------------------------------------- evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config kdeedu - 3.4.2-1.ppc64 requires libboost_python.so.1()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 firstboot - 1.3.45-1.noarch requires system-config-display dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config Broken deps for ia64 ---------------------------------------------------------- gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 rgmanager - 1.9.31-3.ia64 requires ccs lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 initscripts - 8.12-2.ia64 requires kernel >= 0:2.6.12 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 kdeedu - 3.4.2-1.ia64 requires libboost_python.so.1()(64bit) xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 Broken deps for i386 ---------------------------------------------------------- valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 kdeedu - 3.4.2-1.i386 requires libboost_python.so.1 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for x86_64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 kdeedu - 3.4.2-1.x86_64 requires libboost_python.so.1()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 Broken deps for s390 ---------------------------------------------------------- kdeedu - 3.4.2-1.s390 requires libboost_python.so.1 initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 Broken deps for s390x ---------------------------------------------------------- kdeedu - 3.4.2-1.s390x requires libboost_python.so.1()(64bit) From tfox at redhat.com Wed Aug 24 18:53:33 2005 From: tfox at redhat.com (Tammy Fox) Date: Wed, 24 Aug 2005 14:53:33 -0400 Subject: magazine article on "reading" source code Message-ID: <1124909613.5807.16.camel@localhost.localdomain> Hi, As the editor of Red Hat Magazine, I receive a lot of article suggestions. I ran across one recently that sounded like a good idea. Is anyone interesting in writing an article about "reading" source code as a way to start contributing to open source? i.e. Start with submitting patches, eventually get a few patches accepted, then start writing your own apps based on what you've learned from reading source code. If you are interested, email me directly and we can discuss. Thanks, Tammy Fox Editor, Red Hat Magazine From zaitcev at redhat.com Wed Aug 24 22:35:06 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 24 Aug 2005 15:35:06 -0700 Subject: eepro100 Message-ID: <20050824153506.3c755bfa.zaitcev@redhat.com> Hi, Dave, hi, Jeff: Do you happen to remember why is eepro100 enabled in FC5 kernels? I know that a few PCI IDs are not present in e100, seemingly without any system to it. The eepro100 was unmaintained for years now. Right? -- Pete From davej at redhat.com Wed Aug 24 23:59:01 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 24 Aug 2005 19:59:01 -0400 Subject: eepro100 In-Reply-To: <20050824153506.3c755bfa.zaitcev@redhat.com> References: <20050824153506.3c755bfa.zaitcev@redhat.com> Message-ID: <20050824235901.GB22188@redhat.com> On Wed, Aug 24, 2005 at 03:35:06PM -0700, Pete Zaitcev wrote: > Hi, Dave, hi, Jeff: > > Do you happen to remember why is eepro100 enabled in FC5 kernels? > I know that a few PCI IDs are not present in e100, seemingly without > any system to it. Yeah, I just checked. eepro100 supports device ID's 0x1035,0x1036,0x1037,0x1227,0x5200, and 0x5201 Other than that, it's a limited subset of various e100 IDs. > The eepro100 was unmaintained for years now. Right? AFAIK yes. I have a vague recollection that we disabled this a while ago, and had to reenable it when users of the IDs above complained their NICs didn't work any more. I don't recall trying adding those ID's to e100.c and seeing whether they work or not though. Jeff ? Dave From zaitcev at redhat.com Thu Aug 25 00:35:02 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 24 Aug 2005 17:35:02 -0700 Subject: udev and pcmcia In-Reply-To: References: <20050823165930.4f17cdab.zaitcev@redhat.com> Message-ID: <20050824173502.315c63fe.zaitcev@redhat.com> On Wed, 24 Aug 2005 19:15:06 +0800, Jeff Pitman wrote: > On Wednesday 24 August 2005 07:59, Pete Zaitcev wrote: > > This happens when module yenta-socket is built statically into > > kernel, which is how stock Fedora kernels are built. > > Not here. Unless I'm missing something. > [root at kubik log]# uname -r > 2.6.12-1.1398_FC4 I should have not used "stock Fedora" but "stock Rawhide". [zaitcev at niphredil ~]$ cat /proc/version Linux version 2.6.12-1.1483_FC5 (bhcompile at porky.build.redhat.com) (gcc version 4.0.1 20050810 (Red Hat 4.0.1-8)) #1 Sat Aug 13 20:41:53 EDT 2005 [zaitcev at niphredil ~]$ grep YENTA /boot/config-2.6.12-1.1483_FC5 CONFIG_YENTA=y FC4 uses the old PCMCIA system with cardmgr (from pcmcia-cs RPM) and FC5 uses the new system with pcmciautils. BTW, this is a smaller problem than I thought. I'm going to throw together a script for /etc/rc.d/init.d/pcmcia. I ass-ume that yum will handle the details automagically despite the name of the script conflicting. Or perhaps I should use pcmcia-yenta. I do not like to add scripts, because our boot times are atrocious even as they are. However, I do not have a better idea. The udev simply is not involved here. Socket startup has to happen before udev can receive any plug/unplug messages. -- Pete From rdieter at math.unl.edu Thu Aug 25 01:14:39 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 24 Aug 2005 20:14:39 -0500 Subject: why does yum want to upgrade koffice? In-Reply-To: References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> <1124823759.25024.37.camel@cutter> Message-ID: <430D1B7F.5010209@math.unl.edu> sean wrote: > libgs is supplied by ghostscript. koffice from extras won't install > because libgs.so.7 isn't installed. It isn't installed because > ghostscript-8.15-0.rc4.3 installs libgs.so.8. > locate libgs.so > /usr/lib64/libgs.so.8 > /usr/lib64/libgs.so > /usr/lib64/libgs.so.8.15 Then you're not using fc4, but rawhide/devel. -- Rex From msalim at cs.indiana.edu Thu Aug 25 05:26:34 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Thu, 25 Aug 2005 00:26:34 -0500 Subject: evolution-data-server 2.3.8 and address books Message-ID: <1124947594.4139.8.camel@salem> Just a heads-up: Upon upgrading to evolution* 2.3.8 this afternoon I noticed that I could not use any of my address books: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166742 I localized the error to e-d-s - downgrading evolution only to 2.3.7 does not work, but downgrading evolution-data-server as well solves the problem. While doing so I noticed something funny: I was rpm -Uvh --force'ing the old e-d-s package, and a symlink (libedataserverui-1.2.so.6) became dangling. e-d-s 2.3.7 has it pointing to so.6.0.0 while 2.3.8 has so.6.0.1 .. is this specific to the way e-d-s is packaged or more common? Thanks, - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From zaitcev at redhat.com Thu Aug 25 05:50:09 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 24 Aug 2005 22:50:09 -0700 Subject: udev and pcmcia In-Reply-To: References: <20050823165930.4f17cdab.zaitcev@redhat.com> Message-ID: <20050824225009.1cb8c21b.zaitcev@redhat.com> I seem to have figured this out. The udev is not implicated at all, because the kernel will not deliver any hotplug events until the pcmcia-socket-startup was run (so udev cannot do anything about it). Harald suggested to look at scsi_replay() in /sbin/start_udev. I did, and while interesting, it seems like an overkill. I don't know if we want to enable pcmcia sockets that early. We do not boot from CF-in-PCMCIA adapter, right? My main concern is that anything running so early is hard to debug. Bill, how about adding a script to pcmciautils (see appended)? -- Pete #!/bin/sh # # pcmcia This shell script runs pcmcia-socket-statup for sockets # with statically linked socket drivers. # For Ethernet to work, this has to be run before network. # # chkconfig: 2345 09 95 # description: The pcmcia is a fake service. All necessary setup is proviced \ # by udev, except in case a socket driver is built statically. # probe: true # config: /etc/sysconfig/pcmcia . /etc/init.d/functions prog=pcmcia startup=/sbin/pcmcia-socket-startup start () { if [ \! -x $startup ]; then return 1; fi names=$(find /sys/class/pcmcia_socket -name pcmcia_socket[0-9]* 2>&1) if [ \! "$?" ]; then # Something is very broken. Not sure what to do though... return 1; fi if [ -z "$names" ]; then # No PCMCIA on this box, or dynamic socket driver. Good! return 0; fi echo -n $"Running $prog: " for name in $names do name=$(basename $name) /sbin/pcmcia-socket-startup $name done [ $? -eq 0 ] && success || failure echo } case "$1" in start) start ;; stop|restart|reload|status|condrestart) # Do nothing ;; *) echo $"Usage: $0 {start|stop|status|reload|restart|condrestart}" exit 1 esac From rodd at clarkson.id.au Thu Aug 25 06:04:28 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 25 Aug 2005 16:04:28 +1000 Subject: evolution-data-server 2.3.8 and address books In-Reply-To: <1124947594.4139.8.camel@salem> References: <1124947594.4139.8.camel@salem> Message-ID: <1124949868.2985.25.camel@localhost.localdomain> On Thu, 2005-08-25 at 00:26 -0500, Michel Alexandre Salim wrote: > Just a heads-up: Upon upgrading to evolution* 2.3.8 this afternoon I > noticed that I could not use any of my address books: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166742 > > I localized the error to e-d-s - downgrading evolution only to 2.3.7 > does not work, but downgrading evolution-data-server as well solves the > problem. > > While doing so I noticed something funny: I was rpm -Uvh --force'ing the > old e-d-s package, and a symlink (libedataserverui-1.2.so.6) became > dangling. e-d-s 2.3.7 has it pointing to so.6.0.0 while 2.3.8 has > so.6.0.1 .. is this specific to the way e-d-s is packaged or more > common? Yeah, I just noticed the same problem too. Having done any of the testing you've done, but hopefully this might be addressed soon. ;-] R. -- "It's a fine line between denial and faith. It's much better on my side" From tjb at unh.edu Thu Aug 25 12:40:00 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 25 Aug 2005 08:40:00 -0400 Subject: GDM Login Failure Message-ID: <1124973600.6327.2.camel@wintermute.sr.unh.edu> For the last couple of days, gdm login fails with "Cannot start the session due to some internal error." It fails with any session. I search bugzilla but didn't find any recent bugs like this. Is it just me? 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 fedora at camperquake.de Thu Aug 25 12:43:02 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 25 Aug 2005 14:43:02 +0200 Subject: GDM Login Failure In-Reply-To: <1124973600.6327.2.camel@wintermute.sr.unh.edu> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> Message-ID: <20050825124302.GB16229@ryoko.camperquake.de> On Thu, Aug 25, 2005 at 08:40:00AM -0400, Thomas J. Baker wrote: > For the last couple of days, gdm login fails with "Cannot start the > session due to some internal error." It fails with any session. I search > bugzilla but didn't find any recent bugs like this. Is it just me? No, I am seeing this, too. From jspaleta at gmail.com Thu Aug 25 12:50:25 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 25 Aug 2005 08:50:25 -0400 Subject: GDM Login Failure In-Reply-To: <1124973600.6327.2.camel@wintermute.sr.unh.edu> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> Message-ID: <604aa7910508250550250aa95b@mail.gmail.com> On 8/25/05, Thomas J. Baker wrote: > For the last couple of days, gdm login fails with "Cannot start the > session due to some internal error." It fails with any session. I search > bugzilla but didn't find any recent bugs like this. Is it just me? hmm i did a reboot into the lastest kernel last night with a fully synced rawhide system and I'm not having a problem with my normal user. If you make a fresh user and try to login with that user does this still happen? -jef From mailinglists at erwinrol.com Thu Aug 25 12:55:25 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 25 Aug 2005 14:55:25 +0200 Subject: GDM Login Failure In-Reply-To: <20050825124302.GB16229@ryoko.camperquake.de> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <20050825124302.GB16229@ryoko.camperquake.de> Message-ID: <1124974525.7380.55.camel@xpc.home.erwinrol.com> On Thu, 2005-08-25 at 14:43 +0200, Ralf Ertzinger wrote: > On Thu, Aug 25, 2005 at 08:40:00AM -0400, Thomas J. Baker wrote: > > For the last couple of days, gdm login fails with "Cannot start the > > session due to some internal error." It fails with any session. I search > > bugzilla but didn't find any recent bugs like this. Is it just me? > > No, I am seeing this, too. > same here, but after a fixfiles relabel it seems to have gone away. I installed a older version of GDM when those problems with early login started, so i dunno if it really is a general thing of something i broke, but the log files have the following entry; Aug 23 21:24:58 xpc setfiles: relabeling /usr/sbin/gdm-binary from system_u:object_r:sbin_t to system_u:object_r:xdm_exec_t - Erwin From jlaska at redhat.com Thu Aug 25 13:02:43 2005 From: jlaska at redhat.com (James Laska) Date: Thu, 25 Aug 2005 09:02:43 -0400 Subject: GDM Login Failure In-Reply-To: <1124973600.6327.2.camel@wintermute.sr.unh.edu> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> Message-ID: <1124974963.3932.5.camel@flatline.devel.redhat.com> I noticed this after recent rawhide updates. It appeared my logins were being restricted by selinux||audit. $(setenforce 0) was sufficient to let me passed the gate. I noticed the following avc denial in my audit log kernel: audit(1124974394.984:6): avc: denied { transition } for pid=4926 comm="gdm-binary" name="Xsession" dev=hda5 ino=1933254 scontext=system_u:system_r:init_t tcontext=user_u:system_r:unconfined_t tclass=process Bug#166761 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166761) has been filed to address this. Please post any other debug or workaround details you might have. Thanks, James Laska On Thu, 2005-08-25 at 08:40 -0400, Thomas J. Baker wrote: > For the last couple of days, gdm login fails with "Cannot start the > session due to some internal error." It fails with any session. I search > bugzilla but didn't find any recent bugs like this. Is it just me? > > 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 redhat.com Thu Aug 25 13:07:17 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 25 Aug 2005 18:37:17 +0530 Subject: GDM Login Failure In-Reply-To: <1124974963.3932.5.camel@flatline.devel.redhat.com> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <1124974963.3932.5.camel@flatline.devel.redhat.com> Message-ID: <430DC285.5080609@redhat.com> James Laska wrote: >I noticed this after recent rawhide updates. It appeared my logins were >being restricted by selinux||audit. $(setenforce 0) was sufficient to >let me passed the gate. I noticed the following avc denial in my audit >log > >kernel: audit(1124974394.984:6): avc: denied { transition } for >pid=4926 comm="gdm-binary" name="Xsession" dev=hda5 ino=1933254 >scontext=system_u:system_r:init_t tcontext=user_u:system_r:unconfined_t >tclass=process > >Bug#166761 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166761) >has been filed to address this. Please post any other debug or >workaround details you might have. > >Thanks, >James Laska > > You dont turn to turn off SELinux. A simple relabelling procedure will probably fix this http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2827238 regards Rahul From jlaska at redhat.com Thu Aug 25 13:09:07 2005 From: jlaska at redhat.com (James Laska) Date: Thu, 25 Aug 2005 09:09:07 -0400 Subject: GDM Login Failure In-Reply-To: <430DC285.5080609@redhat.com> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <1124974963.3932.5.camel@flatline.devel.redhat.com> <430DC285.5080609@redhat.com> Message-ID: <1124975347.3932.8.camel@flatline.devel.redhat.com> On Thu, 2005-08-25 at 18:37 +0530, Rahul Sundaram wrote: > > > You dont turn to turn off SELinux. A simple relabelling procedure will > probably fix this > > http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2827238 I thought that as well and tried: $ fixfiles -R / restore But still encountered the failure. -James From fedora at camperquake.de Thu Aug 25 13:16:20 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 25 Aug 2005 15:16:20 +0200 Subject: GDM Login Failure In-Reply-To: <1124974525.7380.55.camel@xpc.home.erwinrol.com> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <20050825124302.GB16229@ryoko.camperquake.de> <1124974525.7380.55.camel@xpc.home.erwinrol.com> Message-ID: <20050825131620.GC16229@ryoko.camperquake.de> On Thu, Aug 25, 2005 at 02:55:25PM +0200, Erwin Rol wrote: > same here, but after a fixfiles relabel it seems to have gone away. I do not use selinux, so I think this is a different bug. I do not even get asked for a password, gdm just seems to restart after I enter a user name. From taha_ab at yahoo.fr Thu Aug 25 13:25:08 2005 From: taha_ab at yahoo.fr (taha abderrahman) Date: Thu, 25 Aug 2005 15:25:08 +0200 (CEST) Subject: Proposal for a new package called K3DSurf (from the developer) Message-ID: <20050825132509.18191.qmail@web25301.mail.ukl.yahoo.com> Hi, First I want to thank all of you for your excellent work with Fedora and I hope I'm not in the wrong place for making a proposal for a new software. If it's the case, please let me know how to do it properly. I'm developing an application called K3DSurf which is a program to visualize and manipulate mathematical models. It's also a "modeler" for Pov-Ray. For more informations, please visit : http://k3dsurf.sourceforge.net/ or http://kde-apps.org/content/show.php?content=25049 For any suggestion or question, just let me know. Thanks. Abderrahman Taha taha_ab at yahoo.fr ___________________________________________________________________________ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger T?l?chargez cette version sur http://fr.messenger.yahoo.com From tjb at unh.edu Thu Aug 25 13:26:01 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 25 Aug 2005 09:26:01 -0400 Subject: GDM Login Failure In-Reply-To: <604aa7910508250550250aa95b@mail.gmail.com> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <604aa7910508250550250aa95b@mail.gmail.com> Message-ID: <1124976361.6327.7.camel@wintermute.sr.unh.edu> On Thu, 2005-08-25 at 08:50 -0400, Jeff Spaleta wrote: > On 8/25/05, Thomas J. Baker wrote: > > For the last couple of days, gdm login fails with "Cannot start the > > session due to some internal error." It fails with any session. I search > > bugzilla but didn't find any recent bugs like this. Is it just me? > > hmm i did a reboot into the lastest kernel last night with a fully > synced rawhide system and I'm not having a problem with my normal > user. If you make a fresh user and try to login with that user does > this still happen? > > -jef > It happens with a new user too. It's happening for me on all three of my rawhide systems, up to date as of this morning. The syslog says this: Aug 25 09:22:33 localhost gdm(pam_unix)[4058]: session opened for user gnome by (uid=0) Aug 25 09:22:33 localhost gdm[4085]: session_child_run: Could not exec /etc/X11/xdm/Xsession default Aug 25 09:22:43 localhost gdm(pam_unix)[4058]: session closed for user gnome Starting X manually works fine. 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 rc040203 at freenet.de Thu Aug 25 13:32:34 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 25 Aug 2005 15:32:34 +0200 Subject: Proposal for a new package called K3DSurf (from the developer) In-Reply-To: <20050825132509.18191.qmail@web25301.mail.ukl.yahoo.com> References: <20050825132509.18191.qmail@web25301.mail.ukl.yahoo.com> Message-ID: <1124976755.4363.172.camel@mccallum.corsepiu.local> On Thu, 2005-08-25 at 15:25 +0200, taha abderrahman wrote: > Hi, > I'm developing an application called K3DSurf which is > a program to visualize and manipulate mathematical > models. It's also a "modeler" for Pov-Ray. > For more informations, please visit : > http://k3dsurf.sourceforge.net/ or > http://kde-apps.org/content/show.php?content=25049 As you seem to be its primary developer, how about you packaging it yourself? cf. http://fedoraproject.org/wiki/Extras cf. http://fedoraproject.org/wiki/Extras/NewPackageProcessMarkTwo Ralf From tjb at unh.edu Thu Aug 25 13:41:48 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 25 Aug 2005 09:41:48 -0400 Subject: GDM Login Failure In-Reply-To: <1124974525.7380.55.camel@xpc.home.erwinrol.com> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <20050825124302.GB16229@ryoko.camperquake.de> <1124974525.7380.55.camel@xpc.home.erwinrol.com> Message-ID: <1124977308.6327.8.camel@wintermute.sr.unh.edu> On Thu, 2005-08-25 at 14:55 +0200, Erwin Rol wrote: > On Thu, 2005-08-25 at 14:43 +0200, Ralf Ertzinger wrote: > > On Thu, Aug 25, 2005 at 08:40:00AM -0400, Thomas J. Baker wrote: > > > For the last couple of days, gdm login fails with "Cannot start the > > > session due to some internal error." It fails with any session. I search > > > bugzilla but didn't find any recent bugs like this. Is it just me? > > > > No, I am seeing this, too. > > > > same here, but after a fixfiles relabel it seems to have gone away. I > installed a older version of GDM when those problems with early login > started, so i dunno if it really is a general thing of something i > broke, but the log files have the following entry; > > Aug 23 21:24:58 xpc setfiles: relabeling /usr/sbin/gdm-binary from > system_u:object_r:sbin_t to system_u:object_r:xdm_exec_t > > - Erwin > That fixed it for me too. 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 orion at cora.nwra.com Thu Aug 25 15:20:10 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 25 Aug 2005 09:20:10 -0600 Subject: genhdlist/pkgorder questions Message-ID: I build a custom Fedora distro locally with the following commands: /usr/lib/anaconda-runtime/genhdlist --withnumbers --productpath Fedora ${coradir} PYTHONPATH=/usr/lib/anaconda /usr/lib/anaconda-runtime/pkgorder ${coradir} ${buildarch} Fedora > ${coradir}/pkgorder 2>/dev/null /usr/lib/anaconda-runtime/genhdlist --fileorder ${coradir}/pkgorder --withnumbers --productpath Fedora ${coradir} Two questions: - Is the double running of genhdlist still necessary? - I have been building the x86_64 version on a x86_64 machine because pkgorder complained when run on i386. Does anyone know if this has been fixed? Perhaps I'll just give is a try.... - Orion From buildsys at redhat.com Thu Aug 25 15:46:32 2005 From: buildsys at redhat.com (Build System) Date: Thu, 25 Aug 2005 11:46:32 -0400 Subject: rawhide report: 20050825 changes Message-ID: <200508251546.j7PFkWc0019191@porkchop.devel.redhat.com> Updated Packages: anthy-6801-1 ------------ * Wed Aug 24 2005 Akira TAGOH - 6801-1 - updates to the snapshot version. * Tue Aug 09 2005 Akira TAGOH - added dist tag in Release. bluez-utils-2.19-3 ------------------ * Thu Aug 25 2005 David Woodhouse 2.19-3 - Use dbus fixes from upstream cairo-1.0.0-1 ------------- * Wed Aug 24 2005 Kristian H??gsberg - 1.0.0-1 - Update to cairo-1.0.0. - Drop cairo-0.9.2-cache-eviction-fix.patch and cairo-0.9.2-dont-hash-null-string.patch. checkpolicy-1.25.12-1 --------------------- * Mon Aug 22 2005 Dan Walsh 1.25.12-1 - Update to NSA Release * Fixed handling of validatetrans constraint expressions. Bug reported by Dan Walsh for checkpolicy -M. control-center-1:2.11.91-3 -------------------------- * Tue Aug 23 2005 Ray Strode - 1:2.11.91-3 - Configure all mice for left-handed mode in left-handed mode (bug 126420) - dont use pango-xft when drawing keyboard layout in gnome-keyboard-properties dialog dbus-0.36.1-1 ------------- * Wed Aug 24 2005 John (J5) Palmieri - 0.36.1-1 - Upgrade to dbus-0.36.1 - Install all files to lib64/ on 64bit machines eject-2.1.1-0.fc4.1 ------------------- * Wed Aug 24 2005 Than Ngo 2.1.1-0.fc4.1 - update to 2.1.1 - remove eject-2.0.13-scsi.patch, which included in new upstream elfutils-0.114-1 ---------------- * Wed Aug 24 2005 Roland McGrath - 0.114-1 - update to 0.114 - new program eu-ranlib - libdw: new calls for inlines - libdwfl: new calls for offline modules evolution-connector-2.3.8-1 --------------------------- * Wed Aug 24 2005 David Malcolm - 2.3.8-1 - 2.3.8 - Regenerated patch 200 - Add -Werror-implicit-function-declaration to CFLAGS; make it use RPM_OPT_FLAGS glibc-2.3.90-10 --------------- * Wed Aug 24 2005 Jakub Jelinek 2.3.90-10 - update from CVS - fix growing of nscd persistent database (BZ#1204) - fix _FORTIFY_SOURCE mbstowcs and wcstombs if destination size is known at compile time, but length argument is not kdeedu-3.4.2-2 -------------- * Wed Aug 24 2005 Than Ngo 3.4.2-2 - rebuilt against boost-1.33 kernel-2.6.12-1.1509_FC5 ------------------------ * Tue Aug 23 2005 Dave Jones - 2.6.13-rc7 - Net/Diskdump/netconsole update from Jeff "The Yellow Dart" Moyer. * Tue Aug 23 2005 Rik van Riel - upgrade to latest upstream Xen snapshot lftp-3.3.0-1 ------------ * Wed Aug 24 2005 Jason Vas Dias 3.3.0-1 - Upgrade to upstream version 3.3.0 libselinux-1.25.3-1 ------------------- * Wed Aug 24 2005 Dan Walsh 1.25.3-1 * Merged context translation patch, originally by TCS, with modifications by Dan Walsh (Red Hat). * Wed Aug 17 2005 Dan Walsh 1.25.2-2 - Apply translation patch nfs-utils-1.0.7-15 ------------------ * Wed Aug 24 2005 Peter Jones - 1.0.7-15 - don't strip during "make install", so debuginfo packages are generated right pam-0.80-7 ---------- * Wed Aug 24 2005 Tomas Mraz 0.80-7 - don't fail in audit code when audit is not compiled in on the newest kernels (#166422) * Mon Aug 01 2005 Tomas Mraz 0.80-6 - add option to pam_loginuid to require auditd * Fri Jul 29 2005 Tomas Mraz 0.80-5 - fix NULL dereference in pam_userdb (#164418) pcre-6.3-1 ---------- * Wed Aug 24 2005 Than Ngo 6.3-1 - update to 6.3 pyOpenSSL-0.6-1.p24.6 --------------------- * Wed Aug 24 2005 Jeremy Katz - 0.6-1.p24.6 - add dcbw's patch to fix some threading problems selinux-policy-strict-1.25.4-8 ------------------------------ * Mon Aug 22 2005 Dan Walsh 1.25.4-8 - Apply russell's cleanups * Mon Aug 22 2005 Dan Walsh 1.25.4-7 - Bump for FC-4 selinux-policy-targeted-1.25.4-8 -------------------------------- * Mon Aug 22 2005 Dan Walsh 1.25.4-8 - Apply russell's cleanups * Mon Aug 22 2005 Dan Walsh 1.25.4-7 - Bump for FC-4 * Mon Aug 22 2005 Dan Walsh 1.25.4-6 - Fix /var/lib/yp/* file_context sysklogd-1.4.1-33 ----------------- * Wed Aug 24 2005 Jason Vas Dias 1.4.1rh-33 - fix bug 166643: klogd needs to use internal syslog functions in syslog.c, because only they allow logging with facility==kernel. Fix prototypes to allow use of internal syslog functions. syslinux-3.10-2 --------------- * Mon Aug 22 2005 Peter Jones - 3.10-2 - Update to 3.10 - Don't do "make clean", so we actually ship the bins hpa gives us * Sat Jul 09 2005 Peter Jones - 3.09-2 - Update to 3.09 * Thu Jun 16 2005 Peter Jones - 3.08.92-1 - Update to 3.09-pre2, to fix the i915 .bss overflow bug tetex-3.0-6 ----------- * Fri Aug 19 2005 Jindrich Novy 3.0-6 - fix detectection of X resource file for pxdvi (#164960) - update to mendexk 2.6c (announced by MATSUURA Takanori) xscreensaver-1:4.22-9 --------------------- * Wed Aug 24 2005 Ray Strode 1:4.22-9 - The only legitimate way to call realpath is with NULL buffer (bug 165270). zlib-1.2.3-1 ------------ * Wed Aug 24 2005 Florian La Roche - update to 1.2.3 Broken deps for i386 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 systemtap - 0.2.2-2.i386 requires libdw.so.1(ELFUTILS_0.111) cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ppc ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ia64 ---------------------------------------------------------- initscripts - 8.12-2.ia64 requires kernel >= 0:2.6.12 lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 rgmanager - 1.9.31-3.ia64 requires ccs gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 Broken deps for ppc64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 ppc64-utils - 0.7-9.ppc64 requires yaboot system-config-mouse - 1.2.11-1.noarch requires pyxf86config dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) firstboot - 1.3.45-1.noarch requires system-config-display Broken deps for s390 ---------------------------------------------------------- initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 systemtap - 0.2.2-2.x86_64 requires libdw.so.1(ELFUTILS_0.111)(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 From orion at cora.nwra.com Thu Aug 25 15:49:09 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 25 Aug 2005 09:49:09 -0600 Subject: genhdlist/pkgorder questions In-Reply-To: References: Message-ID: Orion Poplawski wrote: > - I have been building the x86_64 version on a x86_64 machine because > pkgorder complained when run on i386. Does anyone know if this has been > fixed? Perhaps I'll just give it a try.... Looks like pkgorder still fails on i386 for the x86_64 distro: Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 209, in ? pkgOrder.append(hdlist[package].nevra()) File "/usr/lib/anaconda/hdrlist.py", line 431, in __getitem__ raise KeyError, "No such package %s" %(item,) KeyError: 'No such package kernel-smp-devel' From notting at redhat.com Thu Aug 25 15:53:30 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Aug 2005 11:53:30 -0400 Subject: udev and pcmcia In-Reply-To: <20050824225009.1cb8c21b.zaitcev@redhat.com> References: <20050823165930.4f17cdab.zaitcev@redhat.com> <20050824225009.1cb8c21b.zaitcev@redhat.com> Message-ID: <20050825155330.GA4724@nostromo.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > I seem to have figured this out. The udev is not implicated at all, > because the kernel will not deliver any hotplug events until the > pcmcia-socket-startup was run (so udev cannot do anything about it). > > Harald suggested to look at scsi_replay() in /sbin/start_udev. > I did, and while interesting, it seems like an overkill. > I don't know if we want to enable pcmcia sockets that early. > We do not boot from CF-in-PCMCIA adapter, right? My main concern > is that anything running so early is hard to debug. > > Bill, how about adding a script to pcmciautils (see appended)? Looks like overkill for a configuration we don't build. Realistically, there will probably be PCI replay stuff soon, which should cover this. Bill From zaitcev at redhat.com Thu Aug 25 16:13:40 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 25 Aug 2005 09:13:40 -0700 Subject: udev and pcmcia In-Reply-To: <20050825155330.GA4724@nostromo.devel.redhat.com> References: <20050823165930.4f17cdab.zaitcev@redhat.com> <20050824225009.1cb8c21b.zaitcev@redhat.com> <20050825155330.GA4724@nostromo.devel.redhat.com> Message-ID: <20050825091340.038c630f.zaitcev@redhat.com> On Thu, 25 Aug 2005 11:53:30 -0400, Bill Nottingham wrote: > Pete Zaitcev (zaitcev at redhat.com) said: > > Bill, how about adding a script to pcmciautils (see appended)? > > Looks like overkill for a configuration we don't build. But we do. Yenta went static just recently: [zaitcev at niphredil ~]$ grep YENTA /boot/config-2.6.12-1.14* /boot/config-2.6.12-1.1433_FC5:CONFIG_YENTA=m /boot/config-2.6.12-1.1483_FC5:CONFIG_YENTA=y [zaitcev at niphredil ~]$ This is what CVS log says: revision 1.45 date: 2005/08/09 19:45:00; author: davej; state: Exp; lines: +2 -2 PCMCIA/PCCARD are now built non-modular for improved resource management. > Realistically, there will probably be PCI replay stuff soon, > which should cover this. Hrm. I guess I'll watch it and see. The thing is, there aren't any hotplug events involved into this. Just the driver initialization. -- Pete From notting at redhat.com Thu Aug 25 16:49:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Aug 2005 12:49:00 -0400 Subject: udev and pcmcia In-Reply-To: <20050825091340.038c630f.zaitcev@redhat.com> References: <20050823165930.4f17cdab.zaitcev@redhat.com> <20050824225009.1cb8c21b.zaitcev@redhat.com> <20050825155330.GA4724@nostromo.devel.redhat.com> <20050825091340.038c630f.zaitcev@redhat.com> Message-ID: <20050825164900.GD4724@nostromo.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > > Looks like overkill for a configuration we don't build. > > But we do. Yenta went static just recently: > > [zaitcev at niphredil ~]$ grep YENTA /boot/config-2.6.12-1.14* > /boot/config-2.6.12-1.1433_FC5:CONFIG_YENTA=m > /boot/config-2.6.12-1.1483_FC5:CONFIG_YENTA=y > [zaitcev at niphredil ~]$ > > This is what CVS log says: > > revision 1.45 > date: 2005/08/09 19:45:00; author: davej; state: Exp; lines: +2 -2 > PCMCIA/PCCARD are now built non-modular for improved resource management. That's what I get for running a three week old kernel. Dave, you broke it! :) > > Realistically, there will probably be PCI replay stuff soon, > > which should cover this. > > Hrm. I guess I'll watch it and see. The thing is, there aren't any > hotplug events involved into this. Just the driver initialization. I wonder if the static case really requires the resource prodding. May have to talk to Dominik. Bill From zaitcev at redhat.com Thu Aug 25 17:31:45 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 25 Aug 2005 10:31:45 -0700 Subject: udev and pcmcia In-Reply-To: <20050825164900.GD4724@nostromo.devel.redhat.com> References: <20050823165930.4f17cdab.zaitcev@redhat.com> <20050824225009.1cb8c21b.zaitcev@redhat.com> <20050825155330.GA4724@nostromo.devel.redhat.com> <20050825091340.038c630f.zaitcev@redhat.com> <20050825164900.GD4724@nostromo.devel.redhat.com> Message-ID: <20050825103145.7c11b71f.zaitcev@redhat.com> On Thu, 25 Aug 2005 12:49:00 -0400, Bill Nottingham wrote: > I wonder if the static case really requires the resource prodding. > May have to talk to Dominik. One step ahead of you, man. :-) > From: Dominik Brodowski > To: Pete Zaitcev > Cc: linux-pcmcia at lists.infradead.org > Subject: Re: Statically built yenta does not work anymore (in FC5) > Date: Wed, 17 Aug 2005 11:44:04 +0200 > On Tue, Aug 16, 2005 at 10:36:21AM -0700, Pete Zaitcev wrote: > > What is the theory of operations here? What sequence of events is > > supposed to happen between pcmcia_register_socket and the do_io_probe()? > > If yenta is built-in, you need to "cold-plug" pcmcia_sockets, i.e. make sure > pcmcia-socket-startup is called for each pcmcia_socket already registered. -- Pete From seandarcy2 at gmail.com Thu Aug 25 18:00:30 2005 From: seandarcy2 at gmail.com (sean) Date: Thu, 25 Aug 2005 14:00:30 -0400 Subject: why does yum want to upgrade koffice? In-Reply-To: <430D1B7F.5010209@math.unl.edu> References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> <1124823759.25024.37.camel@cutter> <430D1B7F.5010209@math.unl.edu> Message-ID: Rex Dieter wrote: > sean wrote: > >> libgs is supplied by ghostscript. koffice from extras won't install >> because libgs.so.7 isn't installed. It isn't installed because >> ghostscript-8.15-0.rc4.3 installs libgs.so.8. > > >> locate libgs.so >> /usr/lib64/libgs.so.8 >> /usr/lib64/libgs.so >> /usr/lib64/libgs.so.8.15 > > > Then you're not using fc4, but rawhide/devel. > > -- Rex > > > OK. But so what? Why does yum want to "upgrade" koffice? sean From zboszor at freemail.hu Thu Aug 25 18:29:14 2005 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Thu, 25 Aug 2005 20:29:14 +0200 Subject: GDM Login Failure In-Reply-To: <20050825124302.GB16229@ryoko.camperquake.de> References: <1124973600.6327.2.camel@wintermute.sr.unh.edu> <20050825124302.GB16229@ryoko.camperquake.de> Message-ID: <430E0DFA.8090804@freemail.hu> Ralf Ertzinger ?rta: > On Thu, Aug 25, 2005 at 08:40:00AM -0400, Thomas J. Baker wrote: > >>For the last couple of days, gdm login fails with "Cannot start the >>session due to some internal error." It fails with any session. I search >>bugzilla but didn't find any recent bugs like this. Is it just me? > > > No, I am seeing this, too. > A me, too. On a plain FC4 I installed yesterday night. I tried to setup early login and I got that error. Turning on RHGB or just switching off early login again solved it. Although I haven't yet modified startup order or xfs and syslog. Best regards, Zolt?n B?sz?rm?nyi From taha_ab at yahoo.fr Thu Aug 25 19:41:33 2005 From: taha_ab at yahoo.fr (taha abderrahman) Date: Thu, 25 Aug 2005 21:41:33 +0200 (CEST) Subject: Proposal for a new package called K3DSurf (from the developer) Message-ID: <20050825194133.85894.qmail@web25301.mail.ukl.yahoo.com> Hi Ralf, Thanks for the links. I didn't read all pages but it seems that creating package for Fedora is easier than I was expecting. It's not that I don't want to do it but just because it'll be much easier for me if an experienced person give us his help (right now, 2 persons are kindly building Debian and Mac packages). Also, I think that building package is not just compiling and ziping (for example, building Suse package need an installation of 3GB, which is impossible for me). NB: an rpm package already exists for QIlinux distrib : http://www.qilinux.it/modules.php?op=modload&name=distromatic&file=index&tag=devel&pkg=k3dsurf I'm going to try to do it myself but any help will be appreciated. Thanks Taha ___________________________________________________________________________ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger T?l?chargez cette version sur http://fr.messenger.yahoo.com From zaitcev at redhat.com Thu Aug 25 20:09:08 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 25 Aug 2005 13:09:08 -0700 Subject: Gdk-WARNING Message-ID: <20050825130908.67841ae7.zaitcev@redhat.com> Hi, Everyone. A question for GTK hackers here. I get lots and lots of these on stderr after yesterday's update. (gvim:8960): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) (sylpheed:2518): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) This seems to happen to a large number of previously working applications. Is this something that can be corrected in one place, or do I need to rebuild everything? The question arises because I use gvim a lot, and that is started from a command line, so I cannot just ignore stderr. [zaitcev at lembas ~]$ rpm -qa 'gtk*' gtkhtml2-2.6.3-1 gtkhtml-devel-1.1.9-11 gtk+-1.2.10-39 gtk2-devel-2.8.0-2 gtk-doc-1.3-2 gtkhtml-1.1.9-11 gtk-engines-0.12-6 gtk+-devel-1.2.10-39 gtk2-2.8.0-2 gtk2-engines-2.6.3-1 [zaitcev at lembas ~]$ Thanks, -- Pete From pjones at redhat.com Thu Aug 25 20:27:23 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 25 Aug 2005 16:27:23 -0400 Subject: why does yum want to upgrade koffice? In-Reply-To: References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> <1124823759.25024.37.camel@cutter> <430D1B7F.5010209@math.unl.edu> Message-ID: <1125001643.13523.15.camel@localhost.localdomain> On Tue, 2005-08-23 at 10:44 -0400, sean wrote: > [root at amd64-3000 development]# rpm -qa | grep koffice > koffice-filters-1.4.1-4 > koffice-devel-1.4.1-4 > koffice-core-1.4.1-4 > koffice-kword-1.4.1-4 > > yum upgrade > .......... > Added 15 new packages, deleted 0 old in 1.83 seconds > Resolving Dependencies > --> Populating transaction set with selected packages. > Please wait. > ---> Package koffice-kword.x86_64 0:1.4.1-4.fc4 set to be > updated On Thu, 2005-08-25 at 14:00 -0400, sean wrote: > OK. But so what? Why does yum want to "upgrade" koffice? Because "4" is less than ""4.fc4". -- Peter From rdieter at math.unl.edu Thu Aug 25 20:30:31 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 25 Aug 2005 15:30:31 -0500 Subject: why does yum want to upgrade koffice? In-Reply-To: References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> <1124823759.25024.37.camel@cutter> <430D1B7F.5010209@math.unl.edu> Message-ID: <430E2A67.9090409@math.unl.edu> sean wrote: > Rex Dieter wrote: >> sean wrote: >>> libgs is supplied by ghostscript. koffice from extras won't install >>> because libgs.so.7 isn't installed. It isn't installed because >>> ghostscript-8.15-0.rc4.3 installs libgs.so.8. >>> locate libgs.so >>> /usr/lib64/libgs.so.8 >>> /usr/lib64/libgs.so >>> /usr/lib64/libgs.so.8.15 >> Then you're not using fc4, but rawhide/devel. > OK. But so what? Why does yum want to "upgrade" koffice? Why shouldn't it? Are you using the extras-devel repository too? (If not, you should). -- Rex From rstrode at redhat.com Thu Aug 25 20:59:50 2005 From: rstrode at redhat.com (Ray Strode) Date: Thu, 25 Aug 2005 16:59:50 -0400 Subject: Gdk-WARNING In-Reply-To: <20050825130908.67841ae7.zaitcev@redhat.com> References: <20050825130908.67841ae7.zaitcev@redhat.com> Message-ID: <1125003590.3076.0.camel@localhost.localdomain> Hi, > Hi, Everyone. A question for GTK hackers here. > I get lots and lots of these on stderr after yesterday's update. > > (gvim:8960): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > (sylpheed:2518): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) it's a bug in the individual apps. See http://bugzilla.gnome.org/show_bug.cgi?id=161520 for more information. --Ray From msalim at cs.indiana.edu Thu Aug 25 21:19:47 2005 From: msalim at cs.indiana.edu (Michel Salim) Date: Thu, 25 Aug 2005 16:19:47 -0500 Subject: xscreensaver Bug 166776 Message-ID: <430E35F3.2040407@cs.indiana.edu> Has anyone else been bitten by this? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166776 Changing most settings in xscreensaver-demo causes a buffer overflow. The FC4 xscreensaver 4.21 is not affected, but any Rawhide build within at least the past week exhibit this behaviour on my machine. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3424 bytes Desc: S/MIME Cryptographic Signature URL: From piet at www.piet.net Fri Aug 26 07:20:08 2005 From: piet at www.piet.net (Piet Delaney) Date: Fri, 26 Aug 2005 00:20:08 -0700 Subject: lib qt missing in FC4 Message-ID: <1125040808.3669.14.camel@hammer.piet.net> Any reason lib qt isn't available in FC4? It's used by the kernel makefile with 'make xconfig'; seem odd not to provide it. -piet -- Piet Delaney Rocky Mountain Linux Lab From sundaram at redhat.com Fri Aug 26 07:22:57 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 26 Aug 2005 12:52:57 +0530 Subject: lib qt missing in FC4 In-Reply-To: <1125040808.3669.14.camel@hammer.piet.net> References: <1125040808.3669.14.camel@hammer.piet.net> Message-ID: <430EC351.5050602@redhat.com> Piet Delaney wrote: >Any reason lib qt isn't available in FC4? > >It's used by the kernel makefile with 'make xconfig'; >seem odd not to provide it. > >-piet > > > You are looking for qt-devel regards Rahul From dwmw2 at infradead.org Fri Aug 26 08:35:29 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 26 Aug 2005 09:35:29 +0100 Subject: xscreensaver Bug 166776 In-Reply-To: <430E35F3.2040407@cs.indiana.edu> References: <430E35F3.2040407@cs.indiana.edu> Message-ID: <1125045329.4469.11.camel@baythorne.infradead.org> On Thu, 2005-08-25 at 16:19 -0500, Michel Salim wrote: > Has anyone else been bitten by this? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166776 > > Changing most settings in xscreensaver-demo causes a buffer overflow. > The FC4 xscreensaver 4.21 is not affected, but any Rawhide build within > at least the past week exhibit this behaviour on my machine. I've certainly seen it recently but it could have been before 2005-08-19 when Ray claims to have fixed it. I'll check. -- dwmw2 From hk at isphuset.no Fri Aug 26 09:48:31 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 26 Aug 2005 11:48:31 +0200 Subject: [Xen-users] Unable to update glibc package on FC4 In-Reply-To: <000201c5a984$25ce6e30$0c02a8c0@zarw2k> References: <000201c5a984$25ce6e30$0c02a8c0@zarw2k> Message-ID: <1125049711.16991.14.camel@linux> Since we are getting nowhere with this, I'm sending a copy to the fedora-devel list. Hopefully someone will know what needs to be done to fix this problem. -HK On Thu, 2005-08-25 at 07:49 -0700, master wrote: > So, do you think it's a xen issue or a Fedora issue? I can't tell... > > -----Original Message----- > From: Hans Kristian Rosbach [mailto:hans.kristian at isphuset.no] > Sent: Thursday, August 25, 2005 1:02 AM > To: master at bradleyland.com > Subject: Re: [Xen-users] Unable to update glibc package on FC4 > > I can second this error. > > I get it both in DomU and Dom0, beware! > > I'm off to do a reinstall now.. =/ > > On Dom0: > > Running Transaction Test > error: failed to stat proc: No such file or directory > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > error: failed to stat proc: No such file or directory > Updating : glibc-common ####################### > [ 1/26] > Updating : glibc ####################### > [ 2/26] > /usr/sbin/glibc_post_upgrade: While trying to > execute /usr/sbin/iconvconfig.i686 child terminated abnormally > error: %post(glibc-2.3.5-10.3.i686) scriptlet failed, exit status 115 > Updating : bind-libs ####################### > [ 3/26] > error: %pre(glibc-headers-2.3.5-10.3.i386) scriptlet failed, exit status > 0 > error: install: %pre scriptlet failed (2), skipping > glibc-headers-2.3.5-10.3 > Updating : bind-utils ####################### > [ 5/26] > Updating : pcre ####################### > [ 6/26] > error: %pre(slocate-2.7-22.fc4.1.i386) scriptlet failed, exit status 0 > error: install: %pre scriptlet failed (2), skipping > slocate-2.7-22.fc4.1 > Updating : dhcpv6_client ####################### > [ 8/26] > error: %pre(diskdumputils-1.1.9-2.i386) scriptlet failed, exit status 0 > error: install: %pre scriptlet failed (2), skipping > diskdumputils-1.1.9-2 > error: %pre(bind-9.3.1-10_FC4.i386) scriptlet failed, exit status 0 > error: install: %pre scriptlet failed (2), skipping bind-9.3.1-10_FC4 > Updating : eject ####################### > [11/26] > Updating : glibc-devel ####################### > [12/26] > error: %post(glibc-devel-2.3.5-10.3.i386) scriptlet failed, exit status > 0 > error: %pre(nscd-2.3.5-10.3.i386) scriptlet failed, exit status 0 > error: install: %pre scriptlet failed (2), skipping nscd-2.3.5-10.3 > error: %preun(slocate-2.7-22.i386) scriptlet failed, exit status 0 > Cleanup : dhcpv6_client ####################### > [14/26] > error: %preun(diskdumputils-1.1.7-4.i386) scriptlet failed, exit status > 0 > error: %preun(bind-9.3.1-8.FC4.i386) scriptlet failed, exit status 0 > Cleanup : glibc-headers ####################### > [15/26] > Cleanup : pcre ####################### > [16/26] > Cleanup : bind-utils ####################### > [17/26] > error: %postun(bind-utils-9.3.1-8.FC4.i386) scriptlet failed, exit > status 0 > Cleanup : bind-libs ####################### > [18/26] > Cleanup : eject ####################### > [19/26] > error: %preun(glibc-devel-2.3.5-10.i386) scriptlet failed, exit status 0 > Cleanup : glibc-common ####################### > [20/26] > Cleanup : glibc ####################### > [21/26] > error: %trigger(redhat-lsb-1.3-10.i386) scriptlet failed, exit status 0 > > Updated: bind.i386 24:9.3.1-10_FC4 bind-libs.i386 24:9.3.1-10_FC4 > bind-utils.i386 24:9.3.1-10_FC4 dhcpv6_client.i386 0:0.10-14_FC4 > diskdumputils.i386 0:1.1.9-2 eject.i386 0:2.1.1-0.fc4.1 glibc.i686 > 0:2.3.5-10.3 glibc-common.i386 0:2.3.5-10.3 glibc-devel.i386 > 0:2.3.5-10.3 glibc-headers.i386 0:2.3.5-10.3 nscd.i386 0:2.3.5-10.3 > pcre.i386 0:5.0-4.1.fc4 slocate.i386 0:2.7-22.fc4.1 > Complete! > [root at xen1 storage1]# ls > Segmentation fault > [root at xen1 storage1]# > > -HK > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.10.15/80 - Release Date: > 8/23/2005 > > From lfarkas at bppiac.hu Fri Aug 26 10:09:37 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 26 Aug 2005 12:09:37 +0200 Subject: what is this watchmen in cvs? Message-ID: <430EEA61.1080906@bppiac.hu> hi, what is this toplevel project in the cvs?: http://cvs.fedora.redhat.com/viewcvs/watchmen/?root=extras doesn't this should have to be one level lower? yours. -- Levente "Si vis pacem para bellum!" From pnasrat at redhat.com Fri Aug 26 11:23:55 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 26 Aug 2005 07:23:55 -0400 Subject: genhdlist/pkgorder questions In-Reply-To: References: Message-ID: <1125055435.18126.3.camel@enki.eridu> On Thu, 2005-08-25 at 09:49 -0600, Orion Poplawski wrote: > Orion Poplawski wrote: > > - I have been building the x86_64 version on a x86_64 machine because > > pkgorder complained when run on i386. Does anyone know if this has been > > fixed? Perhaps I'll just give it a try.... > > Looks like pkgorder still fails on i386 for the x86_64 distro: > > Traceback (most recent call last): > File "/usr/lib/anaconda-runtime/pkgorder", line 209, in ? > pkgOrder.append(hdlist[package].nevra()) > File "/usr/lib/anaconda/hdrlist.py", line 431, in __getitem__ > raise KeyError, "No such package %s" %(item,) > KeyError: 'No such package kernel-smp-devel' You need to build trees on the same arch as you are targetting as we use rpm under the hood for pkgorder/genhdlist Build the x86_64 tree on an x86_64 box. Paul From bdpepple at ameritech.net Fri Aug 26 13:41:21 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Fri, 26 Aug 2005 09:41:21 -0400 Subject: what is this watchmen in cvs? In-Reply-To: <430EEA61.1080906@bppiac.hu> References: <430EEA61.1080906@bppiac.hu> Message-ID: <1125063681.23611.1.camel@shuttle.273piedmont.com> On Fri, 2005-08-26 at 12:09 +0200, Farkas Levente wrote: > hi, > what is this toplevel project in the cvs?: > http://cvs.fedora.redhat.com/viewcvs/watchmen/?root=extras > doesn't this should have to be one level lower? > yours. Looks like a project that was imported by accident into cvs by me. Who do I need to contact to get this removed? /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 rdieter at math.unl.edu Fri Aug 26 14:02:08 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 26 Aug 2005 09:02:08 -0500 Subject: [Xen-users] Unable to update glibc package on FC4 In-Reply-To: <1125049711.16991.14.camel@linux> References: <000201c5a984$25ce6e30$0c02a8c0@zarw2k> <1125049711.16991.14.camel@linux> Message-ID: <430F20E0.5060405@math.unl.edu> Hans Kristian Rosbach wrote: > Since we are getting nowhere with this, I'm sending a copy to > the fedora-devel list. Hopefully someone will know what needs to > be done to fix this problem. You'd best submit it to http://bugzilla.redhat.com/ if you expect a fix. -- Rex > On Thu, 2005-08-25 at 07:49 -0700, master wrote: > >>So, do you think it's a xen issue or a Fedora issue? I can't tell... >> >>-----Original Message----- >>From: Hans Kristian Rosbach [mailto:hans.kristian at isphuset.no] >>Sent: Thursday, August 25, 2005 1:02 AM >>To: master at bradleyland.com >>Subject: Re: [Xen-users] Unable to update glibc package on FC4 >> >>I can second this error. From jconnor at redhat.com Fri Aug 26 15:01:13 2005 From: jconnor at redhat.com (Jason Connor) Date: Fri, 26 Aug 2005 11:01:13 -0400 Subject: epiphany problems in rawhide Message-ID: <1125068473.28834.24.camel@crux.rdu.redhat.com> This isn't a necessarily a 'development' issue, but I doubt that anyone on the fedora list would have an insight and I'm using rawhide. I updated my rawhide and epiphany has stopped working. All I get is a dialog saying that epiphany as quit unexpectedly. This seems limited to embedded mozilla gtk component as I can open the bookmarks editor with no troubles. I've attached a generated backtrace, but I don't understand what's happening to generate the message: `shared object read from target memory' has disappeared; keeping its symbols. There seems to have been a big change in libcairo, but that's not a terribly educated guess at a problem. Does anyone know how to get epiphany to print out debugging messages? or have a deeper insight into this problem? Any help is appreciated. -- Jason L. Connor Software Engineer, Red Hat Network 919.754.4013 gpg - 1024D/6A34521A -------------- next part -------------- Backtrace was generated from '/usr/bin/epiphany' Using host libthread_db library "/lib/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1208183120 (LWP 3288)] [New Thread -1217930320 (LWP 3289)] 0x00162402 in __kernel_vsyscall () #0 0x00162402 in __kernel_vsyscall () #1 0x00157fcb in __waitpid_nocancel () from /lib/libpthread.so.0 #2 0x005a8c5d in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2.so.0 #3 0x00fa921f in nsProfileLock::FatalSignalHandler () from /usr/lib/mozilla-1.7.11/libgtkembedmoz.so #4 #5 0x00f9ddc9 in EmbedPrivate::Realize () from /usr/lib/mozilla-1.7.11/libgtkembedmoz.so #6 0x00f9c208 in gtk_moz_embed_go_back () from /usr/lib/mozilla-1.7.11/libgtkembedmoz.so #7 0x080b091a in mozilla_embed_realize (widget=0x8e6e118) at mozilla-embed.cpp:230 #8 0x002522d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #9 0x00246565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #10 0x00246b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #11 0x00254e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #12 0x00256820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #13 0x00256b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #14 0x011af3d1 in gtk_widget_realize () from /usr/lib/libgtk-x11-2.0.so.0 #15 0x011af58f in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x01040946 in gtk_container_get_focus_hadjustment () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x01002aeb in gtk_bin_get_type () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x0103f08a in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x0104097f in gtk_container_get_focus_hadjustment () from /usr/lib/libgtk-x11-2.0.so.0 #20 0x0807470b in ephy_tab_map (widget=0x8e6be98) at ephy-tab.c:344 #21 0x002522d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #22 0x00246565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #23 0x00246b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #24 0x00254e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #25 0x00256820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #26 0x00256b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #27 0x011af530 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #28 0x010dfe1c in gtk_notebook_get_tab_label () from /usr/lib/libgtk-x11-2.0.so.0 #29 0x002522d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #30 0x00246565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #31 0x00246b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #32 0x00254e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #33 0x00256820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #34 0x00256b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #35 0x011af530 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #36 0x01040946 in gtk_container_get_focus_hadjustment () from /usr/lib/libgtk-x11-2.0.so.0 #37 0x01006218 in gtk_box_reorder_child () from /usr/lib/libgtk-x11-2.0.so.0 #38 0x0103f08a in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 #39 0x0104097f in gtk_container_get_focus_hadjustment () from /usr/lib/libgtk-x11-2.0.so.0 #40 0x002522d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #41 0x00246565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #42 0x00246b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #43 0x00254e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #44 0x00256820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #45 0x00256b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #46 0x011af530 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #47 0x011b8e25 in gtk_window_reshow_with_initial_size () from /usr/lib/libgtk-x11-2.0.so.0 #48 0x002522d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #49 0x00246565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #50 0x00246b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #51 0x00254e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #52 0x00256820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #53 0x00256b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #54 0x011af530 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 #55 0x011baf6e in gtk_window_get_position () from /usr/lib/libgtk-x11-2.0.so.0 #56 0x080807e6 in ephy_window_show (widget=0x8c32b48) at ephy-window.c:3256 #57 0x002522d3 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #58 0x00246565 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #59 0x00246b98 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #60 0x00254e39 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #61 0x00256820 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #62 0x00256b93 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #63 0x011afcc6 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0 #64 0x080737cb in ephy_shell_new_tab_full (shell=0x8c19ff8, parent_window=0x0, previous_tab=0x0, url=0x811e042 "", flags=) at ephy-shell.c:760 #65 0x0808966b in impl_ephy_automation_loadUrlWithStartupId ( _servant=0x8c287a4, url=0x811e042 "", fullscreen=0 '\0', open_in_existing_tab=0 '\0', open_in_new_tab=0 '\0', startup_id=4390363, ev=0xbfaedd74) at ephy-automation.c:108 #66 0x0809aeee in _ORBIT_skel_small_GNOME_EphyAutomation_loadUrlWithStartupId (_o_servant=0x8c287a4, _o_retval=0x0, _o_args=0xbfaedd00, _o_ctx=0x0, _o_ev=0xbfaedd74, _impl_loadUrlWithStartupId=0x8089570 ) at EphyAutomation-common.c:36 #67 0x002af8bd in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0 #68 0x080891ff in GNOME_EphyAutomation_loadUrlWithStartupId (_obj=0x8c28890, url=0x811e042 "", fullscreen=0 '\0', open_in_existing_tab=0 '\0', open_in_new_tab=0 '\0', startup_id=4390363, ev=0xbfaedd74) at EphyAutomation-stubs.c:52 #69 0x080732b2 in ephy_shell_startup (shell=0x8c19ff8, flags=0, user_time=4390363, args=0x0, string_arg=0x0, error=0xbfaeee54) at ephy-shell.c:337 #70 0x08072811 in main (argc=1, argv=0xbfaeef54) at ephy-main.c:294 Thread 2 (Thread -1217930320 (LWP 3289)): #0 0x00162402 in __kernel_vsyscall () No symbol table info available. #1 0x0446223c in poll () from /lib/libc.so.6 No symbol table info available. #2 0x039c23ac in PR_Poll () from /usr/lib/libnspr4.so No symbol table info available. #3 0x01b07eda in NSGetModule () from /usr/lib/mozilla-1.7.11/components/libnecko.so No symbol table info available. #4 0x01b08585 in NSGetModule () from /usr/lib/mozilla-1.7.11/components/libnecko.so No symbol table info available. #5 0x00d5b291 in nsThread::Main () from /usr/lib/mozilla-1.7.11/libxpcom.so No symbol table info available. #6 0x039c3c2d in PR_Select () from /usr/lib/libnspr4.so No symbol table info available. #7 0x00152b89 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #8 0x0446c21e in clone () from /lib/libc.so.6 No symbol table info available. Thread 1 (Thread -1208183120 (LWP 3288)): #0 0x00162402 in __kernel_vsyscall () No symbol table info available. #1 0x00157fcb in __waitpid_nocancel () from /lib/libpthread.so.0 No symbol table info available. #2 0x005a8c5d in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2.so.0 No symbol table info available. #3 0x00fa921f in nsProfileLock::FatalSignalHandler () from /usr/lib/mozilla-1.7.11/libgtkembedmoz.so No symbol table info available. #4 No symbol table info available. #5 0x00f9ddc9 in EmbedPrivate::Realize () from /usr/lib/mozilla-1.7.11/libgtkembedmoz.so No symbol table info available. #6 0x00f9c208 in gtk_moz_embed_go_back () from /usr/lib/mozilla-1.7.11/libgtkembedmoz.so No symbol table info available. #7 0x080b091a in mozilla_embed_realize (widget=0x8e6e118) at mozilla-embed.cpp:230 rv = From jspaleta at gmail.com Fri Aug 26 15:05:11 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 26 Aug 2005 11:05:11 -0400 Subject: epiphany problems in rawhide In-Reply-To: <1125068473.28834.24.camel@crux.rdu.redhat.com> References: <1125068473.28834.24.camel@crux.rdu.redhat.com> Message-ID: <604aa79105082608051ae67c27@mail.gmail.com> On 8/26/05, Jason Connor wrote: > This isn't a necessarily a 'development' issue, but I doubt that anyone > on the fedora list would have an insight and I'm using rawhide. May I suggest fedora-test-list for future issues you want to discuss with other rawhide users that you feel isn't necessarily a development issue. -jef From jconnor at redhat.com Fri Aug 26 15:14:08 2005 From: jconnor at redhat.com (Jason Connor) Date: Fri, 26 Aug 2005 11:14:08 -0400 Subject: epiphany problems in rawhide In-Reply-To: <604aa79105082608051ae67c27@mail.gmail.com> References: <1125068473.28834.24.camel@crux.rdu.redhat.com> <604aa79105082608051ae67c27@mail.gmail.com> Message-ID: <1125069248.28834.25.camel@crux.rdu.redhat.com> Thank subscribing now. I'll be sure to send my request there. On Fri, 2005-08-26 at 11:05 -0400, Jeff Spaleta wrote: > fedora-test-list -- Jason L. Connor Software Engineer, Red Hat Network 919.754.4013 gpg - 1024D/6A34521A From msalim at cs.indiana.edu Fri Aug 26 16:48:31 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Fri, 26 Aug 2005 11:48:31 -0500 Subject: xscreensaver Bug 166776 In-Reply-To: <1125045329.4469.11.camel@baythorne.infradead.org> References: <430E35F3.2040407@cs.indiana.edu> <1125045329.4469.11.camel@baythorne.infradead.org> Message-ID: <1125074911.2781.7.camel@salem> On Fri, 2005-08-26 at 09:35 +0100, David Woodhouse wrote: > On Thu, 2005-08-25 at 16:19 -0500, Michel Salim wrote: > > Has anyone else been bitten by this? > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166776 > > > > Changing most settings in xscreensaver-demo causes a buffer overflow. > > The FC4 xscreensaver 4.21 is not affected, but any Rawhide build within > > at least the past week exhibit this behaviour on my machine. > > I've certainly seen it recently but it could have been before 2005-08-19 > when Ray claims to have fixed it. I'll check. > Fixed in 4.22-9, nevermind. Guess that build took some time to reach mirrors. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From buildsys at redhat.com Fri Aug 26 17:24:58 2005 From: buildsys at redhat.com (Build System) Date: Fri, 26 Aug 2005 13:24:58 -0400 Subject: rawhide report: 20050826 changes Message-ID: <200508261724.j7QHOwkt005421@porkchop.devel.redhat.com> Updated Packages: am-utils-5:6.1.1-2 ------------------ * Thu Aug 25 2005 Peter Vrabec 6.1.1-2 - use generic linux/nfs_mount.h check * Fri Aug 19 2005 Peter Vrabec 6.1.1-1 - upgrade 6.1.1 * Wed Aug 17 2005 Peter Vrabec 6.0.9-13 - fix the regression introduced with (#143118) fix aspell-es-50:0.50-13 -------------------- * Thu Aug 25 2005 Ivana Varekova 50:0.50-13 - add castellano alias (bug 166286) eject-2.1.2-1 ------------- * Thu Aug 25 2005 Than Ngo 2.1.2-1 - update to 2.1.2 - drop several patches, which included in new upstream * Wed Aug 24 2005 Than Ngo 2.1.1-1 - update to 2.1.1 - remove eject-2.0.13-scsi.patch, which included in new upstream * Thu May 12 2005 Than Ngo 2.0.13-15 - add better translation for zh_TW #157519, thanks to Wei-Lun Chao evolution-data-server-1.3.8-4 ----------------------------- * Wed Aug 24 2005 David Malcolm - 1.3.8-4 - Remove -Werror-implicit-function-declaration from CFLAGS; this broke the configuration test for fast mutexes in the internal copy of libdb, and hence broke access to local addressbooks (#166742) - Introduce static_ldap macro; use it to link to static evolution-openldap library, containing NTLM support for LDAP binds (needed by Exchange support) hardlink-1:1.0-1.14 ------------------- * Fri Aug 26 2005 Dave Jones - Document hardlink command line options. (Ville Skytta) (#161738) hwdata-0.165-1 -------------- * Thu Aug 25 2005 Dan Williams - 0.165-1 - Add a bunch of Acer monitors iso-codes-0.47-1 ---------------- kernel-2.6.12-1.1511_FC5 ------------------------ * Thu Aug 25 2005 Dave Jones - 2.6.13-rc7-git1 * Thu Aug 25 2005 Dave Jones - FUTEX_WAKE_OP support. libselinux-1.25.4-1 ------------------- * Thu Aug 25 2005 Dan Walsh 1.25.4-1 - Update from NSA * Hid translation-related symbols entirely and ensured that raw functions have hidden definitions for internal use. * Allowed setting NULL via context_set* functions. * Allowed whitespace in MLS component of context. * Changed rpm_execcon to use translated functions to workaround lack of MLS level on upgraded systems. * Wed Aug 24 2005 Dan Walsh 1.25.3-2 - Allow set_comp on unset ranges ntp-4.2.0.a.20050816-1 ---------------------- * Thu Aug 25 2005 Jindrich Novy 4.2.0.a.20050816-1 - update to the latest stable 4.2.0.a.20050816 - drop upstreamed .gcc4, .vsnprintf patches - remove obsolete .autofoo patch - make patch numbering less chaotic - don't package backup for .droproot patch php-5.0.4-10.4 -------------- * Mon Aug 15 2005 Joe Orton 5.0.4-10.4 - pear: update to XML_RPC 1.4.0 (CAN-2005-2498, #165847) - use /etc/httpd/conf/magic for mime_magic (#163116) policycoreutils-1.25.7-1 ------------------------ * Thu Aug 25 2005 Dan Walsh 1.25.7-1 - Update to match NSA * Merged patch for fixfiles -C from Dan Walsh. scim-hangul-0.2.0-5.fc5 ----------------------- * Thu Aug 25 2005 Akira TAGOH - 0.2.0-5.fc5 - fixed the description of this package. (Ryo Dairiki) - scim-hangul-0.2.0-ignore-invisible-char.patch: applied to not commit any Hangul characters with the keys unrelated to Yetgeul. (#166138) selinux-policy-targeted-1.25.4-9 -------------------------------- * Thu Aug 25 2005 Dan Walsh 1.25.4-9 - Allow i18n_input to read homedirs - Remove i18n_input from targeted tanukiwrapper-0:3.1.1-4jpp_3fc ------------------------------ * Thu Aug 25 2005 Gary Benson - 0:3.1.1-4jpp_3fc - Use portable JPEG code (from Anthony Green). termcap-1:5.4-5 --------------- * Thu Aug 25 2005 Petr Raszyk 1:5.4-4 - resynchronize termcap <-> terminfo for xterm (#166702) tomcat5-0:5.0.30-8jpp_2fc ------------------------- * Thu Aug 25 2005 Gary Benson 0:5.0.30-8jpp_2fc - Disable build on ppc64 (#166657). - Disable webapps builds on ia64 (#163249) and s390x (#164985). * Wed Aug 24 2005 Gary Benson - Add a status command to the init script (from Jesus Rodriguez). - Silence warnings from recent versions of find (#151749). - Silence progress messages on shutdown. * Fri Jul 22 2005 Gary Benson - Remove workarounds for #163689. xscreensaver-1:4.22-10 ---------------------- * Thu Aug 25 2005 Ray Strode 1:4.22-10 - Move man pages to section 6 (bug 166441). Broken deps for i386 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 systemtap - 0.2.2-2.i386 requires libdw.so.1(ELFUTILS_0.111) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for s390 ---------------------------------------------------------- prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 Broken deps for x86_64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 systemtap - 0.2.2-2.x86_64 requires libdw.so.1(ELFUTILS_0.111)(64bit) dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 Broken deps for ppc64 ---------------------------------------------------------- firstboot - 1.3.45-1.noarch requires system-config-display system-config-mouse - 1.2.11-1.noarch requires pyxf86config evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 initscripts - 8.12-2.ia64 requires kernel >= 0:2.6.12 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 From piet at www.piet.net Fri Aug 26 21:22:10 2005 From: piet at www.piet.net (Piet Delaney) Date: Fri, 26 Aug 2005 14:22:10 -0700 Subject: lib qt missing in FC4 In-Reply-To: <430EC351.5050602@redhat.com> References: <1125040808.3669.14.camel@hammer.piet.net> <430EC351.5050602@redhat.com> Message-ID: <1125091331.31193.13.camel@hammer.piet.net> On Fri, 2005-08-26 at 12:52 +0530, Rahul Sundaram wrote: > Piet Delaney wrote: > > >Any reason lib qt isn't available in FC4? > > > >It's used by the kernel makefile with 'make xconfig'; > >seem odd not to provide it. > > > >-piet > > > > > > > You are looking for qt-devel make xconfig shows: /usr/bin/ld: cannot find -lqt shouldn't the error message be: /usr/bin/ld: cannot find -lqt-devel if it was looking for qt-devel? Kernel make file bug? Even if the kernel is looking for qt-devel shouldn't it be included in the std distribution? You might prefer/need doing a make xconfig so it's obviously an important component. Seems it should be installed in: /usr/lib/qt-3.3/lib and /usr/lib64/qt-3.3/lib files in /etc/ld.so.conf.d look fine. So what do 'we all' need to do to install qt-devel? -piet > > regards > Rahul > -- Piet Delaney Rocky Mountain Linux Lab From jam at zoidtechnologies.com Fri Aug 26 21:30:05 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Fri, 26 Aug 2005 17:30:05 -0400 Subject: lib qt missing in FC4 In-Reply-To: <1125091331.31193.13.camel@hammer.piet.net> References: <1125040808.3669.14.camel@hammer.piet.net> <430EC351.5050602@redhat.com> <1125091331.31193.13.camel@hammer.piet.net> Message-ID: <1125091805.12181.35.camel@eros.zoidtechnologies.com> On Fri, 2005-08-26 at 14:22 -0700, Piet Delaney wrote: > On Fri, 2005-08-26 at 12:52 +0530, Rahul Sundaram wrote: > > Piet Delaney wrote: > > > > >Any reason lib qt isn't available in FC4? > > > > > >It's used by the kernel makefile with 'make xconfig'; > > >seem odd not to provide it. > > > > > >-piet > > > > > > > > > > > You are looking for qt-devel > > make xconfig shows: > > /usr/bin/ld: cannot find -lqt > > shouldn't the error message be: > > /usr/bin/ld: cannot find -lqt-devel > > if it was looking for qt-devel? > Kernel make file bug? > no.. the *package* should be called "qt-devel", and it should have the "libqt" that the kernel makefile is looking for. try that. regards, J -------------- 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 wir-sind-cool.org Fri Aug 26 21:32:11 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 26 Aug 2005 23:32:11 +0200 Subject: lib qt missing in FC4 In-Reply-To: <1125091331.31193.13.camel@hammer.piet.net> References: <1125040808.3669.14.camel@hammer.piet.net> <430EC351.5050602@redhat.com> <1125091331.31193.13.camel@hammer.piet.net> Message-ID: <20050826233211.1a7b9954.fedora@wir-sind-cool.org> On Fri, 26 Aug 2005 14:22:10 -0700, Piet Delaney wrote: > On Fri, 2005-08-26 at 12:52 +0530, Rahul Sundaram wrote: > > Piet Delaney wrote: > > > > >Any reason lib qt isn't available in FC4? > > > > > >It's used by the kernel makefile with 'make xconfig'; > > >seem odd not to provide it. > > > > > >-piet > > > > > > > > > > > You are looking for qt-devel > > make xconfig shows: > > /usr/bin/ld: cannot find -lqt > > shouldn't the error message be: > > /usr/bin/ld: cannot find -lqt-devel > > if it was looking for qt-devel? > Kernel make file bug? Rest assured, you're chasing ghosts. ;) The Qt packages are called "qt" and "qt-devel". The former for run-time needed libraries. The latter for software development, compilation, etc. > Even if the kernel is looking for qt-devel shouldn't it > be included in the std distribution? You might prefer/need > doing a make xconfig so it's obviously an important component. > > Seems it should be installed in: > > /usr/lib/qt-3.3/lib > and > /usr/lib64/qt-3.3/lib > > files in /etc/ld.so.conf.d look fine. > > So what do 'we all' need to do to install qt-devel? Install the qt-devel package, then source /etc/profile.d/qt.sh and try again. . /etc/profile.d/qt.sh If it still doesn't work for you, are you on i386 or x86_64? What is in /etc/profile.d/qt.sh? From seandarcy2 at gmail.com Fri Aug 26 22:09:03 2005 From: seandarcy2 at gmail.com (sean) Date: Fri, 26 Aug 2005 18:09:03 -0400 Subject: why does yum want to upgrade koffice? In-Reply-To: <1125001643.13523.15.camel@localhost.localdomain> References: <1124809124.25024.10.camel@cutter> <430B6D6C.2080504@math.unl.edu> <1124823759.25024.37.camel@cutter> <430D1B7F.5010209@math.unl.edu> <1125001643.13523.15.camel@localhost.localdomain> Message-ID: Peter Jones wrote: > On Tue, 2005-08-23 at 10:44 -0400, sean wrote: > >>[root at amd64-3000 development]# rpm -qa | grep koffice >>koffice-filters-1.4.1-4 >>koffice-devel-1.4.1-4 >>koffice-core-1.4.1-4 >>koffice-kword-1.4.1-4 >> >>yum upgrade >>.......... >>Added 15 new packages, deleted 0 old in 1.83 seconds >>Resolving Dependencies >>--> Populating transaction set with selected packages. >>Please wait. >>---> Package koffice-kword.x86_64 0:1.4.1-4.fc4 set to be >>updated > > > On Thu, 2005-08-25 at 14:00 -0400, sean wrote: > > >>OK. But so what? Why does yum want to "upgrade" koffice? > > > Because "4" is less than ""4.fc4". Aha. Thanks. sean From mharris at redhat.com Fri Aug 26 22:48:55 2005 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 26 Aug 2005 18:48:55 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming Message-ID: <430F9C57.1070301@redhat.com> Overview: ~~~~~~~~ We have begun work on X.Org X11 modularization, and are in the process of packaging the video and input drivers. Upstream, each driver has its own individual tarball, which are available at: http://xorg.freedesktop.org/X11R7.0-RC0/driver One of the benefits of the modularized X.Org X11R7, is that it makes it much easier for us to provide individual driver updates without having to release the entire 150Mb monolithic X release. The ability for us to update a single driver, and release that single driver to users is an important thing for a modern OS, in particular for desktop systems. As such, we have decided to package each driver individually in its own src.rpm package. It has now come to the time where we must make a decision as to how the driver src.rpm packages will be named, so we can begin packaging them, and also let the installer team and other groups know what they're called. As such we are soliciting feedback from the Fedora community, including Red Hat developers and subsystem maintainers. Proposal: ~~~~~~~~ Here is my initial proposal for naming the src.rpms, along with brief rationale, and the real (or perceived) advantages and disadvantages: xorg-x11-driver-- The prefix of "xorg-x11" identifies the driver package as being an official part of the upstream X.Org project. This distinguishes the driver from one that might be provided by the "dri" project, the "gatos" project, or any other project. It makes it easier to substitute alternative driver packages that provide a driver of the same name. It also makes it clear to the user, the developer, and anyone else looking at the package, that the source code contained inside came from X.Org directly. It also makes it clearer where bug reports should be filed upstream. As such, I propose all driver packages start with the "xorg-x11-" prefix. The "driver" portion of the proposed name, indicates that it is a driver for the X server, much like "module" in kernel-module packages. It namespaces all drivers, so that they all appear together in directory listings, and are easy to group together from scripts using globs, etc. ie: # Install all of the xorg drivers: rpm -ivh xorg-x11-driver-*.rpm The "" attribute is either "video" or "input", as used in the upstream tarball names, and further namespaces things, so that all input drivers appear together, and all video drivers appear together. This makes it easy to handle all input drivers or all video drivers from a script as well. Finally, the driver field, is the official name of the driver from the upstream tarballs, which generally is the name of the driver binary that gets installed as well. Using this naming mechanism, I believe gives us the most flexibility with driver packages, and makes life a lot easier down the line as far as maintenance goes. It also makes the packages very obvious as to what their contents are. The only slight disadvantage to this naming scheme that comes to mind which someone might point out, is that the package names are semi-lengthy. I don't see this as a problem however, as all modern shells have filename completion, and it works quite well. The benefits of clarity of contents, directory listing grouping, CVS repository grouping, bugzilla grouping, etc., IMHO far outweigh any perceived disadvantages of lenthy names. Request for comments: ~~~~~~~~~~~~~~~~~~~~ Interested Fedora Core, Fedora Extras, or community developers who have an opinion about the X.Org modular package naming conventions, or who just want to provide feedback concerning the above proposal, are encouraged to respond to this RFC on or before Monday August 29th if possible. We look forward to hearing everyone's feedback, and incorporating the collective concious of the community into our decision making efforts. Thanks for your considerations. -- Mike A. Harris Red Hat Canada, Ltd. X Devel Team From mrsam at courier-mta.com Fri Aug 26 23:09:20 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 26 Aug 2005 19:09:20 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming References: <430F9C57.1070301@redhat.com> Message-ID: Mike A. Harris writes: > Finally, the driver field, is the official name of the > driver from the upstream tarballs, which generally is the > name of the driver binary that gets installed as well. I think it also make sense to subdivide into -. Looking at the existing drivers: such as "s3-virge", "s3-other"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zaitcev at redhat.com Sat Aug 27 00:53:56 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 26 Aug 2005 17:53:56 -0700 Subject: Gdk-WARNING In-Reply-To: References: <20050825130908.67841ae7.zaitcev@redhat.com> Message-ID: <20050826175356.09be93ec.zaitcev@redhat.com> On Thu, 25 Aug 2005 16:59:50 -0400, Ray Strode wrote: > > (gvim:8960): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > > (sylpheed:2518): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > it's a bug in the individual apps. See > http://bugzilla.gnome.org/show_bug.cgi?id=161520 > for more information. [zaitcev at lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep property_get [zaitcev at lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep G_MAXLONG This seems to be called from inside of a library, not from the application. I suppose I have to track it down now. The only way I see is to have a debuggable version of gtk and place a debugger breakpoint where the printf originates. What a hassle... -- Pete From mharris at redhat.com Sat Aug 27 02:24:08 2005 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 26 Aug 2005 22:24:08 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: References: <430F9C57.1070301@redhat.com> Message-ID: <430FCEC8.70900@redhat.com> Sam Varshavchik wrote: > Mike A. Harris writes: > >> Finally, the driver field, is the official name of the >> driver from the upstream tarballs, which generally is the >> name of the driver binary that gets installed as well. > > > I think it also make sense to subdivide into > -. Looking at the existing drivers: such as > "s3-virge", "s3-other"? Some of the drivers support more than one chipset however, so it would be inconsistent. "ati" driver is actually a driver wrapper which loads one of 3 chipset specific drivers: 'atimisc' for Mach64 and older legacy ATI hardware (including ISA), r128 for Rage 128 chipset, and "radeon" for the Radeon and FireGL line. The s3 or s3virge driver's both support more chipsets than their names might suggest. The "sis" driver up until recently supported just SiS hardware, but now supports XGI video hardware also, as the XGI hardware is a future generation of what the SiS hardware was. Likewise, the "cirrus" driver has 3 sub-drivers within one driver package. In some cases, more than one driver can support a given card, such as the "glide" and "voodoo" drivers - both of which support 3Dfx Voodoo I and II hardware. As such, trying to break the namespace down further doesn't seem technically possible, and I'm not sure we'd gain much by doing that. Thanks nonetheless for the feedback! Take care, TTYL From gajownik at fedora.pl Sat Aug 27 08:38:12 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sat, 27 Aug 2005 10:38:12 +0200 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <430F9C57.1070301@redhat.com> References: <430F9C57.1070301@redhat.com> Message-ID: <43102674.90901@fedora.pl> Dnia 08/27/2005 12:48 AM, U?ytkownik Mike A. Harris napisa?: Hi! > Proposal: > ~~~~~~~~ > Here is my initial proposal for naming the src.rpms, along with > brief rationale, and the real (or perceived) advantages and > disadvantages: > > xorg-x11-driver-- I don't have any rights to decide but this pattern looks very good to me :) I'm curious how do you want to pack other tarballs? When I first saw this ? http://xorg.freedesktop.org/X11R7.0-RC0/everything/ I was a bit shocked ;-O Do you plan to have each bz2 archive in its own src.rpm or make packages using this names ? http://xorg.freedesktop.org/X11R7.0-RC0/ For example: xorg-x11-app xorg-x11-data xorg-x11-doc xorg-x11-font xorg-x11-lib, etc. First solution gives more flexibility to the end user - (s)he can install only necessary pacakges. The only disadvantage of this proposal I can see right now may be upgrade process from FC4 to FC5. It may take some time to write proper Provides/Obsoletes in spec files so yum could handle upgrade without a problem. Regards, Dawid -- ^_* From mharris at redhat.com Sat Aug 27 10:10:18 2005 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 27 Aug 2005 06:10:18 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <43102674.90901@fedora.pl> References: <430F9C57.1070301@redhat.com> <43102674.90901@fedora.pl> Message-ID: <43103C0A.1090907@redhat.com> Dawid Gajownik wrote: > Dnia 08/27/2005 12:48 AM, U?ytkownik Mike A. Harris napisa?: > > Hi! > >> Proposal: >> ~~~~~~~~ >> Here is my initial proposal for naming the src.rpms, along with >> brief rationale, and the real (or perceived) advantages and >> disadvantages: >> >> xorg-x11-driver-- > > > I don't have any rights to decide but this pattern looks very good > to me :) > > I'm curious how do you want to pack other tarballs? When I first saw > this ? http://xorg.freedesktop.org/X11R7.0-RC0/everything/ I was a bit > shocked ;-O Yes, it looks a bit intimidating at first. ;o) It's been a long time coming however, and very highly welcomed by the overwhelming majority of the X development community. ;o) The monolith has lived a long life, as has Imake, but I don't think many people feel sad to see both of them go away. ;o) (technically "imake" itself is still provided for 3rd parties to use, although xorg modular no longer uses it) > Do you plan to have each bz2 archive in its own src.rpm or make > packages using this names ? http://xorg.freedesktop.org/X11R7.0-RC0/ > For example: > xorg-x11-app > xorg-x11-data > xorg-x11-doc > xorg-x11-font > xorg-x11-lib, etc. > > First solution gives more flexibility to the end user - (s)he can > install only necessary pacakges. The only disadvantage of this proposal > I can see right now may be upgrade process from FC4 to FC5. It may take > some time to write proper Provides/Obsoletes in spec files so yum could > handle upgrade without a problem. Stay tuned... I'll be posting more about X.Org modularization throughout the next few weeks. These questions and more will be answered probably on a public facing webpage somewhere once we work out the details, etc. Thanks for your feedback! From fedora at leemhuis.info Sat Aug 27 13:23:07 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 27 Aug 2005 15:23:07 +0200 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <430F9C57.1070301@redhat.com> References: <430F9C57.1070301@redhat.com> Message-ID: <1125148987.3351.21.camel@localhost.localdomain> Am Freitag, den 26.08.2005, 18:48 -0400 schrieb Mike A. Harris: >[...] > Proposal: > ~~~~~~~~ > Here is my initial proposal for naming the src.rpms, along with > brief rationale, and the real (or perceived) advantages and > disadvantages: > > xorg-x11-driver-- > >[...] > > The only slight disadvantage to this naming scheme that > comes to mind which someone might point out, is that the > package names are semi-lengthy. I don't see this as a > problem however, as all modern shells have filename completion, > and it works quite well. The benefits of clarity of > contents, directory listing grouping, CVS repository grouping, > bugzilla grouping, etc., IMHO far outweigh any perceived > disadvantages of lenthy names. Both yum (in its overview before the Transaction Summary and in some other places) and rpm (when used with "-ivh" ) have problems with names longer then ~23 characters (in yum the columns don't match in the overview; during the download the name is striped after ~18 chars; in the install-overview it is striped after around 30 chars. In rpm the name is striped after ~23). This is IMHO a minor problem cause the important part of the name is at the end. For example xorg-x11-driver-video-radeon is 28 characters long and you'll see this when installing: # rpm -ivh xorg-x11-driver-video-radeon-1-2.i386.rpm Preparing... ########################################### [100%] 1:xorg-x11-driver-video-rad########################################### [100%] Why not drop the x11. And/or use drv instead of driver and vid instead of video? For example: xorg-drv-vid-radeon or maybe better xorg-drv-video-radeon instead of xorg-x11-driver-video-radeon Just my 2 cent. Otherwise I agree with the proposal. -- Thorsten Leemhuis From skvidal at phy.duke.edu Sat Aug 27 13:29:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 27 Aug 2005 09:29:30 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <1125148987.3351.21.camel@localhost.localdomain> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> Message-ID: <1125149370.5423.6.camel@cutter> > Both yum (in its overview before the Transaction Summary and in some > other places) and rpm (when used with "-ivh" ) have problems with names > longer then ~23 characters (in yum the columns don't match in the > overview; during the download the name is striped after ~18 chars; in > the install-overview it is striped after around 30 chars. In rpm the > name is striped after ~23). just so you know - it's not a problem. it's not an oversight. We're intentionally truncating the output of the package name. Mostly to stay within an 80 character limit. -sv From fedora at leemhuis.info Sat Aug 27 13:49:21 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 27 Aug 2005 15:49:21 +0200 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <1125149370.5423.6.camel@cutter> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> Message-ID: <1125150561.3351.24.camel@localhost.localdomain> Am Samstag, den 27.08.2005, 09:29 -0400 schrieb seth vidal: > > Both yum (in its overview before the Transaction Summary and in some > > other places) and rpm (when used with "-ivh" ) have problems with names > > longer then ~23 characters (in yum the columns don't match in the > > overview; during the download the name is striped after ~18 chars; in > > the install-overview it is striped after around 30 chars. In rpm the > > name is striped after ~23). > > just so you know - it's not a problem. it's not an oversight. We're > intentionally truncating the output of the package name. Mostly to stay > within an 80 character limit. just so you know -- that was sure (at least to me -- yes, I should have mentioned that here) :) Sorry if that sounded like criticism on yum. I like it very much. -- Thorsten Leemhuis From skvidal at phy.duke.edu Sat Aug 27 13:57:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 27 Aug 2005 09:57:52 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <1125150561.3351.24.camel@localhost.localdomain> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> Message-ID: <1125151072.5423.11.camel@cutter> On Sat, 2005-08-27 at 15:49 +0200, Thorsten Leemhuis wrote: > Am Samstag, den 27.08.2005, 09:29 -0400 schrieb seth vidal: > > > Both yum (in its overview before the Transaction Summary and in some > > > other places) and rpm (when used with "-ivh" ) have problems with names > > > longer then ~23 characters (in yum the columns don't match in the > > > overview; during the download the name is striped after ~18 chars; in > > > the install-overview it is striped after around 30 chars. In rpm the > > > name is striped after ~23). > > > > just so you know - it's not a problem. it's not an oversight. We're > > intentionally truncating the output of the package name. Mostly to stay > > within an 80 character limit. > > just so you know -- that was sure (at least to me -- yes, I should have > mentioned that here) :) > > Sorry if that sounded like criticism on yum. I like it very much. I wasn't worried about criticism on yum - I get plenty of that - I just didn't want to see a bug opened by some well-intentioned person based on it. :) -sv From kyrre at solution-forge.net Sat Aug 27 15:56:18 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 27 Aug 2005 17:56:18 +0200 Subject: OT: yum truncating (was: Re: RFC: X.Org X11 modularization project - rpm package driver naming) In-Reply-To: <1125151072.5423.11.camel@cutter> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> Message-ID: <1125158178.3356.2.camel@localhost.localdomain> l?r, 27.08.2005 kl. 15.57 skrev seth vidal: > On Sat, 2005-08-27 at 15:49 +0200, Thorsten Leemhuis wrote: > > Am Samstag, den 27.08.2005, 09:29 -0400 schrieb seth vidal: > > > > Both yum (in its overview before the Transaction Summary and in some > > > > other places) and rpm (when used with "-ivh" ) have problems with names > > > > longer then ~23 characters (in yum the columns don't match in the > > > > overview; during the download the name is striped after ~18 chars; in > > > > the install-overview it is striped after around 30 chars. In rpm the > > > > name is striped after ~23). > > > > > > just so you know - it's not a problem. it's not an oversight. We're > > > intentionally truncating the output of the package name. Mostly to stay > > > within an 80 character limit. > > > > just so you know -- that was sure (at least to me -- yes, I should have > > mentioned that here) :) > > > > Sorry if that sounded like criticism on yum. I like it very much. > > I wasn't worried about criticism on yum - I get plenty of that - I just > didn't want to see a bug opened by some well-intentioned person based on > it. :) > > -sv > What about detecting terminal size (width) and adjusting output according to that (like less, top, etc. does)? From buildsys at redhat.com Sat Aug 27 16:04:31 2005 From: buildsys at redhat.com (Build System) Date: Sat, 27 Aug 2005 12:04:31 -0400 Subject: rawhide report: 20050827 changes Message-ID: <200508271604.j7RG4Vo1028499@porkchop.devel.redhat.com> Updated Packages: evince-0.4.0-1 -------------- * Fri Aug 26 2005 Marco Pesenti Gritti 0.4.0-1 - Update to 0.4.0 - No more need to remove ev-application-service.h evolution-2.3.8-3 ----------------- * Fri Aug 26 2005 David Malcolm - 2.3.8-3 - Added patch for #157074 (patch 804) * Fri Aug 26 2005 David Malcolm - 2.3.8-2 - Move -Werror-implicit-function-declaration from configuration to the make stage, to avoid breaking configuration tests. * Tue Aug 23 2005 David Malcolm - 2.3.8-1 - 2.3.8 - add -Werror-implicit-function-declaration to CFLAGS and a patch to fix the problems arising (patch 110) firefox-1.1-0.2.8.deerpark.alpha2 --------------------------------- * Sat Aug 27 2005 Christopher Aillon - 1.1-0.2.8.deerpark.alpha2 - Re-enable SVG, canvas, and system cairo. - Fix issue with typing in proxy preference panel gcc-4.0.1-11 ------------ * Sat Aug 27 2005 Jakub Jelinek 4.0.1-11 - update from CVS - PRs c++/19004, c++/20817, c++/22454, c++/23044, c++/23491, fortran/20363, libgcj/21020, libstdc++/23465, libstdc++/23550, middle-end/23517, target/20799, target/21571, target/23070, target/23404, tree-optimization/23426, tree-optimization/23546 - fix strength reduction (Richard Henderson, #166353, PR rtl-opt/23560) - allow string and memory builtins to overflow from one structure field into another one (#166707, PR rtl-optimization/23561) - fix stringbuf in_avail() (Benjamin Kosnik, #159408, IT#72781, PR libstdc++/21955) iproute-2.6.13-3 ---------------- * Fri Aug 26 2005 Radek Vokal 2.6.13-3 - added /sbin/cbq script and sample configuration files (#166301) kernel-2.6.12-1.1517_FC5 ------------------------ * Fri Aug 26 2005 Dave Jones - Add another bios rev to the "thinkpad that cant do c2/c3" list. (#165590) - Add another thinkpad to the radeon-pm list. (#166123) - Better identify local builds. (#159696) - Fix up some missing exported symbols. - Build network drivers for Xen0 kernel. libgsf-1.12.2-1 --------------- * Fri Aug 26 2005 Caolan McNamara 1.12.2-1 - bump to latest version mutt-5:1.4.2.1-3 ---------------- * Fri Aug 26 2005 Bill Nottingham 5:1.4.2.1-3 - add patch from 1.5 branch to fix base64 decoding (#166718) openoffice.org-1:1.9.125-4.2.0.fc5 ---------------------------------- * Tue Aug 23 2005 Caolan McNamara - 1:1.9.125-4 - add workspace.cmcfixes16.patch for export dialog problem - rh#166812# crash on keyboard customization save * Tue Aug 23 2005 Caolan McNamara - 1:1.9.125-3 - use only underlying toolkit startup notification - use proper nfslock fix - workspace.cmcfixes15.patch, no MathMLDTD or msfontextract foo - openoffice.org-1.9.125.oooXXXXX.bulletexport.vcl.patch * Mon Aug 22 2005 Caolan McNamara - 1:1.9.125-2 - rh#166432# add README to he_IL dictionary - rh#166290# print range not properly available in gnomeprintui - flr moves inhalt patch into javafilter workspace poppler-0.4.1-2 --------------- * Fri Aug 26 2005 Marco Pesenti Gritti - 0.4.1-2 - Rebuild * Fri Aug 26 2005 Marco Pesenti Gritti - 0.4.1-1 - Update to 0.4.1 rpm-4.4.2-4 ----------- * Fri Aug 26 2005 Paul Nasrat - 4.4.2-4 - Fix build with CFLAGS having --param - Fix for context verification in /tmp (#162037) * Wed Jul 27 2005 Paul Nasrat - 4.4.2-3 - popt minor version requires * Tue Jul 26 2005 Paul Nasrat - 4.4.2-2 - popt minor version bump - revert to perl.req/perl.prov for now star-1.5a65-1 ------------- * Fri Aug 26 2005 Peter Vrabec 1.5a65-1 - upgrade 1.5a65-1 made by Horst H. von Brand - Source URL changed, no homepage now - License changed from GPL to CDDL 1.0 - Define MAKEPROG=gmake like the Gmake.linux script does - Disable fat binary as per star/Makefile, update star-1.5-selinux.patch for the various *.mk files used in that case - Axe /usr/share/man/man1/match.1*, /usr/etc/default/rmt too - Explicit listing in %files, allow for compressed or plain manpages * Fri Aug 26 2005 Peter Vrabec - do not remove star_fat systemtap-0.3-2 --------------- * Fri Aug 26 2005 Frank Eigler - 0.3-2 - Rebuilt for devel * Tue Aug 16 2005 Frank Ch. Eigler - Bump version. * Wed Aug 03 2005 Martin Hunt - 0.2.2-1 - Add directory /var/cache/systemtap - Add stp_check to /usr/libexec/systemtap Broken deps for i386 ---------------------------------------------------------- dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for x86_64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 Broken deps for ia64 ---------------------------------------------------------- initscripts - 8.12-2.ia64 requires kernel >= 0:2.6.12 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 rgmanager - 1.9.31-3.ia64 requires ccs pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 Broken deps for ppc ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390 ---------------------------------------------------------- lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 Broken deps for ppc64 ---------------------------------------------------------- system-config-mouse - 1.2.11-1.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) firstboot - 1.3.45-1.noarch requires system-config-display system-config-keyboard - 1.2.6-2.noarch requires pyxf86config cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) From jspaleta at gmail.com Sat Aug 27 16:05:35 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 27 Aug 2005 12:05:35 -0400 Subject: OT: yum truncating (was: Re: RFC: X.Org X11 modularization project - rpm package driver naming) In-Reply-To: <1125158178.3356.2.camel@localhost.localdomain> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> Message-ID: <604aa791050827090520a06676@mail.gmail.com> On 8/27/05, Kyrre Ness Sjobak wrote: > What about detecting terminal size (width) and adjusting output > according to that (like less, top, etc. does)? while a fancy technical feature... thats going to help a few people. it doesn't really address the underlying issue. There are many many... many 80 column terminals in use. If package names continue to expand to 30 or 40 characters long.. this is a problem for anyone who is using one of those "standard" 80 column terminals. I think its perfectly fair for packagers to be aware of common hardware limitations like this and to try to keep the packagename strings down below a certain length as much as possible. There is a physical constraint here.. 80 columns is very much a defacto standard..even email clients understand that and attempt to respect that 79/80 column line limit. If packagenames inside this project need a 120 column terminal to uniquely identify and use.. thats a package naming policy problem. -jef From linux_4ever at yahoo.com Sat Aug 27 16:39:20 2005 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 27 Aug 2005 09:39:20 -0700 (PDT) Subject: rawhide eth0 not present Message-ID: <20050827163921.44813.qmail@web51502.mail.yahoo.com> Hi, I updated to rawhide from fc4 on Thursday and now I'm getting: Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization. [FAILED] This message is coming from the initscripts, what could be the problem? I've tried booting with old fc4 kernel - no change. The ethernet controller works fine under fc4. lspci shows a Ethernet controller RTL-8139/8139C/8139C+ (rev 10) Thanks, -Steve Grubb __________________________________ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From mike at plan99.net Sat Aug 27 18:11:45 2005 From: mike at plan99.net (Mike Hearn) Date: Sat, 27 Aug 2005 19:11:45 +0100 Subject: RFC: X.Org X11 modularization project - rpm package driver naming References: <430F9C57.1070301@redhat.com> Message-ID: On Fri, 26 Aug 2005 18:48:55 -0400, Mike A. Harris wrote: > One of the benefits of the modularized X.Org X11R7, is that it makes it > much easier for us to provide individual driver updates without having to > release the entire 150Mb monolithic X release. Why not merge in the SUSE support for patch RPMs into the Fedora rpm? That would solve the same problem. thanks -mike From ihok at hotmail.com Sat Aug 27 16:58:34 2005 From: ihok at hotmail.com (Jack Tanner) Date: Sat, 27 Aug 2005 12:58:34 -0400 Subject: OT: yum truncating In-Reply-To: <604aa791050827090520a06676@mail.gmail.com> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > below a certain length as much as possible. There is a physical > constraint here.. 80 columns is very much a defacto standard..even > email clients understand that and attempt to respect that 79/80 column > line limit. If packagenames inside this project need a 120 column > terminal to uniquely identify and use.. thats a package naming policy > problem. But long filenames are a fact of life. They're more descriptive, and people like to use them, hardware limitations be damned. > # rpm -ivh xorg-x11-driver-video-radeon-1-2.i386.rpm > Preparing... ########################################### [100%] > 1:xorg-x11-driver-video-rad########################################### [100%] So rpm makes a decision to display more hash signs than filename. That's nuts, isn't it? It could just as easily display something like this, where each hash stands for a 10% increment. # rpm -ivh xorg-x11-driver-video-radeon-1-2.i386.rpm Preparing... ########## [100%] 1:xorg-x11-driver-video-radeon-1-2.i386.rpm ########## [100%] If the hashes were so dear, you could have a display like this, which gives you much more room for the filename (over 70 chars). # rpm -ivh xorg-x11-driver-video-radeon-1-2.i386.rpm Preparing... ########## [100%] 1:xorg-x11-driver-video-radeon-1-2.i386.rpm ################################################################ [100%] Same for yum, I imagine. From kyrre at solution-forge.net Sat Aug 27 19:22:38 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 27 Aug 2005 21:22:38 +0200 Subject: OT: yum truncating (was: Re: RFC: X.Org X11 modularization project - rpm package driver naming) In-Reply-To: <604aa791050827090520a06676@mail.gmail.com> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> Message-ID: <1125170557.3356.8.camel@localhost.localdomain> l?r, 27.08.2005 kl. 18.05 skrev Jeff Spaleta: > On 8/27/05, Kyrre Ness Sjobak wrote: > > What about detecting terminal size (width) and adjusting output > > according to that (like less, top, etc. does)? > > > while a fancy technical feature... thats going to help a few people. > it doesn't really address the underlying issue. There are many many... > many 80 column terminals in use. If package names continue to expand > to 30 or 40 characters long.. this is a problem for anyone who is > using one of those "standard" 80 column terminals. I think its > perfectly fair for packagers to be aware of common hardware > limitations like this and to try to keep the packagename strings down > below a certain length as much as possible. There is a physical > constraint here.. 80 columns is very much a defacto standard..even > email clients understand that and attempt to respect that 79/80 column > line limit. If packagenames inside this project need a 120 column > terminal to uniquely identify and use.. thats a package naming policy > problem. > > -jef At least when you are sitting in a xterm, it would be nice :) Even if the real problem are "package names to long". Should i file a feature request for yum in bugzilla? Kyrre From sundaram at redhat.com Sat Aug 27 19:29:29 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 28 Aug 2005 00:59:29 +0530 Subject: OT: yum truncating In-Reply-To: <1125170557.3356.8.camel@localhost.localdomain> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> <1125170557.3356.8.camel@localhost.localdomain> Message-ID: <4310BF19.8070708@redhat.com> Hi >At least when you are sitting in a xterm, it would be nice :) Even if >the real problem are "package names to long". Should i file a feature >request for yum in bugzilla? > >Kyrre > > Is already there https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166166 regards Rahul From mlauterbach at mail.wtamu.edu Sat Aug 27 19:32:44 2005 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Sat, 27 Aug 2005 14:32:44 -0500 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: References: <430F9C57.1070301@redhat.com> Message-ID: <1125171164.16106.1.camel@mobilelinux.mattlauterbach.com> On Sat, 2005-08-27 at 19:11 +0100, Mike Hearn wrote: > On Fri, 26 Aug 2005 18:48:55 -0400, Mike A. Harris wrote: > > One of the benefits of the modularized X.Org X11R7, is that it makes it > > much easier for us to provide individual driver updates without having to > > release the entire 150Mb monolithic X release. > > Why not merge in the SUSE support for patch RPMs into the Fedora rpm? That > would solve the same problem. > For Fedora sure...but what about for Debian or any of the other non-RPM based distros? > thanks -mike > Matthew E. Lauterbach From sundaram at redhat.com Sat Aug 27 19:38:14 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 28 Aug 2005 01:08:14 +0530 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <1125171164.16106.1.camel@mobilelinux.mattlauterbach.com> References: <430F9C57.1070301@redhat.com> <1125171164.16106.1.camel@mobilelinux.mattlauterbach.com> Message-ID: <4310C126.4040204@redhat.com> Matthew E. Lauterbach wrote: >On Sat, 2005-08-27 at 19:11 +0100, Mike Hearn wrote: > > >>On Fri, 26 Aug 2005 18:48:55 -0400, Mike A. Harris wrote: >> >> >>>One of the benefits of the modularized X.Org X11R7, is that it makes it >>>much easier for us to provide individual driver updates without having to >>>release the entire 150Mb monolithic X release. >>> >>> >>Why not merge in the SUSE support for patch RPMs into the Fedora rpm? That >>would solve the same problem. >> >> >> >For Fedora sure...but what about for Debian or any of the other non-RPM >based distros? > This RFC and related discussion only applies to Fedora development. Other distributions using a different packaging system have to make their own decisions regards Rahul From mlauterbach at mail.wtamu.edu Sat Aug 27 20:47:19 2005 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Sat, 27 Aug 2005 15:47:19 -0500 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <4310C126.4040204@redhat.com> References: <430F9C57.1070301@redhat.com> <1125171164.16106.1.camel@mobilelinux.mattlauterbach.com> <4310C126.4040204@redhat.com> Message-ID: <1125175639.16106.8.camel@mobilelinux.mattlauterbach.com> On Sun, 2005-08-28 at 01:08 +0530, Rahul Sundaram wrote: > Matthew E. Lauterbach wrote: > >For Fedora sure...but what about for Debian or any of the other non-RPM > >based distros? > > > This RFC and related discussion only applies to Fedora development. > Other distributions using a different packaging system have to make > their own decisions > My bad. I thought it was less specifically about Fedora and more generally about X.Org. Re-reading the orginal post and a minute or two at freedesktop.org shows you to be correct. Matthew E. Lauterbach From jspaleta at gmail.com Sat Aug 27 22:20:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 27 Aug 2005 18:20:31 -0400 Subject: OT: yum truncating In-Reply-To: References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> Message-ID: <604aa7910508271520128ba085@mail.gmail.com> On 8/27/05, Jack Tanner wrote: > But long filenames are a fact of life. They're more descriptive, and > people like to use them, hardware limitations be damned. No, the facts of life involve birds and bees.. and Mrs. Garrett. -jef"You want _more_ descriptive... how about we encode every single tag into the packagename. You cant get more descriptive than that... vendor..packager...license...summary...all of it.. in the frelling packagename..for the sake of maximal descriptive power... and don't forget the actual "description" tag as well.. it'd be really ironic to leave out the tag dedicated to a verbose description in your effort to reach the ultimately descriptive packagename regardless of the costs to sanity and physical hardware limitations"spaleta From mihamina.rakotomandimby at etu.univ-orleans.fr Sun Aug 28 08:32:01 2005 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) Date: Sun, 28 Aug 2005 10:32:01 +0200 Subject: where to download the latest kernel src.rpm Message-ID: <1125217921.21016.3.camel@localhost.localdomain> Hi, I filed a bug about ACPI: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166413 As you see, it's sugested to use the latest kernel available, but I cannot see where to download it. For exaple, my usual mirror: ftp://ftp.univ-pau.fr/pub/mirrors/fedora/updates/4/SRPMS/ does not serve the thing. Any suggestion? -- Administration & Formation ? l'administration de serveurs d?di?s: http://www.google.fr/search?q=aspo+infogerance+serveur From davej at redhat.com Sun Aug 28 08:36:37 2005 From: davej at redhat.com (Dave Jones) Date: Sun, 28 Aug 2005 04:36:37 -0400 Subject: where to download the latest kernel src.rpm In-Reply-To: <1125217921.21016.3.camel@localhost.localdomain> References: <1125217921.21016.3.camel@localhost.localdomain> Message-ID: <20050828083637.GA24668@redhat.com> On Sun, Aug 28, 2005 at 10:32:01AM +0200, Rakotomandimby Mihamina wrote: > Hi, > > I filed a bug about ACPI: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166413 > > As you see, it's sugested to use the latest kernel available, but I > cannot see where to download it. For exaple, my usual mirror: > ftp://ftp.univ-pau.fr/pub/mirrors/fedora/updates/4/SRPMS/ > > does not serve the thing. That's the 'updates' repository, not updates-testing. look in updates/testing/4/ Dave From arjanv at redhat.com Sun Aug 28 08:39:56 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 28 Aug 2005 10:39:56 +0200 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: References: <430F9C57.1070301@redhat.com> Message-ID: <1125218397.3219.5.camel@laptopd505.fenrus.org> On Sat, 2005-08-27 at 19:11 +0100, Mike Hearn wrote: > On Fri, 26 Aug 2005 18:48:55 -0400, Mike A. Harris wrote: > > One of the benefits of the modularized X.Org X11R7, is that it makes it > > much easier for us to provide individual driver updates without having to > > release the entire 150Mb monolithic X release. > > Why not merge in the SUSE support for patch RPMs into the Fedora rpm? That > would solve the same problem. actually not really. What that solves is the download size for "small changes". It doesn't solve the build time. It doesn't solve the testing. It doesn't REALLY solve it either. The moment all components are on different release schedules (which is good; X was helt back for years due to unified schedules for all components together) you get a lot of churn on the whole... while it might be only a few highly maintained drivers and libs that churn. patchrpms are a nice hack to work around some of the download issues, but it's not a real solution; it doesn't encourage more frequent releases for real. -------------- 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 m.f.h at web.de Sun Aug 28 08:41:29 2005 From: m.f.h at web.de (Marcus Hartig) Date: Sun, 28 Aug 2005 10:41:29 +0200 Subject: where to download the latest kernel src.rpm In-Reply-To: <1125217921.21016.3.camel@localhost.localdomain> References: <1125217921.21016.3.camel@localhost.localdomain> Message-ID: <431178B9.9070304@web.de> Rakotomandimby Mihamina wrote: eg: http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/updates/testing/4/SRPMS/ kernel-2.6.12-1.1435_FC4.src.rpm Marcus -- www.marcush.de From m.f.h at web.de Sun Aug 28 09:04:20 2005 From: m.f.h at web.de (Marcus Hartig) Date: Sun, 28 Aug 2005 11:04:20 +0200 Subject: Firefox 1.1-0.2.8.deerpark.alpha2 with cairo now faster rendering? Message-ID: <43117E14.4030302@web.de> Hello, I try here the last 1.1-0.2.8.deerpark.alpha2 firefox. Runs fine, but some little things. - Closing tabs with loaded pages is slow - download dialog window opens very slow - preferences dialog (changing before a font) closes very slow + big/long webpages with many ads or flash are now very fast rendered and scrolling is very fast. :) Is this faster rendering from the new cairo in firefox, now again activated? I think the same goes for my loved gnome-terminal 2.11.2 which is now with transparent BG under gtk2+-2.8 so fast on the nautilus desktop, cool! Regards, Marcus -- www.marcush.de From rodd at clarkson.id.au Sun Aug 28 09:07:31 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sun, 28 Aug 2005 19:07:31 +1000 Subject: OT: yum truncating (was: Re: RFC: X.Org X11 modularization project - rpm package driver naming) In-Reply-To: <1125158178.3356.2.camel@localhost.localdomain> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> Message-ID: <1125220051.2966.1.camel@localhost.localdomain> On Sat, 2005-08-27 at 17:56 +0200, Kyrre Ness Sjobak wrote: > What about detecting terminal size (width) and adjusting output > according to that (like less, top, etc. does)? Why not just use two lines to display file names that are too long for a single line? Is it that big an issue. The only reason why I can think you might not do this is because it would make greping info hard, but if you've mangled the file name what difference does it make? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From m.f.h at web.de Sun Aug 28 09:18:01 2005 From: m.f.h at web.de (Marcus Hartig) Date: Sun, 28 Aug 2005 11:18:01 +0200 Subject: No mtrr with xorg-x11-6.8.2-45 Message-ID: <43118149.6080809@web.de> Hello, with the last xorg from rawhide the mtrr are not written for my GeForce 6800 Go mobile 256MB (Dell Inspiron 9300 Pentium M 750 2MB L2). I get only after booting in X from /proc/mtrr: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0xfeda0000 (4077MB), size= 128KB: write-through, count=1 Where is the video card? Should it not include something like: reg02: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1 which I have now manually echo?ed after reading the linear framebuffer address from the Xorg.0.log: .. (--) NVIDIA(0): Linear framebuffer at 0xC0000000 (--) NVIDIA(0): MMIO registers at 0xDD000000 .. Or is this our beloved newest nVidia closed source driver, which makes problems here? Then, shame on me... Regards, Marcus -- www.marcush.de From ihok at hotmail.com Sun Aug 28 15:35:52 2005 From: ihok at hotmail.com (Jack Tanner) Date: Sun, 28 Aug 2005 11:35:52 -0400 Subject: OT: yum truncating In-Reply-To: <604aa7910508271520128ba085@mail.gmail.com> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> <604aa7910508271520128ba085@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 8/27/05, Jack Tanner wrote: > >>But long filenames are a fact of life. They're more descriptive, and >>people like to use them, hardware limitations be damned. > > No, the facts of life involve birds and bees.. and Mrs. Garrett. Mrs Garrison, perhaps? Point taken. :) > -jef"You want _more_ descriptive... how about we encode every single > tag into the packagename. You cant get more descriptive than that... Let's not go to extremes. An 18 character limit or whatever is more than mildly reminicent of 8.3 DOS filenames. Surely there's a nice middle ground somewhere. On my FC4 box that's nowhere near a complete install of all the core packages, I get $ rpm -qa | wc -L 52 It'd be nice if rpm and yum could display 52 characters or so. From buildsys at redhat.com Sun Aug 28 16:00:40 2005 From: buildsys at redhat.com (Build System) Date: Sun, 28 Aug 2005 12:00:40 -0400 Subject: rawhide report: 20050828 changes Message-ID: <200508281600.j7SG0ecT010653@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.12-1.1519_FC5 ------------------------ * Sat Aug 27 2005 Dave Jones - 2.6.13-rc7-git2 * Sat Aug 27 2005 Dave Jones - Enabled voluntary preemption. kernel-2.6.12-1.1520_FC5 ------------------------ * Sat Aug 27 2005 Dave Jones - 2.6.13-rc7-git2 * Sat Aug 27 2005 Dave Jones - Enabled voluntary preemption. shadow-utils-2:4.0.12-1 ----------------------- * Sat Aug 27 2005 Peter Vrabec 2:4.0.12-1 - upgrade * Sat Aug 13 2005 Dan Walsh 2:4.0.11.1-5 - Change to use new selinux api for selinux_check_passwd_access * Tue Aug 09 2005 Peter Vrabec 2:4.0.11.1-4 - change the password last changed field in the shadow file when "usermod -p" is used (#164943) Broken deps for i386 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for x86_64 ---------------------------------------------------------- cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ia64 ---------------------------------------------------------- xorg-x11 - 6.8.2-45.ia64 requires kernel-drm = 0:4.3.0 pcmciautils - 007-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 initscripts - 8.12-2.ia64 requires kernel >= 0:2.6.12 lvm2 - 2.01.14-1.0.ia64 requires kernel >= 0:2.6 gnome-volume-manager - 1.3.1-1.ia64 requires kernel >= 0:2.6 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for s390 ---------------------------------------------------------- lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 Broken deps for ppc64 ---------------------------------------------------------- firstboot - 1.3.45-1.noarch requires system-config-display ppc64-utils - 0.7-9.ppc64 requires yaboot gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 From skvidal at phy.duke.edu Sun Aug 28 16:16:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 28 Aug 2005 12:16:30 -0400 Subject: OT: yum truncating In-Reply-To: References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> <604aa7910508271520128ba085@mail.gmail.com> Message-ID: <1125245791.7702.6.camel@cutter> > Let's not go to extremes. An 18 character limit or whatever is more than > mildly reminicent of 8.3 DOS filenames. Surely there's a nice middle > ground somewhere. No one is limiting the length of package names. It is just limiting the display of them DURING the transaction. Not before, not after just during. -sv From ihok at hotmail.com Sun Aug 28 16:19:33 2005 From: ihok at hotmail.com (Jack Tanner) Date: Sun, 28 Aug 2005 12:19:33 -0400 Subject: OT: yum truncating In-Reply-To: <1125245791.7702.6.camel@cutter> References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> <604aa7910508271520128ba085@mail.gmail.com> <1125245791.7702.6.camel@cutter> Message-ID: seth vidal wrote: > No one is limiting the length of package names. It is just limiting the > display of them DURING the transaction. > > Not before, not after > > just during. Right. So it's kinda tough to use the display during the transaction to figure distinguish between xorg-x11-driver-- and xorg-x11-driver--, when all you can see is xorg-x11-drive########. Same goes for some long-named ooo packages, etc. I realize this is a cosmetic thing, but since you clearly put a lot of work in to make a nice CLUI... From fedora at camperquake.de Sun Aug 28 16:32:47 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 28 Aug 2005 18:32:47 +0200 Subject: Firefox 1.1-0.2.8.deerpark.alpha2 with cairo now faster rendering? In-Reply-To: <43117E14.4030302@web.de> References: <43117E14.4030302@web.de> Message-ID: <20050828163247.GB13810@ryoko.camperquake.de> On Sun, Aug 28, 2005 at 11:04:20AM +0200, Marcus Hartig wrote: > - Closing tabs with loaded pages is slow Not noticable here. > - preferences dialog (changing before a font) closes very slow > + big/long webpages with many ads or flash are now very fast rendered > and scrolling is very fast. :) This seems faster indeed. The latest version seems far less crash happy, though. Has not crashed once today. From d.jacobfeuerborn at conversis.de Sun Aug 28 16:47:32 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 28 Aug 2005 18:47:32 +0200 Subject: rawhide report: 20050828 changes In-Reply-To: <200508281600.j7SG0ecT010653@porkchop.devel.redhat.com> References: <200508281600.j7SG0ecT010653@porkchop.devel.redhat.com> Message-ID: <4311EAA4.8080800@conversis.de> Build System wrote: > > > > Updated Packages: > > kernel-2.6.12-1.1519_FC5 > ------------------------ > * Sat Aug 27 2005 Dave Jones > - 2.6.13-rc7-git2 > > * Sat Aug 27 2005 Dave Jones > - Enabled voluntary preemption. Is the "Enabled voluntary preemption" bit referring to the work by Arjan van de Ven and Ingo Molnar mentioned on the LKML? (http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0377.html) Regards, Dennis From kyrre at solution-forge.net Sun Aug 28 16:55:06 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 28 Aug 2005 18:55:06 +0200 Subject: Firefox 1.1-0.2.8.deerpark.alpha2 with cairo now faster rendering? In-Reply-To: <43117E14.4030302@web.de> References: <43117E14.4030302@web.de> Message-ID: <1125248105.3358.14.camel@localhost.localdomain> s?n, 28.08.2005 kl. 11.04 skrev Marcus Hartig: > Hello, > > I try here the last 1.1-0.2.8.deerpark.alpha2 firefox. Runs fine, but > some little things. > > - Closing tabs with loaded pages is slow > - download dialog window opens very slow > - preferences dialog (changing before a font) closes very slow > + big/long webpages with many ads or flash are now very fast rendered > and scrolling is very fast. :) > > Is this faster rendering from the new cairo in firefox, now again > activated? > > I think the same goes for my loved gnome-terminal 2.11.2 which is now > with transparent BG under gtk2+-2.8 so fast on the nautilus desktop, cool! > > Regards, > Marcus > > -- > www.marcush.de And SVG is quite nice :) But - am i the only one who has firefox crash every time a dialog box pops up? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166498 Would be nice to have some feedback on this one... Kyrre From mike at plan99.net Sun Aug 28 17:26:12 2005 From: mike at plan99.net (Mike Hearn) Date: Sun, 28 Aug 2005 18:26:12 +0100 Subject: RFC: X.Org X11 modularization project - rpm package driver naming References: <430F9C57.1070301@redhat.com> <1125171164.16106.1.camel@mobilelinux.mattlauterbach.com> Message-ID: On Sat, 27 Aug 2005 14:32:44 -0500, Matthew E. Lauterbach wrote: >> Why not merge in the SUSE support for patch RPMs into the Fedora rpm? >> That would solve the same problem. >> > For Fedora sure...but what about for Debian or any of the other non-RPM > based distros? Oh, I'm not saying modularisation is bad in general, just that some other packages have the same issue like OpenOffice, so if effort is going to be put in for download time you might as well fix the core issue. And there's no reason Debian or any other distro can't implement patch packages either. But what Arjan said about build time, testing and so on makes sense I guess. I never thought about build time: I always assumed beehive was an enormous beast of a system that would eat an X server for breakfast :) thanks -mike From fdl at scottl.com Sun Aug 28 20:23:14 2005 From: fdl at scottl.com (fdl at scottl.com) Date: Sun, 28 Aug 2005 15:23:14 -0500 Subject: Adding interrupt handler to FC3 Message-ID: <200508282023.j7SKNbRZ017301@ms-smtp-03-eri0.texas.rr.com> Hello, I am trying to add my own interrupt handler to FC3. I have tried two methods of modifying the IDT, both of which work under most kernels I've tried (incl the 2.6.9 vanilla kernel) but fail under the FC3 kernel (2.6.9-1.667). I've also tried the FC3 kernel with the alternate security models off, and large memory support off, but I have the same problem. Although I haven't tried it yet personally, I've been told that some code I have working on the vanilla 2.6.9 kernel works fine under FC4. Method 1 is to just modify the IDT in place. This causes a segfault on FC3. Method 2 is to make a copy of the IDT, modify the copy, and then use lidt to change the IDT used by the processor to the copy. This causes an immediate reboot on FC3. Any pointers on what I might be doing wrong? What is the "correct" or "officially supported" way of adding an interrupt handler on FC3? Thanks for any pointers (or sample code :) From jspaleta at gmail.com Sun Aug 28 20:44:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 28 Aug 2005 16:44:04 -0400 Subject: OT: yum truncating In-Reply-To: References: <430F9C57.1070301@redhat.com> <1125148987.3351.21.camel@localhost.localdomain> <1125149370.5423.6.camel@cutter> <1125150561.3351.24.camel@localhost.localdomain> <1125151072.5423.11.camel@cutter> <1125158178.3356.2.camel@localhost.localdomain> <604aa791050827090520a06676@mail.gmail.com> <604aa7910508271520128ba085@mail.gmail.com> Message-ID: <604aa7910508281344281e7cb1@mail.gmail.com> On 8/28/05, Jack Tanner wrote: > $ rpm -qa | wc -L > 52 tsk tsk tsk... go back and do that with just the package name and not the name-version that rpm -q uses by default and exlude things like kernel-module packages where there is no established policy to follow with regard to naming. I do this on my system rpm -qa |grep -v kernel-module|wc -L -> 46 rpm -qa --qf "%{NAME}\n"|grep -v kernel-module|wc -L 32 Leaving the kernel-modules in and I get 60/41. I will reinterate that kernel-modules are not covered by Fedora Extras packaging guidelines. Since you have given up on talking about extremes, such as "damning physical constraints" I'll reiterate. Packaging naming is a matter of policy. If the important bits about a package are 20 or 30 characters deep into the name, that is very much a naming policy problem. There needs to be some thought into making sure the parts of the xorg component names that are unique live inside the first 20 or so characters. If you have polluted the first 20 characters with just a sequence of non-unique preface that corresponds to several packages thats a general readability problem. -jef From arjanv at redhat.com Sun Aug 28 20:44:17 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 28 Aug 2005 22:44:17 +0200 Subject: Adding interrupt handler to FC3 In-Reply-To: <200508282023.j7SKNbRZ017301@ms-smtp-03-eri0.texas.rr.com> References: <200508282023.j7SKNbRZ017301@ms-smtp-03-eri0.texas.rr.com> Message-ID: <1125261857.3219.27.camel@laptopd505.fenrus.org> On Sun, 2005-08-28 at 15:23 -0500, fdl at scottl.com wrote: > Hello, > > I am trying to add my own interrupt handler to FC3. I have tried two methods > of modifying the IDT, both of which work under most kernels I've tried (incl > the 2.6.9 vanilla kernel) but fail under the FC3 kernel (2.6.9-1.667). I've > also tried the FC3 kernel with the alternate security models off, and large > memory support off, but I have the same problem. Although I haven't tried it > yet personally, I've been told that some code I have working on the vanilla > 2.6.9 kernel works fine under FC4. > > Method 1 is to just modify the IDT in place. This causes a segfault on FC3. > > Method 2 is to make a copy of the IDT, modify the copy, and then use lidt to > change the IDT used by the processor to the copy. This causes an immediate > reboot on FC3. > > Any pointers on what I might be doing wrong? What is the "correct" or > "officially supported" way of adding an interrupt handler on FC3? the only way that'll work is to just use request_irq() in your kernel module. Anything else is such a gross hack that it won't ever work reliable. (for example, IDT's may well be per cpu, or read only memory) -------------- 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 fdl at scottl.com Sun Aug 28 21:09:12 2005 From: fdl at scottl.com (fdl at scottl.com) Date: Sun, 28 Aug 2005 16:09:12 -0500 Subject: Adding interrupt handler to FC3 In-Reply-To: <1125261857.3219.27.camel@laptopd505.fenrus.org> Message-ID: <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> Thanks for that info. I had seen that function, but it appears that on Intel the requested IRQ must be less than 16. I need to define multiple interrupt handlers, and there aren't enough slots <= 16. Any other ideas? There must be some way to write an interrupt that can be called by software that is about the range imposed by NR_IRQS. > the only way that'll work is to just use request_irq() in > your kernel module. Anything else is such a gross hack that > it won't ever work reliable. (for example, IDT's may well be > per cpu, or read only memory) From arjanv at redhat.com Sun Aug 28 21:20:54 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 28 Aug 2005 23:20:54 +0200 Subject: Adding interrupt handler to FC3 In-Reply-To: <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> References: <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> Message-ID: <1125264054.3219.32.camel@laptopd505.fenrus.org> On Sun, 2005-08-28 at 16:09 -0500, fdl at scottl.com wrote: > Thanks for that info. I had seen that function, but it appears that on Intel > the requested IRQ must be less than 16. that is not correct. > I need to define multiple interrupt > handlers, and there aren't enough slots <= 16. interrupts are shared anyway so you could register 200 for the same number > Any other ideas? There must > be some way to write an interrupt that can be called by software that is > about the range imposed by NR_IRQS. eh you don't want to userspace callable interrupt gate ? (eg via the int instruction) why??? -------------- 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 bgerst at didntduck.org Sun Aug 28 21:32:37 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Sun, 28 Aug 2005 17:32:37 -0400 Subject: Adding interrupt handler to FC3 In-Reply-To: <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> References: <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> Message-ID: <43122D75.1000104@didntduck.org> fdl at scottl.com wrote: > Thanks for that info. I had seen that function, but it appears that on Intel > the requested IRQ must be less than 16. I need to define multiple interrupt > handlers, and there aren't enough slots <= 16. Any other ideas? There must > be some way to write an interrupt that can be called by software that is > about the range imposed by NR_IRQS. What is it that you are trying to do? Why are you wanting to have software callable interrupts? Can't you make do with a normal system call (int 0x80)? -- Brian Gerst From alan at redhat.com Sun Aug 28 21:50:47 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 28 Aug 2005 17:50:47 -0400 Subject: Adding interrupt handler to FC3 In-Reply-To: <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> References: <1125261857.3219.27.camel@laptopd505.fenrus.org> <200508282109.j7SL9VlG029626@ms-smtp-04.texas.rr.com> Message-ID: <20050828215047.GB15548@devserv.devel.redhat.com> On Sun, Aug 28, 2005 at 04:09:12PM -0500, fdl at scottl.com wrote: > Thanks for that info. I had seen that function, but it appears that on Intel > the requested IRQ must be less than 16. I need to define multiple interrupt > handlers, and there aren't enough slots <= 16. Any other ideas? There must > be some way to write an interrupt that can be called by software that is > about the range imposed by NR_IRQS. The number of physical interrupts on an x86 platform depends on the bus and IRQ chip technology in use. It ranges from 8 (PC XT) to 16 (ISA PC, early PCI) to 240 (APIC using systems). The tasklet and related code then provide support for pure software event handlers or events pushed off from the physical IRQ From fdl at scottl.com Sun Aug 28 22:51:08 2005 From: fdl at scottl.com (fdl at scottl.com) Date: Sun, 28 Aug 2005 17:51:08 -0500 Subject: Adding interrupt handler to FC3 In-Reply-To: <43122D75.1000104@didntduck.org> Message-ID: <200508282251.j7SMpJlG001925@ms-smtp-04.texas.rr.com> Thanks everyone for the information. I am trying to implement a software callable interrupt so it can be called by user-mode code to indicate that certain events have occurred (it's part of an instrumentation package I'm working on). I don't want to add a syscall since there is other code on the system that is already monitoring int 0x80, and I don't want these instrumentation interrupts to be visible by the code already monitoring syscalls. Unless someone has a more specific suggestion, I will look into request_irq(). However, it appears that will require creation of a new device (so I can pass the devname and dev_id params), which I'd rather not do, since I'd rather that the instrumentation impacts/changes the system as little as possible. From pboy at barkhof.uni-bremen.de Mon Aug 29 01:05:35 2005 From: pboy at barkhof.uni-bremen.de (Peter Boy) Date: Mon, 29 Aug 2005 03:05:35 +0200 Subject: kernel problem: undefined symbol initPAnsiStrings Message-ID: <1125277536.5154.8.camel@littlePiet> With the kernel 2.6.11-1.35_FC3 and 2.6.12-1.1372_FC3 I can't use a program. Starting up it complains: undefined symbol: initPAnsiStrings There was no problem with all kernels before 2.6.11-1.35_FC3 2 questions: a) is there a chance to get initPAnsiStrings back in the next kernel release b) does someone know where I can get the kernel before 2.6.11-1.35_FC3 (I removed it accidentally because of space issues, don't even remember the version number)? The download servers and the mirrors I tried have just the actual version available. (It's my online banking program, would be quite nice to have it working in the not so far future :-) ) Thanks Peter From mharris at redhat.com Mon Aug 29 06:37:58 2005 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 29 Aug 2005 02:37:58 -0400 Subject: Attn developers: libdps and libdpstk now obsoleted by X.Org Foundation. Message-ID: <4312AD46.5080206@redhat.com> The libdps and libdpstk libraries have been deprecated for several releases of the X Window System now (approximately 2 years or more), and upstream X.Org has disabled them from being built in X11R7. Generally speaking, this is not a problem because there has never been an open source DPS server-side extension in the XFree86 or X.Org X servers[1], so the DPS functionality is generally not useful anyway, and is more or less unused - which is the primary reason it was deprecated upstream. This change should have very small effect overall on developers at large, however it is possible that some applications in Fedora Core, Fedora Extras, or elsewhere, might have optional DPS support, and might currently have it enabled by default still. Since DPS has been publically deprecated for several years now however, it is likely there are not many applications building with DPS support by default currently. Nonetheless, as a notice to all Fedora Core and Fedora Extras developers, and other rpm package maintainers out there, please check all of your rpm packages which link to X libraries, and examine them for build or runtime dependencies on libdps and libdpstk. If you find any such packages, have a look at their ./configure options to see if they have an option to disable DPS support. Normally this should be something like: ./configure --disable-dps Please update your packages as soon as possible to remove the dependency on DPS, as the DPS libraries will vanish soon in rawhide, once the modular X11R7 gets integrated into our development tree. If anyone has any questions or concerns about the obsolescence of the dps libraries, please subscribe to the xorg at lists.freedesktop.org mailing list where you may discuss any concerns to the relevant upstream X.Org developers. Thanks in advance. [1] The http://dps.sf.net project, was an OSS project to implement DPS support for the XFree86 server, however that code was never integrated into XFree86 nor X.Org sources, and has not to the best of my knowledge ever been shipped by many OS distributions (if any at all). The DPS project has long since been abandoned by it's primary developer, and has been dead for years now. From caillon at redhat.com Mon Aug 29 07:19:55 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 29 Aug 2005 03:19:55 -0400 Subject: Attn developers: libdps and libdpstk now obsoleted by X.Org Foundation. In-Reply-To: <4312AD46.5080206@redhat.com> References: <4312AD46.5080206@redhat.com> Message-ID: <4312B71B.3090605@redhat.com> Mike A. Harris wrote: > Please update your packages as soon as possible to remove the > dependency on DPS, as the DPS libraries will vanish soon in > rawhide, once the modular X11R7 gets integrated into our > development tree. This probably should have been posted to fedora-maintainers rather than here. Are there people on that list which aren't on fedora-devel? From fedora at camperquake.de Mon Aug 29 11:17:42 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 29 Aug 2005 13:17:42 +0200 Subject: Adding interrupt handler to FC3 In-Reply-To: <200508282251.j7SMpJlG001925@ms-smtp-04.texas.rr.com> References: <43122D75.1000104@didntduck.org> <200508282251.j7SMpJlG001925@ms-smtp-04.texas.rr.com> Message-ID: <20050829111742.GA22049@ryoko.camperquake.de> On Sun, Aug 28, 2005 at 05:51:08PM -0500, fdl at scottl.com wrote: > I am trying to implement a software callable interrupt so it can be called > by user-mode code to indicate that certain events have occurred (it's part > of an instrumentation package I'm working on). Somehow this reminds me of DOS-style programming... From aoliva at redhat.com Mon Aug 29 14:43:16 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Aug 2005 11:43:16 -0300 Subject: rawhide eth0 not present In-Reply-To: <20050827163921.44813.qmail@web51502.mail.yahoo.com> References: <20050827163921.44813.qmail@web51502.mail.yahoo.com> Message-ID: On Aug 27, 2005, Steve G wrote: > Bringing up interface eth0: Device eth0 does not seem to be present, delaying > initialization. [FAILED] > The ethernet controller works fine under fc4. lspci shows a Ethernet controller > RTL-8139/8139C/8139C+ (rev 10) Change 8139cp back to 8139too in /etc/modprobe.conf. Search for 8139cp in bugzilla and you'll find a bug to watch :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From msalim at cs.indiana.edu Mon Aug 29 15:07:19 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 29 Aug 2005 10:07:19 -0500 Subject: kernel-devel dependency Message-ID: <1125328039.7519.37.camel@salem> Should kernel-devel be made to depend on the same version of the kernel? I have kernel-devel installed, and every time a new kernel comes out the corresponding version of kernel-devel becomes installed as well - but the old package does not get uninstalled. Unless there is a specific reason why it is desirable to have kernel-devel-X installed when kernel-X is not, having the former Requires: the latter would make maintenance tidier, I think. Regards, - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From dstolte at arcor.de Mon Aug 29 15:26:40 2005 From: dstolte at arcor.de (D. Stolte) Date: Mon, 29 Aug 2005 17:26:40 +0200 Subject: kernel-devel dependency In-Reply-To: <1125328039.7519.37.camel@salem> References: <1125328039.7519.37.camel@salem> Message-ID: <43132930.6060007@arcor.de> Michel Alexandre Salim wrote: > Should kernel-devel be made to depend on the same version of the kernel? > I have kernel-devel installed, and every time a new kernel comes out the > corresponding version of kernel-devel becomes installed as well - but > the old package does not get uninstalled. > > Unless there is a specific reason why it is desirable to have > kernel-devel-X installed when kernel-X is not, having the former > Requires: the latter would make maintenance tidier, I think. > > Regards, > > - Michel > The kernel-devel package is needed for building external kernel modules. Perhaps you can just uninstall this package. /ds From buildsys at redhat.com Mon Aug 29 16:20:33 2005 From: buildsys at redhat.com (Build System) Date: Mon, 29 Aug 2005 12:20:33 -0400 Subject: rawhide report: 20050829 changes Message-ID: <200508291620.j7TGKX1l004364@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.13-1.1526_FC5 ------------------------ * Sun Aug 28 2005 Dave Jones - 2.6.13 final. m2crypto-0.15-1 --------------- * Mon Aug 29 2005 Miloslav Trmac - 0.15-1 - Update to m2crypto-0.15 - Drop bundled swig openoffice.org-1:1.9.126-1.2.0.fc5 ---------------------------------- * Sat Aug 27 2005 Caolan McNamara - 1:1.9.126-1 - next version - drop integrated workspace.gslpatches4.patch - build with FORTIFY_SOURCE * Fri Aug 26 2005 Caolan McNamara - 1:1.9.125-5 - parallel langpack installing * Thu Aug 25 2005 Caolan McNamara - 1:1.9.125-4 - add workspace.cmcfixes16.patch for export dialog problem - rh#166812# crash on keyboard customization save perl-3:5.8.7-0.1.fc5 -------------------- * Sun Aug 28 2005 Warren Togami - 3:5.8.7-0.1 - patch12 from Marius Feraru (#165907) TODO: patch11, patch26 and patch27 clash and need verification - Build without -DDEBUGGING (#156113) * Sun Aug 14 2005 Jose Pedro Oliveira - 3:5.8.7-0 - 5.8.7 - Dropped the CGI.pm update patches (patch25 and patch29). * Fri Aug 12 2005 Jose Pedro Oliveira - 3:5.8.6-17 - Don't remove the core modules: Filter::Util::Call, Filter::Simple, and Time::HiRes. - Obsoletes perl-{Filter,Filter-Simple,Time-HiRes}. spamassassin-3.1.0-0.rc2.fc5 ---------------------------- * Sun Aug 28 2005 Warren Togami - 3.1.0-0.rc2 - 3.1.0-rc2 Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for ppc ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ppc64 ---------------------------------------------------------- evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 firstboot - 1.3.45-1.noarch requires system-config-display evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-mouse - 1.2.11-1.noarch requires pyxf86config Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390 ---------------------------------------------------------- initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 From katzj at redhat.com Mon Aug 29 17:17:12 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 29 Aug 2005 13:17:12 -0400 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <430F9C57.1070301@redhat.com> References: <430F9C57.1070301@redhat.com> Message-ID: <1125335832.2576.35.camel@bree.local.net> On Fri, 2005-08-26 at 18:48 -0400, Mike A. Harris wrote: > As such, we have decided to package each driver individually in its > own src.rpm package. It has now come to the time where we must > make a decision as to how the driver src.rpm packages will be > named, so we can begin packaging them, and also let the installer > team and other groups know what they're called. As such we are > soliciting feedback from the Fedora community, including Red Hat > developers and subsystem maintainers. Hmm, packaging every driver separately is going to be a significant amount of work from the point of view of installer and comps maintenance. Both have hard-coded lists of packages that are going to have to be "regularly" updated. It also introduces some discrepancies on upgrade. Also, I don't even want to think about a driver split for whatever reason and the following fallout... "fun". > Proposal: > ~~~~~~~~ > Here is my initial proposal for naming the src.rpms, along with > brief rationale, and the real (or perceived) advantages and > disadvantages: > > xorg-x11-driver-- > > The prefix of "xorg-x11" identifies the driver package as being > an official part of the upstream X.Org project. This distinguishes > the driver from one that might be provided by the "dri" project, > the "gatos" project, or any other project. It makes it easier > to substitute alternative driver packages that provide a driver > of the same name. It also makes it clear to the user, the > developer, and anyone else looking at the package, that the source > code contained inside came from X.Org directly. It also makes > it clearer where bug reports should be filed upstream. As such, > I propose all driver packages start with the "xorg-x11-" prefix. The source doesn't come from X.org directly -- there's a pretty reasonable chance of there being some patches from us in there. And there's a lot to be said for brevity of package names for reasons alluded to in the off-topic portion of this thread ;) But, really, it'd be like naming every single package that comes from GNOME gnome-foo. And although there is some amount of that, I think that things are drastically better now :) > The "driver" portion of the proposed name, indicates that it is > a driver for the X server, much like "module" in kernel-module > packages. This feels a bit like overkill. Note that 'module' in kernel-module packages isn't at all accepted as definitely the way to go. Adding -driver just feels a lot like adding 7 characters with little gain. > Using this naming mechanism, I believe gives us the most > flexibility with driver packages, and makes life a lot easier > down the line as far as maintenance goes. It also makes the > packages very obvious as to what their contents are. Does it make it obvious? Although it may make the name of the driver module obvious, I'm not sure it actually makes things obvious as to what that's useful for. And sending users scrambling for the foobazbarlet driver is probably less than useful :-) Jeremy From ivazquez at ivazquez.net Mon Aug 29 18:44:50 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 29 Aug 2005 14:44:50 -0400 Subject: kernel-devel dependency In-Reply-To: <1125328039.7519.37.camel@salem> References: <1125328039.7519.37.camel@salem> Message-ID: <1125341091.28096.0.camel@ignacio.lan> On Mon, 2005-08-29 at 10:07 -0500, Michel Alexandre Salim wrote: > Unless there is a specific reason why it is desirable to have > kernel-devel-X installed when kernel-X is not... So that you can build modules for kernels you don't have installed on your machine. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 lamont at gurulabs.com Mon Aug 29 19:30:23 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 29 Aug 2005 13:30:23 -0600 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <1125335832.2576.35.camel@bree.local.net> References: <430F9C57.1070301@redhat.com> <1125335832.2576.35.camel@bree.local.net> Message-ID: <200508291330.28438.lamont@gurulabs.com> On Monday 29 August 2005 11:17am, Jeremy Katz wrote: > On Fri, 2005-08-26 at 18:48 -0400, Mike A. Harris wrote: > > As such, we have decided to package each driver individually in its > > own src.rpm package. It has now come to the time where we must > > make a decision as to how the driver src.rpm packages will be > > named, so we can begin packaging them, and also let the installer > > team and other groups know what they're called. As such we are > > soliciting feedback from the Fedora community, including Red Hat > > developers and subsystem maintainers. > > Hmm, packaging every driver separately is going to be a significant > amount of work from the point of view of installer and comps > maintenance. Both have hard-coded lists of packages that are going to > have to be "regularly" updated. It also introduces some discrepancies > on upgrade. Also, I don't even want to think about a driver split for > whatever reason and the following fallout... "fun". Why would you have to make changes to comps for new driver package sets? If each driver is in it's own package (or maybe some are grouped together into a single package, if it makes sense to do so, of course), then all the installer has to do is select the driver package(s) that support(s) the detected video card (for example) and have those driver packages depend on the core x11 package(s)...yum will resolve the rest. I guess the next question is,"How do we handle driver selection during install and how does that relate to the X11 component group?" Is manual driver selection something we want to give "Joe User" the opportunity to mess up? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Mon Aug 29 19:45:55 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 29 Aug 2005 15:45:55 -0400 Subject: no ia64 kernel In-Reply-To: <431306C8.1040807@redhat.com> References: <431306C8.1040807@redhat.com> Message-ID: <20050829194555.GB26810@redhat.com> On Mon, Aug 29, 2005 at 08:59:52AM -0400, Prarit Bhargava wrote: > Looks like the ia64 kernel has been turned off again ;) The ia64 build boxes were a little flaky lsat week, so I turned off ia64 so we could get something built at all. That situation seems to have resolved itself. > It seems to compile and boot on my systems -- could we get that turned > back on? I pushed one through late last night. (2.6.13-1.1526) I guess it just missed the rawhide push cut-off. Dave From fedora-devel at tlarson.com Mon Aug 29 20:07:40 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Mon, 29 Aug 2005 14:07:40 -0600 Subject: kernel-devel dependency In-Reply-To: <1125328039.7519.37.camel@salem> References: <1125328039.7519.37.camel@salem> Message-ID: <43136B0C.9010206@tlarson.com> Michel Alexandre Salim wrote: > Should kernel-devel be made to depend on the same version of the kernel? > I have kernel-devel installed, and every time a new kernel comes out the > corresponding version of kernel-devel becomes installed as well - but > the old package does not get uninstalled. > > Unless there is a specific reason why it is desirable to have > kernel-devel-X installed when kernel-X is not, having the former > Requires: the latter would make maintenance tidier, I think. > > Regards, > > - Michel > This sounds like a job for the pkgsToInstallNotUpdate option in up2date. I don't know the equivalent for yum. From skvidal at phy.duke.edu Mon Aug 29 20:14:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 29 Aug 2005 16:14:36 -0400 Subject: kernel-devel dependency In-Reply-To: <43136B0C.9010206@tlarson.com> References: <1125328039.7519.37.camel@salem> <43136B0C.9010206@tlarson.com> Message-ID: <1125346476.28267.49.camel@cutter> On Mon, 2005-08-29 at 14:07 -0600, Tyler Larson wrote: > Michel Alexandre Salim wrote: > > Should kernel-devel be made to depend on the same version of the kernel? > > I have kernel-devel installed, and every time a new kernel comes out the > > corresponding version of kernel-devel becomes installed as well - but > > the old package does not get uninstalled. > > > > Unless there is a specific reason why it is desirable to have > > kernel-devel-X installed when kernel-X is not, having the former > > Requires: the latter would make maintenance tidier, I think. > > > > Regards, > > > > - Michel > > > > This sounds like a job for the pkgsToInstallNotUpdate option in up2date. I > don't know the equivalent for yum. it's the default setting in yum and it is named 'installonlypkgs'. yum will watch for kernel packages and try to treat them correctly. -sv From msalim at cs.indiana.edu Mon Aug 29 20:17:36 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 29 Aug 2005 15:17:36 -0500 Subject: kernel-devel dependency In-Reply-To: <43132930.6060007@arcor.de> References: <1125328039.7519.37.camel@salem> <43132930.6060007@arcor.de> Message-ID: <1125346656.2761.2.camel@salem> On Mon, 2005-08-29 at 17:26 +0200, D. Stolte wrote: > Michel Alexandre Salim wrote: > > Should kernel-devel be made to depend on the same version of the kernel? > > I have kernel-devel installed, and every time a new kernel comes out the > > corresponding version of kernel-devel becomes installed as well - but > > the old package does not get uninstalled. > > > > Unless there is a specific reason why it is desirable to have > > kernel-devel-X installed when kernel-X is not, having the former > > Requires: the latter would make maintenance tidier, I think. > > > > Regards, > > > > - Michel > > > The kernel-devel package is needed for building external kernel modules. > Perhaps you can just uninstall this package. > Yes, the question is whether it ever makes sense to have kernel-devel-X installed when the kernel package itself is of version Y. Once I'm sure a new kernel is working, I like just to be able to call 'yum remove kernel-oldversion' and have kernel-module-*-oldversion and kernel-devel-oldversion removed through dependencies. - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From jos at xos.nl Mon Aug 29 20:23:52 2005 From: jos at xos.nl (Jos Vos) Date: Mon, 29 Aug 2005 22:23:52 +0200 Subject: kernel-devel dependency In-Reply-To: <1125346656.2761.2.camel@salem>; from msalim@cs.indiana.edu on Mon, Aug 29, 2005 at 03:17:36PM -0500 References: <1125328039.7519.37.camel@salem> <43132930.6060007@arcor.de> <1125346656.2761.2.camel@salem> Message-ID: <20050829222352.B31270@xos037.xos.nl> On Mon, Aug 29, 2005 at 03:17:36PM -0500, Michel Alexandre Salim wrote: > Yes, the question is whether it ever makes sense to have kernel-devel-X > installed when the kernel package itself is of version Y. Yes, it does, of you want to generate kernel modules for another version (or variant, like smp) than your running kernel. But I agree (if I parsed the original comment correctly) that kernel-devel-* should probably not be installed i.s.o. upgraded like done with kernel or kernel-module packages. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora-devel at tlarson.com Mon Aug 29 20:49:28 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Mon, 29 Aug 2005 14:49:28 -0600 Subject: kernel-devel dependency In-Reply-To: <1125346656.2761.2.camel@salem> References: <1125328039.7519.37.camel@salem> <43132930.6060007@arcor.de> <1125346656.2761.2.camel@salem> Message-ID: <431374D8.8060505@tlarson.com> Michel Alexandre Salim wrote: > > Yes, the question is whether it ever makes sense to have kernel-devel-X > installed when the kernel package itself is of version Y. > > Once I'm sure a new kernel is working, I like just to be able to call > 'yum remove kernel-oldversion' and have kernel-module-*-oldversion and > kernel-devel-oldversion removed through dependencies. > > - Michel > > No. Not a good idea. As a general rule, you should limit your dependency list to the software that the package actually depends on. Violating this rule creates far more problems than it solves. A user wishing to install a kernel-devel package shouldn't be forced to also install the corresponding kernel package--especially since there is no actual dependency there. The question isn't, "would someone want to install the -devel without the kernel," the proper question is, "should someone have to install the kernel in order to install the -devel." If typing two commands instead of just one is really getting to you, put the following in your bashrc: function remove_kernel() { rpm -e kernel-$1 kernel-devel-$1 ; } Then you can just type "remove_kernel " and it will remove both at the same time! From msalim at cs.indiana.edu Mon Aug 29 23:16:06 2005 From: msalim at cs.indiana.edu (Michel Alexandre Salim) Date: Mon, 29 Aug 2005 18:16:06 -0500 Subject: kernel-devel dependency In-Reply-To: <431374D8.8060505@tlarson.com> References: <1125328039.7519.37.camel@salem> <43132930.6060007@arcor.de> <1125346656.2761.2.camel@salem> <431374D8.8060505@tlarson.com> Message-ID: <1125357367.10357.13.camel@salem> On Mon, 2005-08-29 at 14:49 -0600, Tyler Larson wrote: > > Once I'm sure a new kernel is working, I like just to be able to call > > 'yum remove kernel-oldversion' and have kernel-module-*-oldversion and > > kernel-devel-oldversion removed through dependencies. > No. Not a good idea. As a general rule, you should limit your dependency list > to the software that the package actually depends on. Violating this rule > creates far more problems than it solves. > > A user wishing to install a kernel-devel package shouldn't be forced to also > install the corresponding kernel package--especially since there is no actual > dependency there. The question isn't, "would someone want to install the > -devel without the kernel," the proper question is, "should someone have to > install the kernel in order to install the -devel." > Fair enough. Thanks for the explanation. > > If typing two commands instead of just one is really getting to you, put the > following in your bashrc: > > function remove_kernel() { rpm -e kernel-$1 kernel-devel-$1 ; } > > Then you can just type "remove_kernel " and it will remove both at > the same time! > That gave me an idea; my current script removes all _other_ kernel-devel versions apart from the argument passed (bless basename and tab-completion for making this fast too). The other alternative is to only install kernel-devel when needed, but this is more risky as I depend on ndiswrapper to get online half the time. Thanks, - Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: not available URL: From i.pilcher at comcast.net Tue Aug 30 00:32:38 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 29 Aug 2005 19:32:38 -0500 Subject: RFC: X.Org X11 modularization project - rpm package driver naming In-Reply-To: <200508291330.28438.lamont@gurulabs.com> References: <430F9C57.1070301@redhat.com> <1125335832.2576.35.camel@bree.local.net> <200508291330.28438.lamont@gurulabs.com> Message-ID: Lamont R. Peterson wrote: > I guess the next question is,"How do we handle driver selection during install > and how does that relate to the X11 component group?" Is manual driver > selection something we want to give "Joe User" the opportunity to mess up? Absolutely! If you don't give "Joe User" the power to override the automatically selected driver, you're automatic selection code has to be 100% perfect. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From alexl at redhat.com Tue Aug 30 07:24:20 2005 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 30 Aug 2005 09:24:20 +0200 Subject: Gdk-WARNING In-Reply-To: <20050826175356.09be93ec.zaitcev@redhat.com> References: <20050825130908.67841ae7.zaitcev@redhat.com> <20050826175356.09be93ec.zaitcev@redhat.com> Message-ID: <1125386660.3811.60.camel@greebo> On Fri, 2005-08-26 at 17:53 -0700, Pete Zaitcev wrote: > On Thu, 25 Aug 2005 16:59:50 -0400, Ray Strode wrote: > > > > (gvim:8960): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > > > (sylpheed:2518): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > > it's a bug in the individual apps. See > > http://bugzilla.gnome.org/show_bug.cgi?id=161520 > > for more information. > > [zaitcev at lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep property_get > [zaitcev at lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep G_MAXLONG > > This seems to be called from inside of a library, not from the > application. I suppose I have to track it down now. The only way I see > is to have a debuggable version of gtk and place a debugger breakpoint > where the printf originates. What a hassle... "sylpheed --g-fatal-warnings" in a debugger might let you find the place easier. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an all-American albino gentleman spy on a search for his missing sister. She's a wealthy belly-dancing politician from aristocratic European stock. They fight crime! From g.hollestelle at gmail.com Tue Aug 30 08:45:49 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Tue, 30 Aug 2005 10:45:49 +0200 Subject: kernel-devel dependency In-Reply-To: <1125346656.2761.2.camel@salem> References: <1125328039.7519.37.camel@salem> <43132930.6060007@arcor.de> <1125346656.2761.2.camel@salem> Message-ID: <95da2d2905083001454eff9ba@mail.gmail.com> On 8/29/05, Michel Alexandre Salim wrote: > Once I'm sure a new kernel is working, I like just to be able to call > 'yum remove kernel-oldversion' and have kernel-module-*-oldversion and > kernel-devel-oldversion removed through dependencies. No need to remove it like this just install yum-utlis from extras and use package-cleanup it has an option --oldkernels to remove old kernels and associated kernel-devel packages. Greets, Gijs From mclasen at redhat.com Tue Aug 30 13:35:18 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 30 Aug 2005 09:35:18 -0400 Subject: Gdk-WARNING In-Reply-To: <1125386660.3811.60.camel@greebo> References: <20050825130908.67841ae7.zaitcev@redhat.com> <20050826175356.09be93ec.zaitcev@redhat.com> <1125386660.3811.60.camel@greebo> Message-ID: <1125408918.6519.26.camel@golem.boston.redhat.com> On Tue, 2005-08-30 at 09:24 +0200, Alexander Larsson wrote: > On Fri, 2005-08-26 at 17:53 -0700, Pete Zaitcev wrote: > > On Thu, 25 Aug 2005 16:59:50 -0400, Ray Strode wrote: > > > > > > (gvim:8960): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > > > > (sylpheed:2518): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?) > > > it's a bug in the individual apps. See > > > http://bugzilla.gnome.org/show_bug.cgi?id=161520 > > > for more information. > > > > [zaitcev at lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep property_get > > [zaitcev at lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep G_MAXLONG > > > > This seems to be called from inside of a library, not from the > > application. I suppose I have to track it down now. The only way I see > > is to have a debuggable version of gtk and place a debugger breakpoint > > where the printf originates. What a hassle... > > "sylpheed --g-fatal-warnings" in a debugger might let you find the place > easier. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's an all-American albino gentleman spy on a search for his missing sister. > She's a wealthy belly-dancing politician from aristocratic European stock. > They fight crime! > GTK+ 2.8.3 does no longer produce this warning. It should appear in rawhide today, so if you want to find the place, better be quick... From linux_4ever at yahoo.com Tue Aug 30 14:33:48 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 30 Aug 2005 07:33:48 -0700 (PDT) Subject: rawhide eth0 not present In-Reply-To: Message-ID: <20050830143348.32532.qmail@web51508.mail.yahoo.com> >> Bringing up interface eth0: Device eth0 does not seem to be present, delaying >> initialization. [FAILED] > >> The ethernet controller works fine under fc4. lspci shows a Ethernet controller >> RTL-8139/8139C/8139C+ (rev 10) > >Change 8139cp back to 8139too in /etc/modprobe.conf. I did, no real effect. And something keeps changing it to 8139cp. I also deleted HWADDR out of ifcfg-eth0. Still, rawhide does not detect eth0 being present - even though fc4 did. I tried a fc3 live CD and it properly inits the ethernet card...so it seems we went backawards. Is there any information that I can gather to help sort this out? >Search for 8139cp in bugzilla and you'll find a bug to watch :-) I assume you mean bz 157783. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From buildsys at redhat.com Tue Aug 30 16:05:13 2005 From: buildsys at redhat.com (Build System) Date: Tue, 30 Aug 2005 12:05:13 -0400 Subject: rawhide report: 20050830 changes Message-ID: <200508301605.j7UG5D9X024864@porkchop.devel.redhat.com> Updated Packages: anthy-6829-1 ------------ * Tue Aug 30 2005 Akira TAGOH - 6829-1 - New upstream snapshot release. bzip2-1.0.3-1 ------------- * Mon Aug 29 2005 Ivana Varekova 1.0.3-1 - 1.0.3 - add NULL-ptr-check patch (patch author: Mihai Limbasan 1.25.12-2 - Rebuild to get latest libsepol cyrus-sasl-2.1.21-2 ------------------- * Mon Aug 29 2005 Nalin Dahyabhai 2.1.21-2 - move the ANONYMOUS mech plugin to the -lib subpackage so that multilib systems can use it without installing the main package - build the static libraries without sql auxprop support * Mon Aug 29 2005 Nalin Dahyabhai 2.1.21-1 - update to 2.1.21 - turn off compilation of libsasl v1 (finally) - explicitly disable sqlite to avoid the build warning - change the default mechanism which is set for saslauthd from "shadow" to "pam" (#159194) - split the shared library up from saslauthd so that multilib systems don't have to pull in every dependency of saslauthd for the compat arch (#166749) dhcp-11:3.0.3-4 --------------- * Mon Aug 29 2005 Jason Vas Dias - 11:3.0.3-4 - fix bug 166926: make dhclient-script handle interface-mtu option make dhclient-script support /etc/dhclient{,-$IF}-{up,down}-hooks scripts to allow easy customization to support other non-default DHCP options - documented in 'man 8 dhclient-script' . - handle the 'time-offset' DHCP option, requested by default. epiphany-1.7.6-1 ---------------- * Mon Aug 29 2005 Christopher Aillon - 1.7.6-1 - Update to 1.7.6 glibc-2.3.90-11 --------------- * Mon Aug 29 2005 Jakub Jelinek 2.3.90-11 - FUTEX_WAKE_OP support to speed up pthread_cond_signal gtk2-2.8.3-1 ------------ * Mon Aug 29 2005 Matthias Clasen 2.8.3-1 - Newer upstream version libselinux-1.25.5-1 ------------------- * Mon Aug 29 2005 Dan Walsh 1.25.5-1 - Update from NSA * Remove special definition for context_range_set; use common code. libsepol-1.7.22-1 ----------------- * Mon Aug 29 2005 Dan Walsh 1.7.22-1 - Upgrade to latest from NSA * Merged fix for memory leak in sepol_context_to_sid from Jason Tang (Tresys). * Merged fixes for resource leaks on error paths and change to scope_destroy from Joshua Brindle (Tresys). mc-1:4.6.1a-0.13 ---------------- * Mon Aug 29 2005 Jindrich Novy 4.6.1a-0.13 - don't hang when ftpfs connection times out - Hans de Goede (#166976) - fix extension file to better fit FC (xpdf->evince, lynx->links) perl-Archive-Zip-1.16-1 ----------------------- * Mon Jul 11 2005 Jose Pedro Oliveira - 1.16-1 - Update to 1.16. perl-DBD-MySQL-3.0002-1 ----------------------- * Mon Jul 11 2005 Jose Pedro Oliveira - 3.0002-1 - Update to 3.0002. quagga-0:0.98.5-2 ----------------- * Mon Aug 29 2005 Jay Fenlason 0.98.5-2 - New upstream version. selinux-policy-targeted-1.25.4-11 --------------------------------- * Mon Aug 29 2005 Dan Walsh 1.25.4-11 - Change can_resolv to allow tcp_socket name_connect to dns port. * Thu Aug 25 2005 Dan Walsh 1.25.4-10 - Bump for FC4 Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 Broken deps for ppc ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for i386 ---------------------------------------------------------- gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for s390 ---------------------------------------------------------- lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 initscripts - 8.12-2.s390 requires kernel >= 0:2.6.12 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 Broken deps for ppc64 ---------------------------------------------------------- system-config-mouse - 1.2.11-1.noarch requires pyxf86config ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 firstboot - 1.3.45-1.noarch requires system-config-display Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs From notting at redhat.com Tue Aug 30 17:23:19 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Aug 2005 13:23:19 -0400 Subject: rawhide eth0 not present In-Reply-To: <20050830143348.32532.qmail@web51508.mail.yahoo.com> References: <20050830143348.32532.qmail@web51508.mail.yahoo.com> Message-ID: <20050830172319.GB4427@nostromo.devel.redhat.com> Steve G (linux_4ever at yahoo.com) said: > I did, no real effect. And something keeps changing it to 8139cp. I also deleted > HWADDR out of ifcfg-eth0. Still, rawhide does not detect eth0 being present - > even though fc4 did. I tried a fc3 live CD and it properly inits the ethernet > card...so it seems we went backawards. Hm, can you attach /etc/sysconfig/hwconf? Bill From notting at redhat.com Tue Aug 30 18:04:17 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Aug 2005 14:04:17 -0400 Subject: rawhide eth0 not present In-Reply-To: <20050830172319.GB4427@nostromo.devel.redhat.com> References: <20050830143348.32532.qmail@web51508.mail.yahoo.com> <20050830172319.GB4427@nostromo.devel.redhat.com> Message-ID: <20050830180417.GA5304@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Steve G (linux_4ever at yahoo.com) said: > > I did, no real effect. And something keeps changing it to 8139cp. I also deleted > > HWADDR out of ifcfg-eth0. Still, rawhide does not detect eth0 being present - > > even though fc4 did. I tried a fc3 live CD and it properly inits the ethernet > > card...so it seems we went backawards. There's a fix for this in kudzu-1.1.122-1, in theory. Previously, there was code that switched 8139too to 8139cp if necessary; the new version has added code to do the reverse, as the probe that reads modules.pcimap might return 8139cp as the driver for 8139too cards. Bill From zuirdj at gmail.com Tue Aug 30 22:51:32 2005 From: zuirdj at gmail.com (Zuir DJ) Date: Tue, 30 Aug 2005 18:51:32 -0400 Subject: RFE: V4L2 support in pwlib Message-ID: I bugzilla it on April. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155317 Is it possible to include in FC5? Thanks Zuirdj From mharris at redhat.com Tue Aug 30 23:06:35 2005 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 30 Aug 2005 19:06:35 -0400 Subject: Request for volunteers to help track down packages that use /usr/X11R6 Message-ID: <4314E67B.1000304@redhat.com> Overview: ~~~~~~~~ The X.Org Foundation has finally changed X11 to install itself into the /usr heirarchy by default instead of the /usr/X11R6 hierarchy. The basic rationale is that with modern packaging systems like rpm, deb, etc., there is no need to isolate the X Window System into its own private hierarchy on the filesystem. Originally, the /usr/X11R6 directory was intended to strictly be the location where X11R6 itself would get installed. Over time however various other 3rd party software packages, addons and other stuff has infiltrated into the /usr/X11R6 heirarchy for no really good reason, and some of it still sits in there today. A year or two ago, I knew this change would be coming in the future, and sent out email to inform other package maintainers that they should update their packages to install their files in FHS compliant directories instead of abusing the /usr/X11R6 heirarchy. I'm not sure how many people actually listened though, so we're about to find out. ;o) What's changing specifically: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ X.Org X11 will no longer use the /usr/X11R6 directory hierarchy at all. It uses /usr, and installs files where you'd expect them to be found within that heirarchy more or less (although it is a bit buggy in this regard currently, that'll be fixed prior to X11R7's final release). The libraries, binaries, fonts, config files, data files - everything is moving. Along with this upstream X.Org change, there will be a number of backward compatibility issues that we'll face, where we may need to provide backward compatible symlinks for cases like applications hard coding the path to X binaries instead of using "which " and similar. We'll be keeping an eye on such issues and considering where we should provide compatibility links. What we'd like volunteers to help with: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1) A lot of existing Fedora Core, Fedora Extras and other 3rd party packages currently install themselves into /usr/X11R6, need to be updated to install themselves in a more appropriate location under /usr, using %{_datadir} and friends in their rpm specfiles. Volunteers are needed who are willing to take on the task of reporting bugs against the offending packages, and preferably also attaching patches to fix the rpms. 2) A number of packages might have shell scripts, .desktop files, or other things with hard coded paths to binaries such as /usr/X11R6/bin/xterm, or to data files, or other files traditionally installed under /usr/X11R6. Please report bugs against these packages, and where possible, change them to use "which " instead of hard coding the path to the executable/file directly. In some cases dynamic solution might not work, so hard code the new path in that case unless there's another appropriate solution apparent. 3) If you can personally think of any application or compat problems that might occur when the changeover is made, please report them to me via email in advance, so we can try to find a solution sooner than later. This message is being sent out to encourage community involvement in the process, and to help weed out problems sooner in the development cycle than later on, as there is likely to be a fair amount of package churn, so we'd like to get things in order far far in advance of FC5test1. Thanks in advance for any feedback, and also to any volunteers who decide to help out. From dragoran at feuerpokemon.de Wed Aug 31 07:08:54 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 31 Aug 2005 09:08:54 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <4314E67B.1000304@redhat.com> References: <4314E67B.1000304@redhat.com> Message-ID: <43155786.1020603@feuerpokemon.de> Mike A. Harris wrote: > Overview: > ~~~~~~~~ > The X.Org Foundation has finally changed X11 to install itself > into the /usr heirarchy by default instead of the /usr/X11R6 > hierarchy. The basic rationale is that with modern packaging > systems like rpm, deb, etc., there is no need to isolate the > X Window System into its own private hierarchy on the filesystem. > > Originally, the /usr/X11R6 directory was intended to strictly > be the location where X11R6 itself would get installed. Over > time however various other 3rd party software packages, addons > and other stuff has infiltrated into the /usr/X11R6 heirarchy > for no really good reason, and some of it still sits in there > today. > > A year or two ago, I knew this change would be coming in the > future, and sent out email to inform other package maintainers > that they should update their packages to install their files > in FHS compliant directories instead of abusing the /usr/X11R6 > heirarchy. I'm not sure how many people actually listened > though, so we're about to find out. ;o) > > > What's changing specifically: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > X.Org X11 will no longer use the /usr/X11R6 directory hierarchy > at all. It uses /usr, and installs files where you'd expect > them to be found within that heirarchy more or less (although > it is a bit buggy in this regard currently, that'll be fixed > prior to X11R7's final release). The libraries, binaries, > fonts, config files, data files - everything is moving. > > Along with this upstream X.Org change, there will be a number > of backward compatibility issues that we'll face, where we > may need to provide backward compatible symlinks for cases like > applications hard coding the path to X binaries instead of > using "which " and similar. We'll be keeping an > eye on such issues and considering where we should provide > compatibility links. > > > What we'd like volunteers to help with: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1) A lot of existing Fedora Core, Fedora Extras and other 3rd > party packages currently install themselves into /usr/X11R6, > need to be updated to install themselves in a more > appropriate location under /usr, using %{_datadir} and > friends in their rpm specfiles. Volunteers are needed who > are willing to take on the task of reporting bugs against > the offending packages, and preferably also attaching > patches to fix the rpms. > > 2) A number of packages might have shell scripts, .desktop > files, or other things with hard coded paths to binaries > such as /usr/X11R6/bin/xterm, or to data files, or other > files traditionally installed under /usr/X11R6. Please > report bugs against these packages, and where possible, > change them to use "which " instead of hard > coding the path to the executable/file directly. In some > cases dynamic solution might not work, so hard code the > new path in that case unless there's another appropriate > solution apparent. > > 3) If you can personally think of any application or compat > problems that might occur when the changeover is made, > please report them to me via email in advance, so we can > try to find a solution sooner than later. > > > This message is being sent out to encourage community > involvement in the process, and to help weed out problems > sooner in the development cycle than later on, as there > is likely to be a fair amount of package churn, so we'd > like to get things in order far far in advance of > FC5test1. > > Thanks in advance for any feedback, and also to any > volunteers who decide to help out. > some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which allready make problems on multilib systems) From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 31 08:05:35 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 31 Aug 2005 10:05:35 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <43155786.1020603@feuerpokemon.de> References: <4314E67B.1000304@redhat.com> <43155786.1020603@feuerpokemon.de> Message-ID: <20050831100535.7944d0ba@python2> dragoran wrote : > some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which > allready make problems on multilib systems) Indeed, that one will be a bit of a problem. Which brings an interesting question : Will the new X11R7 use pkgconfig? That would be nice, as replacing the above with "pkg-config --libs xorg-x11" should be easy, as well as modifying configure checks. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.36 0.36 0.26 From petro at mail.ru Wed Aug 31 14:00:56 2005 From: petro at mail.ru (Peter Lemenkov) Date: Wed, 31 Aug 2005 10:00:56 -0400 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <4314E67B.1000304@redhat.com> References: <4314E67B.1000304@redhat.com> Message-ID: On Tue, 30 Aug 2005, Mike A. Harris wrote: > Overview: > ~~~~~~~~ > The X.Org Foundation has finally changed X11 to install itself > into the /usr heirarchy by default instead of the /usr/X11R6 > hierarchy. The basic rationale is that with modern packaging > systems like rpm, deb, etc., there is no need to isolate the > X Window System into its own private hierarchy on the filesystem. > > Originally, the /usr/X11R6 directory was intended to strictly > be the location where X11R6 itself would get installed. Over > time however various other 3rd party software packages, addons > and other stuff has infiltrated into the /usr/X11R6 heirarchy > for no really good reason, and some of it still sits in there > today. # ln -s /usr /usr/X11R6 and forget about this problem... -- With best regards, Peter Lemenkov. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 31 10:08:23 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 31 Aug 2005 12:08:23 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: References: <4314E67B.1000304@redhat.com> Message-ID: <20050831120823.757893d0@python2> Peter Lemenkov wrote : > # ln -s /usr /usr/X11R6 > > and forget about this problem... Not sure how serious you're meaning to be, but it's worth pointing out that this is a typical complete blocker with rpm : Replacing a directory with a symlink is impossible, unless the directory is empty and some %pre scriplet takes care of removing it. Well, you've also got the option of "extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he should! ;-)). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.61 0.38 0.30 From ivazquez at ivazquez.net Wed Aug 31 10:24:01 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 31 Aug 2005 06:24:01 -0400 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <20050831120823.757893d0@python2> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> Message-ID: <1125483842.28096.44.camel@ignacio.lan> On Wed, 2005-08-31 at 12:08 +0200, Matthias Saou wrote: > Peter Lemenkov wrote : > > > # ln -s /usr /usr/X11R6 > > > > and forget about this problem... > > Not sure how serious you're meaning to be, but it's worth pointing out > that this is a typical complete blocker with rpm : Replacing a directory > with a symlink is impossible, unless the directory is empty and some %pre > scriplet takes care of removing it. Well, you've also got the option of > "extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he > should! ;-)). The only packages that own the dir are filesystem and (ugh) vnc-server. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 j.w.r.degoede at hhs.nl Wed Aug 31 10:35:35 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 31 Aug 2005 12:35:35 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <1125483842.28096.44.camel@ignacio.lan> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> Message-ID: <431587F7.6050601@hhs.nl> Ignacio Vazquez-Abrams wrote: > On Wed, 2005-08-31 at 12:08 +0200, Matthias Saou wrote: > >>Peter Lemenkov wrote : >> >> >>># ln -s /usr /usr/X11R6 >>> >>>and forget about this problem... >> >>Not sure how serious you're meaning to be, but it's worth pointing out >>that this is a typical complete blocker with rpm : Replacing a directory >>with a symlink is impossible, unless the directory is empty and some %pre >>scriplet takes care of removing it. Well, you've also got the option of >>"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he >>should! ;-)). > > > The only packages that own the dir are filesystem and (ugh) vnc-server. > > "(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the following output on my system: fonts-xorg-75dpi-6.8.2-1 fonts-xorg-base-6.8.2-1 fonts-xorg-truetype-6.8.2-1 multimedia-2.1-21 openmotif-2.2.3-10 playmidi-X11-2.4-16 xinitrc-4.0.19-1 xorg-x11-6.8.2-45 xorg-x11-Mesa-libGL-6.8.2-45 xorg-x11-Mesa-libGLU-6.8.2-45 xorg-x11-deprecated-libs-6.8.2-45 xorg-x11-devel-6.8.2-45 xorg-x11-font-utils-6.8.2-45 xorg-x11-libs-6.8.2-45 xorg-x11-tools-6.8.2-45 xorg-x11-xauth-6.8.2-45 xorg-x11-xdm-6.8.2-45 xorg-x11-xfs-6.8.2-45 xscreensaver-base-4.22-10 xterm-200-7 IOW: multimedia openmotif playmidi xscreensaver-base xterm Are the only non xorg packages on my system which use /use/X11R6 and thus need fixing. Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 31 10:44:19 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 31 Aug 2005 12:44:19 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <431587F7.6050601@hhs.nl> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> Message-ID: <20050831124419.30f02960@python2> Hans de Goede wrote : > IOW: > multimedia > openmotif > playmidi > xscreensaver-base > xterm > > Are the only non xorg packages on my system which use /use/X11R6 and > thus need fixing. I've got vim-X11 to add to the above :-) In the end, it's very little, I guess Mike's previous warning did get taken seriously ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.42 0.51 0.44 From rodd at clarkson.id.au Wed Aug 31 11:01:33 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 31 Aug 2005 21:01:33 +1000 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <431587F7.6050601@hhs.nl> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> Message-ID: <1125486093.2896.5.camel@localhost.localdomain> On Wed, 2005-08-31 at 12:35 +0200, Hans de Goede wrote: > "(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the > following output on my system: > fonts-xorg-75dpi-6.8.2-1 > fonts-xorg-base-6.8.2-1 > fonts-xorg-truetype-6.8.2-1 > multimedia-2.1-21 > openmotif-2.2.3-10 > playmidi-X11-2.4-16 > xinitrc-4.0.19-1 > xorg-x11-6.8.2-45 > xorg-x11-Mesa-libGL-6.8.2-45 > xorg-x11-Mesa-libGLU-6.8.2-45 > xorg-x11-deprecated-libs-6.8.2-45 > xorg-x11-devel-6.8.2-45 > xorg-x11-font-utils-6.8.2-45 > xorg-x11-libs-6.8.2-45 > xorg-x11-tools-6.8.2-45 > xorg-x11-xauth-6.8.2-45 > xorg-x11-xdm-6.8.2-45 > xorg-x11-xfs-6.8.2-45 > xscreensaver-base-4.22-10 > xterm-200-7 > > IOW: > multimedia > openmotif > playmidi > xscreensaver-base > xterm I get this: [rodd at localhost ~]$ (find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq fonts-xorg-100dpi-6.8.2-1 fonts-xorg-75dpi-6.8.2-1 fonts-xorg-base-6.8.2-1 linuxwacom-0.6.6-5 nvidia-glx-1.0.7174-0.lvn.4.4 nvidia-glx-devel-1.0.7174-0.lvn.4.4 openmotif-2.2.3-10 openmotif-devel-2.2.3-10 synaptics-0.14.3-3 vnc-server-4.1.1-16 Xaw3d-1.5E-4 Xaw3d-devel-1.5E-4 xinitrc-4.0.19-1 xorg-x11-6.8.2-45 xorg-x11-deprecated-libs-6.8.2-45 xorg-x11-deprecated-libs-devel-6.8.2-45 xorg-x11-devel-6.8.2-45 xorg-x11-font-utils-6.8.2-45 xorg-x11-libs-6.8.2-45 xorg-x11-Mesa-libGL-6.8.2-45 xorg-x11-Mesa-libGLU-6.8.2-45 xorg-x11-tools-6.8.2-45 xorg-x11-twm-6.8.2-45 xorg-x11-xauth-6.8.2-45 xorg-x11-xfs-6.8.2-45 xscreensaver-base-4.22-10 xterm-200-7 Don't know what this adds to the list. R. -- "It's a fine line between denial and faith. It's much better on my side" From fedora at camperquake.de Wed Aug 31 11:25:10 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 31 Aug 2005 13:25:10 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <1125486093.2896.5.camel@localhost.localdomain> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> <1125486093.2896.5.camel@localhost.localdomain> Message-ID: <20050831132510.6a0882b9@nausicaa.camperquake.de> Hi. Rodd Clarkson wrote: > Don't know what this adds to the list. fluxbox-0.9.13-2.fc5 gv-3.5.8-29 iiimf-x-12.2-6 kterm-6.2.0-40 libXvMCW-0.9.3-1.2.fc4 mtr-gtk-0.69-3 transfig-3.2.4-11 x3270-x11-3.3.4-3 xawtv-3.88-6 xfig-3.2.4-11 I think I got all duplicates posted so far out. -- "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 31 11:43:07 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 31 Aug 2005 13:43:07 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <1125486093.2896.5.camel@localhost.localdomain> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> <1125486093.2896.5.camel@localhost.localdomain> Message-ID: <20050831134307.3d0a4a75@python2> Rodd Clarkson wrote : > linuxwacom-0.6.6-5 > synaptics-0.14.3-3 > vnc-server-4.1.1-16 These packages (and probably some more), are making proper usage of /usr/X11R6 since they're actually installing extensions to the X server. I guess they will need to be modified only once the new location of the modules is known and working. I confirm that vnc-server does have a bug in the %files section though, since it owns /usr/X11R6 as pointed out already ;-) I've filed a bug report for vim-X11 : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167176 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 1.20 0.41 0.35 From bbbush.yuan at gmail.com Wed Aug 31 12:03:22 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Wed, 31 Aug 2005 20:03:22 +0800 Subject: rawhide report: 20050829 changes In-Reply-To: <200508291620.j7TGKX1l004364@porkchop.devel.redhat.com> References: <200508291620.j7TGKX1l004364@porkchop.devel.redhat.com> Message-ID: <76e72f80050831050366de8b70@mail.gmail.com> 2005/8/30, Build System : > > kernel-2.6.13-1.1526_FC5 > ------------------------ > * Sun Aug 28 2005 Dave Jones > - 2.6.13 final. > I cannot boot my computer after having it installed, don't know why :(. mkinitrd has updated to 4.2.21 using yum. It prompts "No volume group found" at boot, then after some other messages it goes panic. I cannot find a reason, what should I do? Thanks! -- bbbush ^_^ -------------- next part -------------- A non-text attachment was scrubbed... Name: panic.png Type: image/png Size: 27701 bytes Desc: not available URL: From kmaraas at broadpark.no Wed Aug 31 12:20:19 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Wed, 31 Aug 2005 14:20:19 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <20050831132510.6a0882b9@nausicaa.camperquake.de> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> <1125486093.2896.5.camel@localhost.localdomain> <20050831132510.6a0882b9@nausicaa.camperquake.de> Message-ID: <1125490819.2620.3.camel@localhost.localdomain> ons, 31,.08.2005 kl. 13.25 +0200, skrev Ralf Ertzinger: > Hi. > > Rodd Clarkson wrote: > > > Don't know what this adds to the list. > My additions are: nedit-5.5-4 Xaw3d-1.5E-4 Xaw3d-devel-1.5E-4 xloadimage-4.1-34.FC3 Cheers Kjartan From jspaleta at gmail.com Wed Aug 31 14:05:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 31 Aug 2005 10:05:55 -0400 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <1125490819.2620.3.camel@localhost.localdomain> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> <1125486093.2896.5.camel@localhost.localdomain> <20050831132510.6a0882b9@nausicaa.camperquake.de> <1125490819.2620.3.camel@localhost.localdomain> Message-ID: <604aa7910508310705486c3871@mail.gmail.com> On 8/31/05, Kjartan Maraas wrote: > My additions are: > > nedit-5.5-4 > Xaw3d-1.5E-4 > Xaw3d-devel-1.5E-4 > xloadimage-4.1-34.FC3 Checking the package scriptlets for items I have installed on my fc4 machine rpm -qa --qf "%{NAME}:\n%{POSTIN}\n\n" fonts-japanese urw-fonts as well as other packages already mentioned so far. rpm -qa --qf "%{NAME}:\n%{TRIGGERSCRIPTS}\n\n" freetype man Can repoquery be used to do this against all packages in the repos? -jef"the references to X11R6 in trigger scripts sort of scares me"spaleta From toshio at tiki-lounge.com Wed Aug 31 14:32:27 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 31 Aug 2005 07:32:27 -0700 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <604aa7910508310705486c3871@mail.gmail.com> References: <4314E67B.1000304@redhat.com> <20050831120823.757893d0@python2> <1125483842.28096.44.camel@ignacio.lan> <431587F7.6050601@hhs.nl> <1125486093.2896.5.camel@localhost.localdomain> <20050831132510.6a0882b9@nausicaa.camperquake.de> <1125490819.2620.3.camel@localhost.localdomain> <604aa7910508310705486c3871@mail.gmail.com> Message-ID: <1125498747.3266.101.camel@localhost> On Wed, 2005-08-31 at 10:05 -0400, Jeff Spaleta wrote: > On 8/31/05, Kjartan Maraas wrote: > > My additions are: > > > > nedit-5.5-4 > > Xaw3d-1.5E-4 > > Xaw3d-devel-1.5E-4 > > xloadimage-4.1-34.FC3 > > Checking the package scriptlets for items I have installed on my fc4 machine > rpm -qa --qf "%{NAME}:\n%{POSTIN}\n\n" > > fonts-japanese > urw-fonts > as well as other packages already mentioned so far. > > rpm -qa --qf "%{NAME}:\n%{TRIGGERSCRIPTS}\n\n" > freetype > man > > Can repoquery be used to do this against all pnckages in the repos? Has the metadata been changed to include the scriptlets? A quick scan of other.xml.gz from development seems to only show changelogs. So we won't be able to scan scriptlets through any of the yum functions. We could scan all spec files in FC and FE pretty easily to see what could be there. (Download the cvs daily seed from cvs.fedora.redhat.com then scan the spec files for /X11 references.) For Mike's #1 I posted a quick and dirty script last night that scanned filelists.xml.gz for files in /usr/X11* /usr/lib/X11* /usr/bin/X11/*. Posted it in a reply to Mike's maintainer-list post instead of here, oops. Too many mailing lists.... -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 czar at czarc.net Wed Aug 31 14:38:21 2005 From: czar at czarc.net (Gene C.) Date: Wed, 31 Aug 2005 10:38:21 -0400 Subject: bugzilla Message-ID: <200508311038.21647.czar@czarc.net> As new packages get added to Fedora Core and Fedora Extras, they are not always added to bugzilla. What is a "good" way to report these needed bugzilla updates? -- Gene From veillard at redhat.com Wed Aug 31 14:41:14 2005 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 31 Aug 2005 10:41:14 -0400 Subject: RFE: V4L2 support in pwlib In-Reply-To: References: Message-ID: <20050831144114.GJ10194@redhat.com> On Tue, Aug 30, 2005 at 06:51:32PM -0400, Zuir DJ wrote: > I bugzilla it on April. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155317 > > Is it possible to include in FC5? I just didn't recompiled it. I expect a new version of gnomemeeting within a month or so (with SIP support) and a large update of the associated libraries. If activating V4L2 doesn't break the build then yes I will switch it on at that point. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From sundaram at redhat.com Wed Aug 31 14:41:31 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 31 Aug 2005 20:11:31 +0530 Subject: bugzilla In-Reply-To: <200508311038.21647.czar@czarc.net> References: <200508311038.21647.czar@czarc.net> Message-ID: <4315C19B.6000407@redhat.com> Gene C. wrote: >As new packages get added to Fedora Core and Fedora Extras, they are not >always added to bugzilla. What is a "good" way to report these needed >bugzilla updates? > > They should be. If not choose "bugzilla" itself as a component and file them regards Rahul From czar at czarc.net Wed Aug 31 14:54:31 2005 From: czar at czarc.net (Gene C.) Date: Wed, 31 Aug 2005 10:54:31 -0400 Subject: bugzilla In-Reply-To: <4315C19B.6000407@redhat.com> References: <200508311038.21647.czar@czarc.net> <4315C19B.6000407@redhat.com> Message-ID: <200508311054.32022.czar@czarc.net> On Wednesday 31 August 2005 10:41, Rahul Sundaram wrote: > Gene C. wrote: > >As new packages get added to Fedora Core and Fedora Extras, they are not > >always added to bugzilla. ?What is a "good" way to report these needed > >bugzilla updates? > > ? > > They should be. If not choose "bugzilla" itself as a component and file > them A bit difficult ... "bugzilla" is not listed as a component under Fedora Extras. I could select "Bugzilla" as the product/category but the only more or less appropriate component looks like "inventory" and that is not used. While something under Fedora Infrastructure may be appropriate in this case, there should be something more obvious and applicable to all products/categories handled by this instantiation of bugzilla. -- Gene From sundaram at redhat.com Wed Aug 31 14:57:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 31 Aug 2005 20:27:47 +0530 Subject: bugzilla In-Reply-To: <200508311054.32022.czar@czarc.net> References: <200508311038.21647.czar@czarc.net> <4315C19B.6000407@redhat.com> <200508311054.32022.czar@czarc.net> Message-ID: <4315C56B.4020501@redhat.com> Gene C. wrote: >On Wednesday 31 August 2005 10:41, Rahul Sundaram wrote: > > >>Gene C. wrote: >> >> >>>As new packages get added to Fedora Core and Fedora Extras, they are not >>>always added to bugzilla. What is a "good" way to report these needed >>>bugzilla updates? >>> >>> >>> >>They should be. If not choose "bugzilla" itself as a component and file >>them >> >> > >A bit difficult ... "bugzilla" is not listed as a component under Fedora >Extras. I could select "Bugzilla" as the product/category but the only more >or less appropriate component looks like "inventory" and that is not used. > > Select Fedora Core -> Bugzilla >While something under Fedora Infrastructure may be appropriate in this case, >there should be something more obvious and applicable to all >products/categories handled by this instantiation of bugzilla. > > Generic FC bugs not classifed into any component should go against "distributions". regards Rahul From czar at czarc.net Wed Aug 31 15:04:52 2005 From: czar at czarc.net (Gene C.) Date: Wed, 31 Aug 2005 11:04:52 -0400 Subject: bugzilla In-Reply-To: <4315C56B.4020501@redhat.com> References: <200508311038.21647.czar@czarc.net> <200508311054.32022.czar@czarc.net> <4315C56B.4020501@redhat.com> Message-ID: <200508311104.52829.czar@czarc.net> On Wednesday 31 August 2005 10:57, Rahul Sundaram wrote: > >A bit difficult ... "bugzilla" is not listed as a component under Fedora > >Extras. ?I could select "Bugzilla" as the product/category but the only > > more or less appropriate component looks like "inventory" and that is not > > used. > > Select Fedora Core -> Bugzilla "bugzilla" as a component under "Fedora Core" does not exist! It appears that this has been rfe'ed a couple of times but never done. -- Gene From stickster at gmail.com Wed Aug 31 15:40:19 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 31 Aug 2005 11:40:19 -0400 Subject: bugzilla In-Reply-To: <200508311104.52829.czar@czarc.net> References: <200508311038.21647.czar@czarc.net> <200508311054.32022.czar@czarc.net> <4315C56B.4020501@redhat.com> <200508311104.52829.czar@czarc.net> Message-ID: <1125502819.2978.4.camel@localhost.localdomain> On Wed, 2005-08-31 at 11:04 -0400, Gene C. wrote: > On Wednesday 31 August 2005 10:57, Rahul Sundaram wrote: > > >A bit difficult ... "bugzilla" is not listed as a component under Fedora > > >Extras. I could select "Bugzilla" as the product/category but the only > > > more or less appropriate component looks like "inventory" and that is not > > > used. > > > > Select Fedora Core -> Bugzilla > > "bugzilla" as a component under "Fedora Core" does not exist! > > It appears that this has been rfe'ed a couple of times but never done. If you want to file a bug against the RH Bugzilla itself, use the Product "Bugzilla," instead of "Fedora Core." Do this if you are sure you have exhausted the current protocols for getting components listed in the "Fedora Extras" product. I thought the owners list in CVS might do this, but could be wrong. -- 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 jwboyer at jdub.homelinux.org Wed Aug 31 16:42:56 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 31 Aug 2005 11:42:56 -0500 Subject: bugzilla In-Reply-To: <1125502819.2978.4.camel@localhost.localdomain> References: <200508311038.21647.czar@czarc.net> <200508311054.32022.czar@czarc.net> <4315C56B.4020501@redhat.com> <200508311104.52829.czar@czarc.net> <1125502819.2978.4.camel@localhost.localdomain> Message-ID: <1125506576.14270.11.camel@windu.rchland.ibm.com> On Wed, 2005-08-31 at 11:40 -0400, Paul W. Frields wrote: > On Wed, 2005-08-31 at 11:04 -0400, Gene C. wrote: > > > Select Fedora Core -> Bugzilla > > > > "bugzilla" as a component under "Fedora Core" does not exist! > > > > It appears that this has been rfe'ed a couple of times but never done. > > If you want to file a bug against the RH Bugzilla itself, use the > Product "Bugzilla," instead of "Fedora Core." Do this if you are sure > you have exhausted the current protocols for getting components listed > in the "Fedora Extras" product. I thought the owners list in CVS might > do this, but could be wrong. It does. But it's still a manual process that the maintainers need to do when they import their packages. If people forget, then no bugzilla component gets created. josh From stickster at gmail.com Wed Aug 31 17:03:40 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 31 Aug 2005 13:03:40 -0400 Subject: bugzilla In-Reply-To: <1125506576.14270.11.camel@windu.rchland.ibm.com> References: <200508311038.21647.czar@czarc.net> <200508311054.32022.czar@czarc.net> <4315C56B.4020501@redhat.com> <200508311104.52829.czar@czarc.net> <1125502819.2978.4.camel@localhost.localdomain> <1125506576.14270.11.camel@windu.rchland.ibm.com> Message-ID: <1125507821.2978.5.camel@localhost.localdomain> On Wed, 2005-08-31 at 11:42 -0500, Josh Boyer wrote: > On Wed, 2005-08-31 at 11:40 -0400, Paul W. Frields wrote: > > On Wed, 2005-08-31 at 11:04 -0400, Gene C. wrote: > > > > Select Fedora Core -> Bugzilla > > > > > > "bugzilla" as a component under "Fedora Core" does not exist! > > > > > > It appears that this has been rfe'ed a couple of times but never done. > > > > If you want to file a bug against the RH Bugzilla itself, use the > > Product "Bugzilla," instead of "Fedora Core." Do this if you are sure > > you have exhausted the current protocols for getting components listed > > in the "Fedora Extras" product. I thought the owners list in CVS might > > do this, but could be wrong. > > It does. But it's still a manual process that the maintainers need to > do when they import their packages. If people forget, then no bugzilla > component gets created. My point exactly, thank you for making it more clearly! -- 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 James_Martin at ao.uscourts.gov Wed Aug 31 18:40:13 2005 From: James_Martin at ao.uscourts.gov (James_Martin at ao.uscourts.gov) Date: Wed, 31 Aug 2005 14:40:13 -0400 Subject: make kudzu stop prompting Message-ID: I'm interested in making a Fedora Live CD, but I've noticed with all the Fedora based Live CD's, kudzu prompts the user if hardware was added/removed and the normal "Keep Configuration" "Do Nothing" prompts. I'd like to add a switch to kudzu that would automatically handle the addition/removal of hardware without any prompts. I know kudzu already has a "quiet" switch, but the manpage states that it is only for supressing dialogs that do not require user input. Anyone worked on this already ? Thanks, James James S. Martin, RHCE Contractor Administrative Office of the United States Courts Washington, DC (202) 502-2394 From ivazquez at ivazquez.net Wed Aug 31 19:14:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 31 Aug 2005 15:14:35 -0400 Subject: make kudzu stop prompting In-Reply-To: References: Message-ID: <1125515675.28096.46.camel@ignacio.lan> On Wed, 2005-08-31 at 14:40 -0400, James_Martin at ao.uscourts.gov wrote: > I'm interested in making a Fedora Live CD, but I've noticed with all the > Fedora based Live CD's, kudzu prompts the user if hardware was > added/removed and the normal "Keep Configuration" "Do Nothing" prompts. > I'd like to add a switch to kudzu that would automatically handle the > addition/removal of hardware without any prompts. I know kudzu already > has a "quiet" switch, but the manpage states that it is only for > supressing dialogs that do not require user input. Anyone worked on this > already ? kudzu hasn't prompted since FC2 or FC3 AFAIK. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Aug 31 19:16:05 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 31 Aug 2005 15:16:05 -0400 Subject: make kudzu stop prompting In-Reply-To: References: Message-ID: <20050831191605.GA9383@nostromo.devel.redhat.com> James_Martin at ao.uscourts.gov (James_Martin at ao.uscourts.gov) said: > I'm interested in making a Fedora Live CD, but I've noticed with all the > Fedora based Live CD's, kudzu prompts the user if hardware was > added/removed and the normal "Keep Configuration" "Do Nothing" prompts. > I'd like to add a switch to kudzu that would automatically handle the > addition/removal of hardware without any prompts. I know kudzu already > has a "quiet" switch, but the manpage states that it is only for > supressing dialogs that do not require user input. Anyone worked on this > already ? '-q' will work. Alternatively, use FC4. :) Bill From zuirdj at gmail.com Wed Aug 31 19:17:26 2005 From: zuirdj at gmail.com (Zuir DJ) Date: Wed, 31 Aug 2005 15:17:26 -0400 Subject: RFE: V4L2 support in pwlib In-Reply-To: <20050831144114.GJ10194@redhat.com> References: <20050831144114.GJ10194@redhat.com> Message-ID: On 8/31/05, Daniel Veillard wrote: > On Tue, Aug 30, 2005 at 06:51:32PM -0400, Zuir DJ wrote: > > I bugzilla it on April. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155317 > > > > Is it possible to include in FC5? > > I just didn't recompiled it. I expect a new version of gnomemeeting > within a month or so (with SIP support) and a large update of the > associated libraries. If activating V4L2 doesn't break the build then > yes I will switch it on at that point. Thank you, Daniel! Zuirdj From linux_4ever at yahoo.com Wed Aug 31 19:19:32 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 31 Aug 2005 12:19:32 -0700 (PDT) Subject: rawhide eth0 not present In-Reply-To: <20050830180417.GA5304@nostromo.devel.redhat.com> Message-ID: <20050831191932.97745.qmail@web51508.mail.yahoo.com> >There's a fix for this in kudzu-1.1.122-1, in theory. Thanks. It boots OK now and eth0 is working properly. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From buildsys at redhat.com Wed Aug 31 19:20:49 2005 From: buildsys at redhat.com (Build System) Date: Wed, 31 Aug 2005 15:20:49 -0400 Subject: rawhide report: 20050831 changes Message-ID: <200508311920.j7VJKnZp018425@porkchop.devel.redhat.com> Updated Packages: cyrus-sasl-2.1.21-3 ------------------- * Tue Aug 30 2005 Nalin Dahyabhai 2.1.21-3 - correct a use of uninitialized memory in the bundled libdb (Arjan van de Ven) evolution-data-server-1.3.8-5 ----------------------------- * Tue Aug 30 2005 David Malcolm - 1.3.8-5 - Add -Werror-implicit-function-declaration back to CFLAGS at the make stage, after the configure, to spot 64-bit problems whilst avoiding breaking configuration tests; expand patch 102 to avoid this breaking libdb's CFLAGS ftp-0.17-29 ----------- * Tue Aug 30 2005 Petr Raszyk - 0.17-29 * Tue Aug 30 2005 Petr Raszyk - 0.17-28 - This 'hack' will avoid a bug in ftp-server ( < vsftpd-2.0.1-5 ). See #165083 (server prints the '150 FILE:...' line twice). This patch can be (later ?) removed. * Mon Aug 22 2005 Petr Raszyk - 0.17-27 - overflow using 'hash mode' (printing '#' but not reading data from network - #79367) * Tue May 24 2005 Miloslav Trmac - 0.17-26 - Fix passive mode with SELinux (#158234, patch by Nalin Dahyabhai) - Fix format string mismatch gdm-1:2.8.0.2-3 --------------- * Tue Aug 30 2005 Ray Strode 1:2.8.0.2-3 - Prune language list of installed languages - Make config file noreplace again (bug 167087). hal-0.5.4-3 ----------- * Tue Aug 30 2005 David Zeuthen - 0.5.4-3 - Rebuild * Tue Aug 30 2005 David Zeuthen - 0.5.4-2 - Pull in cryptsetup-luks and fix some unpackaged files * Tue Aug 30 2005 David Zeuthen - 0.5.4-1 - Update to upstream release 0.5.4 and drop patches already upstream initscripts-8.12-3 ------------------ * Tue Aug 30 2005 Bill Nottingham 8.12-3 - rebuild against fixed kudzu (#157783) java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_45rh ------------------------------------------ * Tue Aug 30 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_45rh - Import java-gcj-compat 1.0.39. - Remove libjawt.so symlinks. - Symlink to jni_md.h. * Tue Aug 30 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_44rh - Install ecj when building a custom java-1.4.2-gcj-compat. - Fix removal of jaxp_parser_impl.jar alternative. * Mon Aug 29 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_44rh - Import java-gcj-compat 1.0.37. - Remove aot-compile and find-and-aot-compile. - Make aot-compile-rpm and rebuild-gcj-db alternatives symlinks. - Mark security file config(noreplace). kdepim-6:3.4.2-3 ---------------- * Tue Aug 30 2005 Than Ngo 6:3.4.2-3 - rebuilt kernel-2.6.13-1.1529_FC5 ------------------------ * Tue Aug 30 2005 Dave Jones - 2.6.13-git1 kudzu-1.1.122-1 --------------- * Tue Aug 30 2005 Bill Nottingham 1.1.122-1 - don't rely on pcimap for 8139too/8139cp; hardcode the logic (#157783) nss_db-2.2-33 ------------- * Tue Aug 30 2005 Nalin Dahyabhai 2.2-33 - update to db 4.3.28 - correct a use of uninitialized memory in the bundled libdb (Arjan van de Ven) - obsolete the compat package, which is useless because current glibc wouldn't use it anyway * Tue Apr 26 2005 Nalin Dahyabhai - set errno to ENOENT by default so that we don't leave stale errno values around in error cases (#152467) - clear the entire key DBT before handing it to a get() function * Tue Mar 29 2005 Nalin Dahyabhai 2.2-32 - set errno to ENOENT when returning NSS_STATUS_NOTFOUND (#152467, Dave Lehman) parted-1.6.24-1 --------------- * Tue Aug 30 2005 Chris Lumens 1.6.24-1 - Updated to 1.6.24. pilot-link-1:0.12.0-0.pre4.5 ---------------------------- * Tue Aug 30 2005 Than Ngo 0.12.0-0.pre4.5 - pre5 cvs snapshots - remove several patches which included new upstream squid-7:2.5.STABLE10-3 ---------------------- * Tue Aug 30 2005 Martin Stransky 7:2.5.STABLE10-3 - removed "--enable-truncate" option (#165948) - added "--enable-cache-digests" option (#102134) - added "--enable-ident-lookups" option (#161640) - some clean up (#165949) xterm-200-8 ----------- * Mon Aug 29 2005 Mike A. Harris 200-8 - Added --disable-tek4014 to ./configure flags, to disable tek support for bug (#164210) Broken deps for i386 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i586 requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU pyparted - 1.6.9-3.i386 requires libparted-1.6.so.12 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.i586 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-smp = 0:2.6.12-1.1398_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.10.i686 requires kernel-xen0 = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.9.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires kernel-xenU = 0:2.6.12-1.1398_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.43.i686 requires /lib/modules/2.6.12-1.1398_FC4xenU Broken deps for x86_64 ---------------------------------------------------------- pyparted - 1.6.9-3.x86_64 requires libparted-1.6.so.12()(64bit) GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.10.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.43.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires /lib/modules/2.6.12-1.1398_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.9.x86_64 requires kernel-smp = 0:2.6.12-1.1398_FC4 valgrind-callgrind - 0.9.11-1.i386 requires valgrind = 1:2.4.0 Broken deps for s390 ---------------------------------------------------------- pyparted - 1.6.9-3.s390 requires libparted-1.6.so.12 prelink - 0.3.5-2.s390 requires kernel >= 0:2.4.10 initscripts - 8.12-3.s390 requires kernel >= 0:2.6.12 lvm2 - 2.01.14-1.0.s390 requires kernel >= 0:2.6 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs pyparted - 1.6.9-3.ia64 requires libparted-1.6.so.12()(64bit) Broken deps for ppc ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc requires /lib/modules/2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires kernel = 0:2.6.12-1.1398_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.9.ppc requires /lib/modules/2.6.12-1.1398_FC4 pyparted - 1.6.9-3.ppc requires libparted-1.6.so.12 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for ppc64 ---------------------------------------------------------- cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.9.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config evolution-webcal - 1.0.10-1.ppc64 requires libsoup-2.2.so.7()(64bit) ppc64-utils - 0.7-9.ppc64 requires yaboot evolution-data-server - 1.0.4-3.ppc64 requires libgnutls.so.11()(64bit) evolution-data-server - 1.0.4-3.ppc64 requires libsoup-2.2.so.7()(64bit) pyparted - 1.6.9-3.ppc64 requires libparted-1.6.so.12()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config firstboot - 1.3.45-1.noarch requires system-config-display dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.10.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires kernel = 0:2.6.12-1.1398_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.43.ppc64 requires /lib/modules/2.6.12-1.1398_FC4 Broken deps for s390x ---------------------------------------------------------- pyparted - 1.6.9-3.s390x requires libparted-1.6.so.12()(64bit)